RE: Getting to consensus on packet number encryption
Praveen Balasubramanian <pravb@microsoft.com> Fri, 06 April 2018 16:31 UTC
Return-Path: <pravb@microsoft.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C12B126BF7 for <quic@ietfa.amsl.com>; Fri, 6 Apr 2018 09:31:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523032317; bh=sQjziYnvwUdJkn0vUPO8+gR1ii6bnRi6sx0+COX4z/c=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=ah1H49/LxvmoNiFY7Hvfq2AKtFPvDz/h8hp7HjdxeU2vn9BUSSZFUuv/x+AheQrTr J9HCy1OSJU2JhhKKwegseWfXBvlKI87q7XuwKrn1V+7BVzmO0JrE6zl0Ti1nW0j1+o mN2YY9+rK918Hxl18C9H1B6L/FmzgzX+IUZE+5eM=
X-Mailbox-Line: From pravb@microsoft.com Fri Apr 6 09:31:57 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 097E912025C; Fri, 6 Apr 2018 09:31:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523032317; bh=sQjziYnvwUdJkn0vUPO8+gR1ii6bnRi6sx0+COX4z/c=; h=From:CC:Subject:Date:References:In-Reply-To:To:To:To; b=ah1H49/LxvmoNiFY7Hvfq2AKtFPvDz/h8hp7HjdxeU2vn9BUSSZFUuv/x+AheQrTr J9HCy1OSJU2JhhKKwegseWfXBvlKI87q7XuwKrn1V+7BVzmO0JrE6zl0Ti1nW0j1+o mN2YY9+rK918Hxl18C9H1B6L/FmzgzX+IUZE+5eM=
X-Original-To: dmarc-reverse@ietfa.amsl.com
Delivered-To: dmarc-reverse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECD2124D68 for <dmarc-reverse@ietfa.amsl.com>; Fri, 6 Apr 2018 09:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbrCZ6gxL5ZM for <dmarc-reverse@ietfa.amsl.com>; Fri, 6 Apr 2018 09:31:53 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe44::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32F212025C for <pravb=40microsoft.com@dmarc.ietf.org>; Fri, 6 Apr 2018 09:31:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sQjziYnvwUdJkn0vUPO8+gR1ii6bnRi6sx0+COX4z/c=; b=g6HS0crQjQdFKncKrVQSokHcCpABikJ+aORWZCC3mWZo/g16mT+6V9W8B3VHNs4rFI6vBaqmDwo5ylRfCp7pqFYpH00qsrxIacc7QHjjlVpR1+6utibjTg2la4du1pJHcIaRR/6ObYHH83UsdJz34YsM0qZb8qOpj5m8vXLNWzY=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0119.namprd21.prod.outlook.com (10.173.189.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.0; Fri, 6 Apr 2018 16:31:51 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.005; Fri, 6 Apr 2018 16:31:51 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
CC: Lars Eggert <lars@eggert.org>, Mark Nottingham <mnot@mnot.net>, IETF QUIC WG <quic@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwkIMAgADKCACAADzkAIAAwwoggAAk8ACAAW7ogA==
Date: Fri, 06 Apr 2018 16:31:51 +0000
Message-ID: <CY4PR21MB0630AD22989C128C741B4A90B6BA0@CY4PR21MB0630.namprd21.prod.outlook.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <F9FCC213-62B9-437C-ADF9-1277E6090317@gmail.com> <CABcZeBM3PfPkqVxPMcWM-Noyk=M2eCFWZw2Eq-XytbHM=0T9Uw@mail.gmail.com> <CAN1APdfjuvd1eBWCYedsbpi1mx9_+Xa6VvZ3aq_Bhhc+HN67ug@mail.gmail.com> <CABcZeBMtQBwsAF85i=xHmWN3PuGRkJEci+_PjS3LDXi7NgHyYg@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <CABcZeBNfPsJtLErBn1=iGKuLjJMo=jEB5OLxDuU7FxjJv=+b=A@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <BBB8D1DE-25F8-4F3D-B274-C317848DE872@akamai.com> <CAN1APdd=47b2eXkvMg+Q_+P254xo4vo-Tu-YQu6XoUGMByO_eQ@mail.gmail.com> <CAKcm_gMpz4MpdmrHLtC8MvTf5uO9LjD915jM-i2LfpKY384O2w@mail.gmail.com> <HE1PR0702MB3611A67E764EE1C7D1644FAD84AD0@HE1PR0702MB3611.eurprd07.prod.outlook.com> <d8e35569-e939-4064-9ec4-2cccfba2f341@huitema.net> <CACpbDccqKoF-Y1poHMN2cLOK9GOuvtMTPsF-QEen3b30kUo9bg@mail.gmail.com> <CAKcm_gNffwpraF-H2LQBF33vUhYFx0bi_UXJ3N14k4Xj4NmWUw@mail.gmail.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <CAOdDvNo9QS=CX5YUWK8Lxs_SYX4nEM7OWv2+zB=VGhOX6J-BEw@mail.gmail.com> <CANatvzyo6xz7Kwh=EJ4GExBM35Dpw_=pLsAYiFA==vVBJwhCXw@mail.gmail.com> <CABkgnnV8ya_YdhU1VE+BuiMvuuZOO1-j-2=YHAGbmdE3OMk7Gg@mail.gmail.com> <CY4PR21MB0630A6AA3D38CC10DC29AB79B6BB0@CY4PR21MB0630.namprd21.prod.outlook.com> <CY4PR21MB06303E8E1F7E6C0C759B4E0EB6BB0@CY4PR21MB0630.namprd21.prod.outlook.com>
In-Reply-To: <CY4PR21MB06303E8E1F7E6C0C759B4E0EB6BB0@CY4PR21MB0630.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:e::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0119; 7:4zQU+M9vhcxWliGc06WjVss9z/H3Y6jFJEpbQimpBga5L51O+ZyiCTA7RquZEwO0p5101xK+UVWw61Qz87xIMxTBRGWvuKRbZUkOen7kcQU1ThrWR//Z4q4OzxlMQAT6Pkuy+283sKDFzWtZ+rHdZNzF2jmC7A0nkBKbDpnydkdPRPjmA0DguZD93vmPte/I9hT4isW5GC2RIUxhhmbA1kupcSjsxw9I96eKfl7PCIdyv1j/3X0FMjf1hNZfB4ZN; 20:VivWvAZs/HKG7dNmihT59Nn6C3dCNZMrBzxEcL8VUazmJaorhr8FudUQso800v6lRV+J+/po/5PtWrJOwOKj8Usf5eVsxOjgc7fjZEnipz/7zmcvphrtDCI2F3LkzvjjLFeBU+OomWuPY9Y3Ke9yzCPczyZkOXx9YKS61Vuw7Ic=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: cd915fad-dc24-4347-e7df-08d59bdbe6b2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0119;
x-ms-traffictypediagnostic: CY4PR21MB0119:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-prvs: <CY4PR21MB0119F2C7802498E0288FBE0BB6BA0@CY4PR21MB0119.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(85827821059158)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0119; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0119;
x-forefront-prvs: 0634F37BFF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39380400002)(366004)(39860400002)(189003)(199004)(13464003)(51444003)(5660300001)(81166006)(10290500003)(105586002)(10090500001)(99286004)(8990500004)(86612001)(8936002)(81156014)(8676002)(186003)(74316002)(102836004)(33656002)(53546011)(6506007)(7736002)(46003)(54906003)(305945005)(110136005)(53936002)(9686003)(6306002)(55016002)(4326008)(6246003)(106356001)(39060400002)(97736004)(2900100001)(6436002)(14454004)(25786009)(3660700001)(76176011)(6116002)(7696005)(2906002)(229853002)(86362001)(68736007)(11346002)(59450400001)(5250100002)(966005)(316002)(446003)(3280700002)(478600001)(486006)(476003)(22452003)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0119; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: r/fHlJ7jgJ2kgsD/Ml/a4H2DC7XV1QYpWCbLsaQtee3dbp+vV185+a6dqTJpf3sYMuzfX0ltkfwsSgUM8bjK3NRVL1XhBUz9JQn30GDX3cS8usfNEoCYfpREGsEKf9ptlG2p1Nf3AuF8xqCwAoEVeYbeMYXHSEBFskwWZ8EmFhuqTBnZhi444YBBZTUcVPs9Ei8bOtzto5LtpJZyM4TsByHUtO3ptQTp2FZ89nAieg70iFZIoDMW5eEPOP625CuJIQQ0ZKchUNfLjmtq0B5QmcN745y91HYKKj+NGDy2w1MhZcK26Eco8wVwmv8/U/3isd5xOjqRfF/bxaqXwgSBdvm5ZScRjJ/flFob81/gWDyARz0OtqIv3MhmofSDVfqgeneEB+B9vGjTNpbXK6d/dCkRimGWNmNUAyYgPTZuLbU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cd915fad-dc24-4347-e7df-08d59bdbe6b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 16:31:51.1819 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0119
To: Praveen Balasubramanian <pravb@microsoft.com>
To: Martin Thomson <martin.thomson@gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Wkh7HsjutTXAO23t7HVfR6Rr3x8>
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, 06 Apr 2018 16:31:57 -0000
Transport parameters can also be used for negotiation. Opened issue #1271 https://github.com/quicwg/base-drafts/issues/1271 for negotiation of connection migration. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian Sent: Thursday, April 5, 2018 11:27 AM To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>; Martin Thomson <martin.thomson@gmail.com>; Kazuho Oku <kazuhooku@gmail.com> Cc: Lars Eggert <lars@eggert.org>; Mark Nottingham <mnot@mnot.net>; IETF QUIC WG <quic@ietf.org>; Patrick McManus <pmcmanus@mozilla.com> Subject: RE: Getting to consensus on packet number encryption I’d like to clarify that when I said v1 and v2 that we will sim ship them in the same RFC. I did not intend to suggest moving migration out of scope. And then clients that want to migrate and servers that support migration will negotiate v2 and rest of the cases will be v1. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian Sent: Thursday, April 5, 2018 9:42 AM To: Martin Thomson <martin.thomson@gmail.com>; Kazuho Oku <kazuhooku@gmail.com> Cc: Lars Eggert <lars@eggert.org>; Mark Nottingham <mnot@mnot.net>; IETF QUIC WG <quic@ietf.org>; Patrick McManus <pmcmanus@mozilla.com> Subject: RE: Getting to consensus on packet number encryption Love this idea. Expanding it a bit further I don’t think we need to make PN transform a transport parameter but rather connection migration itself. We could also simply use QUIC versioning for this. 1. Ship QUIC v1 with no support for connection migration. Servers behind load balancers that are not QUIC aware will only advertise this version. I expect this to be a large fraction of servers especially those hosted in AWS, Azure, GCP. *This is important - I want the group to acknowledge that servers needs to be able to advertise support for connection migration*. 2. Ship QUIC v2 with support for connection migration. If a client and server use this version they MUST do PNE as per #1079. If we find a more efficient scheme before November then we use that instead. Eventually we will ship QUIV vN which has support for multi-path and we can revisit if PNE is needed or multiple PN spaces will work. Until then I can live with higher CPU cost for the fraction of connections that will migrate. Now there is the ossification problem in QUIC v1 as referred to above. We already require a random starting PN. The next problem is one that Kazuho brought up where middleboxes will start seeing strict increasing PN and try to reorder. I was thinking about short random jumps to fix this problem but the monotonic increase will remain. While I think sane middleboxes will not do any reordering, there might be a few crazy outliers like with TCP. I think we can solve this by making the in clear PN jump both forward and back within a "reordering degree". I am thinking about some ideas here and will reply back if I find a simple scheme. >> FWIW, what I got from the info that Praveen and Ian have shared is >> that there are enough problems to solve with UDP that worrying about >> the performance hit from encryption is premature Martin, we have plans to make UDP screaming fast in software. But the real advantage for TCP comes from the batch offloads (see email with subject " Impact of hardware offloads on network stack performance"). Batch offloads for QUIC are impossible to do without crypto offload. I would be happy to explain more on this front. I think we will exhaust software optimizations soon and then get blocked on crypto offload. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Wednesday, April 4, 2018 9:36 PM To: Kazuho Oku <kazuhooku@gmail.com> Cc: Lars Eggert <lars@eggert.org>; Mark Nottingham <mnot@mnot.net>; IETF QUIC WG <quic@ietf.org>; Patrick McManus <pmcmanus@mozilla.com> Subject: Re: Getting to consensus on packet number encryption On Thu, Apr 5, 2018 at 10:57 AM, Kazuho Oku <kazuhooku@gmail.com> wrote: > It is true that #1079 has issues with hardware crypto offload. I am > happy to support switching to a better encryption scheme (if we find > one) at any moment; e.g., during the standardization of QUICv1, or as > an extension to v1, or part of vX. Until this came up, I hadn't considered the use of an extension/transport parameter to negotiate a new scheme, but it's obvious. This fits best with my view of things. If that means that we get the DC-QUIC option that turns the packet number encryption function into identity or some cheaper function, then I think that's an OK outcome. We should stop pretending that one size fits all is achievable; it's not been the case for years already. FWIW, what I got from the info that Praveen and Ian have shared is that there are enough problems to solve with UDP that worrying about the performance hit from encryption is premature.
- 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