preferred_address outside of handshake

Luke Curley <kixelated@gmail.com> Mon, 16 September 2019 06:01 UTC

Return-Path: <kixelated@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 D39BE1200F7 for <quic@ietfa.amsl.com>; Sun, 15 Sep 2019 23:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_HELO_NONE=0.001, SPF_PASS=-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 MaSpD2g1AWHr for <quic@ietfa.amsl.com>; Sun, 15 Sep 2019 23:01:47 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 0198B1200B8 for <quic@ietf.org>; Sun, 15 Sep 2019 23:01:46 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id e18so3083298oii.0 for <quic@ietf.org>; Sun, 15 Sep 2019 23:01:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pbTSd3sm9REjgGsycd+CWKFczA+CW0A3w7yaaBH5bBk=; b=BTf12FeVcW5PkvBVW9YpDlMoGgk2gIRkdjN0+WOpKwqZ2YZJB23fN2PBjX1X/C6SAs +XNhLj5isIoM4OoIsZxCNLINJ992S1wHP7xyAE6oE6p8VdCleT1s8yeSmbbQvczd3Lav eloThSFgOzbcIGyG5YpUSZlsZjn/5uU6RqvSKEuNgrz8nQDFTjTLtuVqxsgyPt68Mpft mLsBUv9NmLN1xMKzbg0fI8LVWoNd6bcUrp/bckzARlqNIzKvyWZ/X+thn8ZMJbcvUG60 JzN2ppB89GBtAI8Bp2C+mbYn39Ro54pVq04rRaQOi7kEofqw3/pefUMUYfjg41ikSOXi 0IUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pbTSd3sm9REjgGsycd+CWKFczA+CW0A3w7yaaBH5bBk=; b=NgJHsg7HUYy5Mu8Jhwc2ucV3SxP3p4fuAWTrimhsYYMbI5/pHlvRxezfgmr3XOCcpb 8D4zd4/M4d5qXGdMFjZo54fEh7lTsCrgIeL3u1WWF41D/Zruunl4XT9+wBLbHrEmIEmh FCthu/qRu3YE1I+yiERb/UW11UAYK1NzDzi9Z7P7K9epSi2ix70H+gykCsKPBqI9+ODA V1NnRzJJ3hJK7PNLf3vQ0nSarbykGWg1Tja+pCIEW4dPajCYjkX03pKSEYY74nWUeEis em8Y8hxo7OXQ4Bw6XJSb9tGXlx9T2AsyZg+3O64FryGS+Y2tlZSQOiCK+2IdJ1z35/Bk EwYA==
X-Gm-Message-State: APjAAAUNzA3DZ3Uyu+0fwFLSeoAOtRjfCqCTCAPucQ0/VK2EMX2yomVt BwTq5ZvZkhzxahNp8BAD8Zd//0YrDg5Sg+gXOBgjk90v
X-Google-Smtp-Source: APXvYqxvnCfKDLLr/esu32w2PInyl9xoHNYzNFIE9KNO40lQogSPlpoVB5ad/1NrrBuDZ+rHuslSTAd36poMlR020kE=
X-Received: by 2002:a05:6808:24a:: with SMTP id m10mr12651653oie.24.1568613706060; Sun, 15 Sep 2019 23:01:46 -0700 (PDT)
MIME-Version: 1.0
From: Luke Curley <kixelated@gmail.com>
Date: Sun, 15 Sep 2019 23:01:35 -0700
Message-ID: <CAHVo=Zm-0m6dttMfLRSLVNq19PHy1VhzTW0e4p+thVc_ZT0s+g@mail.gmail.com>
Subject: preferred_address outside of handshake
To: quic@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bd57810592a55682"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/SBlDrfrXSEXVYl_UKiAuaKCNp5s>
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: Mon, 16 Sep 2019 06:01:49 -0000

Hey guys,

I've spent the last few days reading the QUIC spec and it's amazing. One
thing I love is preferred_address as it gives the server the ability to
redirect traffic from an anycast address to a unicast address (among other
uses). This would obsolete DNS load balancing in many cases!

However, it's only possible to use preferred_address during the handshake.
If there was a frame that behaved the same way, then it would be possible
to migrate traffic to another address. This would be extremely useful; you
could migrate to another port for graceful restarts or another IP address
(including anycast!) to drain the entire host.

This is almost possible today as the new server can send packets (from a
new address) and cause the client to initiate a PATH_CHALLENGE. However,
this won't always work when the client is behind a NATs. What you really
need is the client to punch a hole in the NAT by explicitly telling the
client when to initiate a PATH_CHALLENGE.

What about something like PATH_CHALLENGE_REQUEST, containing similar
information as preferred_address? I even think this frame should replace
preferred_address as it's not a critical handshake parameter.


Thanks!