Re: Asymmetric CIDs

Christian Huitema <huitema@huitema.net> Sat, 17 February 2018 08:12 UTC

Return-Path: <huitema@huitema.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 05F5D12025C for <quic@ietfa.amsl.com>; Sat, 17 Feb 2018 00:12:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 eooPqyRIk02h for <quic@ietfa.amsl.com>; Sat, 17 Feb 2018 00:12:11 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27601200E5 for <quic@ietf.org>; Sat, 17 Feb 2018 00:12:10 -0800 (PST)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx26.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1emxbM-0008Vt-I5 for quic@ietf.org; Sat, 17 Feb 2018 09:12:09 +0100
Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1emxbJ-0003Zo-Jq for quic@ietf.org; Sat, 17 Feb 2018 03:12:06 -0500
Received: (qmail 14536 invoked from network); 17 Feb 2018 08:12:04 -0000
Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.15]) (envelope-sender <huitema@huitema.net>) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for <martin.h.duke@gmail.com>; 17 Feb 2018 08:12:04 -0000
To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= <mikkelfj@gmail.com>, Nick Banks <nibanks@microsoft.com>, Roberto Peon <fenix@fb.com>, Ian Swett <ianswett@google.com>
Cc: Eric Rescorla <ekr@rtfm.com>, IETF QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com>
References: <CABcZeBMVabN9LQ42BxpSwK71hzu_TbzwqhHTJV1uJBKr5g-N3A@mail.gmail.com> <CAKcm_gOvf0N7sq2so38sQaD+2jHGnDpsSQHEwU8HPgSpMJRfzA@mail.gmail.com> <CAM4esxQW1-dVfJSi4zoURNV-7u0EP6h-Xdyx5Wbo0QMdrkLk=w@mail.gmail.com> <AA0705E2-7A79-47DD-846A-C0B74A8A4B24@huitema.net> <D7E469CD-B9D8-41ED-8F5C-9933DCBA90E6@fb.com> <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net> <BN6PR21MB0178395DC04C19D991436525B3CB0@BN6PR21MB0178.namprd21.prod.outlook.com> <CAKcm_gNeFJUP_1VFxSri=V+iDJR9RxvTwmca45bLM0m0BHo-Hw@mail.gmail.com> <BY2PR15MB077577E4358F9922047685A8CDCB0@BY2PR15MB0775.namprd15.prod.outlook.com> <CAN1APdeOm+Bguwx=9hZxgnArNi+iC=QufKkQ=4bScNEU+dyK4g@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <9dfed68d-851d-d1aa-8559-92a42b7c923e@huitema.net>
Date: Sat, 17 Feb 2018 00:12:02 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAN1APdeOm+Bguwx=9hZxgnArNi+iC=QufKkQ=4bScNEU+dyK4g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------C068D5E77F8C156120A97080"
Content-Language: en-US
Subject: Re: Asymmetric CIDs
X-Originating-IP: 168.144.250.232
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.57)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5os7TBGZoTAL3fQZfkAOmVl602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVi23aYmfXg7s6pVf9WD7ZaWM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBy0LkIcQZ+RRGzUcmNZyDXh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYg8fO0sqTNbFIxwq5nK+B tNm4YXH+1fMTrNbJKTtzvwPl5YmPKOW53PX48RxyAL8AeEryWDFh6OMgZL2eLBxw4AfG/OGabeQO D+JyvmSUpW+ZQTl/k5oRlt1ErWfaEWxe22o4BNBy+bVfxj88zI41K1O7B0jvACHkMSS0WCQUO4Cp b4mi9wLRe0dO1qfOpsb8SGG/BQd7r2NVEaNhWos5ptTilnCILaTRj+RmJnkgHAAccBIk1Sag4dKi qCrF8eZZeNMTAWyxeqt3BjCO03tBtqMfDzEXpr5sTuNVuzYBPE2Bi6owqeb+h1kbxIVWYdC7uVGB tJ1DsK23UcLYdhI56Feqv/VOJZnHunWcIBzbsDrLaeA4pl20N4bgeYf9w8whIRFsicyJMEhQFtD8 PLoinpgjWjpMfsxmWdg884icSQEZwRvSfvkJh2VafuDhMcA1uHlEIbR8fMtAowK0FL525g==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/s1RuBWeCCd9U__hPYGCYotcXLbM>
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: Sat, 17 Feb 2018 08:12:13 -0000

On 2/16/2018 4:22 PM, Mikkel Fahnøe Jørgensen wrote:

> This looks good to me.
>
> Path migration might involve CID validation so a connection shuts down
> if a single endpoint messes up linkage.

"Implement migration correctly, or the connection will break on
migration." That may work if the QUIC stack wants to actually make
migration work. And I suppose that a stack that does not care about
migration would simply not provide "NEW CONNECTION ID" in the first
place. If one peer sends data with a CID, the responder needs to also
select a new asymmetric CID in the replies, and must not send a reply if
no such new asymmetric CID is available -- with suitable exception for
0-length CID. This requires that a new asymmetric CID is available, and
as Nick suggested this can be made foolproof by sending a NEW CID frame
in the migration packets.

My point is mostly that iwhen we write the asymmetric CID PR, we must
actually specify the migration behavior.

-- Christian Huitema