Sharon Goldberg writes: > 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.
I think your proposal will usually work. There is a potential problem in that A does not have complete information about what B and C are doing. It may be that B and C are effectively the same machine/source of time, and that B and C would look at the REFID returned by A and decide that there is a timing loop if A is getting its time from B and C (which is also effectively B) is considering using A for time. If we're going for a strictly clean paradigm here we need to note this. H _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
