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

brian.utterback at sun.com brian.utterback at sun.com
Thu Nov 24 04:09:01 UTC 2005

David Schwartz wrote:

>     This is a nonsensical argument. Kernls *do* in fact do this when they
> provide the UDP based services. They *can't* enforce it for applications
> that provide a service because that is functionality that would have to be
> in the kernel.

I never said that matching the addresses shouldn't be done. If the
kernel is
providing remote UDP services, by all means it should make every effort
to match the addresses.

The hosts requirements RFC could have said that the responses MUST
go back on the same address, but it did not. The UDP RFC could also
have made this requirement, but it didn't. The description of the user
interface in the UDP RFC could have specified a way to get the
address, but it didn't. I prefer to think that the orginal designers of
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.

That's just me, though. I would be happy to listen if one of people
forward and said that it was a big mistake and explain what they were
thinking and why it turned out to be wrong. I think it was Kernighan
said that if he had it to do over again, he would have left the "e" on
"creat" call.

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

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

>     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
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.

>     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.

> > 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
knows what the source address is, because that info has always been
readily available, since you need it to send the reply, as you noted.
the server process doesn't usually know or care what the destination
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.

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
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
because nobody thought about the possibility that the IP addresses
not match?

> > 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
received UDP packet.

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

Perhaps that isn't exactly the right phrase. Placing expectations on
UDP protocol that it is not designed to fulfill, and then designing a
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.

This isn't really what I wanted to discuss. The bottom line is that UDP
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
suffering. The real questions I have are:

1. Does the NTP protocol (modulo the crypto extensions) really require
the addresses match?
2. If it does, is that a flaw, or is it a fundemental result of the
design goals
of NTP?
3. If it is a flaw in the NTP protocol, how could it be repaired?
4. Can the crypto functions be made to work given the answer to
question 3?

Don't get me wrong. I love NTP. It is a master work, and I cannot say
how much I respect the time, effort and innovations that went into its
(Hi, Dave!) But as brilliant as Dr. Mills is, is it not outside the
realm of
possibiltiy that with hindsight, we might not see ways to improve the


More information about the questions mailing list