Re: Using QUIC to traverse NATs

Martin Thomson <mt@lowentropy.net> Wed, 19 July 2023 01:55 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238A4C151982 for <quic@ietfa.amsl.com>; Tue, 18 Jul 2023 18:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b="yRo7wnNV"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="XbpPmPt3"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkFDdYO0Ph2b for <quic@ietfa.amsl.com>; Tue, 18 Jul 2023 18:55:34 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47DE7C151068 for <quic@ietf.org>; Tue, 18 Jul 2023 18:55:34 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 70AA15C0117 for <quic@ietf.org>; Tue, 18 Jul 2023 21:55:33 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute6.internal (MEProxy); Tue, 18 Jul 2023 21:55:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1689731733; x=1689818133; bh=TC5l5t3dKt5Ci9//m5rLgwiR0N6IGfVozVF +H+CoJYA=; b=yRo7wnNVDlf2Tk52X93s7UdfloiiBc6oGP2RAz0oC4hQjhsXoKy q/n4gskiG6+oq0WOMvJMJK69BCb+zJfPHkysNnK9ft53wYumQ/6Ej2TJUbwVv/6N FVNQFWpLEoMiOz5CwmRldyDg91l0ztoRm0ELvBfV0rLuGFVss6pJb8pMj1WvC2qQ HG7xmAnvBfdgCXFBt+UWoonvTyHLaGaMUoia6FcZJv2vy4cJEmPQSU7mvV61Y/wR 7X1lAY2SDs5fofjM9mLgnSEKlEc63nlHAL7wNX/prAJBxxOAdfhEfI3jYdp/X0cE 87X1t/2ibkMMZRmEZg2PdtbzldD7Iiz68OQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1689731733; x= 1689818133; bh=TC5l5t3dKt5Ci9//m5rLgwiR0N6IGfVozVF+H+CoJYA=; b=X bpPmPt3aY3LmZpYkekHMMRU2a4T0Dz/HrdOso+za3Qn1x+n8BjrQZutjo24iYgcB Tr/6jo8F9GGt0wbMUe4yGI7BCmMc+JzpnktHQaWM4bM0LuK45lUNMF8RMc0Et3Dq nHDu1hEbUjZIjx7JBqDa1JTA5OwqhBGKkIw+TOGAc69UoCIhCcrx2wFCx+YhDsbf YZJpL6IIsYnRO8Pcu694JFV80cl0kGPbjzGEYJx3f2fV9LjyjdL6QMzDD5q/wUG6 WuBo9nMUiu0tbvE6bPYnlHwi3w3pIbPKPDm7/aEMpYuwLwZFQ48hvtYe5Prv44gc 2sL+HdDy925Itt8tyqdgQ==
X-ME-Sender: <xms:lUK3ZGagDkLq3D5nPncgwnFkwcrhX6XAIQYsmFN6BU3TtYjEBrVVew> <xme:lUK3ZJYLVN4OVMGk4i8JL4StYN0wqzXZLZtHjSj2vgVlKl3p_ZDp0YQwmMUV7uY4h 3sANySTdFCvKe_aj6U>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrgeehgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefftefgvedvhfdtffehje dufefhhfevhedufefhgfelleetieefgeefgffgleehgfenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:lUK3ZA8L2uWcIaiTv0Pwlg1I3l8yQ4oBae_4WfD1mV4OVOSM5eIVcw> <xmx:lUK3ZIqbfTyIMjWCZeKf19gBCa8rbqwHNfLQxK-QRocWlomGJb6_oQ> <xmx:lUK3ZBr6tObkR1GzmGdBMWPCr2mtJt3HXu8XXUaN8b7BflKZnTujlA> <xmx:lUK3ZO1xkK6YgHoSICXxeNj32TDLB5VGQbC7W-UK3IW9rCV8n1TIgg>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 095DD234007E; Tue, 18 Jul 2023 21:55:32 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-531-gfdfa13a06d-fm-20230703.001-gfdfa13a0
Mime-Version: 1.0
Message-Id: <2d0e2504-476f-461e-bd83-39e8e391f8d8@app.fastmail.com>
In-Reply-To: <CAOYVs2pqmQW2J4mkPOhV5b0c2CLG_+uw1iT26f3=bUzRdKameA@mail.gmail.com>
References: <CAOYVs2pqmQW2J4mkPOhV5b0c2CLG_+uw1iT26f3=bUzRdKameA@mail.gmail.com>
Date: Tue, 18 Jul 2023 18:55:11 -0700
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Using QUIC to traverse NATs
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/jH2b8_3qqor_T0bDTIhULPYsZWc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2023 01:55:39 -0000

Hi Marten,

I did a little thinking about this problem a fair while back, see https://datatracker.ietf.org/doc/html/draft-thomson-rtcweb-ice-dtls-00

That's closer in truth to your mode 3.  That is, it collapses the protocols.  And of course there are properties of DTLS that ensure that this is less than ideal, whereas QUIC might be better suited to the sorts of tweaks that connectivity checking demands.

In particular, it is worth thinking about carefully here is how much QUIC's path validation logic is duplicative of parts of ICE and whether that is overhead that can be saved.

As for the non-collapsed versions, you might need to be clearer about which part of the stack is responsible for path selection.  In mode 1, this is not particularly clear.  If you think of classic ICE, you essentially have ICE being responsible for path selection (especially with the continuous ICE versions) and the flow that you initiate on top of it is ignorant of path changes.  That will interact somewhat poorly with a protocol like QUIC that expects to be more involved in that process.  It's worse in mode 2, which might be quite confusing with the two layers interacting as they do.  That could stand to be made much clearer.

Cheers,
theonewithan"i"

On Mon, Jul 10, 2023, at 22:20, Marten Seemann wrote:
> I just submitted a new draft that describes how to do NAT traversal using QUIC: 
> https://datatracker.ietf.org/doc/draft-seemann-quic-nat-traversal/
>
> The document defines 3 distinct modes. The first mode is the simplest 
> one, first running ICE to completion to find a suitable path between 
> two nodes, and then establishing a QUIC connection on that path.
> The other two modes use a proxied QUIC connection to do the ICE 
> signaling (potentially using one of the protocols defined by the MASQUE 
> WG), and then make use of QUIC connection migration to migrate to a 
> better / direct path.
>
> This is an early draft version, and I wouldn’t be surprised if it 
> wasn’t actually implementable, most likely due to my limited 
> familiarity with ICE. I’d appreciate feedback if the general direction 
> makes sense.
>
> Cheers,
> Marten