Connection migration PR
Jana Iyengar <jri@google.com> Mon, 12 February 2018 06:59 UTC
Return-Path: <jri@google.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 C7F90124BE8 for <quic@ietfa.amsl.com>; Sun, 11 Feb 2018 22:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 khiSrQbHs-8C for <quic@ietfa.amsl.com>; Sun, 11 Feb 2018 22:59:04 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 D88D4126E64 for <quic@ietf.org>; Sun, 11 Feb 2018 22:59:03 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id l11so6064675ywh.2 for <quic@ietf.org>; Sun, 11 Feb 2018 22:59:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eOO+bnMh+KhK8/iIoXuNylgWZVT2X+OgYGHbG0Dex38=; b=kBx1sLawGS17UfHnl6jU3zqJJbYyndQDjvd89CVZFH3k/kA+7U+2AEk7ncto4XaN0h HcQ+BRJNhOtmr9GZOqqi/thK+yIx9SYumkG8Mw4n1mMDMTMwLTUZYO0qfYtNVywoN64n lZ+7lQWl9qYbrF0qwfc1/F6fO1sUfT0ZiX2VmGheGjUZFetuCbJFF7nthrEmVihtC2yu f0gpe0BaDVIb0U0bK3wg5gkVV47Pku8RmHse8eNOwGn1HXHpE/o+MeWXeokR4zI/t/D3 MN0hleUlFJdpgQNpvVMqV8f6H3sicPMRHWiUUv4PBNPRzx/YDgHY9N7JMrt2hZKDjB/a r9/g==
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=eOO+bnMh+KhK8/iIoXuNylgWZVT2X+OgYGHbG0Dex38=; b=CPLdbvqoYLn7t4vPfYaNnRiI4DLwFRS1ljQ3f4CsZNX5E7G7yEr6j1BGmkN7rjVHG6 LNyhHfxnmSQqS/VeXuKmFTwoZpT4JQwvLwlAiaIC2xisDAD8P1FNXdKlOK6u62xjqbm3 rSsL+G1DQ2c438LPHXidevY7UqGFKwCfrKEU62jinMXi3l/KIw2JFz9FlgN8uhXzCH5z mBJlmUMSqFzvuCzivu301GWeD5AWtnbl3YhU2YCIL2vhKF301PjAglLCTvK/qvelMtYP XHM3Ed3aBKK8vil0G6Ylxq7WJPUimooM9uJDqx8ZAc3UWBz5Tt22x7JuQgOEaw3eG4w6 Xh2A==
X-Gm-Message-State: APf1xPBjLN9vdQPvj3NE2972AKLpAUI5sK2ZJn3oRkRkoHmHvbVTKZvK mrPkSF9iDGNygVBy8w5++2nKaY4S+GT3O078LNLR4ONdJuI=
X-Google-Smtp-Source: AH8x224wnGggj93IU6FSiYUb6j/9MbaKrzHq+2ZzlTMMth24MWfTJ0a2eNE9LiuMnMnLVqanebS3egMRTDPCYCnHBtc=
X-Received: by 10.37.104.13 with SMTP id d13mr6689321ybc.290.1518418742540; Sun, 11 Feb 2018 22:59:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.135.77 with HTTP; Sun, 11 Feb 2018 22:59:01 -0800 (PST)
From: Jana Iyengar <jri@google.com>
Date: Sun, 11 Feb 2018 22:59:01 -0800
Message-ID: <CAGD1bZZK6659R8FktCZ5zxBTZg_e9HPNepAak5PcuRiTcdQqFg@mail.gmail.com>
Subject: Connection migration PR
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="f403045c0020c583f00564fe6906"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/qdpQ9FoIUIVl_rwMbt7-Kdiy9dw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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, 12 Feb 2018 06:59:06 -0000
FYI: PR #1012 <https://github.com/quicwg/base-drafts/pull/1012> about connection migration. This PR replaces the existing connection migration mechanism in the draft with one that allows a client to probe from an alternate address before actually migrating to it. It also fixes a few holes in the current mechanism. I've done a rewrite based on the comments on the previous version and from the interim. The packet number skip behavior remains unchanged, but that's going to have to come out of the ongoing packet number encryption conversation. For the time being, I would like to leave that aspect untouched in this PR. FWIW, encrypting packet numbers makes it trivial to not track state across multiple connection IDs in series. It needs careful thought otherwise. I am also limiting the migration protocol to client migration since making the description symmetric adds sharp edges that need to be more carefully dealt with. I'm restricting the scope of this PR to the client/server use case that's most relevant for v1.
- Connection migration PR Jana Iyengar