RE: Packet number encryption
Praveen Balasubramanian <pravb@microsoft.com> Sun, 04 February 2018 19:31 UTC
Return-Path: <pravb@microsoft.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 91978127978 for <quic@ietfa.amsl.com>; Sun, 4 Feb 2018 11:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 ZvtEQRUPVqiH for <quic@ietfa.amsl.com>; Sun, 4 Feb 2018 11:31:17 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0114.outbound.protection.outlook.com [104.47.38.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF49124239 for <quic@ietf.org>; Sun, 4 Feb 2018 11:31:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CgbDBOt5Ab6FhSRrYUGRrrD09Tjj9p+N9pHPjozBNZY=; b=XZmNc0LmEz2TW5F7+9Q9XA6F5lL5bA57n5k2j9YIyhLv9goU82cXwWeoqICJUi+CeIyiKWhj5DOiEuYwROJYWPxJpckHgC5nXZwuBDEy273Xbm05JsG0rg8tWYJ4TYpD93MwrtD87htV+9TUTF1EtLA1NMuXzBuHW3zwFIkFk1U=
Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0821.namprd21.prod.outlook.com (10.173.192.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Sun, 4 Feb 2018 19:31:14 +0000
Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Sun, 4 Feb 2018 19:31:14 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: "quic@ietf.org" <quic@ietf.org>, huitema <huitema@huitema.net>
CC: Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric Rescorla <ekr@rtfm.com>, Brian Trammell <ietf@trammell.ch>, "Lubashev, Igor" <ilubashe@akamai.com>, Roberto Peon <fenix@fb.com>, "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>, "Roni Even (A)" <roni.even@huawei.com>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Jana Iyengar <jri@google.com>, "Eggert, Lars" <lars@netapp.com>, Martin Thomson <martin.thomson@gmail.com>, Piotr Galecki <piotr_galecki@affirmednetworks.com>
Subject: RE: Packet number encryption
Thread-Topic: Packet number encryption
Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAAGR4CAAAydAIAAEZUg
Date: Sun, 04 Feb 2018 19:31:14 +0000
Message-ID: <CY4PR21MB0133E20F8C20889A477CDB67B6FF0@CY4PR21MB0133.namprd21.prod.outlook.com>
References: <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> <e529144067624fcba636fc8c24ee3ff4@usma1ex-dag1mb5.msg.corp.akamai.com> <888DE2C2-4EDA-445A-B08F-76DD016C9CA0@huitema.net> <20180204182550.GA19526@1wt.eu>
In-Reply-To: <20180204182550.GA19526@1wt.eu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:5::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0821; 7:enW3XkOxC9cFcVRTZMJAg8SKaWTKU+w1i9G8gTqrMl2nEfOe8q2SACzRKJ00lmhXKjrWIAWd/3Wxiawf7jeAQNNtRpk2uFhjeTUMqZE2KOSmmNr6CojEDKxNh2dF64PQH77kD+drLVrcKIi2prCRq0MP9d8fP6Vi+4O2byD9nVqp8mnTHRPyYmCfaNQCqPPqCI6m8YejIzMkHVyBM1IEDuFEIWhSFbt+riaiW2sf4zg+mMo7Zf5X3zgz2wsWBTNY
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 09a80f6d-d08e-450c-d844-08d56c05dac4
x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0821;
x-ms-traffictypediagnostic: CY4PR21MB0821:
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <CY4PR21MB082104D6E7F8844E12756BABB6FF0@CY4PR21MB0821.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(131327999870524)(50582790962513)(82608151540597)(85827821059158)(788757137089)(67672495146484)(211936372134217)(153496737603132)(130329453890623);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(3002001)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0821; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0821;
x-forefront-prvs: 05739BA1B5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(39380400002)(346002)(366004)(13464003)(199004)(189003)(43544003)(33656002)(5660300001)(110136005)(2900100001)(4326008)(8936002)(2950100002)(3660700001)(9686003)(8676002)(77096007)(3280700002)(55016002)(22452003)(229853002)(7116003)(54906003)(53936002)(68736007)(8990500004)(81166006)(6436002)(81156014)(10290500003)(6506007)(25786009)(14454004)(106356001)(53546011)(93886005)(6116002)(305945005)(105586002)(478600001)(186003)(59450400001)(7736002)(2501003)(6246003)(86362001)(102836004)(6346003)(99286004)(39060400002)(86612001)(7416002)(7696005)(2906002)(8656006)(97736004)(316002)(76176011)(3480700004)(10090500001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0821; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-message-info: iawWtgtayhyfSvLg0aaUfANTvXGPf8BdU1tyGwkwwLVYl7T+SOtynxbyEBO2GdlEGEKa7HlOYfaQgd8HsAEHoA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 09a80f6d-d08e-450c-d844-08d56c05dac4
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2018 19:31:14.2682 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0821
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/aNElZ-Syd3hVFBC4Jc2yxVbQSFQ>
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: Sun, 04 Feb 2018 19:31:20 -0000
>From the charter "This work will ensure that QUIC has security and privacy properties that are at least as good as a stack composed of TLS 1.3 using TCP (or MPTCP when using multipath)." Is the discussion mainly focused on connection migration which is not present in TCP? There seem to be bigger privacy problems due to DNS and TLS SNI extension so in real deployments will packet number encryption add value other than preventing ossification? Is a cryptographically secure random initial packet number and random (forward) jumps in packet number not good enough to prevent ossification? The missing packet number range due to the forward jump could be communicated in the encrypted payload so the receiver knows they are not missing. Thanks -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Willy Tarreau Sent: Sunday, February 4, 2018 10:26 AM To: huitema <huitema@huitema.net> Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>; Eric Rescorla <ekr@rtfm.com>; Brian Trammell <ietf@trammell.ch>; Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon <fenix@fb.com>; Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>; Roni Even (A) <roni.even@huawei.com>; Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Jana Iyengar <jri@google.com>; Eggert, Lars <lars@netapp.com>; QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>; Piotr Galecki <piotr_galecki@affirmednetworks.com> Subject: Re: Packet number encryption On Sun, Feb 04, 2018 at 07:40:41AM -1000, Christian Huitema wrote: > Negotiate privacy off in the name of network performance? Very > slippery slope! For example, the connections that do require privacy would stick out. Well, I personally have stopped fighting on this subject. I've long been bored by the obsession of this so-called "privacy" which justifies any possible protocol degradation and loss of efficiency to hide I-don't- know-what, even sometimes destroying basic security at the same time. Today, people who want to hide their activities use VPNs. Those of us having had to help diagnose network issues on IPSEC connections know that you can't debug anything and that the only fix is to try to randomly replace elements and settings on the path, and to ultimately get rid of this protocol in favor of other solutions with less moving parts. Yes I too am a bit worried about what QUIC will become. The lack of observability may even result in the impossibility at all to build a working firewall to protect the users. Thus instead of nasty people just counting packets on the wire, they'll have an open path to remotely install malware into their victim's devices without any possibility for them to be protected, leaking all their data and history even more easily than today. The Internet infrastructure is robust and fragile at the same time, it's robust against attacks and hardware failures, but it's fragile in front of design mistakes, especially if they're deployed on each and every browser and/or web server. I think it's important to take care of it and to ensure it always remains possible to heal it and to enhance it. I'd rather see some choices offered to the end user in fact. Just like right now some decide to use a VPN, some may decide to enable some super-privacy features that possibly make their connections a bit less reliable, less performant, and prevent them from using an efficient firewall, but it will be their choice at least. And it would allow us to go even further in the privacy domain, possibly contemplating options making it even harder to fix protocol issues but protect users better (eg: the spin bit was a tradeoff to satisfy everyone, with an opt-in solution it's not even needed anymore). Having a bit indicate if the sequence number is encrypted or not could be enough : - the sender decides to use clear sequence numbers and clears the bit - the sender decides to use encrypted sequence numbers and sets the bit. - the receiver knows how to decode the sequence number based on this bit. - a middle box could not achieve anything by clearing this bit since it would mean that the resulting values would appear as almost random and would not be usable by the other end. Just my two cents, Willy
- 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