Re: Getting to consensus on packet number encryption
Ted Hardie <ted.ietf@gmail.com> Tue, 01 May 2018 17:44 UTC
Return-Path: <ted.ietf@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 F063412E8D7 for <quic@ietfa.amsl.com>; Tue, 1 May 2018 10:44:18 -0700 (PDT)
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=unavailable 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 VWfwQgQjz4Im for <quic@ietfa.amsl.com>; Tue, 1 May 2018 10:44:15 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 A904612E8D4 for <quic@ietf.org>; Tue, 1 May 2018 10:44:15 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id y15-v6so10671918oia.13 for <quic@ietf.org>; Tue, 01 May 2018 10:44:15 -0700 (PDT)
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=bmvh57zcYUEMjIbqo4l2C2VqrxYjl+NVVKffrggFwHU=; b=ujLFFW9hzfw4Odq3wYfUK7MOxyneoWjEG+vO5sRAP5j+ygF5GFFFPlFneR9u/ZIcxo ht9TXiQ0+AKCGAz1djvCt1gN5C5+pPMFUXsam7uWwVZw4x+eOCGiwKWEVIV+EYZ8h1ls 5PoCt35g19W9uC71F9TP5b9zw3WbQBA+fdthPRPwc4+s8QXZ6FUiecQEfAP1l4GEkfhQ yfdxVUdMJ7+87ipeaj6dE2nzM6QHYpQcH4PZsWuvWMPBmThHEacuWY+AsJnSDgMUdBsj 6rSJlmVaBdxbcVUDx5G8LTqc1tichKABG1fS7Xm+xBUjQFFLsQ0jv+jTTNEifMzGwRUn vwZw==
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=bmvh57zcYUEMjIbqo4l2C2VqrxYjl+NVVKffrggFwHU=; b=jisSyF+etvuLFndcq/y/W7gfIjD4cQGRuTcKMDnaZoUKGGqWk4Agz2HPAVPBRLjKa+ TJEnfGw2Zty5zZwe/3Axt7ZGlRHE1CiE95OK5PoYFKjEBooFY5ZwSdloASe+A1Sc9L0p 0+LPYjQm7EjJmQkZRIPFMUNaBT99PulJ4Z8FDPC6jfAVDrtssvmD7SQI0AvfvZvd0dEx J3eBwZ4NJ5gofw73Qjm8HNPWLTX0lNaRXarHxn6ESjM8sF/GTG5CkIvz6d9N3Pt39uuY KZaMsg842+CX/2DW9BhR5HObNVXga8YXO4Ea7DIdkgD+yxHkbUt4XDvNfTKS2K1wio4d /Ccw==
X-Gm-Message-State: ALQs6tAcuFVGgl4CeTIi2nxhA+fPiCAzvatvX7+jw2GDnRhgFdwawo+t pvMGqJIoOLS03iIMUhV0ccxRRV/JpolKRatqKaE=
X-Google-Smtp-Source: AB8JxZpwXtzHBXfhHY8EPOaaSEkBJ/HISuB3wKejr63m+m6xIZH6umHhzRO+yWCn0Rq38K27wHs22MxMMFK8gV7HxA4=
X-Received: by 2002:aca:d6c4:: with SMTP id n187-v6mr9683616oig.284.1525196654868; Tue, 01 May 2018 10:44:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.67.153 with HTTP; Tue, 1 May 2018 10:43:44 -0700 (PDT)
In-Reply-To: <89893592-7135-4C24-BE1E-4B0FFD1A2E97@trammell.ch>
References: <CANatvzwCYrOZULG3iVmDFp97nr=M5=Gufo8TZjOGQVFUpsn0bQ@mail.gmail.com> <CAAedzxqDcPXJUE83KVnDiU23PvqDcTCrc6rRMw09FexjJA-Y6Q@mail.gmail.com> <CANatvzwjYE6EdvFtOXJMVQnutbVQ4YY+=XsQFzKwHzqWzZ4U+w@mail.gmail.com> <d32ade7b56bf4651952659307c08893b@usma1ex-dag1mb5.msg.corp.akamai.com> <CANatvzwHtCn8rLB8npf3i7PGyYZhVDRd2uojh5hv3uxtFPEsSA@mail.gmail.com> <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch> <CACpbDcdfF9w3qqrH1eB0sGU_4vheD9aMP5EXnp1o3Y19N19NUg@mail.gmail.com> <e8b4931a-3931-5b8d-8dad-3ca1939d5542@huitema.net> <CAKcm_gPaj3o-VTdA_0+Kk+nTcVJrYcs_BMyOiDGXKub3gB=GLg@mail.gmail.com> <MWHPR21MB063869878060E850137210FEB6820@MWHPR21MB0638.namprd21.prod.outlook.com> <20180501121906.GA5742@akamai.com> <F63059EA-BA14-4886-A4FB-AA5F04AC164B@akamai.com> <BY2PR15MB07757EAB6A818F1D8D8CCED9CD810@BY2PR15MB0775.namprd15.prod.outlook.com> <CA+9kkMCpxve3CKhQk45YKbvyOyQ6kvzyhpJhrTq1UM-QM+ms2Q@mail.gmail.com> <89893592-7135-4C24-BE1E-4B0FFD1A2E97@trammell.ch>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 01 May 2018 10:43:44 -0700
Message-ID: <CA+9kkMCUTRrM9SPEz=Q5GDgU7whryZ1cRdj-O3=GP=-vOr-X+A@mail.gmail.com>
Subject: Re: Getting to consensus on packet number encryption
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
Cc: Roberto Peon <fenix@fb.com>, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d37fc4056b28848d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cSq-3NSoY0Fhypt-sjOaMe5Yel8>
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, 01 May 2018 17:44:19 -0000
On Tue, May 1, 2018 at 9:56 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote: > hi Ted, all, > > At this point I've pretty much come around to the opinion we should just > land 1079 and discuss the rest, but this conversation continues to have me > worried that we're coming to consensus on a feature we do not fully > understand the applicability and limitations of. > > I also think that just landing 1079 and moving on is the right thing to do. > PNE's primary utility is anti-ossification. While it reduces the amount of > information available to an attacker attempting to achieve linkability of > flows across a purposeful path migration, or with a single-PN-space > multipath design, it does not eliminate it, so expecting more than a > marginal privacy benefit from the feature per se is setting oneself up for > disappointment. > > The reason to disable PNE in (admittedly ill-defined) "datacenter" > environments is to trade off the (~1%ish) overhead for ossification > protection you know you don't need because you didn't deploy anything that > tries to abuse the packet number. > > (on which, more below; and on preview, what Praveen said) > > > On 1 May 2018, at 17:55, Ted Hardie <ted.ietf@gmail.com> wrote: > > > > On Tue, May 1, 2018 at 8:13 AM, Roberto Peon <fenix@fb.com> wrote: > > Also, Prism. > > > > -=R > > > > > > > > That's a little more succinct than I would be, but yes. How does an > application know that the flow it is initiating will traverse a topology > that is deemed to be within a controlled environment? You can say > "configuration" but I fear it will turn up on a post-it if you do. Loads > shift, resources move, and suddenly you find that host which used to be in > the same rack, being down, has load-shifted to the next instance, in a > datacenter 500 miles away across a very different network. > > > > Many modern deployments are also in someone else's data center, so > saying "Data center networks" doesn't say much about why you're trusting > the network inside. > > The "load-shifted to the next instance" example is an interesting one iff > said load shifting causes the traffic that used to cross a private network > to transit the open Internet instead. Well, a long-haul link, certainly. That may or may not be "the open Internet" and the chances of it traversing a completely unknown middlebox are low. The chances of it passing by an unknown observer, on the other hand, are not currently known but are presumed to be high. > Is this a thing that ever happens in any of the environments that get > called "datacenter" for networking technology purposes? > > So, the way I look at this boils down to: If the linkability or ossification concerns with packet numbers in the clear are justified, you either need to have it on all the time or have very clear methods for determining when the concerns are not present. The protocol is not aware of the l2 or l3 topology between an initiator and its peer, much less the management of that path. So the clear methods for determination really boil down to "someone turns this off when they think it is right to do so". Flows entirely within the domain of control of a single provider might be a case where folks think it is right to do so. A subset of that domain of control is when the flow has no long-haul links (for however you want to define that), the shorthand for which is "datacenter network" (though it might well also be a small complex of datacenters, an enterprise campus, or similar). But the key is that you believe that the topology between peer A and peer B has no middleboxes outside of the shared domain of control that might ossify the behavior and no observers whose use of this data concerns you. If you control both peers and the network between them, using a QUIC version where this is always turned off might make sense. But having QUIC negotiate this outside of the version does not make sense to me, because there is no way for an initiator or a responding peer to judge whether the other side's assertion of safety is well-founded or even well-meant. If it has no independent data on this (and the protocol provides none), this allows one side or the other to unilaterally turn off an anti-ossification and anti-linkability feature for whatever gain it wants. Since we're trying to optimize for the long-term flexibility of the protocol, allowing that particular point optimization seems contrary to our interests, much less the privacy interests of the peers. regards, Ted > Cheers, > > Brian > > > Ted > > > > Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone > > > > > > -------- Original message -------- > > From: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org> > > Date: 5/1/18 5:25 AM (GMT-08:00) > > To: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>, Praveen > Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org> > > Cc: IETF QUIC WG <quic@ietf.org> > > Subject: Re: Getting to consensus on packet number encryption > > > > > I disagree that we need any more data for not doing PNE in the > datacenter. Why would we add an extra encrypt-decrypt step for no obvious > benefit? > > > > I am concerned that people will mis-interpret the meaning of a > datacenter, and think that a bunch of servers, or even a rack, in an open > colo space is a "datacenter." Computers keep getting faster. > > > > > >
- Hardware acceleration and packet number encryption Christian Huitema
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Kazuho Oku
- Re: Hardware acceleration and packet number encry… Eric Rescorla
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Kazuho Oku
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Eric Rescorla
- RE: Hardware acceleration and packet number encry… Deval, Manasi
- Re: Hardware acceleration and packet number encry… Eric Rescorla
- Re: Hardware acceleration and packet number encry… Subodh Iyengar
- Re: Hardware acceleration and packet number encry… Eric Rescorla
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Christian Huitema
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Ian Swett
- Re: Hardware acceleration and packet number encry… Christian Huitema
- RE: Hardware acceleration and packet number encry… Deval, Manasi
- Re: Hardware acceleration and packet number encry… Salz, Rich
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Ian Swett
- RE: Hardware acceleration and packet number encry… Swindells, Thomas (Nokia - GB/Cambridge)
- RE: Hardware acceleration and packet number encry… Deval, Manasi
- Re: Hardware acceleration and packet number encry… Christian Huitema
- Re: Hardware acceleration and packet number encry… Jana Iyengar
- Re: Hardware acceleration and packet number encry… Ian Swett
- Re: Hardware acceleration and packet number encry… Watson Ladd
- RE: Hardware acceleration and packet number encry… Praveen Balasubramanian
- RE: Hardware acceleration and packet number encry… Praveen Balasubramanian
- RE: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- RE: Hardware acceleration and packet number encry… Praveen Balasubramanian
- Re: Hardware acceleration and packet number encry… Mark Nottingham
- RE: Hardware acceleration and packet number encry… Praveen Balasubramanian
- Getting to consensus on packet number encryption Mark Nottingham
- Re: Getting to consensus on packet number encrypt… Willy Tarreau
- Re: Getting to consensus on packet number encrypt… Mirja Kühlewind
- Re: Getting to consensus on packet number encrypt… Dmitri Tikhonov
- Re: Getting to consensus on packet number encrypt… Patrick McManus
- Re: Getting to consensus on packet number encrypt… Spencer Dawkins at IETF
- Re: Getting to consensus on packet number encrypt… Patrick McManus
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… Patrick McManus
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… Ted Hardie
- Re: Getting to consensus on packet number encrypt… Mirja Kühlewind
- RE: Getting to consensus on packet number encrypt… Mike Bishop
- Re: Getting to consensus on packet number encrypt… Dmitri Tikhonov
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- Re: Getting to consensus on packet number encrypt… Mark Nottingham
- Re: Getting to consensus on packet number encrypt… Ian Swett
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Mark Nottingham
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Martin Thomson
- RE: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- Re: Getting to consensus on packet number encrypt… Willy Tarreau
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- ECN signaling from userland Re: Getting to consen… Lars Eggert
- Re: ECN signaling from userland Re: Getting to co… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… alexandre.ferrieux
- Re: Getting to consensus on packet number encrypt… Eric Rescorla
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Mirja Kühlewind
- Re: Getting to consensus on packet number encrypt… Philipp S. Tiesel
- Privacy holes (was: Re: Getting to consensus on p… Christian Huitema
- Re: Privacy holes (was: Re: Getting to consensus … Frederick Kautz
- Re: Privacy holes (was: Re: Getting to consensus … Christian Huitema
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Privacy holes Gorry Fairhurst
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- RE: Privacy holes (was: Re: Getting to consensus … Mike Bishop
- RE: Privacy holes (was: Re: Getting to consensus … Mikkel Fahnøe Jørgensen
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- RE: Privacy holes (was: Re: Getting to consensus … Lubashev, Igor
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- RE: Privacy holes (was: Re: Getting to consensus … Praveen Balasubramanian
- RE: Privacy holes (was: Re: Getting to consensus … Lubashev, Igor
- RE: Privacy holes (was: Re: Getting to consensus … Lubashev, Igor
- RE: ECN signaling from userland Re: Getting to co… Praveen Balasubramanian
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Frederick Kautz
- Re: Privacy holes (was: Re: Getting to consensus … Willy Tarreau
- Re: Privacy holes (was: Re: Getting to consensus … Martin Thomson
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Martin Thomson
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- RE: Privacy holes (was: Re: Getting to consensus … Lubashev, Igor
- Re: Privacy holes (was: Re: Getting to consensus … Mikkel Fahnøe Jørgensen
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Brian Trammell (IETF)
- Re: Privacy holes (was: Re: Getting to consensus … Martin Thomson
- Re: Privacy holes (was: Re: Getting to consensus … Brian Trammell (IETF)
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Grips in the Wire Image for In-Network State (was… Brian Trammell (IETF)
- Re: Grips in the Wire Image for In-Network State … Mikkel Fahnøe Jørgensen
- Re: Privacy holes (was: Re: Getting to consensus … Martin Thomson
- Re: Privacy holes Roland Zink
- Re: Grips in the Wire Image for In-Network State … Kazuho Oku
- Re: Grips in the Wire Image for In-Network State … Martin Thomson
- Re: Grips in the Wire Image for In-Network State … Brian Trammell (IETF)
- Re: Grips in the Wire Image for In-Network State … Brian Trammell (IETF)
- Re: Privacy holes Ian Swett
- Re: Grips in the Wire Image for In-Network State … Spencer Dawkins at IETF
- Re: Grips in the Wire Image for In-Network State … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Grips in the Wire Image for In-Network State … Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Mark Nottingham
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… Ian Swett
- Bona fide loss measurement bits alexandre.ferrieux
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: [Potential Spoof] Re: Getting to consensus on… Roberto Peon
- RE: Privacy holes (was: Re: Getting to consensus … Praveen Balasubramanian
- Re: Privacy holes Christian Huitema
- RE: Privacy holes Praveen Balasubramanian
- Re: Privacy holes (was: Re: Getting to consensus … Ian Swett
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Martin Thomson
- Re: Getting to consensus on packet number encrypt… Mirja Kühlewind
- RE: Privacy holes (was: Re: Getting to consensus … Mike Bishop
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Mark Nottingham
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- RE: Getting to consensus on packet number encrypt… Deval, Manasi
- Re: Getting to consensus on packet number encrypt… Jana Iyengar
- Re: Getting to consensus on packet number encrypt… Ian Swett
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- RE: Getting to consensus on packet number encrypt… Mike Bishop
- Re: Getting to consensus on packet number encrypt… Ian Swett
- RE: Getting to consensus on packet number encrypt… Mike Bishop
- Re: Getting to consensus on packet number encrypt… Ian Swett
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Erik Kline
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Patrick McManus
- Re: Getting to consensus on packet number encrypt… Ian Swett
- Re: Getting to consensus on packet number encrypt… Patrick McManus
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… Jana Iyengar
- Re: Getting to consensus on packet number encrypt… Martin Thomson
- Re: Getting to consensus on packet number encrypt… Boris Pismenny
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Ian Swett
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- Re: Getting to consensus on packet number encrypt… Martin Thomson
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Martin Thomson
- Re: Getting to consensus on packet number encrypt… Benjamin Kaduk
- Re: Getting to consensus on packet number encrypt… Salz, Rich
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: Getting to consensus on packet number encrypt… Spencer Dawkins at IETF
- Re: Getting to consensus on packet number encrypt… Ted Hardie
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- Re: Getting to consensus on packet number encrypt… Ted Hardie
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: [Potential Spoof] Re: Getting to consensus on… Roberto Peon
- Re: [Potential Spoof] Re: Getting to consensus on… Jana Iyengar
- RE: [Potential Spoof] Re: Getting to consensus on… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Spencer Dawkins at IETF
- Re: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- Re: [Potential Spoof] Re: Getting to consensus on… Mikkel Fahnøe Jørgensen
- Re: Getting to consensus on packet number encrypt… Benjamin Kaduk
- Re: Getting to consensus on packet number encrypt… Ian Swett
- Re: Getting to consensus on packet number encrypt… Mirja Kühlewind
- RE: Getting to consensus on packet number encrypt… Roni Even (A)
- Re: Getting to consensus on packet number encrypt… Dmitri Tikhonov
- Re: Getting to consensus on packet number encrypt… Gorry Fairhurst
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- Re: Getting to consensus on packet number encrypt… Christian Huitema