Re: Packet number encryption
Roberto Peon <fenix@fb.com> Mon, 05 February 2018 00:38 UTC
Return-Path: <prvs=5574192a57=fenix@fb.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 96C781243F6 for <quic@ietfa.amsl.com>; Sun, 4 Feb 2018 16:38:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.731
X-Spam-Level:
X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=eEVGQK1B; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=iP9EEQzg
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 Hb8SrQTKTIsv for <quic@ietfa.amsl.com>; Sun, 4 Feb 2018 16:38:56 -0800 (PST)
Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 AAD9F120725 for <quic@ietf.org>; Sun, 4 Feb 2018 16:38:56 -0800 (PST)
Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w150Y9lC017220; Sun, 4 Feb 2018 16:38:00 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=TwF/h4lugZkHOxT6QcTl3SO8GxkgxP/v6FnQtSK3ep8=; b=eEVGQK1BFMr0TowA5eM94Urx0h/wEr4ZLouMz/TgrJz3o9NtPVzkRsWwHQGZMB/RCKT4 Td36QuqMJAPWY4pH5CObMxVDEqwon3V1mXPCT6EnwSUo8f01kW5tBULzGxI7/fvKBODN Sz0W7Gdg3/PZtWKgvU0vLz7a+NblIQPZl7M=
Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2fw9f256ry-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 04 Feb 2018 16:38:00 -0800
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.23) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 4 Feb 2018 19:37:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TwF/h4lugZkHOxT6QcTl3SO8GxkgxP/v6FnQtSK3ep8=; b=iP9EEQzguIiVLumGl7JPLNXvpD/OnzBeEj5fLzef+wAxiLtq2LNRS1bnxFEz4H81OfUl1edK20MMt1L2rHEneIMPVrgxbS2t5027sdotd3vMdcBPKfZWqVyNze3mIjn45loUGd8ipY5IE5rHbvfWi4zzYTJPC0iPY/Ot48kw87A=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0232.namprd15.prod.outlook.com (10.163.64.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 00:37:53 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0464.015; Mon, 5 Feb 2018 00:37:53 +0000
From: Roberto Peon <fenix@fb.com>
To: "Roni Even (A)" <roni.even@huawei.com>, Piotr Galecki <piotr_galecki@affirmednetworks.com>, Jana Iyengar <jri@google.com>, "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>
CC: Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric Rescorla <ekr@rtfm.com>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, "Eggert, Lars" <lars@netapp.com>, Brian Trammell <ietf@trammell.ch>, Christian Huitema <huitema@huitema.net>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Subject: Re: Packet number encryption
Thread-Topic: Packet number encryption
Thread-Index: AQHTmW3+HjM5RmHWDkij9J5s6UBSSaOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGB6AANx9AIABGNFf
Date: Mon, 05 Feb 2018 00:37:53 +0000
Message-ID: <BY2PR15MB07758F932FBB87047ACB9D9ACDFE0@BY2PR15MB0775.namprd15.prod.outlook.com>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <CABcZeBMbwdwyC9TxxHBLYaZKfNB-FG2wCGjqUZ_mNR-A1R47FA@mail.gmail.com> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <CABkgnnWRQSAufwPss+qf=xAzCwRYeNNH8XLPm3yFaHxOb+ba4g@mail.gmail.com> <BF80500A-6277-45DC-8525-9C3FE138B76D@tik.ee.ethz.ch> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <F990E064-E6F8-41A3-B791-F776C9955E15@nokia.com> <CAGD1bZab0GaZFsHwC+nw3AxxC4VusxMJ6oDanzk3dSDdWKAXdw@mail.gmail.com>, <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <BY2PR15MB07757473DB9788558B902EB5CDF80@BY2PR15MB0775.namprd15.prod.outlook.com>, <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [98.234.190.115]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0232; 20:Sp+NVSP7uM5n/XiA0sV9f+twqvIgMn0v6lCNM0Q/ZPCCVj12VsQEoj4uwqyJei/+J5RSax4axuX59H8Enc4Y0CbCD+esvtRmjahd3G7cQJGqYCy+pbsJqdMmNctaLv1ndvQHtRhDvNqlb7MOHvl9iB2SFtppaE/GyoCjPc2uWlc=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 701844ad-f59c-4726-3d9f-08d56c30b1a5
x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0232;
x-ms-traffictypediagnostic: BY2PR15MB0232:
x-microsoft-antispam-prvs: <BY2PR15MB02320579F212E06005856315CDFE0@BY2PR15MB0232.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(10436049006162)(72170088055959)(50582790962513)(82608151540597)(85827821059158)(211936372134217)(179696456005106)(153496737603132)(130329453890623);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(11241501184)(2400082)(944501161)(93006095)(93001095)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BY2PR15MB0232; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0232;
x-forefront-prvs: 0574D4712B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39380400002)(346002)(39860400002)(376002)(11905935001)(199004)(189003)(377424004)(186003)(5660300001)(19627405001)(7116003)(25786009)(39060400002)(561944003)(55016002)(54906003)(66066001)(4326008)(110136005)(68736007)(33656002)(76176011)(106356001)(7696005)(3660700001)(97736004)(966005)(3280700002)(6606003)(4001150100001)(229853002)(6436002)(53936002)(478600001)(14454004)(9686003)(93886005)(6306002)(99286004)(3480700004)(2900100001)(6246003)(8676002)(81156014)(236005)(54896002)(81166006)(8936002)(8656006)(2950100002)(606006)(6506007)(77096007)(7736002)(53546011)(26005)(105586002)(7416002)(86362001)(2906002)(74316002)(102836004)(6116002)(3846002)(59450400001)(316002)(42262002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0232; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 3ixtazJxgrMgPLkr7MiDso2FZEy8iNh/QxaHK72sAG/WC5OgwmCAQwnoFlXLBENb3nKG5OHwTdTS7LeOIKp6Mw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR15MB07758F932FBB87047ACB9D9ACDFE0BY2PR15MB0775namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 701844ad-f59c-4726-3d9f-08d56c30b1a5
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 00:37:53.5700 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0232
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_07:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/GYH0huusiBt3_D47KXpt-_dLV4g>
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, 05 Feb 2018 00:39:00 -0000
A network could carry whatever protocol it wished to, i.e. by wrapping any/all packets on ingress to the network, and then un-wrapping when forwarding to another network. This would allow a network to record and track whatever it wanted to without placing constraints on layers which should be above it. If the network placed a sequence number on incoming packets, it could detect reordering across all flows. If it do so on a 5-tuple basis, it could detect reordering/duplication/loss across any 5-tuple. -=R ________________________________ From: Roni Even (A) <roni.even@huawei.com> Sent: Saturday, February 3, 2018 11:47:06 PM To: Roberto Peon; Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust; Eric Rescorla; Mirja Kühlewind; Eggert, Lars; Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson Subject: RE: Packet number encryption Hi, Network monitoring: Networks may always wrap the packet(s) they have received with whatever data they wish, and unwrap before forwarding. This can allow any network to understand ordering, loss, etc within its boundaries. RE- so you are saying that we can for example leverage RTP and define RTP payload for QUIC that will carry QUIC packets, we will just need to resolve the MTU size. Roni From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon Sent: Saturday, February 03, 2018 8:38 PM To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust; Eric Rescorla; Mirja Kühlewind; Eggert, Lars; Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson Subject: Re: Packet number encryption Ossification: In the past tcp middleboxes expected in-order, monotonically increasing offsets and tried to fix reordering before forwarding. This middlebox behavior, predicated on observable flows, prevented deployment of things which would have made tcp more efficient. This is the kind of non-theoretical ossification that drove the creation of QUIC in the first place. Network monitoring: Networks may always wrap the packet(s) they have received with whatever data they wish, and unwrap before forwarding. This can allow any network to understand ordering, loss, etc within its boundaries. Debugging: Debugging of flows can still happen for flows that wish to be debugged-- the QUIC connection's key material(s) can be shared manually and used by the debugging tool. This is how one debugs http2, https, etc. already today. -=R -------- Original message -------- From: Piotr Galecki <piotr_galecki@affirmednetworks.com<mailto:piotr_galecki@affirmednetworks.com>> Date: 2/2/18 7:00 PM (GMT-08:00) To: Jana Iyengar <jri@google.com<mailto:jri@google.com>>, "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com<mailto:thomas.fossati@nokia.com>> Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>, Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>>, "Eggert, Lars" <lars@netapp.com<mailto:lars@netapp.com>>, Brian Trammell <ietf@trammell.ch<mailto:ietf@trammell.ch>>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch<mailto:mirja.kuehlewind@tik.ee.ethz.ch>>, QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> Subject: RE: Packet number encryption What is the group’s proposal for allowing network monitoring tools to detect packet retransmission or packet reordering ? These metrics are pretty straightforward to measure for TCP flows. Tools like Wireshark can analyze packets and spot issues. How can the network tools perform this kind of measurements for QUIC flows if PN field is encrypted? From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar Sent: Friday, February 02, 2018 9:31 PM To: Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com<mailto:thomas.fossati@nokia.com>> Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>; Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch<mailto:mirja.kuehlewind@tik.ee.ethz.ch>>; Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>>; Brian Trammell <ietf@trammell.ch<mailto:ietf@trammell.ch>>; Eggert, Lars <lars@netapp.com<mailto:lars@netapp.com>>; QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>; Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> Subject: Re: Packet number encryption A few points as I catch up on this thread. First, I'll remind folks that QUIC is an encrypted transport. I say this because the cost of this operation is trivial in the context of encrypting every packet. The cost is borne at the servers and not at middleboxes, so the additional crypto cost is basically trivial. Second, this simplifies and increases robustness of implementation. Avoiding random PN jumps, as Kazuho points out, makes special-casing of code unnecessary. Special code that is exercised occasionally is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation. Third, yes, ossification is a real concern. A simple example: using increasing packet numbers as a signature for detecting QUIC. Even if you argue against this example, there are innovative ways in which ossification will happen. This is based on a true story: We had no idea how GQUIC's flags field could get ossified, the value that was being used commonly became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper<https://urldefense.proofpoint.com/v2/url?u=https-3A__static.googleusercontent.com_media_research.google.com_en_pubs_archive_46403.pdf&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=SY87I4v_IqTCGOds-j5NCOwkQ0cJcYHGyKdXmMIVn6I&s=U9o6dI-dwzKwvXHvvmv7WtVm84puvxhaP0cN2of3VvA&e=>). There's a win here in terms of implementation complexity and several implementers have said so. There's a win in terms of ossification and our experience says so. There's a potential loss of manageability, in being able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet numbers. On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com<mailto:thomas.fossati@nokia.com>> wrote: On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org<mailto:quic-bounces@ietf.org> on behalf of lars@netapp.com<mailto:lars@netapp.com>> wrote: > On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>> wrote: > > +1 - Simply: This *is* complicated and seems to add little. > > So as an implementor (chair hat off), this adds very little to the > overall complexity of the protocol. This doesn't sound great. It's a bit like saying that adding the Higgs mechanism to the standard model's lagrangian doesn't make it much more complicate :-) (*) More seriously though, I'd like to point out that it is not just about implementation complexity, it's also the energy cost per packet that is quite crucial. I haven't done the math but ISTM that bringing in another batch of non-optional crypto computation on a per packet basis is not going to move the needle in the right direction for stacks that run on low power (IoT). This is not a catastrophe - we have CoAP and a (D)TLS profile - but neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to bridge. (Sure, we have specified the behaviour of a similar box already, but it'd be really better if the extra translation logic could be avoided in the first place.) I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later profile QUIC for the IoT, which would be a bit unlucky. So the question is: would it be possible to make this property a configurable knob instead? (*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-equation<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.symmetrymagazine.org_article_the-2Ddeconstructed-2Dstandard-2Dmodel-2Dequation&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=SY87I4v_IqTCGOds-j5NCOwkQ0cJcYHGyKdXmMIVn6I&s=etIO0AUHiJm8zucsWaTgo-XULFisCMoG2iDvwC69s9Q&e=>
- Packet number encryption Martin Thomson
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Gorry Fairhurst
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Eggert, Lars
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Ted Hardie
- Re: Packet number encryption Ted Hardie
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Duke
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Dmitri Tikhonov
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Piotr Galecki
- Re: Re: Packet number encryption alexandre.ferrieux
- Re: Packet number encryption Patrick McManus
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Roberto Peon
- RE: Packet number encryption Piotr Galecki
- RE: Packet number encryption Roni Even (A)
- RE: Packet number encryption Lubashev, Igor
- RE: Packet number encryption Lubashev, Igor
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Lubashev, Igor
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Willy Tarreau
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Brian Trammell (IETF)
- Reducing ossification through protocol design (wa… Brian Trammell (IETF)
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Roni Even
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Roberto Peon
- Re: Reducing ossification through protocol design… Gorry Fairhurst
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Kazuho Oku
- RE: Packet number encryption Roni Even (A)
- Re: Reducing ossification through protocol design… Mirja Kühlewind
- Re: Reducing ossification through protocol design… Salz, Rich
- Re: Reducing ossification through protocol design… Mirja Kühlewind
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- RE: Reducing ossification through protocol design… Mike Bishop
- Re: Packet number encryption Jana Iyengar
- Re: Packet number encryption Jana Iyengar
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Ted Hardie
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Marten Seemann
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Marten Seemann
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Gorry Fairhurst
- Explicit measurability in the QUIC wire image (wa… Brian Trammell (IETF)
- Explicit measurability in the QUIC wire image (wa… Brian Trammell (IETF)
- RE: Explicit measurability in the QUIC wire image… Roni Even (A)
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Stephen Farrell
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- RE: Packet number encryption Mike Bishop
- Re: Packet number encryption Jana Iyengar
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Eric Rescorla
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Martin Thomson
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Marten Seemann
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Martin Thomson
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Packet number encryption Brian Trammell (IETF)
- RE: Packet number encryption Praveen Balasubramanian
- Re: Explicit measurability in the QUIC wire image… Christian Huitema
- Re: Explicit measurability in the QUIC wire image… Christian Huitema
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Packet number encryption Victor Vasiliev
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Ian Swett
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Ian Swett
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption David Benjamin
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Deval, Manasi
- RE: Packet number encryption Deval, Manasi
- Re: Packet number encryption Victor Vasiliev
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: hardware offload (was: Packet number encrypti… Ian Swett
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Praveen Balasubramanian
- RE: hardware offload (was: Packet number encrypti… Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Victor Vasiliev
- Re: hardware offload (was: Packet number encrypti… Christian Huitema
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: hardware offload (was: Packet number encrypti… Eggert, Lars
- RE: Packet number encryption Praveen Balasubramanian
- RE: hardware offload (was: Packet number encrypti… Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Victor Vasiliev
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen