[ntp:questions] Re: server's address in ntp payload?

David Schwartz davids at webmaster.com
Sat Nov 26 03:47:12 UTC 2005

<brian.utterback at sun.com> wrote in message 
news:1132805341.941207.242150 at f14g2000cwb.googlegroups.com...

> The hosts requirements RFC could have said that the responses MUST
> go back on the same address, but it did not.

    No, it could not have said that. That would have meant that *no* UDP 
query/response protocol could ever permit a reply to be sent from a 
different address, which would be nonsensical. So what it does, sensibly, is 
say that it SHOULD go back on the same address, which means that there has 
to be a damned good reason (such as the more detailed protocol saying so) 
for it to be different.

> The UDP RFC could also
> have made this requirement, but it didn't.

    Again, no it could not. It would be nonsensical for the UDP protocol to 
impose such a requirement on any protocol that might use it. There's no way 
you can do that. All it could do is say that matching the IP is what you 
should do, unless there's some good reason not to. There is no way it could 
enumerate what the criteria or reasons would be because it's too general an 
RFC to get into those kinds of specifics.

> The description of the user
> interface in the UDP RFC could have specified a way to get the
> destination
> address, but it didn't.

    What description? Where? I don't know what you're talking about.

> I prefer to think that the orginal designers of
> these
> protocols and API's gave these issues some thought and decided that
> they were not needed, rather than to think that they all got it wrong.

    I don't know why you think I have issues with protocols and API. I do 
not. I do, on the other hand, have issues with broken *implementations* of 
protocols and *users* of APIs.

>>     And that's not a kernel defect because ... ?

> Broken by design? Seriously, it clearly seems to be the case that
> reading
> the destination address was thought unnecessary. And it apppears that
> this thought was largely correct.

    Then how can you comply with the SHOULD in the UDP RFC? You understand 
that 'SHOULD' means that you can do otherwise only if you have a damned good 
reason. An API that makes it difficult for protocols to comply with a 
'SHOULD' in an RFC is defecient.

>>     Because it's always visible to the application. When I send you a UDP
>> datagram, I know what address I'm sending it too, and if you need that 
>> for
>> some reason (say, to reply from the same address), then I can put it in 
>> the
>> payload. Which gets us back to the subject ... If you're right that it's
>> okay for kernels not to provide this information, it's only because the
>> sender has the information and can put it in the payload if it's needed.

> Yes, the server application needs to know the source address in order
> to
> send a reply. That is why the ability to get the source address of a
> packet was specified in the UDP RFC and has been in the API since it
> was first implemented.

    And the client application needs to know the destination address in 
order to send a query. Thus both IP addresses are already visible at 
application level. Thus, no layering violation.

>>     Right, so NTP is flawed because it does not put the IP address in the
>> payload, thus requiring you to get it from the kernel if you need it. (I
>> don't agree with your premises, but they lead inexorably to this
>> conclusion.)

> Perhaps. My point is that you might need the IP address, or maybe a
> XID is better. Or a unique system ID. Or whatever. I think that your
> original problem (identifying duplicate servers) is better served by a
> unique system ID than an IP address.

    I don't disagree. That's why the RFC says SHOULD rather than MUST.

>> > My point is that the destination is not always readily visible from the
>> > application
>> > level.  And I do not think that this is a bad design, just not
>> > necessarily intuitively
>> > obvious.
>>     What? How can you send a UDP datagram without knowing what address
>> you're sending it to? And when you receive it, you are always told the
>> sender's address. So both the source and destination address of a UDP
>> datagram are visible from application level. There are *no* layering
>> violations here.

> The client knows what host it is sending it to, because it is
> originating the packet.
> The client process probably does not know what the source address of
> that packet
> is going to be, and probably doesn't care. The server that receives the
> packet
> knows what the source address is, because that info has always been
> made
> readily available, since you need it to send the reply, as you noted.
> However,
> the server process doesn't usually know or care what the destination
> address
> was. Likewise, when the reply packet is sent, it will set the
> destination to match
> the orginal source address, but will generally not know or care what
> the reply
> packet's source address will be. This is how most UDP protocols work.

    The point is that both IP addresses are always visible at application 

> I just question the need that NTP has to place the further restriction
> that the
> reply packet source address must match the request packet's destinaton
> address.

    It doesn't have to, provided it gives you some other way to get the 
functionality you lose by not having this. That's why the RFC says 'SHOULD', 
not 'MUST'. But to ignore a SHOULD in an RFC without understanding the 
rationale behind the SHOULD and providing some other way to accomplish what 
the SHOULD is trying to do is reckless.

> Maybe it is legitimate, but be careful of chicken and egg reasoning
> here. We know
> that the crypto ID functions have this requirement, but is it a
> legitimate requirement?
> By that I mean, could it have been done another way, but used IP
> addresses
> because nobody thought about the possibility that the IP addresses
> might
> not match?

    I think using the IP addresses in the crypto code is pretty bone-headed 
anyway, assuming you rely on it in any way. You should use a public key 
identifier, not an IP address. Using it as quick 'which endpoint *might* I 
be talking to' or '*might* this be from the same host I was talking to 
before' is fine. But you should never rely on it.

>> > It is the same here. It was clearly a design goal of UDP protocols not
>> > to have the requirement.

>>     Huh? It may be a design goal of UDP, but every request/response 
>> protocol
>> layered over UDP has its own design requirements. UDP always makes both
>> addresses visible at application level.

> Not to the same application. The ability to get the destination address
> of a
> received packet is a recent addition to the API and is not by any means
> universal.  See
> http://www.cs.helsinki.fi/linux/linux-kernel/2001-28/0744.html for
> a discussion of the most portable way to get the destination address of
> a
> received UDP packet.

    Which application it makes it visible to is irrelevent, the applications 
are talking to each other. Anything visible to application A is visible to 
application B if they are exchanging datagrams.

>>     They are not changing the way UDP works. That's absurd.

> Perhaps that isn't exactly the right phrase. Placing expectations on
> the
> UDP protocol that it is not designed to fulfill, and then designing a
> protocol
> based on those expectations, and then changing the API and otherwise
> jumping through hoops so as to enforce those expectations, that is what
> I am talking about.

    Then why do you think the RFC sets out matching addresses as the default 
for query/response protocols layered on top of UDP? What is your explanation 
for the SHOULD in the RFC? (Which is the strongest possible way they could 
have said it without mandating it absolutely for all UDP query/response 

> This isn't really what I wanted to discuss. The bottom line is that UDP
> does
> not have the requirement that the addresses match. The application can
> conform to that requirement if we want it to, but not without some pain
> and
> suffering. The real questions I have are:

    But it does. That's what 'SHOULD' mean, you have to do it unless you 
have a damned good reason not to. Again, 'SHOULD' means:

   there may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

    Notice it says the full implications must be understood before choosing 
a different course?


More information about the questions mailing list