[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