All, just to summarize the conversation on meetcho just now. I think that this proposal would also solve the problem hashed IPv6 addresses colliding with IPv4 addresses on the same network, which is addressed in draft-stenn-ntp-ipv6-refid-hash-00.
Why? Because the only time a server will put an IP address in the refID field is when it is responding to a query from *that specific IP*. (Else, it puts the "nonsense" value in the refID.) So even if a collision happens, it should not matter, since the only party to see the collision is the IP that sent the query. Sharon On Tue, Apr 5, 2016 at 2:28 PM, Sharon Goldberg <[email protected]> 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 > > > -- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
