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

Danny Mayer mayer at gis.net
Sun Nov 20 03:03:34 UTC 2005

Brian Utterback wrote:
> 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.

That's the MAC in the NTP packet.

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

That has nothing to do with it. If you get a packet arriving from a
different address you should assume it's a different server and will be
considered unauthenticated until the authentication is established.

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

It's done in BIND 9, but it would be a challenge in NTP and much more
difficult than rewriting the interface code.

>>> This has led to the super-kludge of binding to all IP addresses
>>> on the system as being the best of a bad lot.

No, that has nothing to do with it. The binding of all IP addresses is
deliberate and has to do with security and to prevent other applications
binding to the NTP port.

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

No it isn't bogus and is definitely not a non-issue on any Unix based
system. Windows is no different. You ignore the MAC header.

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

No, you must assume it's a different system sending the packet any other
address and must authenticate again.


More information about the questions mailing list