Re: Hardware acceleration and packet number encryption
Subodh Iyengar <subodh@fb.com> Sun, 25 March 2018 04:42 UTC
Return-Path: <prvs=66220d118e=subodh@fb.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 80C4B126E01 for <quic@ietfa.amsl.com>; Sat, 24 Mar 2018 21:42:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level:
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=YZXWOwL2; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Vw1e5LIw
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 UkZN1JzZN_Ia for <quic@ietfa.amsl.com>; Sat, 24 Mar 2018 21:42:00 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685DA126BF6 for <quic@ietf.org>; Sat, 24 Mar 2018 21:42:00 -0700 (PDT)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2P4dLYT028998; Sat, 24 Mar 2018 21:41:53 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=QKUs7MvK00leckVSiVdrbJzz2vFN8FWt/NO6m0K0rvk=; b=YZXWOwL2VjtoKAaIKp8Cs7UpnBW6ppSe5bzxZffP6TXaJSAcLBW/J3x7Cn1MfERj/okZ yNeV5hc6uZ7Y8uvxX+shpEEzRC+Bo8YcaIDkMwlourWcsOW6wGOfYjcDfRRR45yYt6Zr gK8ror/Ppq55WiEsY2qj3EwWfT87NLRHZxA=
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2gwxeq0j7j-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Mar 2018 21:41:53 -0700
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 25 Mar 2018 00:41:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QKUs7MvK00leckVSiVdrbJzz2vFN8FWt/NO6m0K0rvk=; b=Vw1e5LIwl+ksdh9P4N3R8sTrcERpzs+QItn5VzJzZeg5oyCRN5Mvh0PxmqwO5NH3EDJpx/RywntaBboXMoXW2IIdEZTY9epneRfEwHfkvuCFpKfB9JKQ1Li3DHqawQExzmxl90k1WZfYknkxH1S8AAFpliZJmJcPLHXH5KnY0Dg=
Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1712.namprd15.prod.outlook.com (10.174.254.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Sun, 25 Mar 2018 04:41:28 +0000
Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::b431:b2fb:1912:34d8]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::b431:b2fb:1912:34d8%17]) with mapi id 15.20.0609.012; Sun, 25 Mar 2018 04:41:28 +0000
From: Subodh Iyengar <subodh@fb.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: "Deval, Manasi" <manasi.deval@intel.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>, Christian Huitema <huitema@huitema.net>, Kazuho Oku <kazuhooku@gmail.com>
Subject: Re: Hardware acceleration and packet number encryption
Thread-Topic: Hardware acceleration and packet number encryption
Thread-Index: AQHTw2pYkfEUVXztJkynMd/uXC9Ww6Pfab+AgAAo/YCAAFZ6AIAADAQAgAAvsICAAAzVgIAALoAd
Date: Sun, 25 Mar 2018 04:41:28 +0000
Message-ID: <82369B21-CDED-4A6F-9B32-FF1D93816D80@fb.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>
In-Reply-To: <CABcZeBNfPsJtLErBn1=iGKuLjJMo=jEB5OLxDuU7FxjJv=+b=A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [107.77.222.194]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1712; 7:OaiTVQAGj/T+1xTPxDuCV0flNSyBxAZVuKHQFV3B8XygayKDlKzBSnk8KhVL6G38H3QzSEvmUVLqklb4i1UYYyKV3q0V1/Zq4HajIosO6fQVqc1BxbxrAJmEdCHORPrSaMfvwsmBcNSPbFDcH4DOd0epCTCiCh2e2qim849omtrJF7rwqxqsMfNnEYdrg/ipaEYzbuwbNwav1Pre/PzHEnNkhlvP+yEMj5GVziXyzuP5BFwvEfCSJOiaQ3CvHB74; 20:zB+wO2Fw2mVyTNfmKRUMd9NhILjgAhtop26PLcS/kj1cRw1TnlmrxebkHnZbKiLx7MpKt4VFi8rna1g/XbQmoSL4dulJyep0bhbRE/RkQBx/o8lbQnaAi4UtEGl8V6Vsf+jr46IeG2Z1Jf9ZTOUq7Aaroolfi2MzELDNWQfTNqQ=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 4bfce1d2-06c8-4fd0-0486-08d5920aacb6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1712;
x-ms-traffictypediagnostic: MWHPR15MB1712:
x-microsoft-antispam-prvs: <MWHPR15MB171218D6707665B7244F1D7AB6AE0@MWHPR15MB1712.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705)(85827821059158)(228905959029699);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231221)(11241501184)(944501327)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:MWHPR15MB1712; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1712;
x-forefront-prvs: 0622A98CD5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(39380400002)(376002)(39860400002)(199004)(189003)(5250100002)(5660300001)(25786009)(2906002)(478600001)(53546011)(6506007)(83716003)(86362001)(3660700001)(99286004)(3280700002)(93886005)(186003)(446003)(6116002)(82746002)(68736007)(3846002)(59450400001)(102836004)(54906003)(4326008)(66066001)(76176011)(2900100001)(36756003)(26005)(14454004)(105586002)(8676002)(81166006)(53936002)(39060400002)(6246003)(106356001)(97736004)(54896002)(6916009)(561944003)(606006)(236005)(6306002)(33656002)(6486002)(81156014)(8936002)(7736002)(316002)(229853002)(2616005)(11346002)(6436002)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1712; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: bnKhmstKGbsEAhilH6bQ7cLuZes3sotJd8SYK4d2bhNBC5S/iPr2cWL1qmqBMD8D++eM6FaCgOfBahlDZLjp75/DE9ggzPvBfOepe3qam37pYNuT4MjD9INTm5YRsvePalH1QQjXhiEtSmzS3M9srZnxXkuX0N/hYv4GHkYeEVAZO8syMR4rkWQcY9yn6v5dIUMl7oGeT+NgiShNlCCFvktp2jLDmuEXnkk2P+RUebqc4z+zTWT+FdGUdDTPbKIklnJ9BYjang/x2RDpSWbjHR5NVxorQuGFyHy0j4Io9BVD3O/X0i67df6vPo2jK9ecAwU73SO4r6gsMX63Q9jmDw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_82369B21CDED4A6F9B32FF1D93816D80fbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4bfce1d2-06c8-4fd0-0486-08d5920aacb6
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2018 04:41:28.5543 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1712
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-24_11:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/oCemaOJ7_MwB2udvUtP9ge-tQis>
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: Sun, 25 Mar 2018 04:42:02 -0000
When we were first discussing pne, we proposed that the tag be used as the IV for the ctr operation. The pr samples encrypted data in the packet. Did we change that for a reason? Would that help alleviate the buffering of the stream data? Because tag is always the last thing in the packet. Subodh On Mar 25, 2018, at 2:56 AM, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote: On Sun, Mar 25, 2018 at 2:09 AM, Deval, Manasi <manasi.deval@intel.com<mailto:manasi.deval@intel.com>> wrote: From talking to several of the folks last week, I understand that unlinkability is the goal of this protocol and there may be some flexibility in how that can be achieved. Christian’s e-mail has a detailed list of options. Here is the list of favored options as I understand them. 1. Packet number encrypted as current suggestion - The current proposal for PR 1079, uses a two stage serialized approach such that the stream header(s) and payload(s) need to be encrypted and the outcome of encryption forms the nonce of the packet number encryption. 2. Packet number encrypted alternative 1 - One of the ideas suggested was to encrypt the stream header(s) and payload(s) with the packet number as nonce, but have an additional nonce in the clear to encrypt the packet number. A scheme like this can allow for these two encryption operations to occur in parallel. This still has the issue of serialization in decrypt. 3. Packet number encrypted alternative 2 – Another option is to generate 2 IVs – one for PN and the other for stream header(s) and payload(s). The nonce can be a random value in the clear. This allows us to encrypt and decrypt the two fields in parallel. The packet number is encrypted so it also solves the ossification problem. Another variation of this is to generate a single IV but use one part of it to encrypt the PN. Neither of these alternatives seems ideal. Once you are carrying an explicit per-packet nonce, you might as well concatenate the payload and the PN and encrypt them together. The will require the least amount of nonce material. -Ekr 4. PN in the clear – this is a complex scheme and in the discussion with Ian, Jana and Praveen, they seemed to think this may be ok. If folks think this is implementable, then we may need to find an alternate solution for ossification. Thanks, Manasi From: Eric Rescorla [mailto:ekr@rtfm.com<mailto:ekr@rtfm.com>] Sent: Saturday, March 24, 2018 3:18 PM To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>> Cc: Kazuho Oku <kazuhooku@gmail.com<mailto:kazuhooku@gmail.com>>; Deval, Manasi <manasi.deval@intel.com<mailto:manasi.deval@intel.com>>; Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>>; IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>> Subject: Re: Hardware acceleration and packet number encryption On Sat, Mar 24, 2018 at 9:35 PM, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>> wrote: AERO: I did not read all of it, but it does indeed sound esoteric. It can do two things of interest: reduce space used by packet numbers, and presumably fix the encryption issue. However, it has a W parameter which is the limit of reordering which is default 64 and recommended at most 255 for security reasons. This is way way too low (I would assume) if packet clusters take multiple transatlantic paths. That's just a function of how the packet numbers are encoded. It's not difficult to come up with a design that tolerates more reordering. -Ekr If we accepted such a limit, I could very trivially come up with an efficient solution to PN encryption. Since we cover at most 64 packets, we only need a 5 bit packet number and reject false positives on AEAD tag. To simplify, make it 8 bits. The algorithm is to AES encrypt a counter similar to a typical AES based PRNG. Then, for each packet take one byte from the stream and use it as packet number. The receiver creates the same stream and maps the received byte to an index it has. It might occasionally have to try multiple packet numbers since the mapping is not unique. Longer packet numbers reduce this conflict ratio. To help with this detection some short trial decryption might be included. The PN size can be extended as needed. The cost of doing this is much lower than direct encryption for as proposes in PR because 1) a single encryption covers multiple packets, 2) the encryption can be parallelised resulting in a 4-5 fold performance increase. Combined this results in sub-nanosecond overhead for AES-NI. However, you have to deal with uncertainties which is why this isn’t a very good idea unless you have some very good knowledge of the traffic pattern. It also complicates HW offloading, but I don’t see why it couldn’t be done efficiently. Mikkel On 24 March 2018 at 17.26.47, Eric Rescorla (ekr@rtfm.com<mailto:ekr@rtfm.com>) wrote: 3. A more exotic solution like AERO (https://tools.ietf.org/html/draft-mcgrew-aero-00#ref-MF07<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmcgrew-2Daero-2D00-23ref-2DMF07&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=Kqui4PrKKRuP58njW3vlK_ZPgcQX0TQ9iXVtGY1Kp30&s=GthDylmhvmHUnMvnjBT05qJT9VrOTknvVoMbdC7ObLo&e=>)..
- 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