RE: Connection IDs

"Lubashev, Igor" <ilubashe@akamai.com> Thu, 08 March 2018 00:36 UTC

Return-Path: <ilubashe@akamai.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 2FEF61243FE for <quic@ietfa.amsl.com>; Wed, 7 Mar 2018 16:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=akamai.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 588vEA6UP34o for <quic@ietfa.amsl.com>; Wed, 7 Mar 2018 16:36:56 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 DB1C612008A for <quic@ietf.org>; Wed, 7 Mar 2018 16:36:55 -0800 (PST)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w280WLMn026710; Thu, 8 Mar 2018 00:36:50 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=263EOvKPNCSexYCr89Kz+9XGJUQ8sIk4bgKdHIjH7FY=; b=ePlqoTIv8rDJBqV9iPRXh/9a68RwI52LDpeAdRiuzNqOBqJg1GqxnZFIp79M6oxkmEm8 XdHbK3ujTLQKRoSgOP8NuCKFPcP8wqakF1NUJaYNTAPu0twPTDVQYjGVZJsCEhV96aPq og95Ilbpl467nM7nt8fIfe1ASvvRI+PRo5VKV+ti3mTfOmWtb44g7zzF9CGs9sdR8DJI mzi2vWL5PqCHqSq1yK6kIvj+sJty6LIZojk/UA5wql9VvvV3JgS7/VUGlGM/wLybUVD1 /DeQjxssZ5l2RxvOO4taSpIVvtQviUMx6wcvrTDtLyVMNtrqwbRFya91Z2HgoAv1dnHz TQ==
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2gjanttukr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Mar 2018 00:36:50 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w280ZZuh005627; Wed, 7 Mar 2018 19:36:49 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2gfqx0v092-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 07 Mar 2018 19:36:49 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 7 Mar 2018 16:36:48 -0800
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 7 Mar 2018 19:36:47 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Wed, 7 Mar 2018 19:36:47 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Martin Thomson <martin.thomson@gmail.com>, Jana Iyengar <jri.ietf@gmail.com>
CC: Ian Swett <ianswett@google.com>, Subodh Iyengar <subodh@fb.com>, "Mike Bishop" <mbishop@evequefou.be>, Patrick McManus <pmcmanus@mozilla.com>, "IETF QUIC WG" <quic@ietf.org>
Subject: RE: Connection IDs
Thread-Topic: Connection IDs
Thread-Index: AQHTtCTv1bQfI/TxYU6PAlbZLWVMHKPB8OMAgAAPfICAALkxgIAC1QgAgAACEoCAAAJ+AIAAFHWAgAANuoD//8iX4A==
Date: Thu, 8 Mar 2018 00:36:47 +0000
Message-ID: <585499f5ea2d49ca8691dc05d06e99fb@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <CABkgnnVSCnmzjWOZwQM+ctTxFXVzsVYe6Q3Zzk4yj3LNTYUtHw@mail.gmail.com> <CAOdDvNo9qmZqmEXBGM4bM6q3EO1FGuUxLSSWsVhNEYsn5u9puQ@mail.gmail.com> <CAKcm_gMR070JUegQbDw--RNr+0XYiBMwaTM3MBmqUo21u922TQ@mail.gmail.com> <CACpbDccpuNWnX=Y+gKaPxLEjUOnvu+hr9FqH+R6ZspwOfUq-qg@mail.gmail.com> <CABkgnnUPJYG-QE4qxfOd-6AoHHgxVq4K=EyRfoxkcvdDF=oaZA@mail.gmail.com> <MWHPR15MB18215C39DCB3DC5398778EC6B6D80@MWHPR15MB1821.namprd15.prod.outlook.com> <SN1PR08MB1854C45248CD637877C50FACDAD80@SN1PR08MB1854.namprd08.prod.outlook.com> <CACpbDccER27gggsst4DPf-JhtZNDQGdYMX8neaHVcfR19T3hzA@mail.gmail.com> <CABkgnnXcuH8tsgSud-3=8-V96NVVUoYFQe1EZJAbLeTJ74fc_A@mail.gmail.com>
In-Reply-To: <CABkgnnXcuH8tsgSud-3=8-V96NVVUoYFQe1EZJAbLeTJ74fc_A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.36.81]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-07_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803080005
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-07_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803080005
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mbvJDr-DxxWuERbaz5fAc_WyQ5w>
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: Thu, 08 Mar 2018 00:36:58 -0000

+1 for the connid direction from someone from an "eligible" employer.

That said, the proposal precludes load balancers from using Conn ID possibly present in ICMP TooBig payload for routing the ICMP TooBig back to the server, so I am looking forward to "PMTUD for QUIC" talks in QUIC and TSVWG.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Wednesday, March 07, 2018 5:38 PM
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Ian Swett <ianswett@google.com>om>; Subodh Iyengar <subodh@fb.com>om>; Mike Bishop <mbishop@evequefou.be>be>; Patrick McManus <pmcmanus@mozilla.com>om>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Connection IDs

Comments are always appreciated :)

