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

David L. Mills mills at udel.edu
Thu Nov 24 04:25:43 UTC 2005


Guys,

I'm answering Danny's message only because it is short. Bear in mind:

1. The protocol design originated over 25 years ago. There are estimates 
of over 25 million clients on the planet now. Changing the IPv4 refid 
compatibility is simply not in the cards. Certainly it is possible to 
accidently configure two associations with the same server and I have 
done that for test. It may be duplicative, but it is not fatal and does 
not impair good timekeeping.

2. I believe nobody has noticed that NTPv4 autokey extension fields 
contain the association ID of the client, which is returned by the 
server and of course is a transaction ID. If this isn't enough, define a 
new extension field for the purpose.

3. The transmit timestamp is in fact a very good transaction ID, as the 
unused low-order bits are filled with a random bitstring and the 
resulting timestamp is essentially unguessable. It is in fact used as 
the transaction ID to set up manycast client asssociations and has the 
advantage to be useful without autokey. It should include enough bits to 
defy cryptanalysis, yet not require a packet format change. When network 
delays approach 232 picoseconds, this should be reviewed.

4. By design the session key is a hash of some public and some private 
information. When it was designed over ten years ago the intent was to 
nab IP address hijackers, so I included the addresses in the hash. 
Doing without the addresses would be possible, but the resulting session 
key would be cryptographically weak.

5. I am very concerned about rogue broadcasters, which is why the 
broadcaster association ID is included in the extension field and is in 
fact used as a transaction ID. It is possible to do without the IP 
addresses, since the session key is bound by the reverse hash to a 
signature, but the reverse hash itself would be only 64 bits and that 
would ordinarily be considered cryptoanalyzeable.

6. My original and still viable plan was to provide an alternate mode 
where the cookie portion of the session key could be expanded and the IP 
addresses dropped. The cookie already is sliced from a 128-bit hash, so 
this may not be as hard as it looks. However, to avoid using the IP 
addresses, ports and version number for association matching is much 
harder to change.

Dave

Danny Mayer wrote:
> David Schwartz wrote:
> 
>>"Danny Mayer" <mayer at ntp.isc.org> wrote in message 
>>news:43837586.5000403 at ntp.isc.org...
>>
>>
>>
>>>David Schwartz wrote:
>>
>>
>>>>   That's nice but has nothing to do with how you tell whether two 
>>>>packets
>>>>with different source UDP addresses came from the same server or not.
>>
>>
>>>>   Consider a simple case. We have a simple server that is not using
>>>>authentication. It's on a LAN where a lot of machines have both public 
>>>>and
>>>>private IP addresses. We recognize our local and internal LANs by their 
>>>>IP
>>>>range and don't need to authenticate because spoof protection is done at 
>>>>the
>>>>boundaries. We are talking to both 192.168.32.23 and 216.105.54.22, the
>>>>question is, are they the same machine or not?
>>
>>
>>>You cannot tell from the outside, nor should you usually care.
>>
>>
>>    You should care. If you think they're two different servers, you may 
>>give the time data double the weight it really should get.
>>
> 
> 
> If you give more weight to one address over the other then you should
> care that it gets sent from the right address and that's what we make
> sure we do. So I don't understand your objections.
> 
> 
>>    I have seen NTP sync to the same server twice on two different IP 
>>addresses. So if there is a unique identifier that NTP could use to ignore 
>>duplicates, it doesn't use it as far as I've seen.
>>
> 
> 
> That's because of a defect in the implementation of Refids in the
> current code. Refids should be the same for all packets sent by the same
> server no matter what IP address it uses. I intend to fix that in the
> near future where the server will use one and only one refid and it
> won't necessarily be based on an IPv4 address. That's a problem with the
> specific implementation and not the protocol. One example of this is
> that an IPv4 address and an IPv6 address on the same interface will give
> you different refids.
> 
> Danny
> 
>>    DS
>>
>>
>>_______________________________________________
>>questions mailing list
>>questions at lists.ntp.isc.org
>>https://lists.ntp.isc.org/mailman/listinfo/questions
>>
> 
> 
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 




More information about the questions mailing list