Re: negotiating Packet Number Protection

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Fri, 07 September 2018 03:30 UTC

Return-Path: <mikkelfj@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 054E4126BED for <quic@ietfa.amsl.com>; Thu, 6 Sep 2018 20:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_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 MFon9aB20cSN for <quic@ietfa.amsl.com>; Thu, 6 Sep 2018 20:30:20 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 ED887130DCB for <quic@ietf.org>; Thu, 6 Sep 2018 20:30:19 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id u12-v6so13409518wrr.4 for <quic@ietf.org>; Thu, 06 Sep 2018 20:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=Dh6DEtXFczzbPDWQgyeqj74bV1OtKHskxhtY8Z/oXkM=; b=cDtGhXZkkiBGJN7vpdAb16GwkOaoXrMgZPRGWfh5fCp7UzCeCH5p48z5cQXUilDtV7 4s9m+Q7Wq/b2BnSCfeGTXKHhJvr/EdO8AZIYGmt9pX7K1F3RxRw041j9hJORA5KJZXd/ kdEX0xaIwUXpmWYaXEw/1M53VdOO3Byqed1DZJrAiMBdCoNgGEjGCe1qya1QuQraHx70 rz/kF8y0eROyZxdCAZS343sz1dWRWO+0V2rnkFQ96ml1ygIsIynGIBalFSxYj9NAxO2w p76XuMHHKOXsLKwumhvWYrn/TmmodYJpRhO/RlF2lVnmQD1Qf9U6F0FqKzehLX8nOYVP hgZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=Dh6DEtXFczzbPDWQgyeqj74bV1OtKHskxhtY8Z/oXkM=; b=QB5Y8MAzLt8a93tlIoe4i9X+bSAePWdJcvXlpOWrGBrqecck+SKvVI+tzPe9wFaCI/ j6H8m9eJihw+FfgZixl2RsMR3yjEXxrN0IeaisnALp9zAg7CK+un2N3FOwWfcaerDwZP 5ZPowtc+9AA93HpZbFJi+rgciEuP5We2ddxD9xxaTcdpw7IBnmCRy2Y7hQprWePqTJck OdRE5GOJryW1YAH6TUnRBLi4cJzT/SwC+uK4aXVvor8tWGUSwH3wERf2Gtt/KwMMHFcs XVURlzgSQnE7+FkMzQAx+D68nUtYEKmww7kv+z3RuRTo6hyFarQCmoqVnK6Xz195DCLl 8Wbw==
X-Gm-Message-State: APzg51AJbRUtuJQ/9ADziTvvdwR+aIg8yVxuS8JjDScPuzN8d4eU/A2D S79anT5EEdr2REKZcqx6i1YLxrwYBkc=
X-Google-Smtp-Source: ANB0VdYFCHsRivpTvAebGpkQPs8eQ1ODBYH0Iyak3hIi0CVhuib5CImgOJ7U3rxZEOO4wlPQOPTK6w==
X-Received: by 2002:adf:e8c1:: with SMTP id k1-v6mr4372665wrn.43.1536291018014; Thu, 06 Sep 2018 20:30:18 -0700 (PDT)
Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id y128-v6sm7610108wmy.26.2018.09.06.20.30.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Sep 2018 20:30:16 -0700 (PDT)
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
To: Christian Huitema <huitema@huitema.net>, Martin Thomson <martin.thomson@gmail.com>, "gabriel.montenegro=40microsoft.com@dmarc.ietf.org" <gabriel.montenegro=40microsoft.com@dmarc.ietf.org>
CC: QUIC WG <quic@ietf.org>
Subject: Re: negotiating Packet Number Protection
Thread-Topic: negotiating Packet Number Protection
Thread-Index: ATA3QzcwPlVDUWaJFETTE1Zs8pDJrWc4LV9TODExYWPDIuTKhA==
X-MS-Exchange-MessageSentRepresentingType: 2
Date: Fri, 07 Sep 2018 03:30:15 +0000
Message-ID: <DB6PR10MB1766D14FF9B5C1971B72471DAC000@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM>
References: <DM5PR21MB01393FE7097A16C7A68EA7BE95010@DM5PR21MB0139.namprd21.prod.outlook.com> <CABkgnnViOSQOYeEL4bL_hq6jPDaGR-G+O=A96C78+X4mheWaxg@mail.gmail.com>, <0d5fb94c-3a79-ac40-ee12-193d190d4408@huitema.net>
In-Reply-To: <0d5fb94c-3a79-ac40-ee12-193d190d4408@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1766D14FF9B5C1971B72471DAC000DB6PR10MB1766EURP_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rohCVTf-yY5Pwe32xdzNIe0-aG0>
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: Fri, 07 Sep 2018 03:30:23 -0000

The MUST not disable PNP on internet facing nodes is too strong - you want a deployment to be able to move to a new DC while talking to the old DC - although ossification could br a concern, it is not egen limited to quasi stationært use cases.

________________________________
From: QUIC <quic-bounces@ietf.org> on behalf of Christian Huitema <huitema@huitema.net>
Sent: Friday, September 7, 2018 4:09:01 AM
To: Martin Thomson; Gabriel.Montenegro=40microsoft.com@dmarc.ietf.org
Cc: QUIC WG
Subject: Re: negotiating Packet Number Protection

This draft requests assignment of single byte code point. I would rather
not do that know, as we are discussing reserving several consecutive
codes for ACK variants and options. Would it be a deal breaker if the
option used a longer code?

-- Christian Huitema


On 9/6/2018 5:05 PM, Martin Thomson wrote:
> This is an entirely appropriate use of transport parameters and it
> looks like the design works as intended.  I tend to think that the
> IETF doesn't need to publish this - this sort of extension is why we
> have relatively loose registration policies - but I'm happy to have
> that conversation at the appropriate time.
> On Fri, Sep 7, 2018 at 8:55 AM Gabriel Montenegro
> <Gabriel.Montenegro=40microsoft.com@dmarc.ietf.org> wrote:
>> Folks,
>>
>>
>>
>> We just submitted a draft to negotiate Packet Number Protection. This would allow disabling it in environments (e.g., in a datacenter) where it may no be needed if both sides agree. Browsers, of course, would probably not bother with this.
>>
>>
>>
>> https://tools.ietf.org/html/draft-montenegro-quic-negotiate-pnp-00
>>
>>
>>
>> thanks,
>>
>>
>>
>> Gabriel, Nick, Praveen