Brian Utterback wrote: > 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.
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 > ID. > 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. Danny _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
