Re: [Ntp] NTP is unique (was Re: QUIC as a transport substrate (was:re-chartering: include DNS-over-QUIC?))
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 15 April 2020 08:46 UTC
Return-Path: <mikkelfj@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 91BD13A0659; Wed, 15 Apr 2020 01:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level:
X-Spam-Status: No, score=-1.096 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 bXEIa8iGRJOD; Wed, 15 Apr 2020 01:46:24 -0700 (PDT)
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 EE2553A064C; Wed, 15 Apr 2020 01:46:23 -0700 (PDT)
Received: by mail-yb1-xb36.google.com with SMTP id n188so8192849ybc.3; Wed, 15 Apr 2020 01:46:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=VefZpQbv/Ium3YGmm9OLFw09cLq0RgqqXJztQI4n914=; b=A5yMteLXRnNBS+NOzRzLcGMZ6hGZdUd+Rmo/Lh7+lUnKjdKUhAgkWnOjDrdncx28ko LkOoW7P/1ITArQYsbYMHA4UCObrEZS5EQ2oXRedJKcZJCRswZiXsCsdwfVz4SrIDByGd RYTHtD6NvXt5B0pSWqwv1UTunaDAzh7LZXNHxCXSSaVmnKGmCzdhmqc//v6O9fy/vkVo jKunx/WSt4zLi6bUQwSuDrf82gwehqYe4u28u8cik/Mt7ZMD5AzCu73Z24SoE14Csonm D+a78om+q2jzYVW1K++YXeNWtwPLKjSF9ceEcjWNYWVfSXjNa35ZuOEhOys2COTv06GJ 7Vbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=VefZpQbv/Ium3YGmm9OLFw09cLq0RgqqXJztQI4n914=; b=JC1TCElZ7xoajjIrY2DW1WywOAt8JCOoid+3AfhxwLm0+Bm2J0PeYB3/OIiL/lkH4F uwKqCenPQk+zbfjbfTqq5cg2avRv7mlusEP+xzSQZN/GNpL2x6Sd7SkwI912ihJQNdEP Y9l5D7bCXzqkKeKP569HLc3RAtkn4NwbTnR9y8KVtYl5+8QUUWuubdsgBLYve/nDvEWJ jGO/AKcF6/2MJvrdNC4G5ZGB8RasFGbMFXhbt8p81MVF65Zs10UEcAbtAXmLAkpxuBDs BveEMbdMMAfKs7qySKBzvXZAmqqXD8DKHD6PskkEIUSPK5qE2Zp8mxoE/cUIPqySWxZH hIFw==
X-Gm-Message-State: AGi0PuacWhoOiRXNUBAKQrBhBtwEnX24Kbmyn0MEtppgP5+7Q43k294+ MSmWuisffOiUjKT6vZdrWrmPAIQCoGbIixJc31o=
X-Google-Smtp-Source: APiQypIo837YvsiimK9uv+0Q/oKu3I6FEn7MZQe6KigMdmDG9ztBNzPtv+zRH5JOrrvRXP+W9yvwjXsX8UVMkXPB+90=
X-Received: by 2002:a25:7487:: with SMTP id p129mr7043187ybc.378.1586940383053; Wed, 15 Apr 2020 01:46:23 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 15 Apr 2020 01:46:22 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <MW3PR15MB3948FD23BDF352CCBEF6C88ACDDB0@MW3PR15MB3948.namprd15.prod.outlook.com>
References: <176A9D81-A49E-47F0-84AE-6A96864DF7B1@fb.com> <91809E93-26F1-41C0-B349-8BEA3F380402@huitema.net> <CAN1APdfpaNVutPn+Y6Dcip1hpVvTvTW7dLnmHfZVcXyuyqvchg@mail.gmail.com> <MW3PR15MB3948FD23BDF352CCBEF6C88ACDDB0@MW3PR15MB3948.namprd15.prod.outlook.com>
MIME-Version: 1.0
Date: Wed, 15 Apr 2020 01:46:22 -0700
Message-ID: <CAN1APddKrF9oQc92u3yiVOv7dL+iqn5G59euov1Lt2dP_wYP7w@mail.gmail.com>
To: Roberto Peon <fenix@fb.com>, Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>, "ntp@ietf.org" <ntp@ietf.org>, Watson Ladd <watsonbladd@gmail.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Tal Mizrahi <tal.mizrahi.phd@gmail.com>, Erik Kline <ek.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000cfc97c05a3505934"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/IcgCjCR66v_98Md-l0AwtYM-g2w>
Subject: Re: [Ntp] NTP is unique (was Re: QUIC as a transport substrate (was:re-chartering: include DNS-over-QUIC?))
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, 15 Apr 2020 08:46:27 -0000
I do agree on all that but can you please clarify what you mean to address by that comment? Is it merely a vote for NTP over QUIC, or are you saying that a connection carrying NTP only is insufficient because you need to link the time data to other application protocol specific content? In the latter case this is a concern I share - how do you mix multiple application protocols on the same connection? QUIC consensus appears to be that you do don’t do that except where the two, or more, protocols are designed explicitly to coexist. Thus you could have an HTTP/3 extension for time. It would be possible to design an NTP extension for QUIC that is very similar to datagrams but explicitly designed for NTP under the assumption that NTP like data is frequently needed by other application protocols. In that case is simply a new extension frame. I am not opposed to that - but using datagrams is simpler for common case of just NTP over a connection. Kind Regards, Mikkel Fahnøe Jørgensen On 15 April 2020 at 10.28.23, Roberto Peon (fenix@fb.com) wrote: I've seen a couple of applications where we had to do ntp or ntp-like things, but wanted to ensure that we were talking to the same server whom we were transacting requests. You need something to ensure the routing continues to work in that particular case, especially if bouncing through a reverse proxy which may not otherwise understand your application. -=R Get Outlook for Android <https://aka.ms/ghei36> ------------------------------ *From:* Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> *Sent:* Wednesday, April 15, 2020 1:23:32 AM *To:* Christian Huitema <huitema@huitema.net>; Roberto Peon <fenix@fb.com> *Cc:* IETF QUIC WG <quic@ietf.org>; ntp@ietf.org <ntp@ietf.org>; Watson Ladd <watsonbladd@gmail.com>; Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com>; Lucas Pardue <lucaspardue.24.7@gmail.com>; Tal Mizrahi <tal.mizrahi.phd@gmail.com>; Erik Kline <ek.ietf@gmail.com> *Subject:* Re: NTP is unique (was Re: QUIC as a transport substrate (was:re-chartering: include DNS-over-QUIC?)) We also have timestamp frames. That may be related to NTP. Umm - where are these timestamp frames? As to partially reliable streams. I am a big advocagte of these, but I do not think that they are essential to time data because the payload - time - is naturally providing a sequential marker. Thus you can avoid waiting for QUIC v2 and you can avoid the additional complexity. The receiver can just ignore receipt of out of order messages in, for example, datagram frames. Datagrams do and do not have identifiers - the intention was not to remove them, but to let the application provide them as early data in the frame. If the connection only deals with NTP and you only have one unreliable stream, you don’t even need an identifier because all datagrams implicitly belong to the same stream. Kind Regards, Mikkel Fahnøe Jørgensen On 15 April 2020 at 02.16.10, Christian Huitema (huitema@huitema.net) wrote: We also have timestamp frames. That may be related to NTP. -- Christian Huitema On Apr 14, 2020, at 12:03 PM, Roberto Peon <fenix@fb.com> wrote: I agree that Qv1 doesn’t have an ability to express this, since Qv1 doesn’t allow for partial reliability except in extensions. Regardless, if the requirement is to have no retransmission, then that is the requirement, and should be (at least in a spec) written that way. I’ll disagree on whether that is similar to datagrams. Datagrams don’t have the same “address space” as does a stream, and there are certainly many things out there that would prefer to have a stream-with-holes (i.e. an address space that every party to the interaction agrees upon) than require the application to do reassembly of everything (and caching) on its own. This is really a separate conversation we can move somewhere else, though, assuming it is work having at all! -=R *From: *Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> *Date: *Tuesday, April 14, 2020 at 11:54 AM *To: *Erik Kline <ek.ietf@gmail.com>, Watson Ladd <watsonbladd@gmail.com>, Roberto Peon <fenix@fb.com>, Tal Mizrahi <tal.mizrahi.phd@gmail.com> *Cc: *IETF QUIC WG <quic@ietf.org>, "ntp@ietf.org" <ntp@ietf.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> *Subject: *Re: NTP is unique (was Re: QUIC as a transport substrate (was:re-chartering: include DNS-over-QUIC?)) You don’t need the datagram extension, rather, you need a promise to not retransmit or a promise to communicate the time in any retransmission. I don’t understand this promise. In QUIC v1 you have streams, pings, bookkeeping frames, and extensions. You cannot promise not to retransmit something in as stream except by terminating the stream. Pings are not suitable for conveying time information unless perhaps its mere arrival acts a clock tick. You can of course create a new stream for each new time event but it still doesn’t prevent retransmission unless you cancel, and if you cancel, delivery of the payload is not guaranteed. You could define a promise through a new extension with the desired semantics but that is close enough to datagrams that it doesn’t make much sense - but you might want a datagram that does not have ACKs - this affects flow control, but since transmission is infrequent, that could work. Something else: It is hard to prevent an attacker from dropping or delay packets even on an encrypted QUIC connection and a retransmission would not be a useful mitigation, so I am not sure how you can make NTP truly secure. A voting system from multiple sources could make such an attack more difficult. Kind Regards, Mikkel Fahnøe Jørgensen On 14 April 2020 at 19.40.00, Roberto Peon (fenix@fb.com) wrote: You don’t need the datagram extension, rather, you need a promise to not retransmit or a promise to communicate the time in any retransmission. While datagram provides, implicitly today, a promise to not retransmit, datagrams themselves aren’t the requirement. (Also, in the face of multipath, is it true that we won’t have duplicates even for datagrams. I’m not sure this is clear right now?) If the first packet has higher measurable (latency) overhead in the processing stack, then you probably don’t want to use that one for NTP if you’re high time accuracy. In other words, you may find that you get better accuracy if you make a connection, and then do the NTP “stuff”. Similarly, you may find you get better accuracy if you **always** do a handshake on every packet (though that is more expensive)… While QUIC is a wonderful hammer, I do wonder if it provides any significant benefit in this case. -=R *From: *QUIC <quic-bounces@ietf.org> on behalf of Mikkel Fahnøe Jørgensen < mikkelfj@gmail.com> *Date: *Monday, April 13, 2020 at 2:31 AM *To: *Erik Kline <ek.ietf@gmail.com>, Tal Mizrahi <tal.mizrahi.phd@gmail.com>, Watson Ladd <watsonbladd@gmail.com> *Cc: *"ntp@ietf.org" <ntp@ietf.org>, IETF QUIC WG <quic@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Lucas Pardue < lucaspardue.24.7@gmail.com> *Subject: *Re: NTP is unique (was Re: QUIC as a transport substrate (was:re-chartering: include DNS-over-QUIC?)) I think these observations on resource usage are correct, but changing system time could be a significant attack vector. For NTP to make sense over QUIC, the datagram extension would be needed to avoid much of the state and retransmission overhead. A simplified implementation could even forego a lot of the QUIC machinery such as streams and only rely on the handshake and datagram. Of course you could also use DTLS but that is yet another stack. Kind Regards, Mikkel Fahnøe Jørgensen On 13 April 2020 at 11.23.06, Tal Mizrahi (tal.mizrahi.phd@gmail.com) wrote: Hi, > > This came to mind because I had a silly idea. As I watched Christian's presentation in dprive I thought (a) this DoQ doc really benefits from Christian knowing what he's doing with QUIC, and (b) I wondered if I could run NTP over QUIC. Like I said, this is probably silly and there might be nothing to gain from the attempt, but it got me thinking about guidance for anyone else with both (a) such an idea and (b) the time to write/implement a proposal. NTP-over-QUIC is an interesting idea. The main benefits I can think of of running NTP over QUIC are enjoying the inherent security of QUIC, and avoiding middlebox tampering. I wonder if these benefits are worth the effort. On the other side running NTP over QUIC may consume significantly higher resources on NTP servers than are necessary today. NTP servers try to minimize the per-client state (or keep it zero if possible), while QUIC may require per-client state in order to allow 0-RTT. Also the precision of NTP may be lower than existing implementations if implemented in user space. > You also don't want automatic retransmission in NTP, and the flow > control is essentially nonexistent: it's driven by the synchronization > loop. One may consider using QUIC in datagram mode, and this would prevent retransmissions. ACKs would still be sent in this case. Cheers, Tal. On Mon, Apr 13, 2020 at 9:18 AM Watson Ladd <watsonbladd@gmail.com> wrote: > > On Sun, Apr 12, 2020 at 11:03 PM Erik Kline <ek.ietf@gmail.com> wrote: > <chop> > > > > This came to mind because I had a silly idea. As I watched Christian's presentation in dprive I thought (a) this DoQ doc really benefits from Christian knowing what he's doing with QUIC, and (b) I wondered if I could run NTP over QUIC. Like I said, this is probably silly and there might be nothing to gain from the attempt, but it got me thinking about guidance for anyone else with both (a) such an idea and (b) the time to write/implement a proposal. > > NTP has a very unique property: one packet is sent every 1024 or 512 > seconds or so by the client. A single server can handle a high packet > rate easily because of the statelessness. Adding state would start > getting problematic at the high packet rates. > > You also don't want automatic retransmission in NTP, and the flow > control is essentially nonexistent: it's driven by the synchronization > loop. > > Getting through middleboxes isn't nothing! But that's more a new port, > and ideally you want middleboxes to correct for packet queuing times. > > Sincerely, > Watson Ladd >
- Re: [Ntp] NTP is unique (was Re: QUIC as a transp… Tal Mizrahi
- Re: [Ntp] NTP is unique (was Re: QUIC as a transp… Kyle Rose
- Re: [Ntp] NTP is unique (was Re: QUIC as a transp… Mikkel Fahnøe Jørgensen
- Re: [Ntp] NTP is unique (was Re: QUIC as a transp… Mikkel Fahnøe Jørgensen
- Re: [Ntp] NTP is unique (was Re: QUIC as a transp… Roberto Peon
- Re: [Ntp] NTP is unique (was Re: QUIC as a transp… Christian Huitema
- Re: [Ntp] NTP is unique (was Re: QUIC as a transp… Mikkel Fahnøe Jørgensen
- Re: [Ntp] NTP is unique (was Re: QUIC as a transp… Roberto Peon
- Re: [Ntp] NTP is unique (was Re: QUIC as a transp… Mikkel Fahnøe Jørgensen