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

Danny Mayer mayer at ntp.isc.org
Sat Nov 26 21:46:36 UTC 2005

Brian Utterback wrote:
> David Schwartz wrote:
>>     I think if you can make the argument that the source address
>> doesn't have to match the destination of the query, you can equally
>> well argue that the destination address doesn't have to match the
>> source of the query. ;)
>>     Or, to put it another way, as soon as you layer a request/reply
>> protocol on top of UDP, the default presumption would be that the
>> reply MUST have the same source as the query's destination and
>> vice-versa.
> Completely false. Neither RFC 1123 "Requirements for Internet Hosts"
> nor RFC 768 "User Datagram Protocol" make any such requirement. RFC 1123
> does say that a UDP "SHOULD" be returned with the same source address
> as the original destination address, but explicitly does not make that
> a "MUST". Further, description of the API for use with UDP in RFC 768
> lists the ability to determine the source address of a packet, but does
> not list any such ability for the destination, which would be necessary
> to accomplish this. The fact that this ability was not listed
> and indeed not included in any UDP API until relatively recently should
> tell you something about the requirement.
> As I have said before, most UDP protocols are designed to handle this
> problem. Only UDP protocols that deal with network control and topology
> generally have cared about the destination address. The system I am
> using has 356 listening UDP ports open right now, and exactly
> 3 of those have bound all the interfaces: bootps, snmp, and NTP.  Every
> one of the others either does not care or has another mechanism for
> handling it, like XIDs. The bootps/DHCP and SNMP need to know the
> destination address in order  for them to respond with the proper
> answers, which is to say the answer is different depending on the
> destination address of the request. What is NTP's excuse?

NTP doesn't need an excuse. NTP needs to be careful to ensure that only
one process is modifying the system's clock. Not to do so would result
in clock instability.

I noticed that you didn't mention DNS. None of the mentioned protocols
have a need to worry about other processes doing something on the
system. It's not true of NTP.

> I would further point out that none of these are bound to all addresses
> in order to prevent port hijacking.

None of them have to worry about more than one process taking actions
which could cause problems with the system.


More information about the questions mailing list