[ntp:questions] Re: server's address in ntp payload?
mayer at ntp.isc.org
Tue Nov 29 14:21:05 UTC 2005
Brian Utterback wrote:
> David L. Mills wrote:
>> 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.
I need to go back and look again.
>> 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.
Why do you need transaction ID's? You shouldn't be sending more than one
request NTP packet at a time so what you get back should be the request
and in any case the packet contains all of the information you need to
deal with the results.
> 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.
What is the reason for having a server ID and what would you do with it.
> 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
Again what would you do with it?
>> 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.
You have to have both. The source for one is the destination for the
other. You need both.
> 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.
The binding of all interfaces has nothing to do with this. I was
originally not going to bind the wildcard addresses but changed my mind
on this after a discussion with a security expert.
> 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.
It has nothing to do with the NTP protocol, it has to do with the
implementation. For autokey it is required.
More information about the questions