Re: [Ntp] Last Call: <draft-ietf-ntp-interleaved-modes-04.txt> (NTP Interleaved Modes) to Proposed Standard
Daniel Franke <dfoxfranke@gmail.com> Tue, 06 April 2021 18:39 UTC
Return-Path: <dfoxfranke@gmail.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 E7D5D3A2C12; Tue, 6 Apr 2021 11:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 S_kAwtT0gC5l; Tue, 6 Apr 2021 11:39:15 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296B53A2BEA; Tue, 6 Apr 2021 11:39:14 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id l1so7987797plg.12; Tue, 06 Apr 2021 11:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KcEBmMjZJ7uCTCYg783Tpw1PMTd/T8L7z2pbkHQREa4=; b=jyOSeALkELmbpbIOkBDw92zlTZeiVAsYo09MkKGb0J6R4GsUN0ACcUkiG4hLhvNFYk +zrgZ+MNyMoC1U1tSO0Z6X9Ykzom/e1FL+q2B38mtoj5EICnvtAPQhUPOp4hMXjI5v5+ 4yRKLO32fRPvl9ZCJAeG54CXZkXhUKRhYwPLn9kP+zX9w3nASQo9bOorkaJPTtJwszSC kuXMBjtRF3fxVYxzm5DvhayIG1AeymHQopOk5/xNroIHgHZecM7qscVXktiNtwEDFtcV uTll3jd5p65By4C2NbujBVy0QhYoJNrVigvEalHdk5S7y0Txm1qDKcvrW5xpJscy+jtN 2i1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KcEBmMjZJ7uCTCYg783Tpw1PMTd/T8L7z2pbkHQREa4=; b=qaZ0UP6NeeLBv3+R8xb8nyR+BwIanyQ5kN8qq6o8bcwyNAWGuI4VlOyosA0QOuLPTe ZHxHhrD3AMFc+SiW8vbrUv5rZ6tcnDjBhAcy0NeGwKVVcFTDytjirjmIEjCc/sWgMJ75 YJThFzYqN2TBxTuM5f1KiXOtMokJzJ0M5ZVvMD9zpBA2irBPMZ8cdwh8twEQNvgLekWh zZjrJqdw1l4+vd+GeH+ep1Yzlbwsfn+aTUBD7mnHcT3Cet9NlJz+PzZDNdUbapvjHSG4 txi6hbnYYZRcxMePb9wBvG4YJjUuo7amYAy+kmbwr6Q6HRNkIOGfmn6JsRKpm0EMXXZH l58Q==
X-Gm-Message-State: AOAM532ZcjEHCXY5uB3C4DKisYMnUi7/cH5yWqPjxh3Q4POUrc/iDWy3 WoTZeFNc5eM/AQwcoeaIFegXrHv6Q56L6VPCx9sMWvTKa2A=
X-Google-Smtp-Source: ABdhPJxI6ASjZwv4zA+SuIbrGEwykZ6lWEuZjI3Ulh9k+g6xSiV6RfkIV1tzJ2qe73bfTi/ge0KRRX/5RpjBbxPIDdQ=
X-Received: by 2002:a17:902:e2d1:b029:e9:ec4:e0da with SMTP id l17-20020a170902e2d1b02900e90ec4e0damr10844752plc.85.1617734351657; Tue, 06 Apr 2021 11:39:11 -0700 (PDT)
MIME-Version: 1.0
References: <161719557520.16220.12856615921222543758@ietfa.amsl.com>
In-Reply-To: <161719557520.16220.12856615921222543758@ietfa.amsl.com>
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Tue, 06 Apr 2021 14:39:00 -0400
Message-ID: <CAJm83bD7REE1wPEfsfGF9HX2JZ60KAAp-iWZaDdfnQtuepgDeQ@mail.gmail.com>
To: last-call@ietf.org
Cc: IETF-Announce <ietf-announce@ietf.org>, ek.ietf@gmail.com, ntp-chairs@ietf.org, NTP WG <ntp@ietf.org>, draft-ietf-ntp-interleaved-modes@ietf.org, Karen O'Donoghue <odonoghue@isoc.org>
Content-Type: multipart/alternative; boundary="0000000000005f1f7a05bf522199"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/u5D_-IIeFVnj2j_PMvbW-48nd8Y>
Subject: Re: [Ntp] Last Call: <draft-ietf-ntp-interleaved-modes-04.txt> (NTP Interleaved Modes) to Proposed Standard
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: Tue, 06 Apr 2021 18:39:26 -0000
I think the feature introduced by this draft is fundamentally misdesigned. The objections that I'm raising here are ones that I've already raised during and prior to WGLC. When it was clear from the ensuing discussion that I was coming out in the rough on consensus, I asked Karen to go ahead and advance the draft but to note my objections in the shepherd write-up. This seems to have been missed, but no matter; this email captures my concerns. Interleaved mode, as specified by this draft, works by conditionally altering the semantics of certain NTP packet fields, to mean something entirely different from what they mean in RFC 5905. This change of semantics is not signaled anywhere else in the packet; both parties are required to maintain state to keep track of which semantics are intended. The means for a client to signal that it wants to enter interleaved mode is arguably another incompatible change from RFC 5905 semantics, though there is room for some interpretation on this point. A client which fully implements and strictly adheres to RFC 5905 will, on its first request to a given server, set the origin timestamp field in its request packet to zero; on subsequent requests, it will set it by copying the transmit timestamp from the server's most recent response. However, the client's origin timestamp is of no actual significance to the protocol; RFC 5905's description of how a server is to construct its reply makes no use of it at all. SNTP clients typically always set it to zero, and I-D.ietf-ntp-data-minimization recommends that all clients do this, since the behavior of copying the server's transmit timestamp enables tracking. RFC 5905 is vague on what's actually expected of clients here, since there is no RFC 2119 language on the matter. My interpretation, however, is that an SNTP client can put whatever it wants into the origin timestamp, because RFC 5905 Section 14 allows clients to implement "any subset of the NTP on-wire protocol", and phrases all interoperability requirements in terms of how a server is expected to construct its response to a given request packet. In the interleaved-mode draft, a client signals that it wants to enter interleaved mode by setting its origin timestamp from the server's last *receive* timestamp instead of from its transmit timestamp. But in light of the above, I think that such behavior is already allowed of clients that are ignorant of interleaved mode, and so I think this signaling mechanism introduces an incompatibility. One can dismiss this concern as theoretical, saying that no interleaved-mode-ignorant client would ever actually behave this way, and I might be sympathetic to this if no cleaner negotiation mechanism were apparent. But a cleaner mechanism *is* apparent. NTPv4 supports extension fields, and we should use them. Instead of messing with the semantics of existing fields in the base packet, leave those alone and put the interleaved timestamp into an extension. A second problem with this draft, one of more immediately practical concern, involves state management, especially when NATs are involved. Servers supporting interleaved mode are required to keep state on their clients, but the means of distinguishing one client from another is underspecified. It states, "The server MAY separate the timestamps by IP addresses, but it SHOULD NOT separate them by port numbers". A server which opts out of the MAY would just keep one global table mapping every receive timestamp it has produced to a matching (hardware) transmit timestamp, and make lookups into this table based on the client's origin timestamp, removing such entries only when they time out. The draft does not specify what the timeout period should be, but it needs to be at least a decent multiple of 1024 seconds, since that's the polling interval that most clients use by default. A server which behaved this way would be easily DoSed, since a single IP could spam it with requests and quickly exhaust memory. Authentication wouldn't be enough to prevent this, since an adversary who captures even a single authenticated packet can then replay it endlessly. To avoid such a vulnerability, the server really needs to maintain a separate table per IP address, and limit how much it's willing to put into a given table. Actually, that's still not enough: source IPs can be spoofed, so there's a need for some sort of SYN-cookie-esque mechanism to make sure that a client is really able to receive traffic on its purported IP before the server is willing to keep any state for it. Let's imagine for the moment that this mechanism exists: we're *still* in trouble on account of NATs. We can't just assume, "one IP, one client", because there may be multiple, and indeed a very large number, of clients behind a single NAT address. Therefore these per-IP tables still need to be allowed to get quite large to prevent such clients from stepping on each others' state. I think the most tractable solution to the state problem is with a different design that avoids state entirely. Don't wait for another request from the client: just send one packet, capture the hardware timestamp, and immediately send that out in a second packet so that related state can be forgotten. The draft already discusses this approach, but dismisses it on the basis that it would allow for amplification attacks. This would be true of a naive design, but it's easy to problem to solve: just do exactly what DTLS does vis a vis HelloVerifyRequests, where before the server will send follow-up packets to a client, the client must obtain and echo back a server-generated, self-authenticated cookie bound to the client's IP address. This of course can again be done through extension fields. On Wed, Mar 31, 2021 at 9:01 AM The IESG <iesg-secretary@ietf.org> wrote: > > The IESG has received a request from the Network Time Protocol WG (ntp) to > consider the following document: - 'NTP Interleaved Modes' > <draft-ietf-ntp-interleaved-modes-04.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-04-14. Exceptionally, comments > may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document extends the specification of Network Time Protocol > (NTP) version 4 in RFC 5905 with special modes called the NTP > interleaved modes, that enable NTP servers to provide their clients > and peers with more accurate transmit timestamps that are available > only after transmitting NTP packets. More specifically, this > document describes three modes: interleaved client/server, > interleaved symmetric, and interleaved broadcast. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp >
- [Ntp] Last Call: <draft-ietf-ntp-interleaved-mode… The IESG
- Re: [Ntp] Last Call: <draft-ietf-ntp-interleaved-… Daniel Franke
- [Ntp] Antw: [EXT] Re: Last Call: <draft-ietf-ntp-… Ulrich Windl
- Re: [Ntp] Last Call: <draft-ietf-ntp-interleaved-… Miroslav Lichvar
- Re: [Ntp] Last Call: <draft-ietf-ntp-interleaved-… David L. Mills
- Re: [Ntp] Last Call: <draft-ietf-ntp-interleaved-… Miroslav Lichvar