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

Miroslav Lichvar <mlichvar@redhat.com> Wed, 02 January 2019 12:20 UTC

Return-Path: <mlichvar@redhat.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F6612785F for <ntp@ietfa.amsl.com>; Wed, 2 Jan 2019 04:20:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBArt7akfmlA for <ntp@ietfa.amsl.com>; Wed, 2 Jan 2019 04:20:29 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA3A1277D2 for <ntp@ietf.org>; Wed, 2 Jan 2019 04:20:29 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1BAF5750D0; Wed, 2 Jan 2019 12:20:29 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 61F176012C; Wed, 2 Jan 2019 12:20:28 +0000 (UTC)
Date: Wed, 02 Jan 2019 13:20:28 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: ntp@ietf.org
Message-ID: <20190102122028.GE30177@localhost>
References: <2C2DBD6F-727F-48DB-BB48-14CE7F7F8B95@isoc.org> <CAJm83bBWve8DiQksQhnVF1uhnaN0kD-1kuJTDw-hoByyH7kMoA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAJm83bBWve8DiQksQhnVF1uhnaN0kD-1kuJTDw-hoByyH7kMoA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 02 Jan 2019 12:20:29 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/764jHP94paO8tzbqz0mobTnEEog>
Subject: Re: [Ntp] WGLC: draft-ietf-ntp-interleaved-modes
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jan 2019 12:20:31 -0000

On Wed, Dec 19, 2018 at 12:40:26PM -0500, Daniel Franke wrote:
> Existing RFCs do not adequately ensure that existing implementations
> that are not aware of interleaved mode will never send a request of
> this form.

You mean the RFCs don't explicitly say that clients should not send a
request with an origin timestamp equal to the server's receive
timestamp? Is that necessary when the RFCs describe what the origin
field is set to, i.e. the server's transmit timestamp, or zero if it
is a SNTP client or a client following the data minimization?

Even if we ignore the RFCs, I think realistically the only reason for
a client to be inadvertently sending requests in the interleaved mode
would be a bug. IIRC that's what happened in NTPsec when it dropped
support for the interleaved mode, but was sending all requests in the
interleaved mode and no longer being able to process the responses.
(I suspect this might be the origin of your concern.)

> 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.

I think you said this several times, but I still don't understand.

> At minimum, servers must then ensure that they never
> send a transmit timestamp that matches *any* receive timestamp sent to
> the same scope.

That's what the draft says (or at least tries to).

> Even then, non-conforming clients can break conforming
> clients within their scope by sending colliding timestamps.

How exactly? Can you please give a specific example?

> 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.

If there are failures, how would putting the timestamps in an
extension field prevent them? Again, a specific example might help me
to understand the issue.

The trouble with an extension field is that it would make the packet
longer, which would increase the NTP delay. So, a clock filter might
prefer measurements in the basic mode over interleaved mode. That's
not good. I think packets in the basic and interleaved mode need to be
of the same length.

> 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.

Ok. I didn't know that.

Thanks for your comments.

-- 
Miroslav Lichvar