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" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
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
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
