RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Praveen Balasubramanian <pravb@microsoft.com> Thu, 05 April 2018 18:19 UTC
Return-Path: <pravb@microsoft.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 691E312AF84 for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 11:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 9PSWIh1PozBt for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 11:19:26 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0120.outbound.protection.outlook.com [104.47.32.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47203129C6D for <quic@ietf.org>; Thu, 5 Apr 2018 11:19:26 -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=1W8g4r2tTiZki7j+KI6RWstYibwM6cMo8YYtEzC28HM=; b=Tnb0TW7skqAri7JjM6+YhNmtuGqCIAw+9csXReu4pesKym1Xr334E4Yl8e2yGCh9+tR3mur8rO/DP4mxoTtsJdA85KdCxTRimqrzsX/sCu3UGJWbCtpe4GgSvh1vfWbQXUINMyQtugOXPSD+ktNOovK0297P1wne3nRC5ErwTwE=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0856.namprd21.prod.outlook.com (10.173.192.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Thu, 5 Apr 2018 18:19:23 +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.003; Thu, 5 Apr 2018 18:19:23 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Kazuho Oku <kazuhooku@gmail.com>, "Lubashev, Igor" <ilubashe@akamai.com>
CC: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, huitema <huitema@huitema.net>, Mike Bishop <mbishop@evequefou.be>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>, Frederick Kautz <fkautz@alumni.cmu.edu>
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Index: AQHTzPOfhJMCgvyw60+hsX7hCsq0T6PyVBsAgAACsgCAABOkAIAAAk8AgAABDICAAAfeAIAAAtaAgAACq3A=
Date: Thu, 05 Apr 2018 18:19:22 +0000
Message-ID: <CY4PR21MB0630BF7EC130BD8987C8CE11B6BB0@CY4PR21MB0630.namprd21.prod.outlook.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <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> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <B176FC07-887D-4135-B01E-FE8B4986A5EE@mnot.net> <CAKcm_gOCeocLyrYpOS7Ud332xdz3xHSH0psPN8T6BGRjoL9ptQ@mail.gmail.com> <CY4PR21MB0630FA0EDD343396AD414641B6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <CAN1APde13JTzCvKFFvMd183Fka6QGD1kGBjsa9fcoLrYeA2hsA@mail.gmail.com> <CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <CAJGwveB=qs+J2iBQRs3d5jdGuP9yBWoAgv0t3mwD=Wrf6Q5g8g@mail.gmail.com> <F395D018-FFCA-405F-BBD5-1313C6F6DAF9@huitema.net> <CANatvzy8zTFKs-c-rR0jMSHdh2HJMvZrRmcR5A+b6qNpNPzkrw@mail.gmail.com> <SN1PR08MB1854010FD61AC17D19E497FDDABB0@SN1PR08MB1854.namprd08.prod.outlook.com> <CAN1APddJ7b+7Ydtw7i5c3XBHiC3mz9FmJEM-kZ0=Y8DvmpQ0eg@mail.gmail.com> <a02101a18f16419f81233058a1a6de15@usma1ex-dag1mb5.msg.corp.akamai.com> <CANatvzyEWb1esUcPL=pP6eDmyB7cmfuUOn6vGMTui3Jr+Z-oQQ@mail.gmail.com>
In-Reply-To: <CANatvzyEWb1esUcPL=pP6eDmyB7cmfuUOn6vGMTui3Jr+Z-oQQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:a::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0856; 7:O4CDZHK1AprjHOvFt+JcBYR0LoiErigUIjm+aTZKbGkNk0m3ycDphPcv74uItMPmAfLJxJriF/w47S+UtJBryEAYKNYZcj/QiKkOu7drkLsO1Jtm1oq+xm6toB/ngS7rZq+sK5KhHCPQwkMX1n+r+vLSWEMwEl7F7ueGTCwzGo+symxP+SeybLQoyQFDCYSfMmFMEoEhv1k1qC01ubu7vam4fXTTWFc2mmCphDAnTsMW58gVL08BoRteJg6chAtG; 20:/7SEgdmdm+jHctUtqvWkKTpNS/sJMfgjTpGUrgAikXCLaRzDNX5meseS87JBTR3PLebaF+ORXItW/DCt/I/JVoHLq8D4t+kUPzPqxYwTwYw4MDKHQ2jrlKfiAwXNyN8+Lw4zix1jEKTPWpS5X5Jlg3btsY66TtD8Bz53bRdgXRM=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 7cd69645-838d-4fe2-e221-08d59b21c1d8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0856;
x-ms-traffictypediagnostic: CY4PR21MB0856:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <CY4PR21MB08561DE74774B8EBB1D86C8DB6BB0@CY4PR21MB0856.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(100405760836317)(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0856; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0856;
x-forefront-prvs: 06339BAE63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(39380400002)(376002)(396003)(346002)(199004)(189003)(377424004)(8990500004)(6506007)(2900100001)(110136005)(54906003)(46003)(476003)(93886005)(5660300001)(14454004)(11346002)(2906002)(5250100002)(105586002)(7736002)(86362001)(478600001)(74316002)(102836004)(53546011)(486006)(19609705001)(186003)(86612001)(68736007)(8676002)(97736004)(81156014)(22452003)(76176011)(39060400002)(3280700002)(8936002)(446003)(25786009)(81166006)(10090500001)(6246003)(561944003)(106356001)(55016002)(54896002)(790700001)(3660700001)(6306002)(6116002)(53936002)(6436002)(316002)(9686003)(236005)(10290500003)(229853002)(99286004)(33656002)(7696005)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0856; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: X3aJN7jQtL9jZkaXb+iwsMtMVhE2NJ1jPIi27GTEUJ4gqPstcGpbZ4zk/fABxVf8Z+wtaviFyDhYql33uwcZd8lfIvXR/8C9etDFE569y0yiYB+V3FqZ38Rc7RSZtbXHrAJRW/xGIoSLXK+4EmM3o8uhvZ8NO6/tQa5F05L6HQaQfBKfT60jPlzREm9Qblhhs+8I2k/ArdBdAA6TwehguIgBjCN6b14k3NYzDskG6sG41iOmL/axCiRMR14+EYhEz7mDUflkF8/DYzZ2/B+CI1I3+YB9C/0ewqqppV1vLJutvRKPwkndCLcYGqexCbkQzAb9UYtwHEFJzLPX3bmSXp9czrA0Uqwd1XmwIG2LpjWd2NChOf49fr/ckc1Zp5TjLT6DotOLEB6d9k0/qS0Q2K+Y3TPrN3ptf0febdEyGdk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630BF7EC130BD8987C8CE11B6BB0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7cd69645-838d-4fe2-e221-08d59b21c1d8
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 18:19:22.9334 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0856
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7zvrZCAZ_kjUK7ov87D3DzXnJzg>
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: Thu, 05 Apr 2018 18:19:29 -0000
IMO we should not have a design that forces load balancers to decrypt. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Kazuho Oku Sent: Thursday, April 5, 2018 11:09 AM To: Lubashev, Igor <ilubashe@akamai.com> Cc: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>; huitema <huitema@huitema.net>; Mike Bishop <mbishop@evequefou.be>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>; IETF QUIC WG <quic@ietf.org>; Frederick Kautz <fkautz@alumni.cmu.edu> Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption) 2018-04-06 2:59 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>>: * I'd prefer making handshake packets indistinguishable from short header packets. In essence, you move the flags of the long header inside the AEAD-protected area. An endpoint that receives a packet carrying a CID that does not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful reset if the trial-decryption fails. This change would wreck stateless load balancers that rely on being able to distinguish CI packets (and route them based on IPs) from other packets (and route them based on CID). It would not, *if* the stateless load balancer can AES-decrypt the packet (using the key derived from the packet header) to see if the packet is in fact a initial packet. Or another way of solving the issue will be to always route the packet based on CID, then forward the packet between the endpoints behind the load balancer. I agree that it would be a no-deal for stateless load balancers that are incapable of doing such things. - Igor From: Mikkel Fahnøe Jørgensen [mailto:mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>] Sent: Thursday, April 05, 2018 1:31 PM To: Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>; Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>>; Kazuho Oku <kazuhooku@gmail.com<mailto:kazuhooku@gmail.com>> Cc: IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>; Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch<mailto:mirja..kuehlewind@tik.ee.ethz.ch>>; Frederick Kautz <fkautz@alumni.cmu.edu<mailto:fkautz@alumni.cmu.edu>> Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption) Hi On 5 April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be<mailto:mbishop@evequefou.be>) wrote: An endpoint that receives a packet carrying a CID that does not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful reset if the trial-decryption fails. I can see hiding things may be a good thing, but having to trial decrypt all unknown packets as potentially creating a huge load, unless you combine it with my proposal to add a checksum to the encrypted packet number so you only need one crypto block on average to reject random packet content. It won’t solve all DDoS, but it will help. Forcing trial decryption fo the full packet makes me a bit anxious. Mikkel -- Kazuho Oku
- 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