[Ntp] Comments on draft-ietf-ntp-refid-updates-05

[Fernando Gont <[e-mail]>]

Folks,

I've missed the WGLC for this document, but anyway have some comments on it:

I've read the document, and it would seem to me that the proposed
workaround is, at least, sub-optimal.

First of all, based on our work in draft-gont-predictable-numeric-ids
(and most specifically, draft-gont-numeric-ids-sec-considerations), one
should think about the interoperability requirements.

If the goal is to avoid degree-one timing loops, then, in reality, the
REFID need not specify the time source, but the host itself. -- it only
makes sense to specify the time source if you expect to avoid timing
loops of any degree (such that you can trace the whole hierarchy up to
the root).

Now, in the hopes of keeping the same semantics for the REFID (an
identifier of the time reference), and assuming that it is to be
employed to avoid degree-one timing loops (as opposed to any-degree
loops), then the interoperability requirements for the REFID are:

* It must uniquely identify the source on a (local NTP peer, remote NTP
peer) basis. -- i.e., as long as the remote NTP peer can detect whether
it is the time source of this peer, we have complied with the requirement.

* There is a hard failure if the REFID is generated inappropriately
(e.g., if there is a collision of IDs, the NTP peer will mistakenly
assume there is a timing loop).


Based on the above, I propose that the REFID be generated as:
Hash(IP address of the time source, IP address of the query).

A node that means to check if it is talking to an NTP peer that is using
itself as a time reference should check the received REFID as follows:

foreach $address (@myaddresses){
   if(hash($address, $srcaddress) == REFID){
     die "there is a timing loop";
   }
}

 -- where $srcaddress is the address employed for the query.


Of course, if the NTP peer checking the REFID only employs a single
address, only one iteration is required. Also, you can precompute the
hashes (since you are always checking for hashes of the combinations of
your own ip addresses.

Since the REFID is unique on a (NTP peer, NTP peer), then there is no
information leak at all.

Thoughts?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492