[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
> UDP
> 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
level.
> 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
protocols.)
> 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?
DS
More information about the questions
mailing list