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

Brian Utterback brian.utterback at sun.removeme.com
Mon Nov 28 18:12:10 UTC 2005

David L. Mills wrote:
> 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.

I am not sure how refids got into this. I think Danny suggested them
as an existing server ID, which of course, they are not. At best they
are the server's server's ID.

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

Well, a server ID. If it were a transaction ID it would have to change
on each transaction. However, this just shows the desirability of having
a server ID field. My claim is that it would be useful in the base
NTP header and should not require the use of the extension fields.

There are three types of ID that would be useful here. A transaction ID,
which is copied from request to reply. This is made a bit more difficult
by the existence of symmetric peers, since a transaction becomes half of
the full peer exchange. You need two transaction ID fields to implement
symmetric peers.

The next would be a server ID, which, like the transaction ID, is copied
from the reply to the request. And like the transaction ID, runs afoul
of the symmetric peers. It is really a special case of the transaction
ID, with an unchanging value.

And the last would be a server ID, where the value is filled in with a
unique identifier generated by the sender of the packet. This could be
used as a server ID in the sense of the previous paragraph, but only
after the first volley is done. The value of the response could be
recorded in the peer structure after the first response. It is therefore
useless in this first exchange. It does have the added benefit of
allowing the detection of duplicate servers, though.

The first two points are rendered moot by the existence of:
> 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.

So, indeed. I mentioned the use of the transmit timestamp as a
transaction ID in one of my messages on the 23rd. At the time I stated
that it could be used, but might not be unique. Given the information
above, I withdraw that objection. I am a little leery of relying on
a implicit transaction ID; I would prefer to have an explicit field.
The reference implementation only tracks the timestamp to microsecond
resolution, so the number of bits available as a transaction ID is
implementation dependent, with a tradeoff between resolution and this
> 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.

Correction, "weaker", and perhaps able to be made stronger again.
I will have to look at the crypto stuff more closely.

And, just to be clear, I have no objection at all to using the IP
addresses in various places. The objection I have is for any thing
that requires the process to obtain the destination address of a
received packet. The source address is fine.

And to be even clearer still, my real objection is to binding all
of the addresses. It is my research into that problem led me to the
conclusion that the destination address should not be made a
requirement for any portable UDP protocol. I say portable,
because many OS's now have an API to easily get the destination
address, without binding all of the addresses. However, I would
still not make it a requirement gratuitously.

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

Right. This is what led to my discussion about NTPv5. What would you
change if you did not have to be backwards compatible. For instance,
I have made two or three attempts at adding a new extension field to
the existing code base. The treatment of extensions is somewhat
abstruse and inefficient, largely due to backwards compatibility
issues, or so I gather.

The only legitimate reason to bind all of the addresses that I have
heard is to be able to determine the destination IP address of a
packet. Indeed, there is no other way to do this portably. My
contention is that this is not and/or should not be a requirement
of the NTP protocol. You have confirmed this, that modulo the
crypto stuff, the base protocol does not need nor require it.
And the crypto stuff could probably be modified not to need it
as well.


"Having them stolen may become our distribution model..."
Nicolas Negroponte on the Hundred Dollar Laptop.
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

More information about the questions mailing list