Re: Packet number encryption
Martin Duke <martin.h.duke@gmail.com> Fri, 02 February 2018 00:47 UTC
Return-Path: <martin.h.duke@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 A9475126E3A for <quic@ietfa.amsl.com>; Thu, 1 Feb 2018 16:47:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 gU3TOviPS1ok for <quic@ietfa.amsl.com>; Thu, 1 Feb 2018 16:47:20 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 84508126DED for <quic@ietf.org>; Thu, 1 Feb 2018 16:47:19 -0800 (PST)
Received: by mail-wm0-x22d.google.com with SMTP id 141so9113744wme.3 for <quic@ietf.org>; Thu, 01 Feb 2018 16:47:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KgkwxcQSqb7sTUGCxGjHt3Pg7/MhTqlyw7qHX1C3itA=; b=Jal2nZRE2f3Vt88SyBq3kiTJfz8/8Tj+yPYRmxdYQZQA5RqTNJoAv3OUu+oqR8tgWr e0aJkC4z2rzr9k0+NLoDrgOWNqQzLa0uHpFH9uKTPfnJBHjaKdB+nkG568WxQVEeB3fM Ms1xo8qcMSnfSqGc4Hpeci6rAIM3CcwMJPx5vW8o40kI/VjC+QSx3hASrpnEd/qdGf05 pe+p2ar6GTJu8DvP8KoGEWywiMc5hV+iN1HouipUSp9alOEYXL1+1is6CqDiTO3QjJRe negTcti3LT9c7KqYiBBpJVT945V74LSGi2N1BYC/z0ZPpVr/5d0B5cVxbsCboPpmO/r+ Icww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KgkwxcQSqb7sTUGCxGjHt3Pg7/MhTqlyw7qHX1C3itA=; b=TUJMKYsEUCA9fIzDbbeWzOe9z8fcizpZS3gqjC1qKvusuGOZaTHn0OOyPl0k+91uog GDvex9EpfVw4sq1TtR3HIqRhRfBG5YTMn3kYaVDjyUyO4AJT/U+wu2dAiQRlGnbxHdBK 7tjWX7YnAoq5CDv3rQauvL4UZxLXt6+7QyZ8YTeTtGDXqH7fIVMqD9Jut1MY63+20dd0 CVYfV8m+YzhSv3wr1mlodaqxcJl8dj3/VNkQTkfGlWBzuQJUdx28+S6xS4JgTJtT2QAN ttLye68ZDtu6xdv4sbLkEwqr/Mz2X3+W1OCc/5kYft5FxArqaxdnu/3cX8tDtY7jRe1Y OkqQ==
X-Gm-Message-State: AKwxytfoMsNLmAlXZk4tZnV25sPgVNVop5lJOuQRgD2hk5eNvYkwnA3Q v3RxfPPSTx/+RAZEhIatnx/u/JssEF4S5upx9VQ=
X-Google-Smtp-Source: AH8x227spuDpe8vD+FoGTbqX3yjLuhZXMQ9M+avCmDHxviIR/9R2viFaUOsQw+h1OPU3Vch8l8RAJn7hMdKUSiwOSuo=
X-Received: by 10.28.150.86 with SMTP id y83mr21336400wmd.42.1517532438038; Thu, 01 Feb 2018 16:47:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.208.130 with HTTP; Thu, 1 Feb 2018 16:47:17 -0800 (PST)
Received: by 10.223.208.130 with HTTP; Thu, 1 Feb 2018 16:47:17 -0800 (PST)
In-Reply-To: <CAM4esxR_L9OvkEQ3G8z=yK1VgPQDJTMWeB2ts7CSgtV_de9MiQ@mail.gmail.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> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <CA+9kkMDvp64NspznEuVy2tu8Eh1xmFkXu5S0AtDwbZKQ9Kq2fA@mail.gmail.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> <CABkgnnVsx9ohKO95bsDbYpM+bgWb-HQiVW2Yn=XWG458uzNgtg@mail.gmail.com> <CAGD1bZbH2qz2WL0YsOJJ=j7V-Lkt_V6K1RQ+5ZhMAzOWEAvdGQ@mail.gmail.com> <A236CE0B-24C1-41F0-A80D-7DD966D291B7@trammell.ch> <CAM4esxTj6Jv4nv975SDzczx9QEG-18WNm7UC7WxDcjyN+PeVgA@mail.gmail.com> <CAM4esxR_L9OvkEQ3G8z=yK1VgPQDJTMWeB2ts7CSgtV_de9MiQ@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 01 Feb 2018 16:47:17 -0800
Message-ID: <CAM4esxRVecQUJZwSv-+fV43CyTER-OY7H7WZGAKU0yT84qn6aA@mail.gmail.com>
Subject: Re: Packet number encryption
To: Brian Trammell <ietf@trammell.ch>
Cc: Jana Iyengar <jri@google.com>, Ted Hardie <ted.ietf@gmail.com>, Roberto Peon <fenix@fb.com>, Christian Huitema <huitema@huitema.net>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Eric Rescorla <ekr@rtfm.com>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="001a114b33e4e790530564300df2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/A9YDKtQUD5OLnVVfEUzxKVJYCNY>
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: Fri, 02 Feb 2018 00:47:23 -0000
Brian, I can come up with a middlebox design that is trying to be "helpful" but ends up causing PN ossification, but as you suggest this requires the box to be dumb about versions. So, meh. The other benefit of this scheme is that acks can go back to 1 byte PNs in ack frames for many connections, as the true packet number will start at 0 (boo!) or 1 (yay!). On Feb 1, 2018 12:09 AM, "Brian Trammell (IETF)" <ietf@trammell.ch> wrote: hi Jana, all, > On 1 Feb 2018, at 03:46, Jana Iyengar <jri@google.com> wrote: > > I like this proposal for the ossification reason that Roberto described, but I also like it because it really simplifies things from an implementation perspective. There seems to be a largely unquestioned assumption that packet number encryption has utility for ossification prevention. I am not convinced of this. Our experience with TLS greasing shows that placing random values in fields that would otherwise largely be static over the lifetime of the protocol improves the ability to use those fields later. Packet number encryption is greasing only by analogy. "Field X has value Y" is a fundamentally different observation than "The values of field X over time are governed by function F", and I'm not sure that intuition in the simpler case applies directly to the more complicated one. Specifically, for packet number encryption, the assumption appears to be that in-network devices will deploy during the operational lifetime of QUIC v1 that will make use of the observation that packet numbers monotonically increase, in a way that will impair the deployment of QUIC vN > 1 that does not have packet numbers that monotonically increase, or packet numbers that appear at a different location in the header. In other words, these devices will fail on this new version of QUIC in such a way that it will impair service to endpoints using QUIC vN. Analogies to the TCP sequence number here are a bit flawed. The most important difference is that the open nature of TCP's wire image means that usage of the sequence number isn't limited to observation: on-path devices can change it, and forge or delay ACKs based on it. The only thing an on-path device can do with a QUIC packet with a packet number it doesn't like is to drop it. This function might have some utility as part of an in-network QUIC garbage filter, as part of an anti-DDoS system, but any such device would need to track the version number as well (indeed, tracking version negotiation and handshaking would be a useful primitive here in its own right), and would therefore have enough information to not break on new versions it knows about. (Note we specifically don't care about the case where devices making use of this observation stop working in a way that the end-to-end properties of QUIC vN are preserved: the invariants as of a given version are the public wire-image interface to the protocol, anything else is at-your-own-risk, no-user-servicable-parts-inside). I suspect that similar arguments can be had about all but the simplest proposed applications of greasing to functions more complex than "the value of field X is always Y or Z". The example of packet number tracking points to an anti-ossification approach that I have much more confidence in, though: The vigorous and meaningful exercise of the version negotiation and version coexistence systems built into QUIC would force agility on on-path devices. The earlier we do this, the more effective it would be. I've already said this in other contexts, but I'll explicitly suggest it here: let's do QUIC 2, and soon (say, July 2019?), and use version negotiation *itself* as a method to "grease" the version negotiation mechanism along with the rest of the header. > We currently have packet number gaps to be used with new CIDs, but these are the same packet numbers on the wire as within the transport. So, when used with connection migration or after quiescence, the sender and receiver of ACKs has to deal with potentially large gaps... this is encodable on the wire, sure, but these gaps are unnecessary within the transport. > > Encrypting packet numbers reduces complexity in that you get a packet number gap on the wire without having to explicitly model it inside the transport. The transport machinery starts packet numbers at 0, increments it by 1 irrespective of migration or quiescence, and the ACK frames similarly carry the plaintext packet number. Separating what's used within the transport and what's visible on the wire allows you to do things like use multiple CIDs within the same 5-tuple. This is a more convincing argument for packet number encryption -- it does seem hard to get this elegance in the transport while having a non-trivially-linkable wire image without it. > I see it as a clean separation of concerns, with consequent simplification in implementation and an additional degree of freedom. > > I'm not convinced of the value of packet number in measuring reordering degree, since this can be trivially done by looking at the IP ID field for packets on the same 5-tuple. For IPv4 packets, on implementations where IPID is not randomized, yes. I don't have numbers on how prevalent these are; in any case, where it isn't randomized, that's arguably a bug that should be fixed. Should the guidance in the manageability draft, then, be "use IPv4 if you care about loss and reordering detection"? I am not optimistic about the chances of that getting past the IESG. ;) Cheers, Brian > On Wed, Jan 31, 2018 at 6:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > With some light editing for quoting purposes... > > On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon <fenix@fb.com> wrote: > >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for the same > >> communicating peers Alice'sPhone and Bob'sBankServer93? > > > > The latter assuming we allow the server to specify it. > > I find "assuming we allow the server to specify *it*" to be strangely cryptic. > > To be clear, my operating assumption is while that servers can provide > multiple connection IDs, those connection IDs need to be usable on any > 5-tuple. Are you suggesting that a server might need to signal where > a connection is usable? (I can see how that might make sense, but it > isn't possible with the protocol as specified.) Or are you suggesting > that there might need to be some signal that allows clients to > distinguish between connection IDs that are for concurrent use? That > is, as opposed to what you might assume to be sequential use based on > the current specification. > > FWIW, it should be possible to remove the sequencing field from > NEW_CONNECTION_ID after making this change. The only reason left for > sequential connection ID use is to give the server the ability to know > when certain connection IDs no longer need to be available. A server > might then be able to clean up associated state and even reuse them. > > Of course, that likely only makes sense if the server is creating > explicit mappings for each, which - as discussed at the interim - > isn't super practical in many deployments. Right now, I think that > the assumption is an assumption only, and that relying on strictly > linear use of connection IDs would be unwise. > >
- 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