Re: Packet number encryption
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 07 February 2018 00:10 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 9C14B12DA1A for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 16:10:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 hK_Pi-X0jgbc for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 16:10:49 -0800 (PST)
Received: from mail-pl0-x241.google.com (mail-pl0-x241.google.com [IPv6:2607:f8b0:400e:c01::241]) (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 B2CF81242EA for <quic@ietf.org>; Tue, 6 Feb 2018 16:10:49 -0800 (PST)
Received: by mail-pl0-x241.google.com with SMTP id ay8so2327439plb.4 for <quic@ietf.org>; Tue, 06 Feb 2018 16:10:49 -0800 (PST)
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=v6Js9Hpo5MSqZzI2pDiDVglu79X2l1aUg/OQGDFJ/FM=; b=Rs3oE/IKjiJcoqnAS7EVkab/TL618FdjaqzJgnklVHencGdUnd3Unq6jmUaLOGO0h9 9+I+/Z38P+NiiKVgp2IUKqIl4nM3ZWZkpC5cEhD2sfBCxqsimc1vU+F2yLdh5iuhLWy6 T/b7Ae1R59J1BWhGIkzgIs2wFbP6NfQnU2gxmdxaFHLKYP/EzXR6/E2Lxo1jGJnRLTq9 BHUG9HSH6wEOsGGtv1lt9KzVnnaP9/XNUdVRBgFD9yUW/dpAjtlN5jDFgX3Gz2YCEjDZ +TpMzv0a8j3IW0T5akGNE1fuirZ92paY8N+raTnMVguGPhW7oDk9xL0VU/2MAxdwW8qz KFSA==
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=v6Js9Hpo5MSqZzI2pDiDVglu79X2l1aUg/OQGDFJ/FM=; b=HtYIe0MTXPJKAeR7cBAEAEc1o3uE+tnaluSSi/9Pp5oE/ni8p52wMtjIlN9D9hBcf3 SXWN3mXZY0HX0Sty/q6r5wMgzS6pwaCIkA5J+H5FiaPCxcRti0PiDoaFj538lK3+V2pq nyk1zrp2Anj0pbU2tiVcwxeLKaY/237j4qOZeIzRTrsWGZQf08yPv+6ARrCKPT8Jzyb6 LVx8QkwHxMmejCejxotWxKyBswp+HIPk09pl++XgZ/0tZNTg9Rkhg2ptx7ljHvRAlqBW XDF8QGEZg/PhbI8/WXArPGuGph0zhZzhJQiizWqLRoxGt8eetYj9sIF7jcL2oZWIuju3 wD6w==
X-Gm-Message-State: APf1xPBR34XmE2Fy/IzbHlZDJrQIVJn0FYXStQ313Vf+gK5tc/Hoq6lc nGUxzhH0zQpjXLA41QOCiZ0=
X-Google-Smtp-Source: AH8x2266zAlAQp26US7dZs+pxw75IF4fUvb94gBZeYyKMp/VVApJ15d76KULr49ISnadY8OU5oniyw==
X-Received: by 2002:a17:902:b104:: with SMTP id q4-v6mr4136044plr.143.1517962249394; Tue, 06 Feb 2018 16:10:49 -0800 (PST)
Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id y17sm307209pfk.67.2018.02.06.16.10.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 16:10:48 -0800 (PST)
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
To: Jana Iyengar <jri@google.com>, Mike Bishop <mbishop@evequefou.be>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, "Brian Trammell (IETF)" <ietf@trammell.ch>, Praveen Balasubramanian <pravb@microsoft.com>, QUIC WG <quic@ietf.org>, Roberto Peon <fenix@fb.com>, "Lubashev, Igor" <ilubashe@akamai.com>, "Salz, Rich" <rsalz@akamai.com>
Subject: Re: Packet number encryption
Thread-Topic: Packet number encryption
Thread-Index: AWdzZj0zCJVGNsv3EmSkq0r1tERDAUJGNDQ4QW1HTGRkYmQ4Y2dGTmZTREUyNEEzMDZFMTU1MjQzNUM5NDR3M3h3RzNGQkI4MEU1MzBGQ0E5QzQ0NmYwMDUyMzAyOTc0M1FBVTBOMEVFMDBBNHJVcVE2TUdhNzRENDJnMWRGNqt9wcKAgAADUYCAACdFAIAAVRYAgAATm1Q=
X-MS-Exchange-MessageSentRepresentingType: 2
Date: Wed, 07 Feb 2018 00:10:42 +0000
Message-ID: <DB6PR10MB1766F4CAD36D6098F9F69AA7ACFC0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@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> <BY2PR15MB07754D83A1721F2BD742359BCDFE0@BY2PR15MB0775.namprd15.prod.outlook.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <CAGD1bZaUuNxqpDkn62B0wWcFD8=mCUWrAwWGG-rAOxH7Mf1=cQ@mail.gmail.com> <CY4PR21MB01334E30C7AF6AE75F58EEFDB6FE0@CY4PR21MB0133.namprd21.prod.outlook.com> <CAGD1bZaxrqzdkk0wxRaULwOTgg6wnrSrXNBK31s4uxdozaACBA@mail.gmail.com> <CAGD1bZbOAaSBcQw4nVtGuwRunaAW8MYHq9yPxNN6DdKHzt5HtQ@mail.gmail.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <CAN1APde6o6=aCXuWajPFSU=jXv-ERdVHk=uyjM71uQ_uU-oMTg@mail.gmail.com> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <MWHPR08MB2432D0216BC8FE1B0D9E3690DAFD0@MWHPR08MB2432.namprd08.prod.outlook.com>, <CAGD1bZauKbucs_5n7RQbK8H2HiyfiqpGVEcKreGA6umhMBSFgg@mail.gmail.com>
In-Reply-To: <CAGD1bZauKbucs_5n7RQbK8H2HiyfiqpGVEcKreGA6umhMBSFgg@mail.gmail.com>
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_DB6PR10MB1766F4CAD36D6098F9F69AA7ACFC0DB6PR10MB1766EURP_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ekOEYBf-3Hb4qiYObtqXSJQgB0A>
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: Wed, 07 Feb 2018 00:10:53 -0000
Sounds reasonable to me. You could add that the transformation should be space efficient. ________________________________ From: Jana Iyengar <jri@google.com> Sent: Wednesday, February 7, 2018 12:00:32 AM To: Mike Bishop Cc: Stephen Farrell; Mirja Kühlewind; Mikkel Fahnøe Jørgensen; Brian Trammell (IETF); Praveen Balasubramanian; QUIC WG; Roberto Peon; Lubashev, Igor; Salz, Rich Subject: Re: Packet number encryption I'm going to try a different attempt at moving towards convergence. Thinking about this some more, and picking up something that Mirja said way earlier in this thread, I think the following decomposition is useful. 1. In the transport, all packet numbers start at 0, increasing monotonically. ACK frames carry these packet numbers, and therefore do not have to span large gaps and do not have to deal with increases in the size of the largest acked. Basically, no gaps are visible within the transport processing engine. 2. Before sending a packet on the wire, and before processing the packet, QUIC transforms the packet number with some function, replacing the visible packet number with the transformed value. I think we can all agree that (1) is goodness. A sender is also free to use packet numbers from non-contiguous spaces here FWIW, but that's entirely independent of what's visible on the wire. This helps me separate transport processing complexity from the rest of it, which I think is helpful. I think we are disagreeing on the precise properties we want from the transformation in (2). If we can agree on these properties, we can then figure out whether it's possible and how to construct such a transform. Here's a union of what folks are concerned about: 1. Packet number must be unlinkable across connection ID change (for migration.) 2. Packet number must start at an arbitrary value, to avoid ossification of the first packet number. 3. Some sequencing information -- a few bits of the packet number perhaps -- should be revealed (for monitoring. Number of bits TBD.) 4. Any packet number transformation should not be compute intensive. I'm not looking for a construction, but I'd like to agree on the problem first. Does this sound like the set of properties we want? Or is there a contradiction among these properties that I'm not seeing? On Tue, Feb 6, 2018 at 9:56 AM, Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>> wrote: Packet number encryption *does* improve linkability equivalently to random jumps, but without the fragmentation of the ACK packet which those jumps otherwise cause. So I'm with Stephen, we don't yet have agreement on that assertion. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>] On Behalf Of Stephen Farrell Sent: Tuesday, February 6, 2018 7:35 AM To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch<mailto:mirja.kuehlewind@tik.ee.ethz.ch>>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>>; Brian Trammell (IETF) <ietf@trammell.ch<mailto:ietf@trammell.ch>>; Jana Iyengar <jri@google.com<mailto:jri@google.com>> Cc: Praveen Balasubramanian <pravb@microsoft.com<mailto:pravb@microsoft.com>>; QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>; Roberto Peon <fenix@fb.com<mailto:fenix@fb.com>>; Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>>; Salz, Rich <rsalz@akamai.com<mailto:rsalz@akamai.com>> Subject: Re: Packet number encryption On 06/02/18 15:23, Mirja Kühlewind wrote: > > It's also my understanding that we do agree that packet number > encryption does not help likability (and thereby privacy) a lot, or at > least that the benefits we might get (or not) do not justify the > additional complexity. FWIW, which isn't much, I don't (yet) agree to the above. I reckon it'll be a while before we know how linkability pans out. I do agree that packet number encryption is not a panacea for unlinkability, but it may help, or may even end up being required, to do a good job wrt linkability. I also heard people say it was less complex for them so "additional complexity" may also not be quite right. (I guess "differently complex" is correct though.) S. -- PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-)
- 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