IETF Logo Mail Archive

Re: QUIC Address Extension for NAT detection

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 13 March 2019 16:54 UTC

Return-Path: <mikkelfj@gmail.com>
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 D04BB130EF5 for <quic@ietfa.amsl.com>; Wed, 13 Mar 2019 09:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.097
X-Spam-Level:
X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 9x5ScyjnwMzH for <quic@ietfa.amsl.com>; Wed, 13 Mar 2019 09:54:11 -0700 (PDT)
Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 7BB7E130EFB for <quic@ietf.org>; Wed, 13 Mar 2019 09:54:11 -0700 (PDT)
Received: by mail-it1-x12c.google.com with SMTP id h9so54994itl.1 for <quic@ietf.org>; Wed, 13 Mar 2019 09:54:11 -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=7P+0H4BUuYYM+vl6X1PvXVW6wjC4UrYUdQc3jr9QCCw=; b=sMyI7GROv7Xn9unZE8HCiTpm8k8XphJ+ihpMg64lIcwNjJPvcbTKvhxC2f+PtTwC2n f2FYzLxJsoTSGD9MB1L/lFkMxU8/XJPXlv6wsjFeuBYghHUMLeNV/fDZle5pTqxgNbvG Y2v1BGPXC1qwLCQeyji6aiaySYmtsoALtvHz0je23u1HKNX7tYAei4YmbSKnolvFUDty GJ/6ChYiVSM+fuaq9aN4LACgVpsCJtVP5F1Qs1DqXROTqrIVaOJK31pZr7uBimiEJcaN Bd5SnwHuhqKKWkPp1tiTjYC9h5YPFtO0l7j3bOiHS+JZPhd9pNKt+Vg6AAJUdokwv7z5 FplQ==
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=7P+0H4BUuYYM+vl6X1PvXVW6wjC4UrYUdQc3jr9QCCw=; b=r02UM0hvW5oJk3X4U9qFgIs4sMCtTjXSTxcPlIdlynkbTs5oly9TheA9WO9PMl0AZp VJ+CHlVR84VOxY9vDTHEHzF4v1zRx6PhPvY1GX7hwINP3OJQlXvjjcX/d4robaPs1DnC PFTjJDy+moc8Jd7IV+5g1Sv/nDW/SBBtw9MTo1Y+Gff8//MXtBgnXI1MgJ+IYhslK9Ft grSLr9mEqiaAAUdiNRPc25SaivzwDjNNWFVxXcjgWTk2OkmXnSiYqG6X8et5Z+x5MHND TmDGyzCMIpFxSmPi3VOdVqlouQeI37FjmqHvI2doIhFKop49/nJYFHme/H0f4ZuKE/7w +Zxg==
X-Gm-Message-State: APjAAAVuqH/3Uu7sFh6u8phRkkqtMlAmYbdoy4xXOy1xAiiI02r68Akp YxDliGMKG9zmAPd2JBmYy8OupUqVMOt7VqNvF30=
X-Google-Smtp-Source: APXvYqwD/gAluoqVoMEkbCiYSwEb6jR+LUlwP9or7jLiHB6Foa+cCk6HRfq+YQ4ihbocIptV3IoHbQPoEMXaOQN/kWc=
X-Received: by 2002:a24:260d:: with SMTP id v13mr2284431itv.148.1552496050831; Wed, 13 Mar 2019 09:54:10 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Mar 2019 09:54:10 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <3E6E5A5B-C1B1-4ABF-89AB-C5FAF634F080@apple.com>
References: <3E6E5A5B-C1B1-4ABF-89AB-C5FAF634F080@apple.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 13 Mar 2019 09:54:10 -0700
Message-ID: <CAN1APdep9iW+nurOhjCBVNO-KiPEEr_6xsgvSQ0zkRDnAr9Wqg@mail.gmail.com>
Subject: Re: QUIC Address Extension for NAT detection
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, QUIC WG <quic@ietf.org>
Cc: Eric Kinnear <ekinnear@apple.com>, Chris Wood <cawood@apple.com>
Content-Type: multipart/alternative; boundary="000000000000a009500583fca7df"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/hFxTy9Cvta-_igCqk5uUiPAaD3w>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 13 Mar 2019 16:54:14 -0000

How does that work when you are behind multiple layers of translations,
which isn’t that unusual in a cloud environment:
Client has a nat router at home, cloud has public to private IP mappings.

Also, this information could provide information about cloud infrastructure
that maybe best stays local - not sure about implications. But a standard
web framework terminating QUIC might have no idea about the surrounding
infrastructure and volunteer more information that the cloud infrastructure
wants to.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 13 March 2019 at 17.20.02, Tommy Pauly (tpauly=40apple.com@dmarc.ietf.org)
wrote:

We recently posted a draft that defines a proposed extension to QUIC that
allows peers to request their perceived IP address and port from their
peer, effectively allowing NAT detection along a path:

QUIC Address Extension
https://datatracker.ietf.org/doc/draft-pauly-quic-address-extension/

We have posted a corresponding document in TLS that provides the same
mechanism for TLS/TCP connections:

TLS Client Network Address Extension
https://datatracker.ietf.org/doc/draft-kinnear-tls-client-net-address/

One of the benefits specific to QUIC from detecting a NAT is that it helps
determine whether or not NAT rebindings are expected to create “fake”
migration events. It also helps a client know whether or not rotating CIDs
and local ports will be of use to obfuscate a client’s connections.

If you have any thoughts on use cases for this information, or the
mechanism, we’d love to hear them!

Best,
Tommy

v2.23.0 | Report a Bug | By Email