Re: Packet number encryption
Marten Seemann <martenseemann@gmail.com> Tue, 06 February 2018 07:57 UTC
Return-Path: <martenseemann@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 C320B1250B8 for <quic@ietfa.amsl.com>; Mon, 5 Feb 2018 23:57:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_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=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 zWq1mr_5QJGp for <quic@ietfa.amsl.com>; Mon, 5 Feb 2018 23:57:54 -0800 (PST)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 AC864120727 for <quic@ietf.org>; Mon, 5 Feb 2018 23:57:53 -0800 (PST)
Received: by mail-vk0-x229.google.com with SMTP id g83so575032vki.4 for <quic@ietf.org>; Mon, 05 Feb 2018 23:57:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R4auhoBtNpjhTMhTt4KAkP8VDGfFSWIpGlPzzhy69wg=; b=XB4uT2wNouLmrVTcWlPipEVcQhYaS4uo5GZ7CUqTUDPKPT/I3KnPrXyt40p6eP+adx +aVAZRHa1cWV47jAjrqFX2A/LI5VmUuxjuKmBe7Y5+DS39ldPRCPK9TGPFEkiqxfhm/v AjTCDO9z84+2W+IKLBVEnzXk0pegWgzdmvgsxFRq0HYL7pJpBY1r7uoofnuH/gpkBqaV uFJ2i9ztUD7uKKgRjkMQLtttTKzhlh1RzkIKuRtZzMwPHE8k6SAU4LjX9M+9KqnzXgmB GUwc9hjm4+XmNpyHMFHlTiSZpud/Xdv2TGyAl8ql/hryBWXMgBskz44kydRULAmum9b4 h8SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R4auhoBtNpjhTMhTt4KAkP8VDGfFSWIpGlPzzhy69wg=; b=F5mBYD7SC9ovGsdhXnhCzXjHJePmZp/vx7QETxYT9x1RZn00Z8gwpXUSp6Tjl3Iutv F+2Tkfcg0clKfJI3HGwEqeCsm6B9EGwxZkUIthnHifXoxbzxd6/+puOlMQm5jR7JS35r V/AIRvuVEWr+WFl80WrcWC1DpUFGlgby5EGfsC6et7LIu19K2waKUgCmeKrPcN/iHdnr 1BiKHjP7oQzM9mar5URUfqCuQwiOM8Ck8oVJHvcUZwowo5ESkTJvnUu0o/4NWrEe6Nl0 lT9YRDd0CVjsjLTRl5IqbQ6t/lUVkYmRGClYTIqK2ORqMKBv3Wgxy9wB5oRAMzMy8+h1 q9Jw==
X-Gm-Message-State: APf1xPD4eddSDjeXsguj2iAval/n0RmYaaqASEDDapigZ7+MfW0V2ZHz D05Wuz41p2yn+FWBFGypjUNG42o4IhqnKf5h/lY=
X-Google-Smtp-Source: AH8x227Wm1dGs6jpmopFX0+8/fi8WL9h2aZSlRRgZKAfNy5Z97ojErcbWNsUzCd8Uidb9dpA+3n0fjBqi2VnxLWQjLs=
X-Received: by 10.31.179.139 with SMTP id c133mr1439102vkf.194.1517903872484; Mon, 05 Feb 2018 23:57:52 -0800 (PST)
MIME-Version: 1.0
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> <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> <CY4PR21MB01336FF451F8E4A3CF013E47B6FD0@CY4PR21MB0133.namprd21.prod.outlook.com> <CY4PR21MB0133383C5FB993D3F5642A89B6FD0@CY4PR21MB0133.namprd21.prod.outlook.com> <CAOYVs2pZAbu9DsiOYWP-hw4eOuAWOxAzMZDKMmdm7SzigZOMRg@mail.gmail.com> <6E58094ECC8D8344914996DAD28F1CCD8621FA@DGGEMM506-MBX.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8621FA@DGGEMM506-MBX.china.huawei.com>
From: Marten Seemann <martenseemann@gmail.com>
Date: Tue, 06 Feb 2018 07:57:41 +0000
Message-ID: <CAOYVs2o3XPiW8unZtd67LkgHFd5zckZHYsYAywPM9SNvF_5qng@mail.gmail.com>
Subject: Re: Packet number encryption
To: "Roni Even (A)" <roni.even@huawei.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>, Jana Iyengar <jri@google.com>, "Lubashev, Igor" <ilubashe@akamai.com>, Roberto Peon <fenix@fb.com>, QUIC WG <quic@ietf.org>, "Salz, Rich" <rsalz@akamai.com>
Content-Type: multipart/alternative; boundary="001a114354c61f6c100564868905"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/3Y-t1KcrB9NxnR9m2nhSqfXnBbY>
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: Tue, 06 Feb 2018 07:57:58 -0000
That's only true if you assume that the middlebox reads the version number from the Long Header packets, and then only takes action if it understands that version. Additionally, in case of a migrated connection, the middlebox has no way to learn about the QUIC version at all, and would have to refrain from taking any action at all. Furthermore, if we rotate connection IDs more frequently, as Martin suggested, the middlebox would also become ignorant of the QUIC version for that new connection ID, and would have to stop reading the packet number for that flow. These are a lot of ifs, and I'm not sure if it's a wise decision to put all our trust in the manufacturers of middleboxes, that all of them will adhere to all the assumptions outlined above. Note that there's no other way than deploying a new QUIC version to distinguish middleboxes implementing this correctly from middleboxes that don't exactly play by these rules. Since in the beginning QUIC v1 will be the only deployed QUIC version, it might be very tempting for middleboxes to not implement these rules properly. On Tue, Feb 6, 2018 at 3:34 PM Roni Even (A) <roni.even@huawei.com> wrote: > Hi, > > This is what version negotiation is for, you can change it in future > version based on version number. > > Roni > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Marten Seemann > *Sent:* Tuesday, February 06, 2018 9:31 AM > *To:* Praveen Balasubramanian > *Cc:* Jana Iyengar; Lubashev, Igor; Roberto Peon; QUIC WG; Salz, Rich > > > *Subject:* Re: Packet number encryption > > > > Option 2 is the only option that allows us to correct our decision in the > future. If we were to discover that it doesn't work out as we planned (wrt > encryption performance, network manageability or literally any other > unforeseen problem), going back to option 1 (or coming up with another > clever solution) in a future QUIC version would still be a viable option. > > Option 1 on the other hand, once deployed, immediately puts us at risk of > ossification by middleboxes, which will prohibit us from ever switching to > option 2 for a future QUIC version. > > > > On Tue, Feb 6, 2018 at 3:10 PM Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > Oops sorry I think I misread that 1 requires random jumps only around > migration and not always, which means its decidedly inferior to 2 w.r.t. > ossification. Can we include a 1.1 which incorporates random jumps even in > steady state? Or have we ruled that option out? > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Praveen > Balasubramanian > *Sent:* Monday, February 5, 2018 7:13 PM > *To:* Jana Iyengar <jri@google.com> > > > *Cc:* Salz, Rich <rsalz@akamai.com>; Lubashev, Igor <ilubashe@akamai.com>; > Roberto Peon <fenix@fb.com>; QUIC WG <quic@ietf.org> > > *Subject:* RE: Packet number encryption > > > > My opinion is for 1 over 2 but I can live with either. The main concern is > cost of another encryption / decryption step, so the benefit of 2 over 1 > should be demonstrably better on one of ossification, privacy, or > manageability. > > > > *From:* Jana Iyengar [mailto:jri@google.com <jri@google.com>] > *Sent:* Monday, February 5, 2018 4:31 PM > *To:* Praveen Balasubramanian <pravb@microsoft.com> > *Cc:* Salz, Rich <rsalz@akamai.com>; Lubashev, Igor <ilubashe@akamai.com>; > Roberto Peon <fenix@fb.com>; QUIC WG <quic@ietf.org> > *Subject:* Re: Packet number encryption > > > > I don't think we're converging here, so I'd like to try and encourage us > to move towards it. I have my opinion, but I care more about forward > progress at this point. > > > > There are three designs so far: > > 1. Packet numbers as is, with random gaps around migration. > > 2. Packet numbers encrypted, as per Martin's PR. > > 3. Packet numbers encrypted, plus a small modulo sequence number somewhere. > > > > The concrete ones here are (1) and (2). I'm listing (3) but am not > inclined to consider it seriously, since it's not concrete enough, (and I > don't want more bits to be spent in the QUIC packet header if that's where > this info goes.) > > There are opinions about ossification, privacy, and manageability. I'm not > hearing bloody murder, so for what it's worth, I'd like to stipulate first > that we can all live with the final design, whichever one it is. If anyone > disagrees, please say so -- I think it'd be useful to hear if there are > folks who think a particular design is fundamentally problematic. > > > > My opinion is still for (2) over (1), but I can live with either. > > > > On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar <jri@google.com> wrote: > > Praveen, > > > > That was precisely my point about the ecosystem evolving. Now that we have > the ability to classify flows, various things have been built around being > able to tell TCP flows. This obviously has benefits as you point out, but > the downside is that that I can't get good network utilization with a > single flow. I understand the scaling point, but speaking of common > cases, any server in the wild is usually serving a large number of > connections at moderate speeds, not a single one at 25-35 Gbps... which > makes that sort of scaling less exciting than in a microbenchmark. > > > > FWIW, the other downside of ECMP is that multipath transport doesn't work > -- you need to hash on something else besides the 4-tuple. (We had to work > around this in Google's deployment of connection migration.) > > > > I'll disagree with your point about reordering being the uncommon case. > While that's true today, this is again an expectation that the network > works hard to maintain, though the ecosystem and what we expect as "usual" > would be quite different had we not built TCP's requirements into the > network. There's nothing wrong with having n-modal latencies... we can > engineer around that. Any sensible load distribution scheme within the > network will give you increased variance but it should limit the worst-case > latency. You'd perhaps agree that that's a net win. > > > > This was an example of how exposing packet number or not can have long > term ecosystem effects. My point was about the fact that exposing can cause > ossification. > > > > - jana > > > > On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > >> This was definitely true for implementations of TCP, but that is TCP's > problem, not the network's > > Flow classification happens through the network and also on the end host > with RSS where a flow is mapped to a core. This allows for building high > performance receive processing that could be lock free for the most part. > The only downside of ECMP on the network and RSS on the CPU is that a > single flow will not take multiple paths or get processed on more than one > core. Windows on server machines today can saturate 25-35 Gbps for a single > TCP connection before being CPU limited. This is a reasonable trade off > because I don’t know of cases where a single flow is driving more than that > amount of traffic. Assumptions about how flows get classified help make for > more efficient processing. They also lead to consistent latency. You do not > want the traffic to take a bi-modal or N-modal paths (on the network or the > host) to being processed because the fluctuations in latency will hurt the > workload. I am not arguing for TCP not being resilient to reordering but > IMO that should be the uncommon case not the common case. With QUIC if > streams were exposed on the network you could take advantage of stream > level ECMP and RSS to scale better than TCP but we have chosen to keep the > 4-tuple (or the 5-tuple) as the flow classifier on the network which is ok > by me since it leads to TCP parity. > > > > Thanks > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar > *Sent:* Sunday, February 4, 2018 8:35 PM > *To:* Salz, Rich <rsalz@akamai.com> > *Cc:* Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon <fenix@fb.com>; > QUIC WG <quic@ietf.org> > *Subject:* Re: Packet number encryption > > > > Privacy-protection can't be a user choice, for the reasons others have > noted on this thread. > > > That said, my primary argument is for encryption to avoid ossification. > Not that it matters now, but I'll note that much of GQUIC's original > motivation for encrypting headers was to avoid ossification. > > > > I'll reiterate that fields we expose will get ossified and there are > long-term ecosystem effects to this. Let me illustrate this with precisely > the packet number field. Middleboxes commonly assume that a TCP flow can > only handle packets in-order. This assumption comes from the fact that TCP > implementations get poor performance when packets are reordered. This was > definitely true for implementations of TCP, but that is TCP's problem, not > the network's. However, almost all load-balancers I know of now will pin > all packets within a TCP flow to one path, leading to sub-optimal > performance in the network, and destroying incentives for the endpoints to > deploy reordering-resilient TCP implementations (even though there are > plenty of ways of doing this.) > > > > Exposing QUIC's packet number field (as any field) is likely to have > similar consequences and a similar ecosystem arc. > > > > > > On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich <rsalz@akamai.com> wrote: > > > Optional security tends to devolve to non-secure. > > > > That’s a great aphorism. And sadly all too true. > > > > > > > >
- 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