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
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
