Re: [TICTOC] comments on draft-stenn-ntp-suggest-refid-00

[Sharon Goldberg <[e-mail]>]

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 <[e-mail]> 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