[ntp:questions] Re: server's address in ntp payload?
brian.utterback at sun.removeme.com
Fri Nov 18 13:29:50 UTC 2005
Danny Mayer wrote:
> No it is not a flaw in the protocol design. It would be if it were put
> in. The address doesn't belong there, it belongs in the IP header which
> the receiving server always gets.
I agree that the IP address should not be in the NTP header. I do not
know what should be there, just that something should be that acts as
an authentication token of some sort. Almost all other UDP based
protocols include either a token that identifies the system or the
transaction. The ability to send the UDP packet back with the required
IP address on a multihomed host is not even guaranteed, since such
an ability is only in the SHOULD category and is not in the MUST
category in RFC 1123.
>>been the case that it is easy to get the address from whence a UDP
>>was sent, but there is no portable way to determine to where it was
> You can use sendmsg/recvmsg to do this but it's not implemented on all
> platforms and I declined to work all the issues necessary to use it.
Precisely. There is no portable way to get the IP destination. Why do
you think that is? It's because no reasonable application that is not
dealing in network control itself should need need to know it.
>>This has led to the super-kludge of binding to all IP addresses
>>on the system as being the best of a bad lot.
> Not at all. There are a number of reasons to bind all of the IP
> addresses individually. It's true in BIND too. In NTP it's even more
> important to bind all addresses since that means another application
> cannot be using the NTP port. You don't want another application setting
> the clock or sending out its own spurious packets.
I do not know why BIND does it, but my guess is that it needs
to know what interface a packet arrived on. The whole "grab it
so nobody else can" thing is pretty bogus. It is a complete non-issue
on any UNIX based system. I know you deal with the Windows port,
and I couldn't say what the ramifications on that platform might
be, even there, having an auth token in the NTP header would solve
the problem without binding to all the interfaces.
> You MUST guarantee
> that you return packets ONLY on the same address that the requester
> packet was sent to, you must do authentication using only one address
> and only accept packets between those two addresses that you can
> validate once you have an agreed-upon authentication.
That is my whole point. It is only because you rely on the IP address
for authentication that you have all of these "MUST" requirements. That
is the flaw.
"Having them stolen may become our distribution model..."
Nicolas Negroponte on the Hundred Dollar Laptop.
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
More information about the questions