On 4/5/2016 2:28 PM, Sharon Goldberg wrote: > Dear WG, > > To follow up on my comments on draft-stenn-ntp-suggest-refid-00 at the > IETF'95 WG meeting just now. The current draft requires the use of an > extension field. I believe the goals of the draft can be accomplished > without using an extension field, in a backwards compatible fashion. > > The goal of the draft is to limit the information exposed by the REFID > while still preserving robustness to "length-1" timing loops where > system A takes time from system B, but system B takes time from system A.  > This proposal allow system A to limit the info it leaks in its refID, > without harming any of its legacy clients. > > Suppose system A is taking time from system B. Then there are two cases: > 1) If A gets a time query from system B, A puts the IP of B in the refID > of its response. This way, even a legacy B can tell it cannot take time > from A because this would cause a timing loop. > > 2) If A gets a time query from system C, A puts a "nonsense" value in > its refID. Even a legacy C can see that its IP is not in the refID, > and so it is allowed to take time from A. > > One question is what this "nonsense" value should be. I think it > should be a fixed value. For example 0.0.0.0. We would not want a > randomly-chosen value since this might collide with actual IP addresses > on the network. > > Thanks, > Sharon
The problem that I was alluding to in the jabber room is this. I'll keep the problem simple and to one example. A takes its time from B over an IPv4 address. A then gets a time query from C over IPv6. How does it know if B and C are the same system or different system? A has no information about that. Is this clearer? Danny _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
