Re: [Ntp] WGLC: draft-ietf-ntp-interleaved-modes

Sorry for not getting this in during the WGLC period. I strongly
object to this document but nonetheless support advancing it because I
have already raised all these objections at several prior meetings and
it's clear that I'm in the rough on WG consensus. I will communicate
them again during the IETF Last Call period and hope that the IESG
finds them persuasive.

The core of my objection is that this proposal radically and
needlessly alters the semantics of existing timestamp fields and then
relies on a very brittle mechanism to disambiguate which semantics are
intended. Servers which implement this proposal will reply with
interleaved semantics if the origin timestamp in the client's request
is non-zero and matches the receive timestamp of a reply the server
previously sent within some scope, where the bounds of that scope (IP,
port, time window) are largely left to implementers' discretion.
Existing RFCs do not adequately ensure that existing implementations
that are not aware of interleaved mode will never send a request of
this form. If a client fully implements RFC 5905 and is there is no
other request in the same scope, then it's okay: it will instead set
its request's origin timestamp to the server's previous reply's
transmit timestamp, and this proposal correctly requires that the
receive and transmit timestamps in the reply not be equal. However,
this breaks down as soon as there are multiple clients in the same
scope (e.g., both behind the same NAT), especially if some of them are
non-conforming. At minimum, servers must then ensure that they never
send a transmit timestamp that matches *any* receive timestamp sent to
the same scope. Even then, non-conforming clients can break conforming
clients within their scope by sending colliding timestamps.

These failures may prove rare in practice, but there is no excuse for
taking the risk given that there is a much cleaner alternative: do not
alter any existing semantics, and instead put interleaved timestamps
into an extension field. Even if all known failure modes can be
satisfactorily resolved without doing this, it's the right thing as a
matter of basic principle and the WG's resistance to taking this
approach baffles me.

Finally, one unrelated nit: [I-D.ietf-ntp-data-minimization] is listed
as an informative reference, but it's referenced in sentences that use
RFC 2119 language, so it needs to be normative.

On Tue, Nov 6, 2018 at 3:49 PM Karen O'Donoghue <odonoghue@isoc.org> wrote:
>
> Folks,
>
> This message initiates a three plus week working group last call for:
>
> NTP Interleaved Modes
> https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/
>
> Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list will be used to determine WG consensus to proceed.
>
> Please send all comments in by COB on Friday 30 November. We realize this is a bit longer than normal but we are coming out of an IETF week and heading into the Thanksgiving holiday in the US.
>
> Thanks!
> Karen and Dieter
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp