On Tue, Apr 5, 2016 at 3:00 PM, Danny Mayer <[email protected]> wrote:
> 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? > > Yes, it's clear. How does the current ntpd implementation deal with this problem? Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
