Re: [quicwg/base-drafts] A more complete connection migration (#1012)
Martin Thomson <notifications@github.com> Mon, 01 January 2018 23:57 UTC
Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04531124B18 for <quic-issues@ietfa.amsl.com>; Mon, 1 Jan 2018 15:57:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
X-Spam-Status: No, score=-2.03 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 J8dn0h2Ke-CC for <quic-issues@ietfa.amsl.com>; Mon, 1 Jan 2018 15:56:57 -0800 (PST)
Received: from o1.sgmail.github.com (o1.sgmail.github.com [192.254.114.176]) (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 8345412426E for <quic-issues@ietf.org>; Mon, 1 Jan 2018 15:56:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=6edLP6Tdplnc5K2MqSP8VWtrj1A=; b=Tr+ON8ALXVuUYLGR PVJnRDn6eCwIRlIYHb1Z2a0fveOpPFz03+k1CQJCgR8AFIWYddQmud6JgWM8A2Wm w4RgYgbhxwXCdijHLSo3S87z5w4KZWBQ6DVMye5Siqx1vmxDVnOD6szUUas9MUSW okQKJR8XeQevM1wCr6PDaefNf3E=
Received: by filter1185p1mdw1.sendgrid.net with SMTP id filter1185p1mdw1-4326-5A4ACAC8-2F 2018-01-01 23:56:56.860484903 +0000 UTC
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0016p1iad2.sendgrid.net (SG) with ESMTP id Aw4vyQ7rQ5mfYYmfV6Q1lg for <quic-issues@ietf.org>; Mon, 01 Jan 2018 23:56:56.805 +0000 (UTC)
Date: Mon, 01 Jan 2018 23:56:56 +0000
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab1754e573a09168f912ff24f1596cd14c2efbfaee92cf0000000116628cc892a169ce10c89c07@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1012/review/83548162@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1012@github.com>
References: <quicwg/base-drafts/pull/1012@github.com>
Subject: Re: [quicwg/base-drafts] A more complete connection migration (#1012)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5a4acac8aaaca_52523ff717e04f2c1477d3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3vIZ2s15Qnias6mZJKrWGJeXwa2l8VMFFPvr OWvsLb/wLx9daHI+6gZGO5otlNGN0A7uz5Zn+AwYAhHBqzlVFnAzRDF471nSLPDHEWMocs8SNvj8S1 x1HHP4AWd265V+s8nhWybo3nsE1qVcvDWjIhOaoCvROglR82/iBOqZ8C/CmfdxcgCQRq2X4qReff42 c=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/9rmmkT7xA-mV9u-Wm1DiZaV-FpY>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jan 2018 23:57:00 -0000
martinthomson commented on this pull request. I found these old comments. I haven't double-checked if they are still valid though. I agree with Christian about the packet number gap, but I'd like to address that separately. > +frame. The client considers the PMTU verified when a PATH_RESPONSE frame +containing the same payload sent by the server to the new client address is +received. + + +### Client Behavior {#migration-client} + +A client triggers connection migration to a new address by sending a +PATH_CHALLENGE as a probe or by switching to sending all packets to the new +address. The client SHOULD do PMTU verification before considering migration +complete. The client also participates in an address validation that the server +may initiate to confirm the client's ownership of its address (see +{{migration-server}}). + +A client migrating to a new network might use a new connection ID for packets +sent from the new address, see {{migration-linkability}} for further discussion. There's an assumption in the current design that connection IDs are used in series. If a client wants to send on a new path, then it will want to use a new connection ID. But it will then send on the original path, and that will need a different connection ID. It can't use the original connection ID, or the one that it used on the path it was probing with the current design. With the potential need for multiple probes on the new path, interleaved with continuing packets on the old path, this will consume far more connection IDs than our current design really allows for. Or it will be linkable. This is where I think packet number encryption/obfuscation will help. It will allow us to switch back to the old connection ID without having to worry about gaps in packet numbers. I think that we will need to fix that. That doesn't make me think that this is a broken design, only that it reveals that our current design for unlinkability across paths is not suitable any more. > @@ -2358,17 +2419,56 @@ Application Error Code: {{app-error-codes}}). +## PATH_CHALLENGE Frame {#frame-path-challenge} + +Endpoints can use PATH_CHALLENGE frames (type=0x0e) to check reachability to the +peer, to verify a new path's PMTU, and to perform address validation during +connection migration. Yeah, I think that the requirement for a minimum size on probes is a requirement on the probing packet, not a property of any particular frame that it contains. > + +~~~ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Length(8) | Data (*) ... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~~~ + +Length: + +: This 8-bit value describes the length of the Data field. + +Data: + +: This variable-length field contains arbitrary data. Maybe look at it this way. We have a certain dependency on the connection ID for path verification during the handshake and that is only 64 bits. So, maybe we can reasonably say that 64 bits is enough here as well. > +: This 8-bit value describes the length of the Data field. + +Data: + +: This variable-length field contains arbitrary data. + + +The sender of this frame MUST include at least one octet of data in the Data +field. + +The recipient of this frame MUST generate a PATH_RESPONSE frame +({{frame-path-response}}) containing the same Data. An endpoint that receives a +PATH_CHALLENGE frame containing an empty payload MUST generate a connection +error of type FRAME_ERROR, indicating the PATH_CHALLENGE frame (that is, 0x0e). + +A PATH_CHALLENGE frame MUST NOT elicit acknowledgements; the corresponding But frames do elicit acknowledgments. Generally. ACK doesn't. The "MUST NOT" isn't appropriate; it seems like the intent is to say that it doesn't elicit acknowledgment (that is, it's not an interoperability requirement, it's just a property). I don't think that it makes sense to have special acknowledgment rules for PATH_CHALLENGE though. Acknowledging PATH_CHALLENGE doesn't contribute to path validation, but on the other hand explicitly excluding it creates another exception. I don't see any reason to suppress acknowledgments in this case. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/quicwg/base-drafts/pull/1012#pullrequestreview-83548162
- [quicwg/base-drafts] A more complete connection m… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… Martin Thomson
- Re: [quicwg/base-drafts] A more complete connecti… erickinnear
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… Martin Thomson
- Re: [quicwg/base-drafts] A more complete connecti… Mike Bishop
- Re: [quicwg/base-drafts] A more complete connecti… MikkelFJ
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… Christian Huitema
- Re: [quicwg/base-drafts] A more complete connecti… Christian Huitema
- Re: [quicwg/base-drafts] A more complete connecti… Christian Huitema
- Re: [quicwg/base-drafts] A more complete connecti… Christian Huitema
- Re: [quicwg/base-drafts] A more complete connecti… Martin Thomson
- Re: [quicwg/base-drafts] A more complete connecti… ihlar
- Re: [quicwg/base-drafts] A more complete connecti… Martin Thomson
- Re: [quicwg/base-drafts] A more complete connecti… erickinnear
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… ihlar
- Re: [quicwg/base-drafts] A more complete connecti… MikkelFJ
- Re: [quicwg/base-drafts] A more complete connecti… ianswett
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… ianswett
- Re: [quicwg/base-drafts] A more complete connecti… Martin Thomson
- Re: [quicwg/base-drafts] A more complete connecti… Mike Bishop
- Re: [quicwg/base-drafts] A more complete connecti… Mike Bishop
- Re: [quicwg/base-drafts] A more complete connecti… Martin Thomson
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… Mike Bishop
- Re: [quicwg/base-drafts] A more complete connecti… Mike Bishop
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… erickinnear
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… ianswett
- Re: [quicwg/base-drafts] A more complete connecti… Mike Bishop
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… Christian Huitema
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… Martin Thomson
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar
- Re: [quicwg/base-drafts] A more complete connecti… janaiyengar