On Thu, Mar 8, 2018 at 8:48 AM, Jana Iyengar <jri.ietf@gmail.com> wrote:
> I approved the design earlier and I still approve the design, employer 
> notwithstanding :-) I have comments, which I've left on the PR.
>
> - jana
>
> On Wed, Mar 7, 2018 at 12:35 PM, Mike Bishop <mbishop@evequefou.be> wrote:
>>
>> I think Christian’s concerns were addressed.  Language was added to 
>> require that if you see a CID change, you also need to move to the 
>> next CID you have available.  An issue was opened to track the “what if you run out?”
>> question.
>>
>>
>>
>> There was briefly language added saying that if you see the peer 
>> change addresses without changing CIDs, you should change CIDs for 
>> them.  However, if we do that, an on-path attacker can start 
>> rewriting source addresses on packets to drain your pool of allocated 
>> CIDs and force you into the newly-opened issue.
>>
>>
>>
>> However, Christian should confirm whether these resolve his concerns.
>>
>>
>>
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Subodh Iyengar
>> Sent: Wednesday, March 7, 2018 12:26 PM
>> To: Martin Thomson <martin.thomson@gmail.com>om>; Jana Iyengar 
>> <jri.ietf@gmail.com>
>> Cc: Ian Swett <ianswett@google.com>om>; IETF QUIC WG <quic@ietf.org>rg>; 
>> Patrick McManus <pmcmanus@mozilla.com>
>> Subject: Re: Connection IDs
>>
>>
>>
>> Unsurprisingly I am positive on the direction of this as well and the 
>> PR looks good to me
>>
>>
>>
>> Note: I do not work for mozilla or google :), but was a part of the 
>> connid design
>>
>>
>>
>> IIRC there was one unresolved question by Christian about both 
>> clients and servers needing to change the connids to enforce 
>> linkability, was that resolved?
>>
>>
>>
>> Subodh
>>
>> ________________________________
>>
>> From: QUIC <quic-bounces@ietf.org> on behalf of Martin Thomson 
>> <martin.thomson@gmail.com>
>> Sent: Wednesday, March 7, 2018 12:19:02 PM
>> To: Jana Iyengar
>> Cc: IETF QUIC WG; Patrick McManus; Ian Swett
>> Subject: Re: Connection IDs
>>
>>
>>
>> Just to add to this and bring this list up to speed...
>>
>> Ian opened https://github.com/quicwg/base-drafts/issue/1166 which 
>> suggests moving the Version field into a fixed location.
>>
>> To that end: https://github.com/quicwg/base-drafts/pull/1167
>>
>> Does anyone have anything more to add (perhaps someone who does not 
>> work for Mozilla or Google) here?  The feedback I've received is 
>> overwhelmingly positive thus far and my hope is to merge this ahead 
>> of the editors starting an extended editing session next week.
>>
>>
>> On Tue, Mar 6, 2018 at 12:04 PM, Jana Iyengar <jri.ietf@gmail.com> wrote:
>> > +1 to this is the direction we're all converging on.
>> >
>> > On Mon, Mar 5, 2018 at 6:01 AM, Ian Swett 
>> > <ianswett=40google.com@dmarc.ietf.org> wrote:
>> >>
>> >> Agreed, I unsurprisingly think this is the right direction.
>> >>
>> >>
>> >> On Mon, Mar 5, 2018 at 8:05 AM Patrick McManus 
>> >> <pmcmanus@mozilla.com>
>> >> wrote:
>> >>>
>> >>> big picture this is good.
>> >>>
>> >>> On Sun, Mar 4, 2018 at 8:54 PM, Martin Thomson 
>> >>> <martin.thomson@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> I've written up a PR that enacts the changes suggested by the 
>> >>>> design team [1].
>> >>>>
>> >>>> https://github.com/quicwg/base-drafts/pull/1151
>> >>>>
>> >>>> This adds two connection IDs to the long header.  An explicit 
>> >>>> length is added for each.
>> >>>>
>> >>>> The short header includes the raw connection ID without any C 
>> >>>> bit or length.
>> >>>>
>> >>>> I've tried to explain the limitations of the design where they apply.
>> >>>> That includes stateless reset.
>> >>>>
>> >>>> This PR necessarily includes some choices about less critical 
>> >>>> aspects, such as how connection ID lengths are encoded.  I ask 
>> >>>> that you try to separate objections about minor issues like this 
>> >>>> from more serious structural concerns.  I'm happy to discuss 
>> >>>> details, but I'm most interested in whether this is broadly the 
>> >>>> right direction first.
>> >>>>
>> >>>> Cheers,
>> >>>> Martin
>> >>>>
>> >>>> p.s., happy draft submission deadline day
>> >>>>
>> >>>> [1]
>> >>>>
>> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive
>> >>>> .ietf.org_arch_msg_quic_l-5Fb1NnBmQpQGCxCfQteOMkft-2DlE&d=DwIBaQ
>> >>>> &c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=tfbg3BLo-IK
>> >>>> 9aUKrHNiK-A7EBi5XuVtoq9cZsYYBwbA&s=50Q1gLhlSOcRuTmcpkgAnBusZim2N
>> >>>> ElvKAFN6IIX2Ec&e=
>> >>>>
>> >>>
>> >
>
>