From nobody Fri Jul 1 02:22:25 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF20A12D520 for ; Fri, 1 Jul 2016 02:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.046 X-Spam-Level: X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 CQN_bjsl8Uqh for ; Fri, 1 Jul 2016 02:22:20 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34EF12D516 for ; Fri, 1 Jul 2016 02:22:17 -0700 (PDT) Received: from smtptc.telefonica.com (tgtim3c04.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 83D0F8867A; Fri, 1 Jul 2016 11:22:15 +0200 (CEST) Received: from ESTGVMSP104.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP104", Issuer "ESTGVMSP104" (not verified)) by smtptc.telefonica.com (Postfix) with ESMTPS id 690AF88675; Fri, 1 Jul 2016 11:22:15 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.50) with Microsoft SMTP Server (TLS) id 14.3.266.1; Fri, 1 Jul 2016 11:22:14 +0200 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) by DB6PR0601MB2168.eurprd06.prod.outlook.com (10.168.57.27) with Microsoft SMTP Server (TLS) id 15.1.523.4; Fri, 1 Jul 2016 09:22:13 +0000 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26]) by DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26]) with mapi id 15.01.0523.019; Fri, 1 Jul 2016 09:22:13 +0000 From: "Diego R. Lopez" To: Brian Trammell Thread-Topic: [Spud] endpoint control Thread-Index: AQHR0TeyC/uOpD22C06ei2D0qmDo45//DyoAgAMX9ACAACPNAIAAOOOAgADN2wA= Date: Fri, 1 Jul 2016 09:22:13 +0000 Message-ID: <3061F125-CD4A-4F35-AF02-CB529D5F297C@telefonica.com> References: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch> <6B3B89C7-234E-4412-BD83-056A3C69483B@cisco.com> <3558A391-8B03-469E-BFA6-67F6D23C4188@trammell.ch> <2D94CFA8-0C4E-4167-86D8-2D36EF239B12@cisco.com> <93BB2C6A-B3B1-4322-8047-F3FF67D16692@trammell.ch> In-Reply-To: <93BB2C6A-B3B1-4322-8047-F3FF67D16692@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2.84.175.27] x-ms-office365-filtering-correlation-id: c6e95404-74c7-499c-5bb8-08d3a1912fac x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2168; 6:WAUMEgI4qdy5AG11Ey/RG+Ft6qLKbt8CWgyAyc6jGJM5mf1ImeMuIrmCh/Zf4c7EDAMLxnF1pKgoth3DHQF80GWYpPZHx2eq+KtinYRErz+7IFxEBkY2y+ePrId1hIgIW/j41HJbfP5pMSrP0BzvXC/DTvM3gRZeCQN/xmMgdb2ruTUf+41OTLqy6ROzRXMMeD0zjs1z0H7cJpRqDGrzE0ABx6LI3jTmaXZBi1HV08a7+/DF0nM/VhlzpnhoJ8lNgwu/ZFkTSAx4XR/WoGgq9DnCKhlEHLRD98Nw9hM0LZU35EiUeu0C7mhiSITBnU8a; 5:3qXtUTSKDU6kzJTNsthBYJMMJpVcG6coxWh1i7WZIynETFUnQCV2deUnKRpL+NPCUcLOzU6yzA4w3tNcrpBGXx//G4FHd6XAYQUMrQgMfDVUy6e45x20kt5jGwCUYul5QvYJZSKrHHYUjN8pfiI1Ew==; 24:P0/pPhHMK/2aHRJ1vVGNxpGV9EgF0PF7jz8NNN+dZQNUM+/I6oZ1M/fVjMxvv6g2UJPwPdyuhPZnzLw8IkkCZn1esta0IuQywPgehpgDFZM=; 7:ql4NdWle7aLAbZ1qesUQ1qn4LatdmKlg8Q9P4UM+70K7vWZQubPQL7Pqy4Lf3/exBBrKlI99K+0FOCJLvmTCqgODvcquTt42FneyqzZjC9wPaMm6BnjE1WxM9kIQolmirRjqMBB0kgNmoEyXtBYe6vPOvs+yZFTgCwqhIpT/Ql+F6b56XzLh2o6b+i5UBp/hbKJ64Jd1NtZ7Vh0CEQHiw//6TUaueNF4djJHG3f38XQgrBg7hpD5H2/m4PXzSgdISn9QLWc25na786md1XlnLA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0601MB2168; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(158342451672863)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB6PR0601MB2168; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2168; x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(24454002)(252514010)(8936002)(105586002)(106356001)(10400500002)(50986999)(66066001)(76176999)(101416001)(15395725005)(3660700001)(82746002)(11100500001)(122556002)(68736007)(54356999)(87936001)(97736004)(36756003)(16236675004)(3280700002)(8676002)(6116002)(5002640100001)(86362001)(586003)(81166006)(81156014)(83716003)(93886004)(102836003)(4326007)(19580405001)(19617315012)(8666005)(7736002)(19580395003)(7846002)(2900100001)(92566002)(2950100001)(7906003)(2906002)(77096005)(110136002)(33656002)(15975445007)(189998001)(106116001)(3846002)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2168; H:DB6PR0601MB2167.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3061F125CD4A4F35AF02CB529D5F297Ctelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2016 09:22:13.0685 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2168 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 Archived-At: Cc: "Smith, Kevin, \(R&D\) Vodafone Group" , =?utf-8?B?8J+Uk0RhbiBXaW5n?= , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 09:22:24 -0000 --_000_3061F125CD4A4F35AF02CB529D5F297Ctelefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCih0ZXh0IHRyaW1tZWQgdG8gZWFzZSByZWFkaW5nKQ0KDQpPbiAxIEp1bCAyMDE2LCBh dCAyNDowNSAsIEJyaWFuIFRyYW1tZWxsIDxpZXRmQHRyYW1tZWxsLmNoPG1haWx0bzppZXRmQHRy YW1tZWxsLmNoPj4gd3JvdGU6DQoNCg0KT24gMzAgSnVuIDIwMTYsIGF0IDE5OjQxLCDwn5STRGFu IFdpbmcgPGR3aW5nQGNpc2NvLmNvbTxtYWlsdG86ZHdpbmdAY2lzY28uY29tPj4gd3JvdGU6DQoN Cg0KT24gMzAtSnVuLTIwMTYgMDg6MzMgYW0sIEJyaWFuIFRyYW1tZWxsIDxpZXRmQHRyYW1tZWxs LmNoPG1haWx0bzppZXRmQHRyYW1tZWxsLmNoPj4gd3JvdGU6DQoNCldlbGwsIHlvdSBuZWVkIHRo ZSBlbmRwb2ludCB0byBrbm93IHdoaWNoIGFuZCB3aGF0IGtpbmRzIG9mIG1pZGRsZWJveGVzIGl0 cyB0cmFmZmljIGlzIGxpa2VseSB0byBlbmNvdW50ZXIgb24gdGhlIHdheSB0byB0aGUgb3RoZXIg ZW5kcG9pbnQuIFRoZXJlIGFyZSB0aHJlZSBjYXNlcyBJIGNhbiB0aGluayBvZiBoZXJlOg0KDQox LiBBbiBlbnRlcnByaXNlIGRldmljZSBjYW4gYXV0aGVudGljYXRlIHRoZSBlbnRlcnByaXNlIGZp cmV3YWxsIGFuZC9vciBWUE4gZ2F0ZXdheS4NCg0KMi4gQSBtb2JpbGUgaGFuZHNldCBjYW4gYXV0 aGVudGljYXRlIGluZnJhc3RydWN0dXJlIGluIHRoZSBtb2JpbGUgYWNjZXNzIG5ldHdvcmsuDQoN CjMuIEEgc2VydmVyIGluIGEgZGF0YSBjZW50ZXIgY2FuIGF1dGhlbnRpY2F0ZSBpbmZyYXN0cnVj dHVyZSBpbiB0aGUgZGF0YSBjZW50ZXIgbmV0d29yay4NCg0KKFlvdSBjb3VsZCBleHRlbmQgMSB0 byBpbmNsdWRlIGhvbWUgYWNjZXNzIG5ldHdvcmtzIGFzIHdlbGwsIGJ1dCBnZXR0aW5nIHRoZSBp bi1ob21lIGRldmljZXMgYW5kIHRoZSBnYXRld2F5cyB0byBhdXRoZW50aWNhdGUgZWFjaCBvdGhl ciByZWxpYWJseSBpcyBhbiBhcmVhIHRoYXQgc3RpbGwgbmVlZHMgc29tZSB3b3JrIHRvIGtlZXAg ZnJvbSBiZWluZyBhIGdpYW50IHN1cHBvcnQtY2FsbCBnZW5lcmF0b3IuKQ0KDQpJbiBhbGwgdGhy ZWUgb2YgdGhlc2UgY2FzZXMsIHRoZSBhdXRoZW50aWNhdGlvbiByZWxhdGlvbnNoaXAgZG9lc24n dCBjcm9zcyBhbiBhZG1pbmlzdHJhdGl2ZSBkb21haW4gYm91bmRhcnkuIEluIGFuIEludGVybmV0 IGNvbnRleHQsIHRoaXMgaXMgd2hhdCBJIG1lYW4gYnkgImxpbWl0ZWQiLiBOb3RlIHRoYXQgaXQg KmRvZXNuJ3QqIGNvdmVyIHRoZSBjYXNlIHdoZXJlIGEgZGF0YSBjZW50ZXIgc2VydmVyIHNheXMg c29tZXRoaW5nIHRvIHRoZSBtb2JpbGUgYWNjZXNzIG5ldHdvcmssIG9yIHRoZSBoYW5kc2V0IGFu ZCB0aGUgc2VydmVyIGNvb3BlcmF0ZSB0byBzYXkgc29tZXRoaW5nIHRvIHRoZSBzYW1lIG5ldHdv cmssIGJlY2F1c2UgYXMgc29vbiBhcyB5b3UgY3Jvc3MgdGhlIGFkbWluIGRvbWFpbiBib3VuZGFy eSB0aGUgZGV2aWNlLXRvLWRldmljZSBhdXRoZW50aWNhdGlvbiBwcm9ibGVtIHF1aWNrbHkgYmVj b21lcyBpbnRyYWN0YWJsZS4NCg0KQnVpbGRpbmcgYSBjb21tb24gZnJhbWV3b3JrIGZvciBtYWtp bmcgdGhpcyBraW5kIG9mIGF1dGhlbnRpY2F0aW9uIHdvcmsgaXMgYSB2ZXJ5IGludGVyZXN0aW5n IHByb2JsZW0sDQoNClllcy4gIEkgd2FzIGhvcGluZyB5b3UgaGFkIGEgc29sdXRpb24uDQoNClNh ZGx5LCBuby4gSSBkbyBiZWxpZXZlIHRoZSBwcm9ibGVtIGNhbiBiZSBzY29wZWQgaW4gc3VjaCBh IHdheSB0aGF0IGEgdXNlZnVsIHNvbHV0aW9uIGlzIHBvc3NpYmxlLi4uIGJ1dCBJIGRvbid0IGtu b3cgd2hhdCBpdCBsb29rcyBsaWtlLg0KDQpJIHZlcnkgbXVjaCBhZ3JlZSB0aGlzIHdvdWxkIGJl IGhpZ2hseSBkZXNpcmFibGUsIGFuZCB0aGVyZSBhcmUgYSBjb3VwbGUgb2YgcGllY2VzIG9mIHdv cmsgdGhhdCBjb3VsZCBiZWNvbWUgYXBwbGljYWJsZTogUGhpbGxpcCBIYWxhbS1CYWtlcuKAmXMg TWF0aGVtYXRpY2FsIE1lc2ggKHRoYXQgeW91IGNhbiBzdW1tYXJpemUgYXMgYSBwZXJzb25hbCBQ S0ksIHNlZSBodHRwOi8vcHJpc21wcm9vZi5vcmcvKSBhbmQgdGhlIEFCRkFCIFdHLiBBbmQgbGV0 IG1lIG5vdGUgdGhlcmUgd2lsbCBiZSBhIChzZWNvbmQpIElSVEYgc2Vzc2lvbiBvbiBzZXJ2aWNl IGZlZGVyYXRpb24gaW5mcmFzdHJ1Y3R1cmVzIGluIEJlcmxpbiAoaHR0cHM6Ly90cmFjLnRvb2xz LmlldGYub3JnL2dyb3VwL2lydGYvdHJhYy93aWtpL2Jsb2NrY2hhaW4tZmVkZXJhdGlvbiBhbmQg aHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW4pIHRoYXQgSSB0aGluayBp cyByZWxhdGVkIHRvIHRoaXMgZGlzY3Vzc2lvbi4NCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2 ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0K VGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1h aWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20NClRlbDogICAgKzM0IDkxMyAxMjkgMDQx DQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2Fq ZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRh cmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5j aWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRl c3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5v dGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkv byBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVk IGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUg cG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRl IHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQg YW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0 aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5 IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5n IG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBs ZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0 YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1 IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3Ug Y29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFk ZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBp bmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8Ojbywg ZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJv aWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3Rh IG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRp YXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28N Cg== --_000_3061F125CD4A4F35AF02CB529D5F297Ctelefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <3FFACA56D8C2354CBBB23A4A87A04AA3@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4odGV4dCB0cmltbWVkIHRvIGVhc2Ug cmVhZGluZyk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxIEp1bCAyMDE2 LCBhdCAyNDowNSAsIEJyaWFuIFRyYW1tZWxsICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFt bWVsbC5jaCIgY2xhc3M9IiI+aWV0ZkB0cmFtbWVsbC5jaDwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gMzAgSnVuIDIw MTYsIGF0IDE5OjQxLCDwn5STRGFuIFdpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpkd2luZ0BjaXNj by5jb20iIGNsYXNzPSIiPmR3aW5nQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDMwLUp1bi0yMDE2IDA4OjMzIGFt LCBCcmlhbiBUcmFtbWVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdHJhbW1lbGwuY2giIGNs YXNzPSIiPmlldGZAdHJhbW1lbGwuY2g8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpXZWxsLCB5b3UgbmVl ZCB0aGUgZW5kcG9pbnQgdG8ga25vdyB3aGljaCBhbmQgd2hhdCBraW5kcyBvZiBtaWRkbGVib3hl cyBpdHMgdHJhZmZpYyBpcyBsaWtlbHkgdG8gZW5jb3VudGVyIG9uIHRoZSB3YXkgdG8gdGhlIG90 aGVyIGVuZHBvaW50LiBUaGVyZSBhcmUgdGhyZWUgY2FzZXMgSSBjYW4gdGhpbmsgb2YgaGVyZTo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoxLiBBbiBlbnRlcnByaXNlIGRldmljZSBjYW4g YXV0aGVudGljYXRlIHRoZSBlbnRlcnByaXNlIGZpcmV3YWxsIGFuZC9vciBWUE4gZ2F0ZXdheS48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoyLiBBIG1vYmlsZSBoYW5kc2V0IGNhbiBhdXRo ZW50aWNhdGUgaW5mcmFzdHJ1Y3R1cmUgaW4gdGhlIG1vYmlsZSBhY2Nlc3MgbmV0d29yay48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQozLiBBIHNlcnZlciBpbiBhIGRhdGEgY2VudGVyIGNh biBhdXRoZW50aWNhdGUgaW5mcmFzdHJ1Y3R1cmUgaW4gdGhlIGRhdGEgY2VudGVyIG5ldHdvcmsu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKFlvdSBjb3VsZCBleHRlbmQgMSB0byBpbmNs dWRlIGhvbWUgYWNjZXNzIG5ldHdvcmtzIGFzIHdlbGwsIGJ1dCBnZXR0aW5nIHRoZSBpbi1ob21l IGRldmljZXMgYW5kIHRoZSBnYXRld2F5cyB0byBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciByZWxp YWJseSBpcyBhbiBhcmVhIHRoYXQgc3RpbGwgbmVlZHMgc29tZSB3b3JrIHRvIGtlZXAgZnJvbSBi ZWluZyBhIGdpYW50IHN1cHBvcnQtY2FsbCBnZW5lcmF0b3IuKTxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkluIGFsbCB0aHJlZSBvZiB0aGVzZSBjYXNlcywgdGhlIGF1dGhlbnRpY2F0aW9u IHJlbGF0aW9uc2hpcCBkb2Vzbid0IGNyb3NzIGFuIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBib3Vu ZGFyeS4gSW4gYW4gSW50ZXJuZXQgY29udGV4dCwgdGhpcyBpcyB3aGF0IEkgbWVhbiBieSAmcXVv dDtsaW1pdGVkJnF1b3Q7LiBOb3RlIHRoYXQgaXQgKmRvZXNuJ3QqIGNvdmVyIHRoZSBjYXNlIHdo ZXJlIGEgZGF0YSBjZW50ZXIgc2VydmVyIHNheXMgc29tZXRoaW5nIHRvIHRoZSBtb2JpbGUNCiBh Y2Nlc3MgbmV0d29yaywgb3IgdGhlIGhhbmRzZXQgYW5kIHRoZSBzZXJ2ZXIgY29vcGVyYXRlIHRv IHNheSBzb21ldGhpbmcgdG8gdGhlIHNhbWUgbmV0d29yaywgYmVjYXVzZSBhcyBzb29uIGFzIHlv dSBjcm9zcyB0aGUgYWRtaW4gZG9tYWluIGJvdW5kYXJ5IHRoZSBkZXZpY2UtdG8tZGV2aWNlIGF1 dGhlbnRpY2F0aW9uIHByb2JsZW0gcXVpY2tseSBiZWNvbWVzIGludHJhY3RhYmxlLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkJ1aWxkaW5nIGEgY29tbW9uIGZyYW1ld29yayBmb3IgbWFr aW5nIHRoaXMga2luZCBvZiBhdXRoZW50aWNhdGlvbiB3b3JrIGlzIGEgdmVyeSBpbnRlcmVzdGlu ZyBwcm9ibGVtLDxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClll cy4gJm5ic3A7SSB3YXMgaG9waW5nIHlvdSBoYWQgYSBzb2x1dGlvbi48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpTYWRseSwgbm8uIEkgZG8gYmVsaWV2ZSB0aGUg cHJvYmxlbSBjYW4gYmUgc2NvcGVkIGluIHN1Y2ggYSB3YXkgdGhhdCBhIHVzZWZ1bCBzb2x1dGlv biBpcyBwb3NzaWJsZS4uLiBidXQgSSBkb24ndCBrbm93IHdoYXQgaXQgbG9va3MgbGlrZS48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2PkkgdmVyeSBtdWNoIGFncmVlIHRoaXMgd291bGQgYmUgaGlnaGx5IGRlc2lyYWJs ZSwgYW5kIHRoZXJlIGFyZSBhIGNvdXBsZSBvZiBwaWVjZXMgb2Ygd29yayB0aGF0IGNvdWxkIGJl Y29tZSBhcHBsaWNhYmxlOiBQaGlsbGlwIEhhbGFtLUJha2Vy4oCZcyBNYXRoZW1hdGljYWwgTWVz aCAodGhhdCB5b3UgY2FuIHN1bW1hcml6ZSBhcyBhIHBlcnNvbmFsIFBLSSwgc2VlDQo8YSBocmVm PSJodHRwOi8vcHJpc21wcm9vZi5vcmcvIiBjbGFzcz0iIj5odHRwOi8vcHJpc21wcm9vZi5vcmcv PC9hPikgYW5kIHRoZSBBQkZBQiBXRy4gQW5kIGxldCBtZSBub3RlIHRoZXJlIHdpbGwgYmUgYSAo c2Vjb25kKSBJUlRGIHNlc3Npb24gb24gc2VydmljZSBmZWRlcmF0aW9uIGluZnJhc3RydWN0dXJl cyBpbiBCZXJsaW4gKDxmb250IGNvbG9yPSIjODAwMDgwIiBjbGFzcz0iIj48YSBocmVmPSJodHRw czovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaXJ0Zi90cmFjL3dpa2kvYmxvY2tjaGFpbi1m ZWRlcmF0aW9uIiBjbGFzcz0iIj5odHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaXJ0 Zi90cmFjL3dpa2kvYmxvY2tjaGFpbi1mZWRlcmF0aW9uPC9hPjwvZm9udD4mbmJzcDthbmQmbmJz cDs8YSBocmVmPSJodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbiIgY2xh c3M9IiI+aHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW48L2E+KQ0KIHRo YXQgSSB0aGluayBpcyByZWxhdGVkIHRvIHRoaXMgZGlzY3Vzc2lvbi48L2Rpdj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkJlIGdvb2RlLDwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+LS08L2Rpdj4NCjwvZGl2Pg0KPGRpdiBhcHBsZS1jb250ZW50LWVk aXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCiZx dW90O0VzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyZxdW90OzxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkRyIERpZWdvIFIuIExvcGV6PGJyIGNsYXNzPSIiPg0KVGVs ZWZvbmljYSBJJiM0MztEPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL3Blb3BsZS50aWQu ZXMvZGllZ28ubG9wZXovIiBjbGFzcz0iIj5odHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Bl ei88L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KZS1tYWlsOiBkaWVnby5yLmxvcGV6 QHRlbGVmb25pY2EuY29tPGJyIGNsYXNzPSIiPg0KVGVsOiAmbmJzcDsgJm5ic3A7JiM0MzszNCA5 MTMgMTI5IDA0MTxiciBjbGFzcz0iIj4NCk1vYmlsZTogJiM0MzszNCA2ODIgMDUxIDA5MTxiciBj bGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2Rpdj4NCjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIg Y29sb3I9IkdyYXkiIHNpemU9IjEiPjxicj4NCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBz ZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5l ciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28g ZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVz dGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxh DQogbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRv cml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNp w7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJv Z2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEg dsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uPGJyPg0KPGJyPg0KVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25m aWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNz YWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmll ZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLA0KIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRo aXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBp bW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC48YnI+DQo8YnI+DQpF c3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBz ZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBv dSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlk YWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlv IGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGENCiBsZWl0dXJhLCB1dGlsaXphw6fD o28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFy IHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUg ZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBp bWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOn w6NvPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3061F125CD4A4F35AF02CB529D5F297Ctelefonicacom_-- From nobody Sun Jul 3 06:59:32 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F057912B007 for ; Sun, 3 Jul 2016 06:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 lKBUp2nRrEXI for ; Sun, 3 Jul 2016 06:59:28 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA2812B006 for ; Sun, 3 Jul 2016 06:59:27 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 94FDC1A19FC; Sun, 3 Jul 2016 15:58:55 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D18813E5-480D-4EA3-A112-9788E6DF0744"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Sun, 3 Jul 2016 15:58:54 +0200 Message-Id: <657B751A-8AF1-42F5-8451-D04688544490@trammell.ch> References: To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ted Hardie , Natasha Rooney , spud Subject: Re: [Spud] Details about PLUS BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 13:59:31 -0000 --Apple-Mail=_D18813E5-480D-4EA3-A112-9788E6DF0744 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 29 Jun 2016, at 20:26, Tom Herbert wrote: >=20 > On Wed, Jun 29, 2016 at 10:33 AM, Ted Hardie = wrote: >> On Mon, Jun 27, 2016 at 2:28 PM, Tom Herbert = wrote: >>>=20 >>> On Mon, Jun 27, 2016 at 1:12 PM, Ted Hardie = wrote: >>>=20 >>>>=20 >>>> You appear to be saying that the eliminated implicit path layer = simply >>>> should not be replaced in UDP encapsulations unless evidence comes >>>> through >>>> to define what information should be exposed. >>>>=20 >>> Right. Consider that we want to deploy encrypted UDP-based = transports >>> in the near term and that no middlebox supports anything resembling >>> PLUS. In the simplest model, either a network path forwards UDP >>> packets without impediment or it doesn't. If it doesn't we will >>> fallback to TCP and probably alert the user of that at some point. = If >>> PLUS does come on-line then it's worth using only if it provides = some >>> tangible benefit to our traffic or it "fixes" whatever networks are >>> still blocking UDP. >>>=20 >>=20 >> So, having the path forward UDP packets without impediment should be = a >> consistent aim. The idea behind an explicit path layer is to move = from >> "without impediment" to "with optimization". If an endpoint is is = willing >> to inform the path of session start and stop for a UDP-based flow, = for >> example, it may get the longer dwell times in NAT bindings that are >> currently available to flows that reveal that in an implicit path = layer. >> That advantage might translate to avoiding heartbeat traffic, which = is quite >> useful. >>=20 > Ted, >=20 > IMO the idea that the network should be tracking session state like > that is a red herring because it presumes that the "path" of a flow is > well defined and has some invariant hops. IP is a packet switched > network architecture, not circuit switched. There has never been > either a protocol nor architectural requirement that packets of any > flow always go through the same intermediate device. Agreed. This is why, e.g., TCP anycast is such a terrible idea, and is = completely undeployable. Someone should probably point this out to the people deploying it: see = e.g. [1], [2]. Cicalese et al had a nice measurement study on this in = CoNext last year, too [3]. > In fact, I think > we are going to see more cases of flows taking alternate paths within > their lifetime. I hope we do. Restoring the ability to safely treat IP as a = packet-switched architecture is one of the goals of this work (see the = SPUD use cases draft, section 6 [4]). As of today, since common wisdom = holds that TCP performance *sucks* if you reorder packets, quite a lot = of effort goes into reducing reordering within a flow, and it turns out = an excellent way to do that is to make sure all the packets in a flow = hit all the same queues in the absence of rerouting. How can a transport = signal that reordering is tolerable today? > Consider that any smart phone is now typically > multi-homed to both a mobile network and a WIFI network. It's pretty > obvious that we'd like to seamlessly transition from using one network > to the other without breaking established connections. This world has existed for a couple of decades now: SCTP (where it = deploys) and MPTCP do this already by building a session over multiple = transport connections. > In that world > I'm not even sure what sort of PLUS state signaling would be > meaningful (e.g. when transitioning do we need to send a PLUS 'FIN' > into the old network, and a PLUS 'SYN' to the new one?). Simple: map the transport layer signaling for the individual transport = connections to the state signaling on PLUS. > In any case, state signaling to the network seems at best to be a > hint. Any intermediate devices that tracks tries to track stack must > realize they could be completely wrong and need to take this fact into > account. Absolutely. We spend a fair amount of time making this clear in the = requirements document (see requirements 5.7-5.9 [5], though it turns out = that the mechanism for 5.7 and 5.8 are probably identical). > And if the network can't provide any assurances to the host > given the signaled state, for instance a guarantee that NAT bindings > are maintained for the duration of the connection, then the only > recourse for the host has is to fallback to assuming network doesn't > track state (e.g. still needs to send keepalives to maintain NAT). This is also covered in the documents (see esp. use case 3). The goal is = to reduce the aggregate nonproductive traffic in the network once = PLUS-aware middleboxes are deployed, not to make guarantees for any = particular flow or path. > As for the NAT binding issue, I believe that IPv6 is supposed to > obsolete the need for NAT in the first place. Heh. Someone should point this out to all the people working on the = menagerie of ways to make IPv4-only services accessible on IPv6-only = access networks. Cheers, Brian [1] http://blog.catchpoint.com/2015/09/24/tcp-over-ip-anycast/ [2] https://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf [3] = http://conferences.sigcomm.org/co-next/2015/img/papers/conext15-final100.p= df [4] = https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-01#section-6 [5] https://tools.ietf.org/html/draft-trammell-spud-req-04#section-5.7 = et seq. --Apple-Mail=_D18813E5-480D-4EA3-A112-9788E6DF0744 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIbBAEBCgAGBQJXeRofAAoJEIoSt78L6kajBcUP9iBoJJIvELYieZjQIZC6z9IE hwnZhCaWBbv0Kji6IufOwneC8YDclaPTjqbo1qA7wm6hO/v/du0lj3G9WtJaWKtv S02BcNPLpCELHDAonk4SiY3sDU+8wCSdiWUYkjZfC2Hr5uiuqvATmIBgtHfyoOEq 5zPtK8YQIDI7Bx33Vfj8Dbo45uKasDgVJvFnadMD67hx1AW9CXuDBu3Lhh0AUt4D p5SGp/F/QusSG0FTfPowG7MzZKnlwJNjh250CX/aIVCm/unCy6/jWBFmuUf5IVYK kkjpZt6DX2/wAn3y2AQw9Yop5+x7YXxTeJPklbkfVhnG0Gj8leA+uFYK3DbOtpKQ 6gBkRLmPjyFuJ6KIdKRNPsq2tqvQ800ln3MW/pNk+fBMcTgsVdgUzMsqcHlOx/q9 jq9GpBcZMuFM9xS8YDiXBOIPhPQx/FUQFCBzB7XJ4vp2UcuycmTlVkDmQQZzyTXU ApSlLLynlGlO6lRWdaS2ug+L0/WORsMvMozuPExAn+cqtdQ5dUZY/zEFMdBao5Dz jALHbo/L7g8z2GlG9GSISxQY2HUwi7tjDHF99f2uuvgPQOqMWq+ntztcB0zsQgqa Y4CchTpBDAgmkGwJmxNKrdKRvvIvDtVctbtzgMZgIT2i9bkIET7818/0SJmLeZmV 5zUmnRddeZqO5Lwa0cg= =3i3g -----END PGP SIGNATURE----- --Apple-Mail=_D18813E5-480D-4EA3-A112-9788E6DF0744-- From nobody Sun Jul 3 08:39:39 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F6312D119 for ; Sun, 3 Jul 2016 08:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVFEPx7G-BHG for ; Sun, 3 Jul 2016 08:39:37 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 12A1312D0A4 for ; Sun, 3 Jul 2016 08:39:37 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id 187so17533453wmz.1 for ; Sun, 03 Jul 2016 08:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MtzcwqBqiDnaTlK+LGGoy9XaKOLboJzH884JioroQdo=; b=ZYvSIRqS+RmfGYatrMC7UOC+wXw4d1dBBciiqxRif2mu0Rg1Y1M33yegoohKKkNqSV u6rRVRe5pbn+IFJ2OplABK7DAhugeIGTuaBw9WwNjmNNyswzBgEgFelhtl/Qa74LkNvF XY75qgMjmlnXL49F4lBEB5yHCNCWZ5tNadF2Grmh1U0WZ+dKvAasXjBtPDoX5UoLW5+D 81sEPjQV8JMMAt3LwXvVacJivw510UExGy+OHuGe7LroYYa1ODqsrUuSHirRQYzE2QNN a4kzmZMmNOH4rliieCbl0J6lajhVKHqm17hi1cRv3Dv5xDLhzQJ9rhCxWvOhDovE7fgD 3JlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MtzcwqBqiDnaTlK+LGGoy9XaKOLboJzH884JioroQdo=; b=h8Hxn8dt1Lhq5UTsCdhBd1NfRe0/thMRAZyaZ+5z4+Pk8JI8SMWhwg+APbaxZlqY+p ixJzpm5igQuxJYTzziZXVHGa+BmTu6uzNAWAYoapHvOSpkRHQF1f62BT2snEw4ty+GFM Wyd+Ii+4vK3aYwbRh+I7GQkNGSTSyNVZgeWVK37CizZZB6GL6fgGg08r6eTlq/eQi/Aw AfW2A1TFx6z6pqS4MMDX7hl9vhAtcZuw3CPIcDXd5q9w8v3f3pSmbeP/A2BWI9ulug7/ 0tT7Pr2QZGOFgaDmKvq0RZM6ep/5KIE7nPfHpbcCt/YA+YBdQzm3i8WpKWcc7/VzJamO 45cQ== X-Gm-Message-State: ALyK8tLY19LCyd8QTqj1fpeYa0/2MJNoKKyv17GyN6bo2xDNkKWDWSrHKJiTF9ErJoeSHA== X-Received: by 10.28.69.134 with SMTP id l6mr6990461wmi.80.1467560375466; Sun, 03 Jul 2016 08:39:35 -0700 (PDT) Received: from [172.24.249.249] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id ej9sm5438004wjd.7.2016.07.03.08.39.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Jul 2016 08:39:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Sun, 3 Jul 2016 18:39:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <163067B5-A5AC-4360-985F-D54A235A1093@gmail.com> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Szilveszter Nadas , Joe Touch , spud , Brian Trammell , Ca By , Christian Huitema Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 15:39:39 -0000 > On 26 Jun 2016, at 12:32 AM, Tom Herbert wrote: >=20 >>>=20 >>>=20 >>=20 >> Is there anyone from a middle box vendor here? Do you want to hear = what PLUS >> is telling you? Or will middleboxes keep doing what they want? >>=20 > +1, these are very important questions to be answered for PLUS effort. Well, I hesitate to speak for all middlebox vendors, but I work for a = firewall vendor, and I=E2=80=99ve been told that firewalls are the = second most problematic middlebox ([1]). So IMO middleboxes will do whatever their developers feel is necessary = to accomplish the box=E2=80=99s job. If PLUS tells the middlebox things = that allow it to do its job better or cheaper, they will listen.=20 For example, if PLUS marks some flows as latency-sensitive and others as = loss-sensitive, middleboxes that perform q QoS function are likely to = listen. Similarly, information that would help in filtering (although I can=E2=80=99= t off-hand think of an example) would be used by a firewall/IDS. If a = firewall/IDS currently performs TLS proxy functionality to make some = categorization, and the same categorization can be made on the basis of = PLUS data, that would be a win for both usability and performance.=20 >=20 >> I am concerned plus is saying things nobody is listening to. >>=20 > Unless somebody's listening, there's no reason to believe applications > are going to bother to say anything. I agree that this would be important input for a potential WG. It would = be appropriate to find a use-case for why somebody would listen for = anything someone proposes that the applications say. Yoav [1] First place being buggy middleboxes from defunct vendors that will = never ever get updated.= From nobody Wed Jul 6 17:00:36 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E89312B078 for ; Wed, 6 Jul 2016 17:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 63U9GFgLYSZs for ; Wed, 6 Jul 2016 17:00:32 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 5D36412B03E for ; Wed, 6 Jul 2016 17:00:32 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id f30so9352360ioj.2 for ; Wed, 06 Jul 2016 17:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RqIS3/LzRXx+/PrAdgoEPRnBqScddBtLrpbIFPMQFQ0=; b=OK34ge/C05C6XUkJn6ab/q4UPhlQ4kFoSqqySubZkEUx8FdnWxDT96mjqA4mqET/bD uWP/lV4gRRY7VB2Ts4LTANiNqDH9l1WX/AB57Dxi1IHfU7t/YhcEQtYZkOFNr+Ch93/X v0J3AF098VEu502D+ryfocd9Rktzt1aghdbM+rOsysIMZqMHikNuwQ3XSFWTydFXuobL oj8u6QFDJhbZCtg6QhwUH3goEHxG2yflOir8yKKNBlowAJhvanej4K9I6gJQ0jT1OpPm 8w6Dnme/olCf1fS7xHxYznD56M19O03/sjQquivYoEBT1YEISwFIq1Avjps0NB5J19HY m5yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RqIS3/LzRXx+/PrAdgoEPRnBqScddBtLrpbIFPMQFQ0=; b=bgQSxRsPAxhkxsFFcCLvYI98PVc8eQQPIan3ZukrK/OixU1jiZMfLhLhDi1eP8ERyW 1Ojf5Ynpa+oFa6iYJ7LnQJp515GoPun1c4TI2HvIof5J+D0Selp2dD1E5F/UvmtUNDTw rGVWta5S9ATELaaiaX6lG/j/MOz2lp4eK3ygaIEghgwZltTLK8IvgPHavdjlzvgydOSu EZoD2QwpeE6xxPX2L2HBPNIAMvZI4I2ame1Ikn6ljNaMqlgosjozUt7nd9e1NriVvrXW izp7y12381NAVD1kSLSN/B9Y1TYN7t1MaZ7sQUMdgBjt1APxwt1Fbo+iS1IQsBxAQwAv ammg== X-Gm-Message-State: ALyK8tI6kVENWxniaAdcMQCoOB8rGL9xhZgnWk8iClsn61uGFckdc1EJKpmA2qi6ddtkzogIy6SjTBJVAANmsQ== X-Received: by 10.107.11.26 with SMTP id v26mr24500901ioi.107.1467849631513; Wed, 06 Jul 2016 17:00:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Wed, 6 Jul 2016 17:00:30 -0700 (PDT) In-Reply-To: <20160706235033.26688.47764.idtracker@ietfa.amsl.com> References: <20160706235033.26688.47764.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Wed, 6 Jul 2016 17:00:30 -0700 Message-ID: To: spud Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Blake Matheny , Natasha Rooney Subject: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 00:00:35 -0000 Hello, I just posted a new version -01 of Transport Over UDP. The major changes are more elaboration of disassociated location, making session numbers not be symmetric, more details on session negotiation, peer address and port learning described, don't use addresses in pseudo header with TOU, and handling for TCP resets. I would like to present TOU at the PLUS BOF if possible. Thanks, Tom ---------- Forwarded message ---------- From: Date: Wed, Jul 6, 2016 at 4:50 PM Subject: New Version Notification for draft-herbert-transports-over-udp-01.txt To: Tom Herbert A new version of I-D, draft-herbert-transports-over-udp-01.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-transports-over-udp Revision: 01 Title: Transport layer protocols over UDP Document date: 2016-07-06 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-herbert-transports-over-udp-01.txt Status: https://datatracker.ietf.org/doc/draft-herbert-transports-over-udp/ Htmlized: https://tools.ietf.org/html/draft-herbert-transports-over-udp-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-herbert-transports-over-udp-01 Abstract: This specification defines a mechanism to encapsulate layer 4 transport protocols over UDP. Such encapsulation facilitates deployment of alternate transport protocols or transport protocol features on the Internet. DTLS can be employed to encrypt the encapsulated transport header in a packet thus minimizing the exposure of transport layer information to the network and so promoting the end-to-end networking principle. Transport connection identification can be disassociated from network location (IP addresses) to provide connection persistence for mobility and across state eviction in NAT. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Jul 7 15:37:13 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A37812D770 for ; Thu, 7 Jul 2016 15:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dayVVUOU0tUf for ; Thu, 7 Jul 2016 15:37:08 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 E7CC312D0EB for ; Thu, 7 Jul 2016 15:37:02 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id t127so27427985qkf.1 for ; Thu, 07 Jul 2016 15:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ePf050OeVpKmXl+jPwbvl4i8cckND/bo6e9J/CUTbAg=; b=B63qnhF/NvTdfByapRShsOIm20NDJhaUtcyv0jj6spm2NeS7qN3YiDdRDtunddGfLn TH5KISKKjIS8msP2sqAMdhqPWcAqxkhP86+p5hpF0GXiHhKX3eUEzymF6/SvwVftWDU3 s/KklcY93umR42PQqx/Wmh7FHer8HvWuaYKkTBr7oAejmoGKwDwEo1sF2u6M05lR1V+c UODgu+jKBP9u0eE9UPlp/99jFSFUlFcDt2dKT74AuU9uZ2vpL5+OT1kqSITePgldZozF Aq0RLSEOI1YjA/90OSLmxYddm6x7/XjLOgBgns0GlluZH/0V51peLWSNjuWeFQ39xopr apNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ePf050OeVpKmXl+jPwbvl4i8cckND/bo6e9J/CUTbAg=; b=JQIJprL26oQnY5XLb6yn1WlBYM2LyR3O1LsQbHOX4IfuShH8YTYsBu7Ej0B71Cx1AK Qtc7jVj6+WOmPRR/uqzoHTWGA9V2yreKrBmNJwRY8J53tPTOXgqFBGqFoSMNaJG7sv3F 3jPLyifnFhVvlGBfWHvYtdX2n9xJ9XJhTbODQFz2lOtzuqufYQSh5Z+RU7y0M0CHcwii g1HsVKPSWOf5yrEU/c6itADwzjpQVTMre4CKXmbX7liPR52wlTCNGnckHNfUiktAjabw 9srv8KDSMxsjQJW7ug1UZKBwVDHnlS1J7uGMubbSikDrYIIv9TobwOXIixv1H4THAprW +22Q== X-Gm-Message-State: ALyK8tJGCVF1G3wC+5kMQKA5IUt7rNZeb7PxKk+tyxsEm57YX1V0i3XAj6wdT4KVi8hAbg== X-Received: by 10.55.92.198 with SMTP id q189mr3270671qkb.155.1467931022014; Thu, 07 Jul 2016 15:37:02 -0700 (PDT) Received: from ?IPv6:2001:4878:8000:60:64be:3eee:ece8:cc4d? ([2001:4878:8000:60:64be:3eee:ece8:cc4d]) by smtp.gmail.com with ESMTPSA id 29sm2198044qtx.4.2016.07.07.15.37.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jul 2016 15:37:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5403952E-D13B-400A-9D6B-6EE08B6FF08D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Aaron Falk In-Reply-To: Date: Thu, 7 Jul 2016 18:37:00 -0400 Message-Id: References: <20160706235033.26688.47764.idtracker@ietfa.amsl.com> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Blake Matheny , Natasha Rooney , spud Subject: Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 22:37:11 -0000 --Apple-Mail=_5403952E-D13B-400A-9D6B-6EE08B6FF08D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tom- One explicit goal of PLUS is to enable controlled communication between = endpoints and devices on the network path. As I understand it, TOU is = designed to preclude that communication. As this is a BoF about = chartering a working group around PLUS, the TOU draft neither addresses = PLUS motivation (e.g., why we need to communicate to middleboxes?) or = architecture (e.g., how could we make this communication work in an = world with pervasive encryption?). Since there was some email = discussion of your draft on this list, Brian has tried to address the = distinction between PLUS and TOU in his slide deck = = (specifically, slide 20) and I encourage you to send any clarification = comments to him. To be clear, this isn=E2=80=99t a reflection on the merits of your = proposal, only that it doesn=E2=80=99t address the goals of the BoF: to = determine whether the IETF should take on the work described in the PLUS = charter. Indeed, one could consider TOU to be a competing proposal from = an applications perspective, one based on a different set of = requirements. I would suggest that it might be a totally reasonable fit = with the TSVWG and you might seek agenda time in that working group. If = you are going to discuss TOU in a wg in Berlin, I encourage you to drop = a note to the spud list with the specifics. Best, =E2=80=94aaron > On Jul 6, 2016, at 8:00 PM, Tom Herbert wrote: >=20 > Hello, >=20 > I just posted a new version -01 of Transport Over UDP. The major > changes are more elaboration of disassociated location, making session > numbers not be symmetric, more details on session negotiation, peer > address and port learning described, don't use addresses in pseudo > header with TOU, and handling for TCP resets. >=20 > I would like to present TOU at the PLUS BOF if possible. >=20 > Thanks, > Tom >=20 > ---------- Forwarded message ---------- > From: > Date: Wed, Jul 6, 2016 at 4:50 PM > Subject: New Version Notification for = draft-herbert-transports-over-udp-01.txt > To: Tom Herbert >=20 >=20 >=20 > A new version of I-D, draft-herbert-transports-over-udp-01.txt > has been successfully submitted by Tom Herbert and posted to the > IETF repository. >=20 > Name: draft-herbert-transports-over-udp > Revision: 01 > Title: Transport layer protocols over UDP > Document date: 2016-07-06 > Group: Individual Submission > Pages: 18 > URL: > = https://www.ietf.org/internet-drafts/draft-herbert-transports-over-udp-01.= txt > Status: > https://datatracker.ietf.org/doc/draft-herbert-transports-over-udp/ > Htmlized: = https://tools.ietf.org/html/draft-herbert-transports-over-udp-01 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-herbert-transports-over-udp-01= >=20 > Abstract: > This specification defines a mechanism to encapsulate layer 4 > transport protocols over UDP. Such encapsulation facilitates > deployment of alternate transport protocols or transport protocol > features on the Internet. DTLS can be employed to encrypt the > encapsulated transport header in a packet thus minimizing the > exposure of transport layer information to the network and so > promoting the end-to-end networking principle. Transport connection > identification can be disassociated from network location (IP > addresses) to provide connection persistence for mobility and across > state eviction in NAT. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_5403952E-D13B-400A-9D6B-6EE08B6FF08D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Tom-

One explicit goal of PLUS is to enable = controlled communication between endpoints and devices on the network = path. As I understand it, TOU is designed to preclude that = communication.  As this is a BoF about chartering a working group = around PLUS, the TOU draft neither addresses PLUS motivation (e.g., why = we need to communicate to middleboxes?) or architecture (e.g., how could = we make this communication work in an world with pervasive encryption?). =  Since there was some email discussion of your draft on this list, = Brian has tried to address the distinction between PLUS and TOU = in his slide deck (specifically, slide 20) and I = encourage you to send any clarification comments to him.

To be clear, this = isn=E2=80=99t a reflection on the merits of your proposal, only that it = doesn=E2=80=99t address the goals of the BoF: to determine whether the = IETF should take on the work described in the PLUS charter. =  Indeed, one could consider TOU to be a competing proposal from an = applications perspective, one based on a different set of requirements. =  I would suggest that it might be a totally reasonable fit with the = TSVWG and you might seek agenda time in that working group.  If you = are going to discuss TOU in a wg in Berlin, I encourage you to drop a = note to the spud list with the specifics.

Best,

=E2=80=94aaron


On Jul 6, 2016, at 8:00 PM, Tom Herbert = <tom@herbertland.com> wrote:

Hello,

I just posted a new = version -01 of Transport Over UDP. The major
changes are = more elaboration of disassociated location, making session
numbers not be symmetric, more details on session = negotiation, peer
address and port learning described, = don't use addresses in pseudo
header with TOU, and = handling for TCP resets.

I would like to = present TOU at the PLUS BOF if possible.

Thanks,
Tom

---------- Forwarded message ----------
From: =  <internet-drafts@ietf.org>
Date: Wed, Jul = 6, 2016 at 4:50 PM
Subject: New Version Notification for = draft-herbert-transports-over-udp-01.txt
To: Tom Herbert = <tom@herbertland.com>



A new version of I-D, = draft-herbert-transports-over-udp-01.txt
has been = successfully submitted by Tom Herbert and posted to the
IETF= repository.

Name: =           draft-herbert-= transports-over-udp
Revision: =       01
Title: =          Transport layer = protocols over UDP
Document date:  2016-07-06
Group: =          Individual = Submission
Pages: =          18
URL:
https://www.ietf.org/internet-drafts/draft-herbert-transports-o= ver-udp-01.txt
Status:
https://datatracker.ietf.org/doc/draft-herbert-transports-over-= udp/
Htmlized: =       https://tools.ietf.org/html/draft-herb= ert-transports-over-udp-01
Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-herbert-transports-ov= er-udp-01

Abstract:
=   This specification defines a mechanism to encapsulate layer = 4
  transport protocols over UDP. Such = encapsulation facilitates
  deployment of = alternate transport protocols or transport protocol
=   features on the Internet. DTLS can be employed to encrypt = the
  encapsulated transport header in a packet = thus minimizing the
  exposure of transport = layer information to the network and so
=   promoting the end-to-end networking principle. Transport = connection
  identification can be = disassociated from network location (IP
=   addresses) to provide connection persistence for mobility = and across
  state eviction in NAT.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud

= --Apple-Mail=_5403952E-D13B-400A-9D6B-6EE08B6FF08D-- From nobody Fri Jul 8 08:36:26 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8340512D51C for ; Fri, 8 Jul 2016 08:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 kXjpkZYqtIHM for ; Fri, 8 Jul 2016 08:36:22 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 DE01812D0C9 for ; Fri, 8 Jul 2016 08:36:10 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id t74so10185903ioi.0 for ; Fri, 08 Jul 2016 08:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rqg+7wWZSGk8Zgld6G7bi/k6mEXc5Nq4WiaiCThHbVA=; b=uCURSVtkahuSgrEUvU/FQFzm6XhC+X5207yjQsRSyKzbiSrlLF+BT/p/twrlbgH2e6 h4eH86TcRko565YqjcYogMv0QToq2+ACcwTy9n5QtDt9Hb3LHxarp22DnyNpaQ628Rl+ Nn8tVO2FVeL51/R3Afk+5hY+Gd4dMy/j0b10y66y+sp0gUij9ejVsNi1DrARvB+9Rxcg HlTmFPKATV6iuyQKA3Zj2Lku3RS9KxHmlE1UFY42ja7JF8YKUK1OjXagiwuUOoooHsUM HoqLR1zaZFcjTqJxlLadg+vAvDBUZKIoyFjw2dRd3HqJuotPk5+RKCh9ynLRkaAemwwG YzWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rqg+7wWZSGk8Zgld6G7bi/k6mEXc5Nq4WiaiCThHbVA=; b=ZwFNtZB81oBr4Glj228H+gGxVXhrKggrDfQ50O6ycJIsu4C1jh41qt3st9lEXnwoyK 0icwmYXytdzISkUZwVP5z5i4TuzzubxCQxeBY9iS/PnsI6dD+IpFI1xb28mENBocKV0Y a8metouaEGcmZe/QQrZqwBumzAvJDt9CqyrLCcpdCgPVFSno65CM0P9Ypaevpw7Fb0ZZ +5CKKftAaZppIh1S11anrNncEkTP66tun+N4+5ZA8LTFBbPkkpns6d/veZKjG1KClk8i Aji3r73X0lo1YCTc6eOr0hCphGikQZmmJDg06KmLVtkklA6DlmCVO43NbwQ4d0CDC8Xc oPyA== X-Gm-Message-State: ALyK8tLXZa4dSoU0vSoo/BycvJ0NUw/QVpxXNNsRbiO/WqknnFX4+SohN8y7NfyU1LMg6YDrRNk6L+jSn7zXnw== X-Received: by 10.107.11.74 with SMTP id v71mr1242070ioi.107.1467992170197; Fri, 08 Jul 2016 08:36:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Fri, 8 Jul 2016 08:36:09 -0700 (PDT) In-Reply-To: References: <20160706235033.26688.47764.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Fri, 8 Jul 2016 10:36:09 -0500 Message-ID: To: Aaron Falk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Blake Matheny , Natasha Rooney , spud Subject: Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:36:24 -0000 On Thu, Jul 7, 2016 at 5:37 PM, Aaron Falk wrote: > Hi Tom- > > One explicit goal of PLUS is to enable controlled communication between > endpoints and devices on the network path. As I understand it, TOU is > designed to preclude that communication. As this is a BoF about chartering > a working group around PLUS, the TOU draft neither addresses PLUS motivation > (e.g., why we need to communicate to middleboxes?) or architecture (e.g., > how could we make this communication work in an world with pervasive > encryption?). Since there was some email discussion of your draft on this > list, Brian has tried to address the distinction between PLUS and TOU in his > slide deck (specifically, slide 20) and I encourage you to send any > clarification comments to him. > Aaron, I would agree if the goal of PLUS was to provide signaling to network path for any existing transport protocols (IMO this would have been a better goal). But, PLUS is explicitly being described for use with transport protocols over _UDP_. Such transport protocols don't really even exist yet (TOU and QUIC are being proposed). Without understanding how transport protocols over UDP will even work I think it is difficult to design another layer intended to work with them. Tom From nobody Sun Jul 10 14:35:45 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59CD12D094 for ; Sun, 10 Jul 2016 14:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 dIepn2CXqP5v for ; Sun, 10 Jul 2016 14:35:43 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 541B812D08D for ; Sun, 10 Jul 2016 14:35:43 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id q83so22091130iod.1 for ; Sun, 10 Jul 2016 14:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rkykjBsqCBWjvrGeAmL1ww0tmVqsinGB9HIOya0cJKE=; b=Xkkwk3iqI2Zt5lCVYSmbrAbIp8wF9f4H7YQqKxBHjvQyiOxFsRHdEAFL3QD4olhsWl 5o3OcPcAQP9WXPJ7eQCFwDQbEebYr8T/Tdqq6K9mmGoC86ZLmIg7Z1B9xB+bBNX/g4xB r69P/1seEbWn8cMmvVo2f6VtNOqIe8btXp59gPc5/GIwS9XXg21MLvMibiEV4iofS/8u wTO7N8eej2Ckl+BygfsQ51jkfLbVlNtjHmejML+LH4OhrGkY7eETr18CuTSrXLy46jVD q1vEyqU70Q+zs5L+/6gBn29uEEFYcfjpCLPE/0rxCst8epi90aeUY95EN5v72K3WLABZ QNZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rkykjBsqCBWjvrGeAmL1ww0tmVqsinGB9HIOya0cJKE=; b=Jau2Vn3c1AU89vlX9JCQhZhMy5pVeuLCzda5r3IyQXXMQXo9forZ/o8Zq3py1K+xMK e0pzfNn/CmMoCISp+kFkaeydpkaG2VTcYiZid/EcG7ejkdJXlLxFDKxopZKzyeDNCFpA G7f4gEi9XdFQlgoE5Wex6ZNmdGSor6wz5IrKxi6P17V6FXswhr7PguypgEJZBYpnBY7j oPdEs95w5t+xkucA6jTtg/BaaxnNMPDykiHt5F0OSGLSgkwikQS/UDRu9Gp8j3eJcOE1 5vvdXbEX3lX5J6JOurZRJyIar0P57o/fqf9veWAQ+k4XmXslcNabPiKkLK7+oW+Ou883 jeIA== X-Gm-Message-State: ALyK8tLTctWAUx/kQTPbRguO4qLw6l1K4XtTwgcZtzXsP7btRkSAOfqA78gBR7xMdEvdxmmCw602fksHwBq7ig== X-Received: by 10.107.11.74 with SMTP id v71mr10602789ioi.107.1468186542527; Sun, 10 Jul 2016 14:35:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Sun, 10 Jul 2016 14:35:41 -0700 (PDT) In-Reply-To: <657B751A-8AF1-42F5-8451-D04688544490@trammell.ch> References: <657B751A-8AF1-42F5-8451-D04688544490@trammell.ch> From: Tom Herbert Date: Sun, 10 Jul 2016 16:35:41 -0500 Message-ID: To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ted Hardie , Natasha Rooney , spud Subject: Re: [Spud] Details about PLUS BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 21:35:44 -0000 > I hope we do. Restoring the ability to safely treat IP as a packet-switch= ed architecture is one of the goals of this work (see the SPUD use cases dr= aft, section 6 [4]). As of today, since common wisdom holds that TCP perfor= mance *sucks* if you reorder packets, quite a lot of effort goes into reduc= ing reordering within a flow, and it turns out an excellent way to do that = is to make sure all the packets in a flow hit all the same queues in the ab= sence of rerouting. How can a transport signal that reordering is tolerable= today? > Brian, I believe that TCP performance *sucks* with OOO packet is mostly a myth at this point. In the Internet, bad TCP performance is dominated by packet loss and retransmissions (which I guess leads to OOO but that's a secondary issue then). In the datacenter where loss is low we do typically prefer in order delivery to keep variance down. But in order delivery has never be a requirement there either (except when people have attempt to use protocols that really require in order like FCoe, RDMA). There are also results that show all packets could purposely be sent over different paths in a well engineered with good effect but would generate OOO (ttps://engineering.purdue.edu/~ychu/publications/infocom13_pktspray.pdf). Also, as described in that paper, modern TCP stacks are robust with some amount of reordering. A transport can signal that reordering is tolerable by changing the IPv6 FlowID on every packet. This would be one way to accomplish Random Packet Spraying without needing special support in network devices as described in the paper above. >> Consider that any smart phone is now typically >> multi-homed to both a mobile network and a WIFI network. It's pretty >> obvious that we'd like to seamlessly transition from using one network >> to the other without breaking established connections. > > This world has existed for a couple of decades now: SCTP (where it deploy= s) and MPTCP do this already by building a session over multiple transport = connections. > It's not quite the same, these require that the transport layer or network understand network topology. That breaks down for instance if devices are behind a NAT which is change source addresses for existing connections. As I mentioned previously, NAT state eviction causing connections to be dropped is one thing we want to fix with UDP based transport protocols (e.g. by disassociated location). Tom From nobody Wed Jul 20 14:27:36 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CEA12D84B for ; Wed, 20 Jul 2016 14:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 70ZvZhLE11nJ for ; Wed, 20 Jul 2016 14:27:33 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6ADC12D5A3 for ; Wed, 20 Jul 2016 14:27:32 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0294.000; Wed, 20 Jul 2016 17:27:31 -0400 From: Dave Dolson To: "spud@ietf.org" Thread-Topic: SPUD/PLUS and ECN feedback Thread-Index: AdHiyqkBYFddUog0QIqMi5f5CIF8Iw== Date: Wed, 20 Jul 2016 21:27:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98310320ECwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [Spud] SPUD/PLUS and ECN feedback X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 21:27:34 -0000 --_000_E8355113905631478EFF04F5AA706E98310320ECwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Neither draft-trammell-spud-req-04 nor draft-kuehlewind-spud-use-cases-01 d= iscuss conveying ECE/CWR signals in the SPUD/PLUS layer. I'm referring to https://tools.ietf.org/html/rfc3168#section-6.1 for how TC= P works. Was this intentionally omitted from the requirements, leaving it to the tra= nsport layer? Even though the transport layer is responsible for controlling its transmit= window, the ECN feedback should be used by every transport protocol, so pl= acing the info in the SPUD/PLUS layer could be appropriate. (Also I wonder if the network might use this to identify ECN cheaters.) -Dave --_000_E8355113905631478EFF04F5AA706E98310320ECwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Neither draft-trammell-spud-req-04 nor draft-kuehlew= ind-spud-use-cases-01 discuss conveying ECE/CWR signals in the SPUD/PLUS la= yer.

 

I’m referring to https://tools.ietf.org/html/rfc3168#section-6.1 for how TCP works.=

 

Was this intentionally omitted from the requirements= , leaving it to the transport layer?

Even though the transport layer is responsible for c= ontrolling its transmit window, the ECN feedback should be used by every tr= ansport protocol, so placing the info in the SPUD/PLUS layer could be appro= priate.

 

(Also I wonder if the network might use this to iden= tify ECN cheaters.)

 

-Dave

 

--_000_E8355113905631478EFF04F5AA706E98310320ECwtlexchp2sandvi_-- From nobody Wed Jul 20 14:43:51 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36C112D133 for ; Wed, 20 Jul 2016 14:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 5ZpXZNOlRd2r for ; Wed, 20 Jul 2016 14:43:48 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF0B12B05D for ; Wed, 20 Jul 2016 14:43:47 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 20 Jul 2016 17:43:46 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0294.000; Wed, 20 Jul 2016 17:43:46 -0400 From: Dave Dolson To: "spud@ietf.org" Thread-Topic: SPUD/PLUS Integrity Thread-Index: AdHiyuAEWW3tvt+uRKGHx2/tJcFn3Q== Date: Wed, 20 Jul 2016 21:43:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E983103224Awtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [Spud] SPUD/PLUS Integrity X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 21:43:49 -0000 --_000_E8355113905631478EFF04F5AA706E983103224Awtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In draft-trammell-spud-req-04, Section "6.3 Integrity" says, "Endpoints should be able to detect changes to headers SPUD uses for its own signaling..." It does not (in this section, at least) say that elements on the path shoul= d be able to detect changes to the headers. Is this omission accidental or intentional? Section 1.1.1 in the spud-use-cases document does indicate there may be som= e situations in which there could be such verifiability. There are a few charging-related use-cases that would be assisted by confir= ming that a sender has the authority to say what it said. I can also imagine how DDoS scrubbing might be assisted by examining some i= ntegrity aspect of the PLUS/SPUD layer. -Dave --_000_E8355113905631478EFF04F5AA706E983103224Awtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In draft-trammell-spud-req-04,

Section “6.3 Integrity” says,= 

“Endpoints should be able to detect changes to headers SPUD uses=
 for

   its own signaling…”

 

It does not (in this section, at least) say that ele= ments on the path should be able to detect changes to the headers.

Is this omission accidental or intentional?

 

Section 1.1.1 in the spud-use-cases document does in= dicate there may be some situations in which there could be such verifiabil= ity.

 

There are a few charging-related use-cases that woul= d be assisted by confirming that a sender has the authority to say what it = said.

 

I can also imagine how DDoS scrubbing might be assis= ted by examining some integrity aspect of the PLUS/SPUD layer.

 

 

-Dave

 

 

--_000_E8355113905631478EFF04F5AA706E983103224Awtlexchp2sandvi_-- From nobody Thu Jul 21 05:42:27 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3A12DAE7 for ; Thu, 21 Jul 2016 05:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 5DxTfPWFgcsH for ; Thu, 21 Jul 2016 05:42:21 -0700 (PDT) Received: from gorgon.tele.no (gorgon.tele.no [193.156.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCE712DA69 for ; Thu, 21 Jul 2016 05:42:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by gorgon.tele.no with esmtp (Exim 4.84_2) (envelope-from ) id 1bQDKF-0006jL-2Y for spud@ietf.org; Thu, 21 Jul 2016 14:43:39 +0200 To: spud@ietf.org From: Frode Kileng Message-ID: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> Date: Thu, 21 Jul 2016 14:40:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 12:42:24 -0000 Hi, the claims that encryption has taken away something that was used for mobile network traffic management and that PLUS is needed to to save mobile network operations keeps surfacing, including at the BoF today. This view should not be interpreted as representing the view of all mobile operators The rule is that all "Internet traffic" is assigned the default bearer and there's no differentiated handling of the traffic within this bearer. It has been hinted that there's exceptions "somewhere" but as long this claim is never substantiated, and there's no problem related to this in today in mobile networks, we should conclude that PLUS is not solving an existing problem related to mobile network management. Feel free to disagree but then please provide details. That said, PLUS may be an enabler for mobile network management practices, for example a 1-bit latency/throughput prioritization indicator. Best regards Frode Kileng From nobody Thu Jul 21 06:05:57 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C6412DA3A for ; Thu, 21 Jul 2016 06:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.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 Q9JPsHkxlznq for ; Thu, 21 Jul 2016 06:05:44 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30078.outbound.protection.outlook.com [40.107.3.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B4512DAE8 for ; Thu, 21 Jul 2016 06:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bnqT3fZc/A4E8oF83zFQGISsYUYSB+TKcWrFwtf1lu4=; b=UsccqZmZplTKdZPLmqhXcDB95oAKhvbsPXrulVqWfkXCS93ri/vcDLvhWNDtKVWnWi+8/vfHRMbcDWhw5GRNjC+3dE9AzvtFmStnDdx6faWAGT3RQi+PrOynnss+pGk4BaO2k2M1IRKdLJ83/j8+i4E/iRosvpZM5nnycq063EE= Received: from HE1PR0401MB2060.eurprd04.prod.outlook.com (10.166.123.12) by HE1PR0401MB2059.eurprd04.prod.outlook.com (10.166.123.11) with Microsoft SMTP Server (TLS) id 15.1.539.14; Thu, 21 Jul 2016 13:05:01 +0000 Received: from HE1PR0401MB2060.eurprd04.prod.outlook.com ([10.166.123.12]) by HE1PR0401MB2060.eurprd04.prod.outlook.com ([10.166.123.12]) with mapi id 15.01.0539.019; Thu, 21 Jul 2016 13:05:01 +0000 From: Natasha Rooney To: Frode Kileng Thread-Topic: [Spud] No. Operators don't need SPUD for mobile network management Thread-Index: AQHR401XCKZNpNKEuE+Y5dI1HwFpyqAi2l+A Date: Thu, 21 Jul 2016 13:05:01 +0000 Message-ID: <6CCF34EB-BA70-426B-89B4-D1C722E62084@gsma.com> References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> In-Reply-To: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:160:7520:26f3:ee8b:5945] x-ms-office365-filtering-correlation-id: cfb08744-5a78-4015-292d-08d3b1679ff7 x-microsoft-exchange-diagnostics: 1; HE1PR0401MB2059; 6:JZf7tQIu9zVm84TIncP3/unlvrgSS8uYCZ72PD37nEobO4R1sblaB1p9AnWjjXwgZHIGE4+BeYZXZFt/XcTtsrxQbyGbhh0eJgE6tnZqHwgBfGdoYOBDS6coWUFydR5JaT+CgR41TSd03lP9a4JWQoaAzkrFlUUDTHM/rzu58iQd/zDeg3kk5fNeqnMS0jeLrylMZxkg687J+v7Lg+rzowFluQgc/cPje5mtFZQXAZZtvywrFKalWITRZt0jjE0Tjc3JVW9rj2l86p/nuWWJ7o8l4sVqjq2X3GKgQZYjkJg=; 5:tj7jO5wrxhRn2wVUOViDhJ/AuhDa0wkxbaEckAWkhl0TlqE35EeprNQLy3sRpdq31LPcckjSSQGBBlMgPhrejnlLTsK9pw6DRbelkeSXhjOG+dCt604y33p9YFHqfT+KzGClqxcFccyNXFz2IIZxuw==; 24:IIXjm7oXMSWELrMJAp6easofmpO9Kn/2w6K1dpNKJyVKxMejs46e6WRjitwPQJBiI2b4gymZsO+HHCeeSYfA+KnKlkmwF8jD6e15gv1eZ6c=; 7:CTOpLCeh5XwPz/DYfreVjNzEZ51UW1iZOUHzNPUvjKN6qDCy6iXjFaw2PBgEZ3Nx4A2SBj1+r9y+N7UkyZIv/iWUGcU9Bc9PHNMoq905Fmm3lJkNISHA1PpeQXRTvYJmvp0NC/bMReFvx50qcKodSDFeK6e8ffuwoyOHGtQfgX8/TFIsB6refRPJXtrGQs1ymgKYdGip7vZFYo84hc/KFo5d7s0GWwIy6AiWkPuF4tzYC4rm9TqwNWgGnF3rrdTK x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0401MB2059; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR0401MB2059; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0401MB2059; x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(7916002)(24454002)(189002)(199003)(52044002)(189998001)(101416001)(19580405001)(19580395003)(586003)(8676002)(68736007)(83716003)(76176999)(2950100001)(50986999)(2900100001)(92566002)(82746002)(15975445007)(10400500002)(87936001)(57306001)(122556002)(97736004)(110136002)(77096005)(5890100001)(11100500001)(105586002)(50226002)(33656002)(36756003)(2906002)(102836003)(7846002)(16236675004)(81166006)(5002640100001)(8936002)(7736002)(4326007)(106356001)(3660700001)(81156014)(106116001)(86362001)(3280700002)(6116002)(3826002)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0401MB2059; H:HE1PR0401MB2060.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_6CCF34EBBA70426B89B4D1C722E62084gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 13:05:01.1664 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0401MB2059 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR0401MB2060.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:67c:370:160:7520:26f3:ee8b:5945 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR0401MB2059.eurprd04.prod.outlook.com Archived-At: Cc: spud Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:05:54 -0000 --_000_6CCF34EBBA70426B89B4D1C722E62084gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEZyb2RlIGhlcmUgLSB0aGUgZmluYWwgc2VudGVuY2Ugd2FzIG1vcmUgb2Yg d2hhdCBJIHdhcyB0cnlpbmcgdG8gZ2V0IHRvIGluIHRvZGF54oCZcyBCb0YuDQoNCk5hdGFzaGEN Cg0KDQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRlcm5ldCwgVzND ICYgSUVURiB8IEdTTUEgfCBucm9vbmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5QGdzbWEuY29t PiB8ICs0NCAoMCkgNzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6IG5yb29uZXlA Z3NtLm9yZzxtYWlsdG86bnJvb25leUBnc20ub3JnPg0KDQoNCk9uIDIxIEp1bCAyMDE2LCBhdCAx NDo0MCwgRnJvZGUgS2lsZW5nIDxmcm9kZWtAdGVsZS5ubzxtYWlsdG86ZnJvZGVrQHRlbGUubm8+ PiB3cm90ZToNCg0KSGksDQoNCnRoZSBjbGFpbXMgdGhhdCBlbmNyeXB0aW9uIGhhcyB0YWtlbiBh d2F5IHNvbWV0aGluZyB0aGF0IHdhcyB1c2VkIGZvciBtb2JpbGUgbmV0d29yayB0cmFmZmljIG1h bmFnZW1lbnQgYW5kIHRoYXQgUExVUyBpcyBuZWVkZWQgdG8gdG8gc2F2ZSBtb2JpbGUgbmV0d29y ayBvcGVyYXRpb25zIGtlZXBzIHN1cmZhY2luZywgaW5jbHVkaW5nIGF0IHRoZSBCb0YgdG9kYXku IFRoaXMgdmlldyBzaG91bGQgbm90IGJlIGludGVycHJldGVkIGFzIHJlcHJlc2VudGluZyB0aGUg dmlldyBvZiBhbGwgbW9iaWxlIG9wZXJhdG9ycw0KDQpUaGUgcnVsZSBpcyB0aGF0IGFsbCAiSW50 ZXJuZXQgdHJhZmZpYyIgaXMgYXNzaWduZWQgdGhlIGRlZmF1bHQgYmVhcmVyIGFuZCB0aGVyZSdz IG5vIGRpZmZlcmVudGlhdGVkIGhhbmRsaW5nIG9mIHRoZSB0cmFmZmljIHdpdGhpbiB0aGlzIGJl YXJlci4gSXQgaGFzIGJlZW4gaGludGVkIHRoYXQgdGhlcmUncyBleGNlcHRpb25zICJzb21ld2hl cmUiIGJ1dCBhcyBsb25nIHRoaXMgY2xhaW0gaXMgbmV2ZXIgc3Vic3RhbnRpYXRlZCwgYW5kIHRo ZXJlJ3Mgbm8gcHJvYmxlbSByZWxhdGVkIHRvIHRoaXMgaW4gdG9kYXkgaW4gbW9iaWxlIG5ldHdv cmtzLCB3ZSBzaG91bGQgY29uY2x1ZGUgdGhhdCBQTFVTIGlzIG5vdCBzb2x2aW5nIGFuIGV4aXN0 aW5nIHByb2JsZW0gcmVsYXRlZCB0byBtb2JpbGUgbmV0d29yayBtYW5hZ2VtZW50Lg0KDQpGZWVs IGZyZWUgdG8gZGlzYWdyZWUgYnV0IHRoZW4gcGxlYXNlIHByb3ZpZGUgZGV0YWlscy4NCg0KVGhh dCBzYWlkLCBQTFVTIG1heSBiZSBhbiBlbmFibGVyIGZvciBtb2JpbGUgbmV0d29yayBtYW5hZ2Vt ZW50IHByYWN0aWNlcywgZm9yIGV4YW1wbGUgYSAxLWJpdCBsYXRlbmN5L3Rocm91Z2hwdXQgcHJp b3JpdGl6YXRpb24gaW5kaWNhdG9yLg0KDQpCZXN0IHJlZ2FyZHMNCkZyb2RlIEtpbGVuZw0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU3B1ZCBtYWls aW5nIGxpc3QNClNwdWRAaWV0Zi5vcmc8bWFpbHRvOlNwdWRAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwdWQNCg0KDQpUaGlzIGVtYWlsIGFuZCBpdHMg YXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5 IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBt dXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNo b3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgKzQ0 IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4NCg== --_000_6CCF34EBBA70426B89B4D1C722E62084gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <17AFBD8F20F5BE4FB67CEFF28562E1FC@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSBhZ3JlZSB3aXRoIEZyb2RlIGhl cmUgLSB0aGUgZmluYWwgc2VudGVuY2Ugd2FzIG1vcmUgb2Ygd2hhdCBJIHdhcyB0cnlpbmcgdG8g Z2V0IHRvIGluIHRvZGF54oCZcyBCb0YuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdo aXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmF0YXNoYTxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGEgUm9vbmV5IHwg VGVjaG5vbG9naXN0LCBXZWImbmJzcDthbmQgSW50ZXJuZXQsIFczQyAmYW1wOyBJRVRGIHwgR1NN QSB8Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtYS5jb20iIGNsYXNzPSIiPm5yb29u ZXlAZ3NtYS5jb208L2E+Jm5ic3A7fCAmIzQzOzQ0ICgwKSA3NzMwJm5ic3A7MjE5IDc2NSB8IEB0 aGlzTmF0YXNoYSB8IFNreXBlOiZuYnNwOzxhIGhyZWY9Im1haWx0bzpucm9vbmV5QGdzbS5vcmci IGNsYXNzPSIiPm5yb29uZXlAZ3NtLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ T24gMjEgSnVsIDIwMTYsIGF0IDE0OjQwLCBGcm9kZSBLaWxlbmcgJmx0OzxhIGhyZWY9Im1haWx0 bzpmcm9kZWtAdGVsZS5ubyIgY2xhc3M9IiI+ZnJvZGVrQHRlbGUubm88L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj5IaSw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQp0aGUg Y2xhaW1zIHRoYXQgZW5jcnlwdGlvbiBoYXMgdGFrZW4gYXdheSBzb21ldGhpbmcgdGhhdCB3YXMg dXNlZCBmb3IgbW9iaWxlIG5ldHdvcmsgdHJhZmZpYyBtYW5hZ2VtZW50IGFuZCB0aGF0IFBMVVMg aXMgbmVlZGVkIHRvIHRvIHNhdmUgbW9iaWxlIG5ldHdvcmsgb3BlcmF0aW9ucyBrZWVwcyBzdXJm YWNpbmcsIGluY2x1ZGluZyBhdCB0aGUgQm9GIHRvZGF5LiBUaGlzIHZpZXcgc2hvdWxkIG5vdCBi ZSBpbnRlcnByZXRlZCBhcyByZXByZXNlbnRpbmcNCiB0aGUgdmlldyBvZiBhbGwgbW9iaWxlIG9w ZXJhdG9yczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBydWxlIGlzIHRoYXQgYWxs ICZxdW90O0ludGVybmV0IHRyYWZmaWMmcXVvdDsgaXMgYXNzaWduZWQgdGhlIGRlZmF1bHQgYmVh cmVyIGFuZCB0aGVyZSdzIG5vIGRpZmZlcmVudGlhdGVkIGhhbmRsaW5nIG9mIHRoZSB0cmFmZmlj IHdpdGhpbiB0aGlzIGJlYXJlci4gSXQgaGFzIGJlZW4gaGludGVkIHRoYXQgdGhlcmUncyBleGNl cHRpb25zICZxdW90O3NvbWV3aGVyZSZxdW90OyBidXQgYXMgbG9uZyB0aGlzIGNsYWltIGlzIG5l dmVyIHN1YnN0YW50aWF0ZWQsIGFuZCB0aGVyZSdzDQogbm8gcHJvYmxlbSByZWxhdGVkIHRvIHRo aXMgaW4gdG9kYXkgaW4gbW9iaWxlIG5ldHdvcmtzLCB3ZSBzaG91bGQgY29uY2x1ZGUgdGhhdCBQ TFVTIGlzIG5vdCBzb2x2aW5nIGFuIGV4aXN0aW5nIHByb2JsZW0gcmVsYXRlZCB0byBtb2JpbGUg bmV0d29yayBtYW5hZ2VtZW50LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkZlZWwgZnJl ZSB0byBkaXNhZ3JlZSBidXQgdGhlbiBwbGVhc2UgcHJvdmlkZSBkZXRhaWxzLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClRoYXQgc2FpZCwgUExVUyBtYXkgYmUgYW4gZW5hYmxlciBmb3Ig bW9iaWxlIG5ldHdvcmsgbWFuYWdlbWVudCBwcmFjdGljZXMsIGZvciBleGFtcGxlIGEgMS1iaXQg bGF0ZW5jeS90aHJvdWdocHV0IHByaW9yaXRpemF0aW9uIGluZGljYXRvci48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpCZXN0IHJlZ2FyZHM8YnIgY2xhc3M9IiI+DQpGcm9kZSBLaWxlbmc8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NClNwdWQgbWFpbGluZyBsaXN0PGJyIGNs YXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlNwdWRAaWV0Zi5vcmciIGNsYXNzPSIiPlNwdWRAaWV0 Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHVkPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNl cmlmO2ZvbnQtc2l6ZToxMXB4O2NvbG9yOiM5OTk5OTk7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOiM5OTk5OTk7IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItbGF0 aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90OzsgbXNvLWFuc2ktbGFu Z3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tR0I7IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSI+VGhpcw0KIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVk IGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhl eSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2Vk IG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFz ZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgJiM0Mzs0NCAyMDcgMzU2IDA2MDANCiBhbmQg aGlnaGxpZ2h0IHRoZSBlcnJvci4gPC9zcGFuPjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6CCF34EBBA70426B89B4D1C722E62084gsmacom_-- From nobody Thu Jul 21 06:29:00 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3CE126FDC for ; Thu, 21 Jul 2016 06:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 tRAPNIdLM4O9 for ; Thu, 21 Jul 2016 06:28:58 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 DD96812B076 for ; Thu, 21 Jul 2016 06:28:57 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id u186so14122127ita.0 for ; Thu, 21 Jul 2016 06:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5Dvjryy1MbyNPyDKSj/eqTjgPfJqw+dzvQcMAjjQecA=; b=0AtAidZfTzwP0gW9Qy7kPaTo7d+PGOGsTHHzG67tbHEKzG34QmxBXnDz3jS61ERrbZ 25LgRAl4Kn5NU1WMBPPPcylYHjrXdGmVFM+yTmYEIR393Z09E7XKG7MvoLxu+Cwa2sis 9bZPZ3Sy8vMRkZTLAlI2wH3JYbq1ijr+g9vi2lM7FCGfRCOSHBuH95CDc4ZlenTRnjj4 bAz85/iAHnhlBRGRYtkj/MEOUqV7M9C5cFELN/LZ+XPYNTUh+o+wTyHt4ut1yg1r2nr9 JikDnymxyuB/hwmz2lijWDPWWxT1sCIk4y/y4QYGC55RpnN80KvmFuTUwnzS0gMGw+vd kLOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5Dvjryy1MbyNPyDKSj/eqTjgPfJqw+dzvQcMAjjQecA=; b=K39KNTGGsG54djeGEfcNnFLUnTfGgLB6MiqPiHnOBmcBzX3dTh/6JHa6B6hW/5atRY quxEQuN/P7er3BHsZHPIHujCqh7NYsJr4tRjG/5QdVCkgrJAkLt3cYbSW/s7EkdO8QKm oGuiLb2sQIA39u1CH5qruqqWiNUJWrzDhgEPf4bSkKQaXdDqRc0lSnvQXBW9IljlJ0vC 1a61ElnDJNY1IAYa4U4HdrGVbETG3rVO9ipamAkw4t6XSeVoxqd2bLiKmcCM4wJ1swPf gWs3ZAEnAKatsDMaPA8QABIALq4nkYhhWHzyFKoBTb/u+Ytlkmzm+8OxkIrQ4kVgqjmg T/5g== X-Gm-Message-State: ALyK8tIcw6+8RT5LT9xwjnrPtq97eW4tkZuXg1qnL0Vbq0ZOupVWDC18M1jVU73EAMQkIrcsiLVYAEFKT3/FwQ== X-Received: by 10.36.14.193 with SMTP id 184mr12680338ite.91.1469107736602; Thu, 21 Jul 2016 06:28:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Thu, 21 Jul 2016 06:28:56 -0700 (PDT) In-Reply-To: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> From: Tom Herbert Date: Thu, 21 Jul 2016 15:28:56 +0200 Message-ID: To: Frode Kileng Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: spud Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:28:59 -0000 > That said, PLUS may be an enabler for mobile network management practices, > for example a 1-bit latency/throughput prioritization indicator. > Doesn't DSCP/TOS already provide that? Tom From nobody Thu Jul 21 06:36:16 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D19E12D0F0 for ; Thu, 21 Jul 2016 06:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 lqce07zCLU9Z for ; Thu, 21 Jul 2016 06:36:05 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B56512D5CD for ; Thu, 21 Jul 2016 06:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1654; q=dns/txt; s=iport; t=1469108165; x=1470317765; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=gfw7BpV6l+YfPgIoESfznhQq/b9M2JWPrRGFNNIhfU8=; b=BNbBvAHd0zF7DE8RTdcBdVukMStkLNqnwRXUkmELylvxrV6RF1aK7oJb ZSirj7LaQ0bDlCgKfAPouU4Jv0PeDjtAjf8ro0c3cYNWhgo+sOBxesGK2 GEif4Vp9fzim4fOT9HdQtLKG2vzvyVaMk7+KsaganJZGUCh7Efdf+ikFB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgBjzpBX/5xdJa1dgz9WfLhmgXsih?= =?us-ascii?q?XgCgS04FAEBAQEBAQFlJ4RdAQUBATg0CxALGAklDwUTNhOIMA69DwEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBARcFineBSohRBY8BiiWOYQqBbIRZiHWQIR42ggscgWwcM?= =?us-ascii?q?odOAQEB?= X-IronPort-AV: E=Sophos;i="5.28,399,1464652800"; d="scan'208";a="299908116" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 13:36:04 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6LDa3KX007849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2016 13:36:03 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6LDa25b002882; Thu, 21 Jul 2016 06:36:02 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6LDa2an002880; Thu, 21 Jul 2016 06:36:02 -0700 Date: Thu, 21 Jul 2016 06:36:02 -0700 From: Toerless Eckert To: Frode Kileng Message-ID: <20160721133602.GY7377@cisco.com> References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:36:10 -0000 I haven;t talked much with mobile network operators. One data point a US mobile operator gave me was about recognizing certain type p2p traffic that had real bad congestion control and was monopolizing congested links. And then counter that. I am not sure if this policing happened on some mobile link/path-segment or at the edge to the non-mobile core. Cheers Toerless On Thu, Jul 21, 2016 at 02:40:12PM +0200, Frode Kileng wrote: > Hi, > > the claims that encryption has taken away something that was used for > mobile network traffic management and that PLUS is needed to to save > mobile network operations keeps surfacing, including at the BoF today. > This view should not be interpreted as representing the view of all > mobile operators > > The rule is that all "Internet traffic" is assigned the default bearer > and there's no differentiated handling of the traffic within this > bearer. It has been hinted that there's exceptions "somewhere" but as > long this claim is never substantiated, and there's no problem related > to this in today in mobile networks, we should conclude that PLUS is not > solving an existing problem related to mobile network management. > > Feel free to disagree but then please provide details. > > That said, PLUS may be an enabler for mobile network management > practices, for example a 1-bit latency/throughput prioritization indicator. > > Best regards > Frode Kileng > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Thu Jul 21 06:39:03 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D8F12D590 for ; Thu, 21 Jul 2016 06:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 DSoVEBvdgicQ for ; Thu, 21 Jul 2016 06:38:52 -0700 (PDT) Received: from gorgon.tele.no (gorgon.tele.no [193.156.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id C02A312D53B for ; Thu, 21 Jul 2016 06:38:50 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by gorgon.tele.no with esmtp (Exim 4.84_2) (envelope-from ) id 1bQECv-0006nY-4d for spud@ietf.org; Thu, 21 Jul 2016 15:40:09 +0200 To: spud@ietf.org References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> From: Frode Kileng Message-ID: <0643740d-32c0-7b4f-6ff5-3a4320db90fe@tele.no> Date: Thu, 21 Jul 2016 15:36:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:38:53 -0000 On 21.07.2016 15:28, Tom Herbert wrote: >> That said, PLUS may be an enabler for mobile network management practices, >> for example a 1-bit latency/throughput prioritization indicator. >> > Doesn't DSCP/TOS already provide that? Oh, I didn't intend to say this is a good idea, just one potential usage of PLUS as it has been identified. I do think there's need to do a lot of work to understand the pro/cons and how it should be implemented. frodek From nobody Thu Jul 21 06:57:04 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA83512D5CE for ; Thu, 21 Jul 2016 06:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 wKRz5IxLEeiU for ; Thu, 21 Jul 2016 06:57:00 -0700 (PDT) Received: from gorgon.tele.no (gorgon.tele.no [193.156.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id AF19712D5D2 for ; Thu, 21 Jul 2016 06:56:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by gorgon.tele.no with esmtp (Exim 4.84_2) (envelope-from ) id 1bQEUP-0006oN-Kq; Thu, 21 Jul 2016 15:58:13 +0200 To: Toerless Eckert References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <20160721133602.GY7377@cisco.com> From: Frode Kileng Message-ID: <149f1b85-ddbe-bf9e-fab5-9e09f7dc2bc5@tele.no> Date: Thu, 21 Jul 2016 15:54:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160721133602.GY7377@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:57:02 -0000 On 21.07.2016 15:36, Toerless Eckert wrote: > I haven;t talked much with mobile network operators. One data > point a US mobile operator gave me was about recognizing certain > type p2p traffic that had real bad congestion control and was > monopolizing congested links. And then counter that. I am not sure > if this policing happened on some mobile link/path-segment or at > the edge to the non-mobile core. Not sure about how relevant this example is for PLUS or for enabling mechanisms for helping traffic management in mobile networks. We could of course define a "Bad Congestion Implementation" path signal.... Or just ask such P2P apps to set the evil bit... :-) IMHO we are at a state where we should demand facts and details to address features related to mobile network traffic management. frodek From nobody Thu Jul 21 07:47:43 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0004E12D68F for ; Thu, 21 Jul 2016 07:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.736 X-Spam-Level: X-Spam-Status: No, score=-2.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_AMBIEN=0.552, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 8Hqtkj4chboe for ; Thu, 21 Jul 2016 07:47:40 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 0229212D675 for ; Thu, 21 Jul 2016 07:47:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 79EA4A2; Thu, 21 Jul 2016 16:47:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1469112457; bh=WD5LwRF9RSlojlf9P3KlRJqYcjzXao9NV2PHV7ywbH0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=hzPL9l7fIqdmbbAWyBgRhimbxcyuEdSDzhbP7HgYggsD/sq3kpY6DwCAqULf9rork 359gMxwml3xAz2GQpFBz+dxn0iFZ4p/DjnER3DB52VncfonDeZDL056M1ohPXT8yVa PCMWSFzug9DzsDVqltzX2oJB+t/kXh2wKMVbf/LE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7014DA1; Thu, 21 Jul 2016 16:47:37 +0200 (CEST) Date: Thu, 21 Jul 2016 16:47:37 +0200 (CEST) From: Mikael Abrahamsson To: Frode Kileng In-Reply-To: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> Message-ID: References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 14:47:42 -0000 On Thu, 21 Jul 2016, Frode Kileng wrote: > The rule is that all "Internet traffic" is assigned the default bearer > and there's no differentiated handling of the traffic within this > bearer. It has been hinted that there's exceptions "somewhere" but as > long this claim is never substantiated, and there's no problem related > to this in today in mobile networks, we should conclude that PLUS is not > solving an existing problem related to mobile network management. I know people that for instance have middle-boxes that drops unsolicited TCP SYN+ACK packets (no SYN was seen, now there is a SYN-ACK that the end system didn't seem to have requested). This saves power for devices and it saves signaling resources in the ombile network. I've seen mobile networks melt down because of someone else being SYN-flooded with spoofed source addresses and the resulting "backscatter" was not doing the mobile network any good. SPUD could be used to have similar benefits for non-TCP traffic, in that it might be easier to identify un-solicited traffic. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 21 08:00:18 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBE212D68A for ; Thu, 21 Jul 2016 08:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C-CUtvTzF2J for ; Thu, 21 Jul 2016 08:00:12 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 D09D412D67B for ; Thu, 21 Jul 2016 08:00:11 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id f93so64451748lfi.2 for ; Thu, 21 Jul 2016 08:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=/OnCfiOadxJFCTRU0qJbbh9lJyiZrjRnzi+pFNmZiYU=; b=c99SEHrXiaItQwMCqK4xjWXZKvb9qnf/2aW/nBErVgY4THHbj5BYKsZLTD4XUXTVQC yqi92rvFeMvlv8PLOjeeEr9PUDnMHLUmTZeXK/lZWb23KffeiMxMNXLxZuq9ZXg1Oyb4 2k5sEuelPDcIJ25SNqtbK31SbpHc9ZyyOyM26mUkCEINgj9UKlMEQ7LPYtInDzblDKAc p4wmGIgihp3L26dCYbRLWRzW8sunWPxVX8nOvMpjA5try2eSvSyET24lbtjz1fhqc50m eBKD4h4/mYPwN1OzQCZuxrAoiCdEKd//hJq9RqSXkMvNJXluhBfSzZJ+kTfe/gMgb5qP wXHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/OnCfiOadxJFCTRU0qJbbh9lJyiZrjRnzi+pFNmZiYU=; b=NBtserQEmVGHX3OA53WsWi/q5TWYGhNFFp2gXfRLBYu61gErVHDqL0LTS4Ygl/04wS b6FdVw0232f/pipLxsRlj5BxmevOK0pPDgCkmYqcxlC9H9/i5X7jGf8cbE4v7sVUPWbj JyIcb2ri0RdrTC7eYX6bJnjWznsadU3YFIuV8vhwD1ixHZ+CDuaBn0R1uJ6hdr/DlZcm HPV6yk6QH5kSVK2or+CNLhjwiPk5rOChihhwIoQHLWyMHBgn5OhWcJDqP87vnGUdAwJX 4sxFwiNegmbOgdWStmUnAPL4kW+34kEV1cLSkKDKlXDdCe5SR6wIUHn99yKeOAHm3uDw iZ6Q== X-Gm-Message-State: ALyK8tIUH3vcZ1O4vav7gtzGGsdKAvypDp0bzzcsNUMcDPWtNBu0TLbGEVCsp6C/pS+xpw== X-Received: by 10.25.163.132 with SMTP id m126mr25652570lfe.56.1469113209335; Thu, 21 Jul 2016 08:00:09 -0700 (PDT) Received: from ?IPv6:2003:74:cf54:d255:8990:29d2:df8a:b967? (p20030006154B7555899029D2DF8AB967.dip0.t-ipconnect.de. [2003:6:154b:7555:8990:29d2:df8a:b967]) by smtp.googlemail.com with ESMTPSA id k63sm1939375lfe.48.2016.07.21.08.00.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 08:00:08 -0700 (PDT) To: spud References: <32DC1941-126F-4513-801F-559617E85436@trammell.ch> From: Martin Stiemerling Message-ID: <92f8bd8e-f0d0-93ac-1e35-57c2222f7e4b@gmail.com> Date: Thu, 21 Jul 2016 17:00:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <32DC1941-126F-4513-801F-559617E85436@trammell.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spud] PLUS charter rev. 23 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:00:15 -0000 Hi all, Here is my proposed addendum to the charter text with respect to prior work in the world of middlebox signalling. This is not saying that I am endorsing any of them. However, it is wise to check what has happened in the past in that space and to recoginize that signaling protocols coupled with the data path are a challenging topic -- still. The proposed text (feel free to tweak it so that terminology matches): "There are a number of protocols inside and outside to the IETF that deal with endpoint to network signaling, namely to talk with middleboxes. These protocols are, for instance, MIDCOM, PCP and NSIS. The PLUS WG can leverage knowdlegde out of these older activities with respect to endpoint to middlebox signaling." Thanks, Martin Am 23.06.16 um 11:29 schrieb Brian Trammell: > Greetings, all, > > We've updated the proposed PLUS charter based on outstanding issues (Christian's comment on threat modeling and mitigations) and added a list of things we believe to be out of scope based on list discussion. > > New charter, as always, at https://github.com/ietf-plus/charter/blob/master/charter-plus.txt, and inline below. > > Cheers, > > Brian > > > Path Layer UDP Substrate (PLUS) > =============================== > > The PLUS working group's goal is to define a common shim layer atop the User > Datagram Protocol (UDP) to provide a transport-independent method to signal > flow semantics under transport and application control, necessary to enable > the deployment of new, encrypted transport protocols within the existing > Internet. UDP provides compatibility with currently deployed middleboxes as > well as ubiquitous support in endpoints, and supports userspace implementation > of new transport protocols. The working group will not specify any new > transport protocols. > > The current Internet protocol stack does not provide explicit, in-band, > transport-independent signaling to on-path network devices. This has led to > the deployment of devices which perform implicit discovery of transport > semantics and traffic characteristics via inspection of protocol headers and > payload, a practice made possible when these are sent in the clear. > > In order to support more ubiquitous deployment of encryption, and the > encryption of transport headers to allow deployment of new transport > protocols, explicit in-band signaling must be added to the stack. This > signaling must be transport protocol independent, and the types of information > signaled must be based on characteristics that can be independently verified > by devices on path, or that can be usefully applied without requiring a trust > relationship between endpoints and the path. Further, a feedback channel that > provides information from on-path devices back to endpoints and applications, > e.g. for error handling, is essential for the deployment and success of an > explicit cooperation approach. > > While IP would seem to be the natural home for this facility, both IPv4 and > IPv6 options and extensions have deployment problems on their own, which makes > it hard to include any additional information in these protocols. > > The PLUS working group will specify a new protocol as a Path Layer > UDP Substrate (PLUS), to support experimental deployment of > explicit cooperation between endpoints and devices on path, with the following goals: > > - enable ubiquitous deployment of encrypted higher layer protocols > by providing exposure of basic TCP-like semantics (e.g. SYN, FIN, > RST flags) to devices on path (e.g. NATs and firewalls). > > - allow applications and transport protocols to explicitly provide > limited information with integrity protection to devices on path > > - allow devices on path to provide unencrypted feedback and information > about the path directly to sending endpoints, under sending endpoint > control > > - allow devices on path to provide unencrypted information about the > path to receiving endpoints, with encrypted feedback to the > sending endpoint, under sending endpoint control > > This approach explicitly gives the control of information exposure back the > application and/or transport layer protocol on the end host. It is the goal of > PLUS to minimize the information exposed, to make information exposure > transparent, and to limit the level of detail to that useful for network > treatment, while encrypting everything else. Endpoint verification of > signaling integrity, careful design of minimal data structures, and > restrictive policies for registration of signals can help to meet this goal. > This is important to avoid future implicit treatment and resulting > ossification, as well as to minimize the privacy risks presented by explicit > cooperation. > > Given that the primary goal of PLUS is to enable the deployment of transport > protocols with encrypted headers, we assume that the higher-layer protocol can > provide an encryption context that can be used by PLUS to provide > authentication, integrity, and encryption where needed. The primary threat > model to defend against will be modification or deletion of exposed > information by middleboxes and other devices on path, by allowing a remote > endpoint to detect modifications. > > The working group will start with an initial set of use cases (see draft- > kuehlewind-spud-use-cases) and requirements (see draft-trammell-spud-req), > taken from experience with the Substrate Protocol for User Datagrams (SPUD) > prototype. The working group's main output will be an experimental protocol > specification, together with an initial registry of types of information that > can be exposed using PLUS, clearly aligned to the use cases determined by the > working group. This specification will consider potential attacks against the > protocol, both arising from the encapsulation chosen as well as new attacks > made possible by the protocol, and propose mitigations for these attacks. > > The working group will close if it is not able to come to consensus on a > protocol design to meet these requirements. > > The working group will additionally aim to identify and work with other > working groups that could address parts of these requirements within existing > protocols, e.g. by specifying new protocol extensions, or as input for on- > going standardization work. It will aim to work with working groups defining > encryption protocols (e.g. DTLS) which could be used for encryption of > transport protocols running over PLUS. > > Out of scope for the working group are: > > - The design and specification of new transport protocols running over PLUS. > - Mechanisms for signaling among multiple devices on path between two endpoints > - Mechanisms for key exchange or cryptographic context establishment between endpoints and devices on path > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Thu Jul 21 08:06:14 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C31112D63B for ; Thu, 21 Jul 2016 08:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 nC7c0Ryl90vd for ; Thu, 21 Jul 2016 08:06:11 -0700 (PDT) Received: from gorgon.tele.no (gorgon.tele.no [193.156.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4308412D5F9 for ; Thu, 21 Jul 2016 08:06:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by gorgon.tele.no with esmtp (Exim 4.84_2) (envelope-from ) id 1bQFZL-0006s0-7t; Thu, 21 Jul 2016 17:07:23 +0200 To: Mikael Abrahamsson References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> From: Frode Kileng Message-ID: <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> Date: Thu, 21 Jul 2016 17:03:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:06:12 -0000 On 21.07.2016 16:47, Mikael Abrahamsson wrote: > > SPUD could be used to have similar benefits for non-TCP traffic, in > that it might be easier to identify un-solicited traffic. I'm not a native English speaker and I'm sorry if I was not clear enough in my initial e-mail. I was talking about existing operational practices hindered by end-to-end encryption and that PLUS can bring back (i.e. referring to a statement today that "mobile operators need PLUS"). Your example is covers new functionality to enable FWs/etc with "signaling and control impaired with respect to TCP" (As Joe Hildebrand stated on one of the slides on his presentation at the BoF). Except that a solution not requiring PLUS is preferable, there's nothing wrong with this IMHO. frodek From nobody Thu Jul 21 08:09:18 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892FA12D674 for ; Thu, 21 Jul 2016 08:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URSqlmbwZGVL for ; Thu, 21 Jul 2016 08:09:16 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 CC76912D5F8 for ; Thu, 21 Jul 2016 08:09:15 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b199so64753501lfe.0 for ; Thu, 21 Jul 2016 08:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=wYj6LJhBBZEWrZMA22v80LJ71wTnE5iVrlWpXpkmGYs=; b=td0gQiYluNwC0zzHedRVs9CLUS5BAokY69jc4Soua6+HcSuzYf4p583vb4kTM9RCjF MDKcYdcQovTxHu6jPien2xulOJxTYSKR3L18tgD37KRbKD3cyorzcKNmXxSBA09dz7i6 9mg8jHC7WqbTI9ZRPECA7DKqSaLCvheSOMjgWodsJcKfJu0QDut3MLTphVqCHkDgEjsi gr67pzflOom2KTlbhMNYnvcxzWPAItvVPYKFc19qfr0vFT/oDssBwZr40JhXUY0/Noc6 03CY+EuSCbdJSaKzcOvHoNuMP5c7kSjAR7qtHqhydnQULEFIaywi5xsVEsYMaZBUps+/ yiuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=wYj6LJhBBZEWrZMA22v80LJ71wTnE5iVrlWpXpkmGYs=; b=fRjThOuMhZTqrrZ/O/UIKrj/WXa7eo0dU5oQj14eHtf584xmJSsS1CrAsFtYBMTCjf iHkCApo1AIRZyRR37PhZf8WHcQTtyH3Ee3J0B8/DdxqUgT4yvyTE7mwJK65Yj4vfX4nq uRn+9/gWVgkjq5TpD+qsBk56Mi5qSJwO8zawNTQS+wXPEQrsojLG7y5gc90blcCUprh3 MTHwx1lVCNtZ8s3/i8qirT8+vQ9jlzMntJPT2lJQH4/l6kS7ympzlgEIbB8vhkgwLXFr Y8tcrRyEAR4KSy1eRvumubw78MTx7MIdPxsK9v7qDkS6i5RqLV2fUDLS7uuU1ff7CXpB T6Lg== X-Gm-Message-State: ALyK8tL89Uif2LotP6qSBQk5pcEf4u1yf1hDOJTKKBXFwAohhkttQDtSS3+N8jrMkaqHuw== X-Received: by 10.25.214.76 with SMTP id n73mr17121123lfg.162.1469113753624; Thu, 21 Jul 2016 08:09:13 -0700 (PDT) Received: from ?IPv6:2003:74:cf54:d255:8990:29d2:df8a:b967? (p20030006154B7555899029D2DF8AB967.dip0.t-ipconnect.de. [2003:6:154b:7555:8990:29d2:df8a:b967]) by smtp.googlemail.com with ESMTPSA id 67sm1969773ljj.8.2016.07.21.08.09.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 08:09:12 -0700 (PDT) To: spud@ietf.org From: Martin Stiemerling Message-ID: <5c86a251-7acd-6036-542c-55cfad96ee08@gmail.com> Date: Thu, 21 Jul 2016 17:09:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Spud] The PLUS BOF today and why should PLUS be better than the pack? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:09:17 -0000 Hi, I did had the comment about prior work in the space of middlebox signaling during the PLUS today (via jabber). And I got an interesting reply (from Aaron I believe) a long these lines: The prior work just didn't do the job and PLUS will do all better. This was a nice, but without any technial meat behind, right?! :-/ So why should PLUS be better as the pack (e.g., NSIS, as we talk about path-coupled signaling)? And by the way, I am not a promoter of NSIS (though I have been one of the co-chairs), but an interest IETF member that would like understand why people believe making a new protocol will just solve the problems others have run into before? And those problems haven't been fixed by today. Thanks in advance, Martin From nobody Thu Jul 21 08:15:48 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8C212D5F8 for ; Thu, 21 Jul 2016 08:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 RrIqXqnYcLlt for ; Thu, 21 Jul 2016 08:15:46 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 03C5A12D67C for ; Thu, 21 Jul 2016 08:15:46 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EC709A3; Thu, 21 Jul 2016 17:15:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1469114143; bh=trb7u1OqLu7gfW0gpJ5PSjscPnA6fZdDOR+CCegD9Hg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=CU7cOwJNrCG4xfvhZNq/LEHtGd19mOu6eaoTGVOyzXxv6pVryYN009bBkXQ0hXvoM hNFQuC9JS0Iznu3swaIh3KFn1FLxljiOPqSXZZQBuksxoA3AP378igMd+QWwW4Xr46 tdgvkydXDXXe/zzv5ClxARX2TPjUJsc22p+ODeTE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E8B95A2; Thu, 21 Jul 2016 17:15:43 +0200 (CEST) Date: Thu, 21 Jul 2016 17:15:43 +0200 (CEST) From: Mikael Abrahamsson To: Frode Kileng In-Reply-To: <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> Message-ID: References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:15:47 -0000 On Thu, 21 Jul 2016, Frode Kileng wrote: > I'm not a native English speaker and I'm sorry if I was not clear enough > in my initial e-mail. I was talking about existing operational practices > hindered by end-to-end encryption and that PLUS can bring back (i.e. > referring to a statement today that "mobile operators need PLUS"). If all traffic is IPSEC encrypted and the SYN flag is no longer available to network operators, they can't do what I described. They can't do it either with various UDP protocols that people are now developing. If SPUD comes with flags that say "this is a connection establishment packet" (SYN-like) and another flag that matches ACK, then middle boxes can track connection establishment for all traffic based on SPUD, without needing to know anything more about the traffic. This is the functionality I'm talking about. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 21 08:18:08 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF7912D662 for ; Thu, 21 Jul 2016 08:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.188 X-Spam-Level: X-Spam-Status: No, score=-8.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 R_MdBsjFlvNB for ; Thu, 21 Jul 2016 08:18:05 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8783212D14A for ; Thu, 21 Jul 2016 08:18:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,399,1464678000"; d="asc'?scan'208";a="128923484" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx143-out.netapp.com with ESMTP; 21 Jul 2016 08:13:00 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 08:13:00 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::2c76:6bc2:2216:a24d%21]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 08:13:00 -0700 From: "Eggert, Lars" To: Martin Stiemerling Thread-Topic: [Spud] PLUS charter rev. 23 June Thread-Index: AQHRzTKo98YIixQtiUSsP/Szri6Uc6AjnBSAgAADnAA= Date: Thu, 21 Jul 2016 15:13:00 +0000 Message-ID: <1500CF05-9BB9-472B-AD63-C017E4BE1BA3@netapp.com> References: <32DC1941-126F-4513-801F-559617E85436@trammell.ch> <92f8bd8e-f0d0-93ac-1e35-57c2222f7e4b@gmail.com> In-Reply-To: <92f8bd8e-f0d0-93ac-1e35-57c2222f7e4b@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_F38AA4F3-34F6-4F40-B92C-429F271CF08B"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: spud Subject: Re: [Spud] PLUS charter rev. 23 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:18:07 -0000 --Apple-Mail=_F38AA4F3-34F6-4F40-B92C-429F271CF08B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2016-07-21, at 17:00, Martin Stiemerling wrote: > "There are a number of protocols inside and outside to the IETF that = deal with endpoint to network signaling, namely to talk with = middleboxes. These protocols are, for instance, MIDCOM, PCP and NSIS. = The PLUS WG can leverage knowdlegde out of these older activities with = respect to endpoint to middlebox signaling." FWIW, almost ten years ago, we tried to survey prior work in this space. = We never managed to publish the RFC, but already back then there were at = least ten or so: https://tools.ietf.org/html/draft-eggert-middlebox-control-survey-01 Lars --Apple-Mail=_F38AA4F3-34F6-4F40-B92C-429F271CF08B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXkOZ9AAoJEFS1wwm/cMFX/3sP/1+Tst1mQY5JuwxH757KzyvQ YqVZ3YZ4eCRfwsqoorRyZcUwpx/kZvR/fkPzv318EtFymD3K4fhbNS1/Ot7slpws l1BzGILg+u7ado4Wnkek0YMUMrZkI9dLOoBZzHW+on+TmGsW8EAguk+lbbBJi6jM OrZXcp9cUrXdC9EKvIIEIZ/UnFtl82hr9G5NN+ScjvcTA544BnO0wuUKw6DvTkgT j/fh0vRdi1SAywlcLgIy734i5n2bLgNH/5QI06nCUZrL8W0J8L2IX3d36SvgDsbc QG3CrsLMsqm+Iq3B3MEj4jehBMD3mVft5VjeN7lmN/7Z3asbeBhFMLnepItkmYkE 5zQ3TRhCXUpCQre7JRQp7QE3FupB82Bnt1jSOhMxWxs1laYDbJ4b0Kqrgp51hMuO 2nR9D5pr+rfozC7KI0oWo87q90M139JLMQer8ULxTusYjxE4KmN5VPrjfmXUdI7J 9IBklVrKkRO/lnPqBqW+F8jXWXQlbIJs0AFxgyeBuwKsuE8aG9UQvX4ujfMdDx3G dZbnU6Lhvbs+d6ZdEqmbX3/pYvyeiTX5FTAeJCSN2qyLSBYsmxF67EwWwxDHKdOR OuUxMqhxJn+qo5ZjqS+69mUu3txEs8ARaQuT7f16JfMcHDFuIo1+1giWpkI7snLA NKFbkHd4Ozp1gsGWS5qC =2BXp -----END PGP SIGNATURE----- --Apple-Mail=_F38AA4F3-34F6-4F40-B92C-429F271CF08B-- From nobody Thu Jul 21 08:20:48 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AADA12D6B1 for ; Thu, 21 Jul 2016 08:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 rKZYjGAZipfu for ; Thu, 21 Jul 2016 08:20:45 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4998912D69C for ; Thu, 21 Jul 2016 08:20:45 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 0AAC0F09AF844; Thu, 21 Jul 2016 15:20:41 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6LFKhxi015419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jul 2016 15:20:43 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6LFKXYA003335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Jul 2016 17:20:43 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 21 Jul 2016 17:20:41 +0200 From: "Scharf, Michael (Nokia - DE)" To: Martin Stiemerling , "spud@ietf.org" Thread-Topic: [Spud] The PLUS BOF today and why should PLUS be better than the pack? Thread-Index: AQHR42Hrz3dzvlK1gU63zg2rIKypSKAi/qog Date: Thu, 21 Jul 2016 15:20:40 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4892D396@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <5c86a251-7acd-6036-542c-55cfad96ee08@gmail.com> In-Reply-To: <5c86a251-7acd-6036-542c-55cfad96ee08@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Spud] The PLUS BOF today and why should PLUS be better than the pack? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:20:47 -0000 For what it is worth, NSIS has been raised quite some time ago, e.g.: https= ://www.ietf.org/mail-archive/web/spud/current/msg00367.html There was some follow-up discussion on in-band vs. out-of-band. Of course, NSIS was not the first attempt in this space. Michael > -----Original Message----- > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Martin > Stiemerling > Sent: Thursday, July 21, 2016 5:09 PM > To: spud@ietf.org > Subject: [Spud] The PLUS BOF today and why should PLUS be better than > the pack? >=20 > Hi, >=20 > I did had the comment about prior work in the space of middlebox > signaling during the PLUS today (via jabber). >=20 > And I got an interesting reply (from Aaron I believe) a long these > lines: > The prior work just didn't do the job and PLUS will do all better. >=20 >=20 > This was a nice, but without any technial meat behind, right?! :-/ >=20 >=20 > So why should PLUS be better as the pack (e.g., NSIS, as we talk about > path-coupled signaling)? >=20 > And by the way, I am not a promoter of NSIS (though I have been one of > the co-chairs), but an interest IETF member that would like understand > why people believe making a new protocol will just solve the problems > others have run into before? And those problems haven't been fixed by > today. >=20 > Thanks in advance, >=20 > Martin >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Thu Jul 21 08:23:32 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FC512D74C for ; Thu, 21 Jul 2016 08:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.208 X-Spam-Level: X-Spam-Status: No, score=-8.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 n60EjZ7k-aGx for ; Thu, 21 Jul 2016 08:23:22 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDFB12D5F7 for ; Thu, 21 Jul 2016 08:23:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,399,1464678000"; d="asc'?scan'208";a="125044385" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx142-out.netapp.com with ESMTP; 21 Jul 2016 08:22:22 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 08:22:20 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::2c76:6bc2:2216:a24d%21]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 08:22:21 -0700 From: "Eggert, Lars" To: Mikael Abrahamsson Thread-Topic: [Spud] No. Operators don't need SPUD for mobile network management Thread-Index: AQHR417WpScLTP95BEiIterukq9w8KAjcM8AgAADS4CAAAHWAA== Date: Thu, 21 Jul 2016 15:22:20 +0000 Message-ID: <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_F42E86B2-397D-4E3E-8EE1-E0376ED92F32"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Frode Kileng , "spud@ietf.org" Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:23:28 -0000 --Apple-Mail=_F42E86B2-397D-4E3E-8EE1-E0376ED92F32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2016-07-21, at 17:15, Mikael Abrahamsson wrote: > If SPUD comes with flags that say "this is a connection establishment = packet" (SYN-like) and another flag that matches ACK, then middle boxes = can track connection establishment for all traffic based on SPUD, = without needing to know anything more about the traffic. This is the = functionality I'm talking about. I think Christian said much the same thing in an earlier email: Why is the first packet arriving at a middlebox for which it has no = binding not treated as such a "connection establishment packet"? Why = does a bit need to be set for it to be treated as such? Lars --Apple-Mail=_F42E86B2-397D-4E3E-8EE1-E0376ED92F32 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXkOiqAAoJEFS1wwm/cMFXLREP/RCcYBbntAMm04q1SjWdsCSg 90shVMfUZAuDkIHNiyAQqNwgP56sRePEF2qIeVArrjiPXJIOUT8lcl88iX1zgj/w MJ1CNWoJw3d++UrLsmhs/x9rsWuljIsSHQvDAlkfQQ+/d0+P+iZJYBrSOmQJS+Sm tfHwJLrw+t+9U9qUjSOXPE0J2WQXPUbcALP9ZJRM//U/kP63YKYXcVO5dmKE3Ruv KlF/v66j0kgUFOfw9hF3HRBbChthywRmEHcJVrok0zjUpPQ3BFsnlu1i6G4SHfwo Htp7a8fhG5l12yOANqsCxFqv8w12HguTG/uRJ73N16/jJxF9N0M6EMRqkG4QVPPB f3qotSGi2yww5NwS43bERjyHzhLx5fBqSIs4WDF1RANhk/vVAOvbfRKrVJPxRf8s rEdtAFhlJrVsPBCFfJf5xrT9wQREPEUtvh1h8kG5MMt2i2KSBquYLwelQV1allGK U4eVc+ToHYktcDJKTX0D2mCygzxxjHYZVAweAKg6A6TJjUNmpT9RIVxM/qMM+oUd 6Waf9VkORBD0Y41fEJVZKRdBymnc7Z6+vJcxaqQhxaxskKpPZyslTZJWqbL79DLY 54ASqAIDFOuosf1ND+sjyFKQ6yJbSOpoW2EzyjuMKbHFaiSkeR2Cs0ijQjKtVBCZ Q5BuELkrmH8BD8RZbl+Y =ts79 -----END PGP SIGNATURE----- --Apple-Mail=_F42E86B2-397D-4E3E-8EE1-E0376ED92F32-- From nobody Thu Jul 21 08:27:48 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A04F12D0B4 for ; Thu, 21 Jul 2016 08:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 N1EQET7jtFHx for ; Thu, 21 Jul 2016 08:27:43 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 BDBFB12D76C for ; Thu, 21 Jul 2016 08:27:22 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7439EA2; Thu, 21 Jul 2016 17:27:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1469114840; bh=TOAM5ikHEVCOLOwvKmI0hlWwhIwUgjeqN190CdrWPLE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=L+/sePCnIxUALzQZw8N3OOQPdDuWkrYwKHEtBgluCDsWgGP4R4g5h/STIoWwpJIF3 Qf0NJK9Quvs4HMtON1wGFnGVbRkgR6UB9IRzE0EykeWh99yDnLSv4IhNSAr7orVFXk 5ybl2TI+PfJXlK/K1EulKpZ95B5aYWpu69zrciCk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6B212A1; Thu, 21 Jul 2016 17:27:20 +0200 (CEST) Date: Thu, 21 Jul 2016 17:27:20 +0200 (CEST) From: Mikael Abrahamsson To: "Eggert, Lars" In-Reply-To: <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> Message-ID: References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Frode Kileng , "spud@ietf.org" Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:27:46 -0000 On Thu, 21 Jul 2016, Eggert, Lars wrote: > Why is the first packet arriving at a middlebox for which it has no > binding not treated as such a "connection establishment packet"? Why > does a bit need to be set for it to be treated as such? Because you still want to allow incoming connections to the customers from the Internet. If there are no flags, I can't differentiate an incoming new connection Internet->UE (that I want to allow), from a backscatter packet (that I want to drop). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 21 08:28:13 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17B812D658 for ; Thu, 21 Jul 2016 08:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DglGsEeX8OZR for ; Thu, 21 Jul 2016 08:28:08 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 11C1412D0B4 for ; Thu, 21 Jul 2016 08:28:04 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id p64so31464439pfb.1 for ; Thu, 21 Jul 2016 08:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7rOf+u76pfBubdobWpWjEWztf5AiGFE3tn9DQRuMwQs=; b=QF7DkiVlcvqznt+NC4vIx0wTb7UeXKNFg2nj2GxKCIbDra+/IT+yeTD1G+FLO26OD8 IOAIgL9kk4tHgyytqFMMa1uazjgix0/I6oOWTQRd+G81Ubpx6321YOZycWsKO8ByI20Z 0oU6YeeP+K2aggxylNoE+sV0UUehwhijbMW2Kcx9u6ljMbkAoSjQxNy7azRbnVJaUf0K 11MTDtwD1GJfVjJbyhJeBmYAEAPW+kqzqWr7DdTxd/JxxwNkhfGZKJ67hQQdzVekThAN POcgV+s8dIdIodxNDxjkjS4HiZ985niNxN9MZIlpUXe6Xqq7XiS/pyPlmqokCn3Mu1au IN9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7rOf+u76pfBubdobWpWjEWztf5AiGFE3tn9DQRuMwQs=; b=RWZt1q5+xOullcvVV1f7DepEEaBSgDbNUcaqd9mVJrExx7/a97x8nuPWtw9dr4M3s7 SWINXjeJfr1zavoSbadtH5kz4yrhpjGounXABhNj2J0o/0jW8t6iv1RFjbDBNqicmtoK ltQ32AWiM6v/w0/ceeKPcwLcV/A5MjBeE4mAYWuKjTz3Bn9xW6fZ03ey911uCbwsXjqq knRZlqW/4ZQEyEdxRE55Z9bhhpX11lMFCRaITACV7Z+2thuBL6ndoA9Na4MSH3dwc8W4 G6hls/BAB4+YTxb9Ks5BydZPhUn2yA2++dS2qe/8eO1v+dYW7WMcJ3ByF/oE+I89qPNA w3HA== X-Gm-Message-State: ALyK8tIlR3XkX06asVcT1aDMKTHhGRU/mUGe9H2D9qckqugBma9AJIFLVwutd8atiV5q+G49bRuVSYGs4meoPw== X-Received: by 10.98.87.138 with SMTP id i10mr69703588pfj.16.1469114883719; Thu, 21 Jul 2016 08:28:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.47.163 with HTTP; Thu, 21 Jul 2016 08:28:03 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D4892D396@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <5c86a251-7acd-6036-542c-55cfad96ee08@gmail.com> <655C07320163294895BBADA28372AF5D4892D396@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: "mls.ietf" Date: Thu, 21 Jul 2016 17:28:03 +0200 Message-ID: To: "Scharf, Michael (Nokia - DE)" Content-Type: multipart/alternative; boundary=001a1135189ec74638053826f692 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] The PLUS BOF today and why should PLUS be better than the pack? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:28:11 -0000 --001a1135189ec74638053826f692 Content-Type: text/plain; charset=UTF-8 Hi Michael, all, On Thu, Jul 21, 2016 at 5:20 PM, Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > For what it is worth, NSIS has been raised quite some time ago, e.g.: > https://www.ietf.org/mail-archive/web/spud/current/msg00367.html > > There was some follow-up discussion on in-band vs. out-of-band. > > Of course, NSIS was not the first attempt in this space. > Right and I am not riding the NSIS train but more the why the hell all attempts to make use of path-coupled signaling to let endpoints talk to the net and vice versa did fail. I do not see that any of the reasons why they failed, e.g., missing trust on a global, Internet-wide scale, is not valid anymore today. Cheers, Martin --001a1135189ec74638053826f692 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael, all,=C2=A0

<= div class=3D"gmail_quote">On Thu, Jul 21, 2016 at 5:20 PM, Scharf, Michael = (Nokia - DE) <michael.scharf@nokia.com> wrote:
For what it is worth, NSIS has been raised quite some time ag= o, e.g.: https://www.ietf.org/mail-a= rchive/web/spud/current/msg00367.html

There was some follow-up discussion on in-band vs. out-of-band.

Of course, NSIS was not the first attempt in this space.

Right and I am not riding the NSIS train but more th= e why the hell all attempts to make use of path-coupled signaling to let en= dpoints talk to the net and vice versa did fail.=C2=A0

=
I do not see that any of the reasons why they failed, e.g., missing tr= ust on a global, Internet-wide scale, is not valid anymore today.=C2=A0

Cheers,

=C2=A0 Martin
<= /div>
--001a1135189ec74638053826f692-- From nobody Thu Jul 21 08:31:41 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8200912D5A1 for ; Thu, 21 Jul 2016 08:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.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 uR-nbUDW3Tvd for ; Thu, 21 Jul 2016 08:31:35 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (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 D6FA412D0B4 for ; Thu, 21 Jul 2016 08:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1469115091; x=1500651091; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lavKz6aDzViRP+OVjURD/GGyYzXmp+qeEPMZomiwlW8=; b=fvb4vc3/3Je241ghFmsvyVP+635CYzSIaRAaGkM0i78ZOGBfuN7tBeHG TZtNnqWEEQPQpNISAr5lauH1dyu5X8/HS4vChOl1BPcPgdl8QoBYrlh38 Os1VASUG/5gHtYBcJaamdJM6e8UfIIHc/FleuVkMNeQkwWZK2janzVkyQ c=; X-IronPort-Anti-Spam-Filtered: false Received: from omzsmtpi03.vzbi.com ([165.122.46.173]) by omzsmtpe02.verizonbusiness.com with ESMTP; 21 Jul 2016 15:31:31 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="5.28,399,1464652800"; d="scan'208";a="738483977" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by omzsmtpi03.vzbi.com with ESMTP; 21 Jul 2016 15:31:29 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Thu, 21 Jul 2016 11:31:28 -0400 To: Frode Kileng , "spud@ietf.org" Date: Thu, 21 Jul 2016 11:31:28 -0400 Thread-Topic: [E] [Spud] No. Operators don't need SPUD for mobile network management Thread-Index: AdHjTVmY6fesqvXaQ5evzJ8klp8lDwAFlXpQ Message-ID: <900A1E2059ADB149B905E3C8FA0046A62CED1774BB@FHDP1LUMXC7V23.us.one.verizon.com> References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> In-Reply-To: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Spud] [E] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:31:41 -0000 +1 Frode. Well said.=20 -Sanjay -----Original Message----- From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Frode Kileng Sent: Thursday, July 21, 2016 2:40 PM To: spud@ietf.org Subject: [E] [Spud] No. Operators don't need SPUD for mobile network manage= ment Hi, the claims that encryption has taken away something that was used for mobil= e network traffic management and that PLUS is needed to to save mobile netw= ork operations keeps surfacing, including at the BoF today.=20 This view should not be interpreted as representing the view of all mobile = operators The rule is that all "Internet traffic" is assigned the default bearer and = there's no differentiated handling of the traffic within this bearer. It ha= s been hinted that there's exceptions "somewhere" but as long this claim is= never substantiated, and there's no problem related to this in today in mo= bile networks, we should conclude that PLUS is not solving an existing prob= lem related to mobile network management. Feel free to disagree but then please provide details. That said, PLUS may be an enabler for mobile network management practices, = for example a 1-bit latency/throughput prioritization indicator. Best regards Frode Kileng _______________________________________________ Spud mailing list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud From nobody Thu Jul 21 08:32:26 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF4E12D69A for ; Thu, 21 Jul 2016 08:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO9Ck1PQZKrd for ; Thu, 21 Jul 2016 08:32:23 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 10CD312D520 for ; Thu, 21 Jul 2016 08:32:23 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id pp5so30047495pac.3 for ; Thu, 21 Jul 2016 08:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zKLOtqydEkNlACG2OQ5hmX0QolFpuyfPNE+Yggkk9ek=; b=KSUbmFhRhYywTfG06yTY3GEQW5ZprFtbyeE7FVAeJrNt7AljU06bUu3Da5HLkHzdpb W0rnj/KJG1YVIkUtL64r9i3qSbHtz0Vr9SQ7AQzCdpNikToYbr6OpM6MZ+Lxnh0CmNEk H0+cXYhFxcKrZ03RUoiaZ/regl+VDaEM6m7P5FtznKusYEzel47itc0fXbfRvTjbjf2n bg6UhduPhve9on+AMERIi3AtsMXnm/l+gguGnvbzFo6/AKBjdhBhguhQ/r3hssKqDyL6 ErVPzDs2zL9fs5dH1BTchtHvTNhaFJF+qhtI/hHjplunAes7cDZOVO9fs2rUUdaWHXVh L5fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zKLOtqydEkNlACG2OQ5hmX0QolFpuyfPNE+Yggkk9ek=; b=YvOSGW/8t3jIZFADQUUpOYe+v9YhVpKVZIw9zv+Ceo2cD1eGpphelSVxp8Sa8XQrQt W11ghHwEx/c+h5nDCvwkE21/kcCJ+tFF1lEmwz77zBlg/Sfqt2GgcI++y61ORa0YT5wM PS2C8ReTSodpoxxPwMwVQ6z7RRQztStsJ4w4xfme6/93NWtUKj8qjncv+n1dA+uv73vj QCiOHUZ1QjPoMnDxR9aptzsPCQOeJbUAjMXv2AsMmmfTL431YMnMV4244uiMGLezUpO7 tF7EEtBzN/v0UiudRrGibCD9woML9et5yqu61UKCuLEPEJh6rJQM3YUI1a7kpLpp7RKW 6GPg== X-Gm-Message-State: ALyK8tIymF08V872/ERkOzexxo2W6CEJnKQAxHGZck6OL9dBOTn2ep0BM7XPqsZXYj9Auad9mQ/Z9WwZrsHhpQ== X-Received: by 10.66.216.70 with SMTP id oo6mr83777005pac.39.1469115142591; Thu, 21 Jul 2016 08:32:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.47.163 with HTTP; Thu, 21 Jul 2016 08:32:21 -0700 (PDT) In-Reply-To: <1500CF05-9BB9-472B-AD63-C017E4BE1BA3@netapp.com> References: <32DC1941-126F-4513-801F-559617E85436@trammell.ch> <92f8bd8e-f0d0-93ac-1e35-57c2222f7e4b@gmail.com> <1500CF05-9BB9-472B-AD63-C017E4BE1BA3@netapp.com> From: "mls.ietf" Date: Thu, 21 Jul 2016 17:32:21 +0200 Message-ID: To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=001a11c1e3b6355f4705382706d7 Archived-At: Cc: spud Subject: Re: [Spud] PLUS charter rev. 23 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:32:25 -0000 --001a11c1e3b6355f4705382706d7 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 21, 2016 at 5:13 PM, Eggert, Lars wrote: > On 2016-07-21, at 17:00, Martin Stiemerling wrote: > > "There are a number of protocols inside and outside to the IETF that > deal with endpoint to network signaling, namely to talk with middleboxes. > These protocols are, for instance, MIDCOM, PCP and NSIS. The PLUS WG can > leverage knowdlegde out of these older activities with respect to endpoint > to middlebox signaling." > > FWIW, almost ten years ago, we tried to survey prior work in this space. > We never managed to publish the RFC, but already back then there were at > least ten or so: > > https://tools.ietf.org/html/draft-eggert-middlebox-control-survey-01 I forgot about this, but this good to read for everybody :) Thanks, Martin > > > Lars > --001a11c1e3b6355f4705382706d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 21, 2016 at 5:13 PM, Eggert, Lars <lars@netapp.com> wrote:
On 2016-07-= 21, at 17:00, Martin Stiemerling <= mls.ietf@gmail.com> wrote:
> "There are a number of protocols inside and outside to the IETF t= hat deal with endpoint to network signaling, namely to talk with middleboxe= s. These protocols are, for instance, MIDCOM, PCP and NSIS. The PLUS WG can= leverage knowdlegde out of these older activities with respect to endpoint= to middlebox signaling."

FWIW, almost ten years ago, we tried to survey prior work in this sp= ace. We never managed to publish the RFC, but already back then there were = at least ten or so:

https://tools.ietf.org/html/draf= t-eggert-middlebox-control-survey-01

I = forgot about this, but this good to read for everybody :)

Thanks,

=C2=A0 Martin
=C2=A0


Lars

--001a11c1e3b6355f4705382706d7-- From nobody Thu Jul 21 08:36:02 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACE212D520 for ; Thu, 21 Jul 2016 08:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 Jvy2lkjrOO5Z for ; Thu, 21 Jul 2016 08:35:55 -0700 (PDT) Received: from gorgon.tele.no (gorgon.tele.no [193.156.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id E264F12D0B4 for ; Thu, 21 Jul 2016 08:35:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by gorgon.tele.no with esmtp (Exim 4.84_2) (envelope-from ) id 1bQG4E-0006um-4F; Thu, 21 Jul 2016 17:39:18 +0200 To: "Eggert, Lars" , Mikael Abrahamsson References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> From: Frode Kileng Message-ID: Date: Thu, 21 Jul 2016 17:35:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:36:00 -0000 On 21.07.2016 17:22, Eggert, Lars wrote: > Why is the first packet arriving at a middlebox for which it has no > binding not treated as such a "connection establishment packet"? Why > does a bit need to be set for it to be treated as such? Yes. And if needed, any return traffic can be used as an indicator that something is consenting to this traffic. frodek From nobody Thu Jul 21 08:39:02 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96C812D520 for ; Thu, 21 Jul 2016 08:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 ssXzvMdxBmqW for ; Thu, 21 Jul 2016 08:38:56 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 E3E5912D5F7 for ; Thu, 21 Jul 2016 08:38:55 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DA697A2; Thu, 21 Jul 2016 17:38:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1469115533; bh=rnDxXh2SK8CGuJ/vnWxBYoyq7WCjQ0nwc4SMEEMOkdQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bDGOdrtj/dKxsj7vQ/Rpe8T0fRq7WOYddIKHRBPgzkX/amgA+j8g57+WAvrn9ACvZ RNSs10jFoJmRbw4OUMmLv1ON1OpHB67kIc5rNieLqmQugbXnW3+S8Phgr3nFTjEcKW 4KGnxB0tL3Bm9kevTYoCR6mkMYtDyco3lujIzoo0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D3123A1; Thu, 21 Jul 2016 17:38:53 +0200 (CEST) Date: Thu, 21 Jul 2016 17:38:53 +0200 (CEST) From: Mikael Abrahamsson To: Frode Kileng In-Reply-To: Message-ID: References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "Eggert, Lars" , "spud@ietf.org" Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:38:58 -0000 On Thu, 21 Jul 2016, Frode Kileng wrote: > Yes. And if needed, any return traffic can be used as an indicator that > something is consenting to this traffic. I don't understand this comment. You're getting SYN+ACK backscatter, if you forward them you'll melt the mobile network. The only way to discern if the user consents to the traffic, is to forward them. How can this possibly work? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 21 08:42:52 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFFE12D774 for ; Thu, 21 Jul 2016 08:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.208 X-Spam-Level: X-Spam-Status: No, score=-8.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 AuxkfO8Y9fIP for ; Thu, 21 Jul 2016 08:42:49 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2055912B031 for ; Thu, 21 Jul 2016 08:34:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,399,1464678000"; d="asc'?scan'208";a="125048215" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx142-out.netapp.com with ESMTP; 21 Jul 2016 08:33:09 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 08:33:07 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::2c76:6bc2:2216:a24d%21]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 08:33:07 -0700 From: "Eggert, Lars" To: Mikael Abrahamsson Thread-Topic: [Spud] No. Operators don't need SPUD for mobile network management Thread-Index: AQHR42RpGk3XmQdBTUelMR4DQNA8/aAjeOuA Date: Thu, 21 Jul 2016 15:33:07 +0000 Message-ID: References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_124E3C75-FB65-4714-A444-0D703E02B695"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Frode Kileng , "spud@ietf.org" Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:42:51 -0000 --Apple-Mail=_124E3C75-FB65-4714-A444-0D703E02B695 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2016-07-21, at 17:27, Mikael Abrahamsson wrote: > If there are no flags, I can't differentiate an incoming new = connection Internet->UE (that I want to allow), from a backscatter = packet (that I want to drop). We probably have different opinions on how important it is for a = firewall to be able to drop backscatter vs. the ability for an app to = benefit from 0-RTT. (Cue Lorenzo). Lars --Apple-Mail=_124E3C75-FB65-4714-A444-0D703E02B695 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXkOszAAoJEFS1wwm/cMFX4uAP/idNl/R71u9d2e6d9+8N+hvX L9wuHnV3wJdpPcnySygR2o9/O7Kpf/kDKeSDQvmnWo0Z0JJjfO3qKqPkrco0lM17 PelWLcj5LdmvhmM3ldqhM6eoZgcAFmAceamQd8/Sp26KcDXbGnHP75K+WSIHZ0Nu mU6Q6keWB+ItrojuvflnbEYVGfHJ0hPYYw2Ph/jdDr2hQZziF+bwQSFroCM1oBvA kEo2eJx3BQ2YTrgJ6MCnAC+QUIbOV0IIgChdI25V4Kvwkli4dHAEKReiiYTEU4R2 ot8yJ7ZQEE4jBZobdBXyFdrurJo5nTDCD6dV5baLCVYilf5LdsWVmE41g+ZelqPw QSqa8/8iCF+qyPnVnY9OM/ekouk9AnIVm8ZCM4XW2CCF70qk25fgV4Zl58z/Vk55 8pRNItBmKCM6b+65D2sFZCx8iPEcAJVWruusJxlIqosUq/5L52Uf97tzowBFxaO1 POklTYx40WrP4c1jtsePNkBSaRpXDHgky0yaqnrA8GT2qY05vMo26NStTmr2OKHj dOz+RnAfJ6+M24/yVCt1h+ENof5YvDQOkEHHhxrpOnO4w+2KIgT9v9V9Hc4KPBkp mu8xa8rJCkAhafvGlLbEAtIj4Mm/BWaHhN4oOlXTLo6uhcLnPkNLZLC2dapjRcw1 5vdLDDv5ubsCH7f/KBHS =cSAY -----END PGP SIGNATURE----- --Apple-Mail=_124E3C75-FB65-4714-A444-0D703E02B695-- From nobody Fri Jul 22 03:25:57 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C3912DC89 for ; Fri, 22 Jul 2016 03:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no 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 kTIjoBhF_mfw for ; Fri, 22 Jul 2016 03:25:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 8DDFB12DFC3 for ; Fri, 22 Jul 2016 03:25:52 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id EED1E6EF50900 for ; Fri, 22 Jul 2016 10:25:47 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6MAPoJO002792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 22 Jul 2016 10:25:50 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6MAPoaJ011804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Jul 2016 12:25:50 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.83]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 22 Jul 2016 12:25:50 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "spud@ietf.org" Thread-Topic: questions on the BoF outcome Thread-Index: AQHR5ANq+tZUgMMtYEuhq8vSOXYEcw== Date: Fri, 22 Jul 2016 10:25:49 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <78727A36A0A05D408CBC4F775A89F4ED@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Spud] questions on the BoF outcome X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 10:25:56 -0000 Hi, Unfortunately I could not attend the PLUS BoF. So, I've just gone through the minutes [1] (thanks a lot, scribes) and got the feeling that this work is pushed back due to the perception that it'd weaken users' privacy? I hear these arguments: - "potential to compel clients to send metadata or packets will dropped" But that could have happened already if the network wanted to (just drop any TCP payload that starts with 0x16 and allow only clear-text traffic!). Access networks that you pay for do not have that incentive though, so I'm very skeptical this could now happen *because of* PLUS. - "possibility for abuse" Well, that depends on the metadata that *users* decide to leak (which is a separate discussion on the vocabulary), but in general Brian's framework looks pretty well designed to bias control towards the endpoints which can act as circuit-breakers at any point in time. - "giving more power to the network"; This is actually true, but in a good way: the network will have power to send useful information to the endpoints -- if it's asked to -- while being empowered by the signalling coming from the endpoints (e.g., for DDoS prevention). So, sorry but this looks a lot like FUD to me. Is the working group not formed on these grounds? Or have more substantial weaknesses been highlighted during the discussion that have not been captured in the minutes? Cheers, thanks, t [1] http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-plus From nobody Fri Jul 22 03:30:36 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1365A12DF11 for ; Fri, 22 Jul 2016 03:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no 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 3i1iK6LZSq4p for ; Fri, 22 Jul 2016 03:30:33 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186FC12DFD8 for ; Fri, 22 Jul 2016 03:30:32 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-c0-5791f5c75ca7 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id ED.D5.12516.7C5F1975; Fri, 22 Jul 2016 12:30:31 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.93]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0294.000; Fri, 22 Jul 2016 12:29:13 +0200 From: Szilveszter Nadas To: "Fossati, Thomas (Nokia - GB)" , "spud@ietf.org" Thread-Topic: questions on the BoF outcome Thread-Index: AQHR5ANq+tZUgMMtYEuhq8vSOXYEc6AkPxYQ Date: Fri, 22 Jul 2016 10:29:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7hO7xrxPDDY49lbdYdOEpo0XL509s DkweS5b8ZPK4e+sSUwBTFJdNSmpOZllqkb5dAlfG9QmpBc8EKw6cTm1gnMrXxcjJISFgIvG4 pZ8NwhaTuHBvPZDNxSEkcIRRYu3sB8wQzmJGid2bToBVsQlYSDSs3AxmiwgkSKz8OgOoiIND WEBT4vS5SIiwlsT/o1+ZIGwjiZ/7vzOD2CwCqhI/3l4Ca+UV8JVYc/kwWI2QgJ3Ew77tTCBj OAXsJS5udwYJMwLd8/3UGrASZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/rBC2osTV6cuh6nUk Fuz+xAZha0ssW/iaGWKtoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUbQ4tbg4N93IWC+1 KDO5uDg/Ty8vtWQTIzBCDm75rbuDcfVrx0OMAhyMSjy8C3gnhguxJpYVV+YeYpTgYFYS4eX5 AhTiTUmsrEotyo8vKs1JLT7EKM3BoiTO6/9SMVxIID2xJDU7NbUgtQgmy8TBKdXAaD7znOwy m+kWCQl30+Ki4tZausjXlv/c5b3nXKvq9z1SX5wDZ2z7M+GKosGMFzsf2d5Xz3vP6Hrn9ePe JzYHfO6duZw+VWlqq82hy7tW3Xuxn/f2t0ep61dMnLP5QYrR+acv3d+t6Nqz7oOP+uH0TDHu 6RMXZoofeVsQtmSL9tztr//4tNzaZCqpxFKckWioxVxUnAgAGE971IwCAAA= Archived-At: Subject: Re: [Spud] questions on the BoF outcome X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 10:30:35 -0000 Hi, Some other argument was e.g. overhead. There was a significant amount of "N= O" hums for the first question, the rest of the questions was not even aske= d. It is also not clear to me, is there still hope, or is it hat eating time? = :) Cheers, Sz. > -----Original Message----- > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Fossati, Thomas > (Nokia - GB) > Sent: Friday, July 22, 2016 12:26 > To: spud@ietf.org > Subject: [Spud] questions on the BoF outcome >=20 > Hi, >=20 > Unfortunately I could not attend the PLUS BoF. So, I've just gone throug= h the > minutes [1] (thanks a lot, scribes) and got the feeling that this work is= pushed > back due to the perception that it'd weaken users' privacy? >=20 > I hear these arguments: > - "potential to compel clients to send metadata or packets will dropped" >=20 > But that could have happened already if the network wanted to (just drop = any > TCP payload that starts with 0x16 and allow only clear-text traffic!). > Access networks that you pay for do not have that incentive though, so I= 'm > very skeptical this could now happen *because of* PLUS. >=20 > - "possibility for abuse" >=20 > Well, that depends on the metadata that *users* decide to leak (which is = a > separate discussion on the vocabulary), but in general Brian's framework = looks > pretty well designed to bias control towards the endpoints which can act = as > circuit-breakers at any point in time. >=20 > - "giving more power to the network"; >=20 > This is actually true, but in a good way: the network will have power to = send > useful information to the endpoints -- if it's asked to -- while being em= powered > by the signalling coming from the endpoints (e.g., for DDoS prevention). >=20 > So, sorry but this looks a lot like FUD to me. >=20 > Is the working group not formed on these grounds? Or have more substanti= al > weaknesses been highlighted during the discussion that have not been > captured in the minutes? >=20 > Cheers, thanks, > t >=20 > [1] http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-plus >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Fri Jul 22 03:31:16 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101DD12DFDE for ; Fri, 22 Jul 2016 03:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 bWHxbbWxyu-r for ; Fri, 22 Jul 2016 03:31:13 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 2F99212DFD7 for ; Fri, 22 Jul 2016 03:31:13 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A7F0995E23070 for ; Fri, 22 Jul 2016 10:31:08 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6MAVAML008118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 22 Jul 2016 10:31:11 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6MAUnEr002293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Jul 2016 12:31:10 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.83]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 22 Jul 2016 12:31:00 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "spud@ietf.org" Thread-Topic: A few comments on Brian's proposal Thread-Index: AQHR5AQjYx+nd6Tx8ke3LkmcV7dl4w== Date: Fri, 22 Jul 2016 10:31:00 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <97B38684F7701A439505654066DA0A12@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Spud] A few comments on Brian's proposal X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 10:31:15 -0000 Hi, One thing that I like about the PLUS co-operative game, as currently proposed, is that you can set a precise goal for it, and subverting the game is going to be very hard because users are in control of what they leak to the path. Another pleasant thing, is that opt-in is not a boolean flag, but rather a multi-dimensional variable that users can slice the way they want at any time depending on the game they want to play (even reducing it to zero dimensions if they want to stay out of any game). This looks like very good design to me. Now, the goal we are looking at is direct/indirect ways to improve users' QoE. (Mobile NwOs and users are aligned on this -- for different reasons of course, yet aligned, and this is the only thing that matters.) PLUS would give us a solid platform to build the needed signalling in a pretty straightforward way. All the use cases we are working on (i.e., adaptive video flows through the mobile network, radio traffic scheduling) depend on in-band signalling, so if we had to do that ourselves we'd probably reinvent PLUS. Other people have use cases that are more on the side of "give me back the ability to do proper network management" which certainly need to be tackled. But I would not narrow PLUS' scope down to those use cases only. There is a great line that the minutes attribute to Mark that starts with: "By standardizing this, we might make new things possible.", which I wholeheartedly agree with: the innovation potential in PLUS is exactly what we want to explore and are excited about. And then continues with: "That worries me, because I don't understand how this impacts end users." Well, that doesn't worry me at all, and for a couple of good reasons: 1. PLUS' architecture gives me enough guarantees that the QoE game that I want to enable is not going to be easily subverted; 2. The vocabulary is not yet defined, and this is where the discussion about users' privacy would certainly happen involving the relevant stakeholders. If it's not yet clear: I support the creation of this working group :-) and also plan to contribute with drafts, reviews, and running code. Cheers, t From nobody Fri Jul 22 07:49:12 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0712D5BD for ; Fri, 22 Jul 2016 07:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 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_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5_vwnmyhia6n for ; Fri, 22 Jul 2016 07:49:09 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 D53C812D1AC for ; Fri, 22 Jul 2016 07:49:08 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id 38so107222225iol.0 for ; Fri, 22 Jul 2016 07:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8BRn1IQs3kuFoTEityUCMwTVeSa5/fL3DsanjO11V2o=; b=PM6ofBZxBBrj77tUf+jHZNAUXzpZF49eL/DthVW8GepDw+Q6/YvzMV+CP+zsDAwisj Kqa4lpcGJYNwBECZaT47Cllh0nc6HYyRoe/Umktz9059/i9OBrp/y82PGzBb25Ev3L6u kFXLGxLX7Xt/85/hOBkSI4v88pUx+9gfF0wNgy/9V766XEz7ZDPUdtthC54kRpTebXoQ 9cJSC1sEUrjFARv7wY6ZLQS0WcWM5cCSd/sGBfwHppu2/0Kd+Q+/Bp3cz+pz3iEMBemx kFJM+6XW1BGBNHFKCU7NodBge+6jNBhiJq2VvHhHSl6DUGO2Wgd/5TeVFxZmT99Vkmcm WNOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8BRn1IQs3kuFoTEityUCMwTVeSa5/fL3DsanjO11V2o=; b=Xbp4KKLUowRSwT/YbDKkhDmTkhuR4v2sprTLSYcdDB9Vz8TiVLSU47n2aat8IghVwD eqa5ItwxltrMj8B2lLPCfoDaE0Kq1ObaBtbXjUwllNyKO9pchqawRIVVZFUE/RNqbmmT hZeL23iK0GsvV4GCFfvATC/wppik+6dVZHi6OmcSRxaNLmW7HOHxEtHcm/OAGmO56PX+ T+ORMut0UzdmbUu1IJaOV0gCSuHk9txMTxcKN4Ia0p9qxf98tDelqEHf0ObRZOKaJqzt r7pqdS/5g/XVuYUTn/ZkyvkLApOXQMK0ITVvFjutLgVTFLbePOxeiwEfO5E7f8BC8yZM mbFQ== X-Gm-Message-State: AEkooutc1sPJEJ+awVCijQNqLKfJQ9uRcg7M7veI0WPL01hFCAg05Vw5qC3Og2rNmihrKF6D1VO2TYjx28/SpomJ X-Received: by 10.107.9.42 with SMTP id j42mr4891580ioi.33.1469198948045; Fri, 22 Jul 2016 07:49:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.15.73 with HTTP; Fri, 22 Jul 2016 07:48:47 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Fri, 22 Jul 2016 10:48:47 -0400 Message-ID: To: Szilveszter Nadas Content-Type: multipart/alternative; boundary=001a113df6ac67990605383a898d Archived-At: Cc: "Fossati, Thomas \(Nokia - GB\)" , "spud@ietf.org" Subject: Re: [Spud] questions on the BoF outcome X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 14:49:11 -0000 --001a113df6ac67990605383a898d Content-Type: text/plain; charset=UTF-8 I hummed no largely because I felt I didn't clearly understand the work of the group, and hence couldn't evaluate whether it was possible and desirable. I personally would have preferred a clearly scoped set of initial use cases, with other use cases of potential future interest requiring a re-charter. I believe there are a lot of people interested in something along these lines, so my no hum was not an expression they should stop trying to move forward with a WG. I also want to continue having the conversation about what the path needs at the IETF, because it comes up fairly often, but I feel there's currently no coherent forum for the conversation. It would be great to see some amount of running code as well, with some clearly improved metrics for that particular use case. I would hope small scale experiments would inform the WG on what topics may warrant a re-charter. On Fri, Jul 22, 2016 at 6:29 AM, Szilveszter Nadas < Szilveszter.Nadas@ericsson.com> wrote: > Hi, > > Some other argument was e.g. overhead. There was a significant amount of > "NO" hums for the first question, the rest of the questions was not even > asked. > > It is also not clear to me, is there still hope, or is it hat eating time? > :) > > Cheers, > Sz. > > > -----Original Message----- > > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Fossati, Thomas > > (Nokia - GB) > > Sent: Friday, July 22, 2016 12:26 > > To: spud@ietf.org > > Subject: [Spud] questions on the BoF outcome > > > > Hi, > > > > Unfortunately I could not attend the PLUS BoF. So, I've just gone > through the > > minutes [1] (thanks a lot, scribes) and got the feeling that this work > is pushed > > back due to the perception that it'd weaken users' privacy? > > > > I hear these arguments: > > - "potential to compel clients to send metadata or packets will dropped" > > > > But that could have happened already if the network wanted to (just drop > any > > TCP payload that starts with 0x16 and allow only clear-text traffic!). > > Access networks that you pay for do not have that incentive though, so > I'm > > very skeptical this could now happen *because of* PLUS. > > > > - "possibility for abuse" > > > > Well, that depends on the metadata that *users* decide to leak (which is > a > > separate discussion on the vocabulary), but in general Brian's framework > looks > > pretty well designed to bias control towards the endpoints which can act > as > > circuit-breakers at any point in time. > > > > - "giving more power to the network"; > > > > This is actually true, but in a good way: the network will have power to > send > > useful information to the endpoints -- if it's asked to -- while being > empowered > > by the signalling coming from the endpoints (e.g., for DDoS prevention). > > > > So, sorry but this looks a lot like FUD to me. > > > > Is the working group not formed on these grounds? Or have more > substantial > > weaknesses been highlighted during the discussion that have not been > > captured in the minutes? > > > > Cheers, thanks, > > t > > > > [1] http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-plus > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --001a113df6ac67990605383a898d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I hummed no largely because I felt I didn't clearly un= derstand the work of the group, and hence couldn't evaluate whether it = was possible and desirable. =C2=A0

I personally would have preferre= d a clearly scoped set of initial use cases, with other use cases of potent= ial future interest requiring a re-charter. =C2=A0

I believe there are a lot of people interested in something along these li= nes, so my no hum was not an expression they should stop trying to move for= ward with a WG.=C2=A0 I also want to continue having the conversation about= what the path needs at the IETF, because it comes up fairly often, but I f= eel there's currently no coherent forum for the conversation.

It would be great to see some amount of running code as wel= l, with some clearly improved metrics for that particular use case.=C2=A0 I= would hope small scale experiments would inform the WG on what topics may = warrant a re-charter.

On Fri, Jul 22, 2016 at 6:29 AM, Szilveszter Nadas <Szilveszter.Nadas@ericsson.com> wrote:
Hi,

Some other argument was e.g. overhead. There was a significant amount of &q= uot;NO" hums for the first question, the rest of the questions was not= even asked.

It is also not clear to me, is there still hope, or is it hat eating time? = :)

Cheers,
Sz.

> -----Original Message-----
> From: Spud [mailto:spud-bounc= es@ietf.org] On Behalf Of Fossati, Thomas
> (Nokia - GB)
> Sent: Friday, July 22, 2016 12:26
> To: spud@ietf.org
> Subject: [Spud] questions on the BoF outcome
>
> Hi,
>
> Unfortunately I could not attend the PLUS BoF.=C2=A0 So, I've just= gone through the
> minutes [1] (thanks a lot, scribes) and got the feeling that this work= is pushed
> back due to the perception that it'd weaken users' privacy? >
> I hear these arguments:
> - "potential to compel clients to send metadata or packets will d= ropped"
>
> But that could have happened already if the network wanted to (just dr= op any
> TCP payload that starts with 0x16 and allow only clear-text traffic!).=
>=C2=A0 Access networks that you pay for do not have that incentive thou= gh, so I'm
> very skeptical this could now happen *because of* PLUS.
>
> - "possibility for abuse"
>
> Well, that depends on the metadata that *users* decide to leak (which = is a
> separate discussion on the vocabulary), but in general Brian's fra= mework looks
> pretty well designed to bias control towards the endpoints which can a= ct as
> circuit-breakers at any point in time.
>
> - "giving more power to the network";
>
> This is actually true, but in a good way: the network will have power = to send
> useful information to the endpoints -- if it's asked to -- while b= eing empowered
> by the signalling coming from the endpoints (e.g., for DDoS prevention= ).
>
> So, sorry but this looks a lot like FUD to me.
>
> Is the working group not formed on these grounds?=C2=A0 Or have more s= ubstantial
> weaknesses been highlighted during the discussion that have not been > captured in the minutes?
>
> Cheers, thanks,
> t
>
> [1] http://etherpad.tools.ietf.org:9000= /p/notes-ietf-96-plus
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud

--001a113df6ac67990605383a898d-- From nobody Fri Jul 22 07:57:19 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4880512DB6C for ; Fri, 22 Jul 2016 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 aSdTTm71ujRB for ; Fri, 22 Jul 2016 07:57:14 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D792D12D612 for ; Fri, 22 Jul 2016 07:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4347; q=dns/txt; s=iport; t=1469199433; x=1470409033; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=0XoOe0u+XMC6n15ydkVo6gpZFgbUXW47V1P87BydvFA=; b=efjCiCvVzPtPbMR8JREsnwJAcrQJUm/psCdG7vz7VjtiHXb2e7Wrb3yq bPYRm2l3VnIHU5FoeAX4f8sBFQgdXHGoeB1o/IYQJjlw47SYgkNqytTku Hh9t2/7e8AvqYIVfQiEoVF+NjHflulvIN1xrughsvvJGPiRPgtNHPtO32 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAwC5M5JX/5pdJa1egz9WfLhfgXsjh?= =?us-ascii?q?RpfAoEvOBQBAQEBAQEBXSdBDgGEDAEBBQEBODQLBQcECxEEAQEBCR4HDwUTHwk?= =?us-ascii?q?OE4gwDrwMAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIp3hCaFdQWPAYolhhZxh10Kg?= =?us-ascii?q?WxOjQCQIR42hBMcMgGFPoM0AQEB?= X-IronPort-AV: E=Sophos;i="5.28,405,1464652800"; d="scan'208";a="300259783" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2016 14:57:12 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6MEvCov002279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2016 14:57:12 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6MEvBQP021351; Fri, 22 Jul 2016 07:57:11 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6MEvBce021350; Fri, 22 Jul 2016 07:57:11 -0700 Date: Fri, 22 Jul 2016 07:57:11 -0700 From: Toerless Eckert To: Ian Swett Message-ID: <20160722145711.GP7377@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "Fossati, Thomas \(Nokia - GB\)" , Szilveszter Nadas , "spud@ietf.org" Subject: Re: [Spud] questions on the BoF outcome X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 14:57:16 -0000 Whats actually the official process for asking for support - only Hum i the WG, or is there going to be a call here or whatever other mailing list ? If anyone is counting, here's one in favor of Plus WG. Use-case: Controlled network edge to Internet firewalls wanting to have similar flow recognition to TCP for UDP flows with replay-safe intent to receive indication. Cheers Toerless On Fri, Jul 22, 2016 at 10:48:47AM -0400, Ian Swett wrote: > I hummed no largely because I felt I didn't clearly understand the work of > the group, and hence couldn't evaluate whether it was possible and > desirable. > > I personally would have preferred a clearly scoped set of initial use > cases, with other use cases of potential future interest requiring a > re-charter. > > I believe there are a lot of people interested in something along these > lines, so my no hum was not an expression they should stop trying to move > forward with a WG. I also want to continue having the conversation about > what the path needs at the IETF, because it comes up fairly often, but I > feel there's currently no coherent forum for the conversation. > > It would be great to see some amount of running code as well, with some > clearly improved metrics for that particular use case. I would hope small > scale experiments would inform the WG on what topics may warrant a > re-charter. > > On Fri, Jul 22, 2016 at 6:29 AM, Szilveszter Nadas < > Szilveszter.Nadas@ericsson.com> wrote: > > > Hi, > > > > Some other argument was e.g. overhead. There was a significant amount of > > "NO" hums for the first question, the rest of the questions was not even > > asked. > > > > It is also not clear to me, is there still hope, or is it hat eating time? > > :) > > > > Cheers, > > Sz. > > > > > -----Original Message----- > > > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Fossati, Thomas > > > (Nokia - GB) > > > Sent: Friday, July 22, 2016 12:26 > > > To: spud@ietf.org > > > Subject: [Spud] questions on the BoF outcome > > > > > > Hi, > > > > > > Unfortunately I could not attend the PLUS BoF. So, I've just gone > > through the > > > minutes [1] (thanks a lot, scribes) and got the feeling that this work > > is pushed > > > back due to the perception that it'd weaken users' privacy? > > > > > > I hear these arguments: > > > - "potential to compel clients to send metadata or packets will dropped" > > > > > > But that could have happened already if the network wanted to (just drop > > any > > > TCP payload that starts with 0x16 and allow only clear-text traffic!). > > > Access networks that you pay for do not have that incentive though, so > > I'm > > > very skeptical this could now happen *because of* PLUS. > > > > > > - "possibility for abuse" > > > > > > Well, that depends on the metadata that *users* decide to leak (which is > > a > > > separate discussion on the vocabulary), but in general Brian's framework > > looks > > > pretty well designed to bias control towards the endpoints which can act > > as > > > circuit-breakers at any point in time. > > > > > > - "giving more power to the network"; > > > > > > This is actually true, but in a good way: the network will have power to > > send > > > useful information to the endpoints -- if it's asked to -- while being > > empowered > > > by the signalling coming from the endpoints (e.g., for DDoS prevention). > > > > > > So, sorry but this looks a lot like FUD to me. > > > > > > Is the working group not formed on these grounds? Or have more > > substantial > > > weaknesses been highlighted during the discussion that have not been > > > captured in the minutes? > > > > > > Cheers, thanks, > > > t > > > > > > [1] http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-plus > > > > > > _______________________________________________ > > > Spud mailing list > > > Spud@ietf.org > > > https://www.ietf.org/mailman/listinfo/spud > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Fri Jul 22 09:44:23 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883CF12DC96 for ; Fri, 22 Jul 2016 09:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no 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 FoFtwoLr5pT8 for ; Fri, 22 Jul 2016 09:44:19 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id C95C312D790 for ; Fri, 22 Jul 2016 09:44:18 -0700 (PDT) Received: from dhcp-974a.meeting.ietf.org (unknown [IPv6:2001:67c:370:136:50de:9034:beb0:2f00]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B7BEB1B0007D; Fri, 22 Jul 2016 17:44:12 +0100 (BST) Message-ID: <57924D61.5090808@erg.abdn.ac.uk> Date: Fri, 22 Jul 2016 18:44:17 +0200 From: G Fairhurst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Toerless Eckert References: <20160722145711.GP7377@cisco.com> In-Reply-To: <20160722145711.GP7377@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Fossati, Thomas \(Nokia - GB\)" , Szilveszter Nadas , Ian Swett , "spud@ietf.org" Subject: Re: [Spud] questions on the BoF outcome X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 16:44:22 -0000 I'm also hoping this proceeds. We need a framining like this to allow us to continue transport inovation. Being able to see, but also protect (MAC) certain protocol fields in the transport header seems a positive step towards ensuring end-to-end semantics as we look at new protocols. From this perspective, it is sooo much better than using a TCP header field, RTP option, or IPv6 header. Gorry On 22/07/2016, 16:57, Toerless Eckert wrote: > Whats actually the official process for asking for support - only > Hum i the WG, or is there going to be a call here or whatever other > mailing list ? > > If anyone is counting, here's one in favor of Plus WG. > > Use-case: Controlled network edge to Internet firewalls wanting to have similar > flow recognition to TCP for UDP flows with replay-safe intent to receive > indication. > > Cheers > Toerless > > On Fri, Jul 22, 2016 at 10:48:47AM -0400, Ian Swett wrote: >> I hummed no largely because I felt I didn't clearly understand the work of >> the group, and hence couldn't evaluate whether it was possible and >> desirable. >> >> I personally would have preferred a clearly scoped set of initial use >> cases, with other use cases of potential future interest requiring a >> re-charter. >> >> I believe there are a lot of people interested in something along these >> lines, so my no hum was not an expression they should stop trying to move >> forward with a WG. I also want to continue having the conversation about >> what the path needs at the IETF, because it comes up fairly often, but I >> feel there's currently no coherent forum for the conversation. >> >> It would be great to see some amount of running code as well, with some >> clearly improved metrics for that particular use case. I would hope small >> scale experiments would inform the WG on what topics may warrant a >> re-charter. >> >> On Fri, Jul 22, 2016 at 6:29 AM, Szilveszter Nadas< >> Szilveszter.Nadas@ericsson.com> wrote: >> >>> Hi, >>> >>> Some other argument was e.g. overhead. There was a significant amount of >>> "NO" hums for the first question, the rest of the questions was not even >>> asked. >>> >>> It is also not clear to me, is there still hope, or is it hat eating time? >>> :) >>> >>> Cheers, >>> Sz. >>> >>>> -----Original Message----- >>>> From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Fossati, Thomas >>>> (Nokia - GB) >>>> Sent: Friday, July 22, 2016 12:26 >>>> To: spud@ietf.org >>>> Subject: [Spud] questions on the BoF outcome >>>> >>>> Hi, >>>> >>>> Unfortunately I could not attend the PLUS BoF. So, I've just gone >>> through the >>>> minutes [1] (thanks a lot, scribes) and got the feeling that this work >>> is pushed >>>> back due to the perception that it'd weaken users' privacy? >>>> >>>> I hear these arguments: >>>> - "potential to compel clients to send metadata or packets will dropped" >>>> >>>> But that could have happened already if the network wanted to (just drop >>> any >>>> TCP payload that starts with 0x16 and allow only clear-text traffic!). >>>> Access networks that you pay for do not have that incentive though, so >>> I'm >>>> very skeptical this could now happen *because of* PLUS. >>>> >>>> - "possibility for abuse" >>>> >>>> Well, that depends on the metadata that *users* decide to leak (which is >>> a >>>> separate discussion on the vocabulary), but in general Brian's framework >>> looks >>>> pretty well designed to bias control towards the endpoints which can act >>> as >>>> circuit-breakers at any point in time. >>>> >>>> - "giving more power to the network"; >>>> >>>> This is actually true, but in a good way: the network will have power to >>> send >>>> useful information to the endpoints -- if it's asked to -- while being >>> empowered >>>> by the signalling coming from the endpoints (e.g., for DDoS prevention). >>>> >>>> So, sorry but this looks a lot like FUD to me. >>>> >>>> Is the working group not formed on these grounds? Or have more >>> substantial >>>> weaknesses been highlighted during the discussion that have not been >>>> captured in the minutes? >>>> >>>> Cheers, thanks, >>>> t >>>> >>>> [1] http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-plus >>>> >>>> _______________________________________________ >>>> Spud mailing list >>>> Spud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spud >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud > From nobody Fri Jul 22 16:34:29 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9F712D941 for ; Fri, 22 Jul 2016 16:34:28 -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, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRXl3mUU6YrX for ; Fri, 22 Jul 2016 16:34:25 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 1204412D89B for ; Fri, 22 Jul 2016 16:34:24 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id r9so116983740ywg.0 for ; Fri, 22 Jul 2016 16:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kn0hgDXNdxH7SXWRhdBYJyvR63HvG0U4wyYmgBzEvbc=; b=wbkWhkb3vx4lQPDqtdKp4MhK9t8VCSIUcYyRt2xYSXInA4mH1VO6PcQbYsEwUCVSjh IA7YiujnSE5qaBwO6s05bCuSLlU9lObIXV6sN3Wjyk9RRbuIerr1JU0fNazK+SOytNQr twCoUkIUJXBfo6Kxo5+sgGkqhiDCJaf3zrCe0EvUGe6HEhAlSUWuc4ngeU4dF3UEJBEQ gXYu98s6D1sg9C3WuYnyvMJ3N78kMWDdWx/247GrBRbs9JxXdUm9M84KCOmYbi6pS+3l iOiFVd8pFXEco6qwUX8JqZx7861DlTHFC/pZCnMO+E+BiNC8O408ZJEifDj8668NlBoq e5ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kn0hgDXNdxH7SXWRhdBYJyvR63HvG0U4wyYmgBzEvbc=; b=XIEcNZF2Y+PQfJSIR3BfXSNIhttTD7ygxJjgY0yLGVdcW24tePTsBrlfeoDxRpXgPh OYGe0PiairEfVpi2I0zEh83OgUEZTL/EWQeOAbcp9/x14W6vmam1GOLEeWuVfvBppmu8 ECBpMq6IRmjKGbmN0Ls0L59lFKkFLHci8PD4XW2n/uP5/Qx8TV3ux41M6dOGFD9QKHUM ploMegyTVJgiQ0lZgTuBGOQN1xoBkS30vbZERWh5DBTFypcL9p8Sm7ZYukY4uI2zx9HW z8OTiPPhChv77F5+BWVkHg7NtTgvqfjQDaI8L+MSy0i/Em44ym2AbsHaHb6pjBWoxUw6 CZgQ== X-Gm-Message-State: AEkoousLTV4Z0/1/4YFtP9Qhb1ZkqqtJE9hwPpFZAGUzJXKsMbgt7X3BXBBoE8zAtdsdFkbSfZ+EWqKzsUB5hg== X-Received: by 10.13.222.133 with SMTP id h127mr5967459ywe.211.1469230463897; Fri, 22 Jul 2016 16:34:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.231.20 with HTTP; Fri, 22 Jul 2016 16:34:23 -0700 (PDT) In-Reply-To: <20160722145711.GP7377@cisco.com> References: <20160722145711.GP7377@cisco.com> From: Spencer Dawkins at IETF Date: Sat, 23 Jul 2016 01:34:23 +0200 Message-ID: To: Toerless Eckert Content-Type: multipart/alternative; boundary=94eb2c07cfb8e4d7ca053841dfe5 Archived-At: Cc: "Fossati, Thomas \(Nokia - GB\)" , Szilveszter Nadas , Ian Swett , "spud@ietf.org" Subject: Re: [Spud] questions on the BoF outcome X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 23:34:28 -0000 --94eb2c07cfb8e4d7ca053841dfe5 Content-Type: text/plain; charset=UTF-8 Hi, Toerless, On Fri, Jul 22, 2016 at 4:57 PM, Toerless Eckert wrote: > Whats actually the official process for asking for support - only > Hum i the WG, or is there going to be a call here or whatever other > mailing list ? Thanks for asking. I met with the BOF proponents for at least a couple of hours today/tonight, and talked with them about next steps. I don't plan to ask for opinions about the charter as proposed at this time, in order to give the proponents and chairs time to take those next steps (they have two and a half hours of opinions from about 250 people to absorb now). If PLUS moves forward, the complete process would be something like - proponents absorb feedback to date - proponents take steps based on that feedback - proponents hand Spencer a revised charter, a more formal problem statement, and whatever else seems appropriate - Spencer asks the IESG and IAB for comments ("internal review") - Spencer absorbs comments received from internal review - Spencer takes steps based on those comments - The IESG asks the community for comments ("external review"). This includes both the IETF community and other SDOs (This is where you come in :-) - The IESG absorbs feedback we receive from external review - Spencer takes steps based on that feedback - Spencer places the resulting charter on an IESG telechat agenda for approval of WG creation I hope that's helpful! And thanks for asking. Spencer > If anyone is counting, here's one in favor of Plus WG. > > Use-case: Controlled network edge to Internet firewalls wanting to have > similar > flow recognition to TCP for UDP flows with replay-safe intent to receive > indication. > > Cheers > Toerless > > On Fri, Jul 22, 2016 at 10:48:47AM -0400, Ian Swett wrote: > > I hummed no largely because I felt I didn't clearly understand the work > of > > the group, and hence couldn't evaluate whether it was possible and > > desirable. > > > > I personally would have preferred a clearly scoped set of initial use > > cases, with other use cases of potential future interest requiring a > > re-charter. > > > > I believe there are a lot of people interested in something along these > > lines, so my no hum was not an expression they should stop trying to move > > forward with a WG. I also want to continue having the conversation about > > what the path needs at the IETF, because it comes up fairly often, but I > > feel there's currently no coherent forum for the conversation. > > > > It would be great to see some amount of running code as well, with some > > clearly improved metrics for that particular use case. I would hope > small > > scale experiments would inform the WG on what topics may warrant a > > re-charter. > > > > On Fri, Jul 22, 2016 at 6:29 AM, Szilveszter Nadas < > > Szilveszter.Nadas@ericsson.com> wrote: > > > > > Hi, > > > > > > Some other argument was e.g. overhead. There was a significant amount > of > > > "NO" hums for the first question, the rest of the questions was not > even > > > asked. > > > > > > It is also not clear to me, is there still hope, or is it hat eating > time? > > > :) > > > > > > Cheers, > > > Sz. > > > > > > > -----Original Message----- > > > > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Fossati, > Thomas > > > > (Nokia - GB) > > > > Sent: Friday, July 22, 2016 12:26 > > > > To: spud@ietf.org > > > > Subject: [Spud] questions on the BoF outcome > > > > > > > > Hi, > > > > > > > > Unfortunately I could not attend the PLUS BoF. So, I've just gone > > > through the > > > > minutes [1] (thanks a lot, scribes) and got the feeling that this > work > > > is pushed > > > > back due to the perception that it'd weaken users' privacy? > > > > > > > > I hear these arguments: > > > > - "potential to compel clients to send metadata or packets will > dropped" > > > > > > > > But that could have happened already if the network wanted to (just > drop > > > any > > > > TCP payload that starts with 0x16 and allow only clear-text > traffic!). > > > > Access networks that you pay for do not have that incentive though, > so > > > I'm > > > > very skeptical this could now happen *because of* PLUS. > > > > > > > > - "possibility for abuse" > > > > > > > > Well, that depends on the metadata that *users* decide to leak > (which is > > > a > > > > separate discussion on the vocabulary), but in general Brian's > framework > > > looks > > > > pretty well designed to bias control towards the endpoints which can > act > > > as > > > > circuit-breakers at any point in time. > > > > > > > > - "giving more power to the network"; > > > > > > > > This is actually true, but in a good way: the network will have > power to > > > send > > > > useful information to the endpoints -- if it's asked to -- while > being > > > empowered > > > > by the signalling coming from the endpoints (e.g., for DDoS > prevention). > > > > > > > > So, sorry but this looks a lot like FUD to me. > > > > > > > > Is the working group not formed on these grounds? Or have more > > > substantial > > > > weaknesses been highlighted during the discussion that have not been > > > > captured in the minutes? > > > > > > > > Cheers, thanks, > > > > t > > > > > > > > [1] http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-plus > > > > > > > > _______________________________________________ > > > > Spud mailing list > > > > Spud@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spud > > > > > > _______________________________________________ > > > Spud mailing list > > > Spud@ietf.org > > > https://www.ietf.org/mailman/listinfo/spud > > > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud > > > -- > --- > Toerless Eckert, eckert@cisco.com > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --94eb2c07cfb8e4d7ca053841dfe5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Toerless,

On Fri, Jul 22, 2016 at 4:57 PM, Toerless Eckert <eckert@cisco= .com> wrote:
Whats actually= the official process for asking for support - only
Hum i the WG, or is there going to be a call here or whatever other
mailing list ?

Thanks for asking.=C2=A0

I met with the BOF proponents for at least a couple o= f hours today/tonight, and talked with them about next steps.
I don't plan to ask for opinions about the charter as propo= sed at this time, in order to give the proponents and chairs time to take t= hose next steps (they have two and a half hours of opinions from about 250 = people to absorb now).

If PLUS moves forward, the = complete process would be something like=C2=A0
  • proponents= absorb feedback to date
  • proponents take steps based on that feedba= ck
  • proponents hand Spencer a revised charter, a more formal problem= statement, and whatever else seems appropriate
  • Spencer asks the IE= SG and IAB for comments ("internal review")
  • Spencer absor= bs comments received from internal review
  • Spencer takes steps based= on those comments
  • The IESG asks the community for comments ("= external review"). This includes both the IETF community and other SDO= s
(This is where you come in :-)
  • The IESG absorb= s feedback we receive from external review
  • Spencer takes steps base= d on that feedback
  • Spencer places the resulting charter on an IESG = telechat agenda for approval of WG creation
I hope that's= helpful! And thanks for asking.

Spencer
=C2=A0
If anyone is counting, he= re's one in favor of Plus WG.

Use-case: Controlled network edge to Internet firewalls wanting to have sim= ilar
flow recognition to TCP for UDP flows with replay-safe intent to receive indication.

Cheers
=C2=A0 =C2=A0 Toerless

On Fri, Jul 22, 2016 at 10:48:47AM -0400, Ian Swett wrote:
> I hummed no largely because I felt I didn't clearly understand the= work of
> the group, and hence couldn't evaluate whether it was possible and=
> desirable.
>
> I personally would have preferred a clearly scoped set of initial use<= br> > cases, with other use cases of potential future interest requiring a > re-charter.
>
> I believe there are a lot of people interested in something along thes= e
> lines, so my no hum was not an expression they should stop trying to m= ove
> forward with a WG.=C2=A0 I also want to continue having the conversati= on about
> what the path needs at the IETF, because it comes up fairly often, but= I
> feel there's currently no coherent forum for the conversation.
>
> It would be great to see some amount of running code as well, with som= e
> clearly improved metrics for that particular use case.=C2=A0 I would h= ope small
> scale experiments would inform the WG on what topics may warrant a
> re-charter.
>
> On Fri, Jul 22, 2016 at 6:29 AM, Szilveszter Nadas <
> Szilveszter.Nadas@er= icsson.com> wrote:
>
> > Hi,
> >
> > Some other argument was e.g. overhead. There was a significant am= ount of
> > "NO" hums for the first question, the rest of the quest= ions was not even
> > asked.
> >
> > It is also not clear to me, is there still hope, or is it hat eat= ing time?
> > :)
> >
> > Cheers,
> > Sz.
> >
> > > -----Original Message-----
> > > From: Spud [mailto:= spud-bounces@ietf.org] On Behalf Of Fossati, Thomas
> > > (Nokia - GB)
> > > Sent: Friday, July 22, 2016 12:26
> > > To: spud@ietf.org
> > > Subject: [Spud] questions on the BoF outcome
> > >
> > > Hi,
> > >
> > > Unfortunately I could not attend the PLUS BoF.=C2=A0 So, I&#= 39;ve just gone
> > through the
> > > minutes [1] (thanks a lot, scribes) and got the feeling that= this work
> > is pushed
> > > back due to the perception that it'd weaken users' p= rivacy?
> > >
> > > I hear these arguments:
> > > - "potential to compel clients to send metadata or pack= ets will dropped"
> > >
> > > But that could have happened already if the network wanted t= o (just drop
> > any
> > > TCP payload that starts with 0x16 and allow only clear-text = traffic!).
> > >=C2=A0 Access networks that you pay for do not have that ince= ntive though, so
> > I'm
> > > very skeptical this could now happen *because of* PLUS.
> > >
> > > - "possibility for abuse"
> > >
> > > Well, that depends on the metadata that *users* decide to le= ak (which is
> > a
> > > separate discussion on the vocabulary), but in general Brian= 's framework
> > looks
> > > pretty well designed to bias control towards the endpoints w= hich can act
> > as
> > > circuit-breakers at any point in time.
> > >
> > > - "giving more power to the network";
> > >
> > > This is actually true, but in a good way: the network will h= ave power to
> > send
> > > useful information to the endpoints -- if it's asked to = -- while being
> > empowered
> > > by the signalling coming from the endpoints (e.g., for DDoS = prevention).
> > >
> > > So, sorry but this looks a lot like FUD to me.
> > >
> > > Is the working group not formed on these grounds?=C2=A0 Or h= ave more
> > substantial
> > > weaknesses been highlighted during the discussion that have = not been
> > > captured in the minutes?
> > >
> > > Cheers, thanks,
> > > t
> > >
> > > [1] http://etherpad.tools.iet= f.org:9000/p/notes-ietf-96-plus
> > >
> > > _______________________________________________
> > > Spud mailing list
> > > Spud@ietf.org
> > > https://www.ietf.org/mailman/listinfo/spu= d
> >
> > _______________________________________________
> > Spud mailing list
> > Spud@ietf.org
> > https://www.ietf.org/mailman/listinfo/spud > >

> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud


--
---
Toerless Eckert, eckert@cisco.com

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud

--94eb2c07cfb8e4d7ca053841dfe5-- From nobody Sun Jul 24 05:00:16 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F7312B040 for ; Sun, 24 Jul 2016 05:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 padnet_wksUI for ; Sun, 24 Jul 2016 05:00:12 -0700 (PDT) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 A9C4D12B009 for ; Sun, 24 Jul 2016 05:00:12 -0700 (PDT) Received: by mail-qk0-x243.google.com with SMTP id q8so11972897qke.3 for ; Sun, 24 Jul 2016 05:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=2FajbjQCIb0LhXEFTxa3NqlxzK0be2LaIDfzQubjdwU=; b=YL+JhHmSmGeDY6EI3ufW6KaFn/NGhh4wkdqrTqsJcTlXlai7LY77aIUC+Dpwg9Na0H 1lbxU3a5GecZb/DHjmNa4gVydW8q3seHMPK5g/5yMDgwBvXeAvdex31aUqYuTVMH67jU qbohXURDDv/DwGlcfz3LN44bfAQNQeY4IZ9P0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2FajbjQCIb0LhXEFTxa3NqlxzK0be2LaIDfzQubjdwU=; b=ZNV1pFqcPJAaaFIMRVN/n227MtnpvsOvlsmhU//KmI4LPYOU77xdwFYwMcXtYWyxD+ 6N0GrZOXEE9VRkr64mr4sui6FuaIMdWYNgFgD6jAXaXOvH37UYST0NM74otGAPlp5ZEw J2+E0IKOiszDfbAbsmC5g+tO4JsL9TEe96JbPoMdXSgQrohDFg/kKoKnqkHQDzj0cSDP 7ie334dEJwAYqfpjThfWDDNFkltkm6hng62dUKYhoU++DsOLZbuFU62PXGbw8Wn+S/zf wY52vs2/V1XVxL89zllPklJ09R/1BcDaCjGeTx4wRwXsn/2qQXV86sDM0+qv5loRopHp L54w== X-Gm-Message-State: AEkoouuTYRC60kJl88YX7AkEu3vKjJkbBlPA7MFJw24xxpHZ3JZGJ12woZqeEFmZdhWhUgUtmqMNq9VLzdFc4w== X-Received: by 10.55.41.167 with SMTP id p39mr15686657qkp.119.1469361611489; Sun, 24 Jul 2016 05:00:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.94.70 with HTTP; Sun, 24 Jul 2016 05:00:10 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:6946:8c8e:426d:13ff] From: Kyle Rose Date: Sun, 24 Jul 2016 08:00:10 -0400 Message-ID: To: spud@ietf.org Content-Type: multipart/alternative; boundary=001a11493a04e658c705386068aa Archived-At: Subject: [Spud] Thoughts on the privacy concerns expressed at the BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:00:15 -0000 --001a11493a04e658c705386068aa Content-Type: text/plain; charset=UTF-8 Following the BoF, I spoke with several folks who hummed "no" to the first question on privacy grounds. There were two main concerns I heard voiced: concrete issues with standardizing a mechanism for passing arbitrary metadata, and the more amorphous problem of the wise not being able to see all ends. The concrete concerns are straightforward to understand, even for those who don't agree: at least from my perspective, dismissals of the form "But they (operators, governments, etc.) can already add arbitrary metadata!" fail to take into account that an internet standard for adding arbitrary metadata to client requests makes it much easier for governments and others to coerce users into adding identifying information to every packet and know that it will survive end-to-end, and interoperate universally, over the entire internet and not just within the source networks. That means, for instance, not having to strip proprietary encapsulation at exchanges/peering points, or to build and maintain proprietary software and network hardware: this potentially creates a glide path to global user activity tracking, something I suspect most government officials would love to have. End-to-end survivability is a property that PLUS (probably?) needs if it is going to be useful, but is something we don't want for arbitrary extra-protocol metadata that may have nothing to do with traffic management or routing. A too-general mechanism is disqualifying on these grounds. To the second hum ("If scope were restricted to flow state semantics and multi-path, would that be agreeable?"), it's not clear to me how much of the objection comprised general resistance to giving any useful information to middle boxes to prevent ossification, versus to concerns that even those limited semantics could still be used to invade users' privacy (versus other concerns). While I am concerned about further ossification of the protocol stack, the latter issue is more troubling to me because the privacy implications of even a few bits of metadata are still unclear in this early stage of recognition of the existence of pervasive surveillance. We don't want to standardize something that turns out, for example, to be a side channel for identifying information when transmitted in large enough quantities. Mathematical/statistical guidance here would be particularly helpful. All that having been said, on the other side are concerns that if we don't standardize something the demand won't simply disappear: like NAT, refusal to cough up an acceptable official standard doesn't mean that a worse de facto standard won't emerge. It's not entirely clear to me how analogous the two situations are, or how likely this outcome is, but it is a valid concern. I am not firmly against PLUS, but I won't support any proposal that doesn't adequately address these issues. What I need is either a convincing argument that my privacy concerns are crap (however unlikely that seems now), or a protocol proposal narrowly-tailored enough that I'm convinced abuse won't be possible. Kyle --001a11493a04e658c705386068aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following the BoF, I spoke with several folks who hum= med "no" to the first question on privacy grounds. There were two= main concerns I heard voiced: concrete issues with standardizing a mechani= sm for passing arbitrary metadata, and the more amorphous problem of the wi= se not being able to see all ends.

The concrete concerns are s= traightforward to understand, even for those who don't agree: at least = from my perspective, dismissals of the form "But they (operators, gove= rnments, etc.) can already add arbitrary metadata!" fail to take into = account that an internet standard for adding arbitrary metadata to client r= equests makes it much easier for governments and others to coerce users int= o adding identifying information to every packet and know that it will surv= ive end-to-end, and interoperate universally, over the entire internet and = not just within the source networks.

That means, for instance, not h= aving to strip proprietary encapsulation at exchanges/peering points, or to= build and maintain proprietary software and network hardware: this potenti= ally creates a glide path to global user activity tracking, something I sus= pect most government officials would love to have. End-to-end survivability= is a=20 property that PLUS (probably?) needs if it is going to be useful, but is so= mething we don't want for=20 arbitrary extra-protocol metadata that may have nothing to do with=20 traffic management or routing. A too-general mechanism is disqualifying on = these grounds.

To the second hum ("If scope were restricted to flow state semantics and multi-path, woul= d that be agreeable?"), it's not clear to me how much of the objec= tion comprised general resistance to giving any useful information to middl= e boxes to prevent ossification, versus to concerns that even those limited= semantics could still be used to invade users' privacy (versus other c= oncerns). While I am concerned about further ossification of the protocol s= tack, the latter issue is more troubling to me because the privacy implicat= ions of even a few bits of metadata are still unclear in this early stage o= f recognition of the existence of pervasive surveillance. We don't want= to standardize something that turns out, for example, to be a side channel= for identifying information when transmitted in large enough quantities. M= athematical/statistical guidance here would be particularly helpful.
All that having been said, on the other= side are concerns that if we don't standardize something the demand wo= n't simply disappear: like NAT, refusal to cough up an acceptable offic= ial standard doesn't mean that a worse de facto standard won't emer= ge. It's not entirely clear to me how analogous the two situations are,= or how likely this outcome is, but it is a valid concern.
=

I am not firmly against PLUS, but I won't support any proposal= that doesn't adequately address these issues. What I need is either a convincing argument that my privacy concerns are crap (ho= wever unlikely that seems now), or a protocol proposal narrowly-tailored enough that I'm convinced=20 abuse won't be possible.

Kyle
--001a11493a04e658c705386068aa-- From nobody Mon Jul 25 03:49:37 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AF312D7A2 for ; Mon, 25 Jul 2016 03:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 hJB58due05eJ for ; Mon, 25 Jul 2016 03:49:33 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.113]) (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 4EB9F12D78F for ; Mon, 25 Jul 2016 03:49:32 -0700 (PDT) Received: from [193.109.254.3] by server-9.bemta-14.messagelabs.com id 91/D2-10182-BBEE5975; Mon, 25 Jul 2016 10:49:31 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRWlGSWpSXmKPExsVy+MWXVt1d76a GG3TdsrB4eGcqq8WL1z0sFosuPGW0eLl0K5sDi8eSJT+ZPGZ8+sLm8XfSQyaPd2sWMgewRLFm 5iXlVySwZuybtpmxYBNXxaTGScwNjFc4uhi5OIQE9jBKNL3eyQbhrGSUmLLsM5SznEnifPseR ghnE6PEj8cPmLsYOTnYBFwlju66ww5iiwh4S3S97WUDsZkFnCR2PzvJCmILCwRIHLl4lg2iJl Di4Zk9LBB2mMTSM/vBalgEVCWu/NoCZvMKhEo8m97EDrHsK5PEjNWtTCAJTgE7icczToPZjAK yEl8aVzNDLBOXuPVkPlhcQkBAYsme88wQtqjEy8f/WCFqdCQW7P4EdZy2xLKFr5khlglKnJz5 hGUCo+gsJKNmIWmZhaRlFpKWBYwsqxg1ilOLylKLdA2N9JKKMtMzSnITM3N0DQ1N9HJTi4sT0 1NzEpOK9ZLzczcxAmOOAQh2MJ6d5nyIUZKDSUmUd+KaqeFCfEn5KZUZicUZ8UWlOanFhxhlOD iUJHgb3wLlBItS01Mr0jJzgNEPk5bg4FES4fUFSfMWFyTmFmemQ6ROMSpKifMqgiQEQBIZpXl wbbCEc4lRVkqYlxHoECGegtSi3MwSVPlXjOIcjErCvMEgU3gy80rgpr8CWswEtHgBz2SQxSWJ CCmpBsaZl+RUbVIlb595sTnQb9eRlvXt/B3yr0qTH/xdL/pg6u/YGb8bJv+r/Mz79lq/TtO/3 zU7unutNTb0/WzYvWjb//877xjVevbOO9mbGSAsMNvJLVd54mm7y/0SXUpzNaImzmqe4RX65u ntfkmu6OydHutkf2a7bH9XLWTOHZvQvVCx/LmmHbsSS3FGoqEWc1FxIgDQ8BQ3MwMAAA== X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-5.tower-184.messagelabs.com!1469443770!32600956!1 X-Originating-IP: [195.232.244.133] X-StarScan-Received: X-StarScan-Version: 8.77; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12148 invoked from network); 25 Jul 2016 10:49:30 -0000 Received: from mailout01.vodafone.com (HELO mailout01.vodafone.com) (195.232.244.133) by server-5.tower-184.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 25 Jul 2016 10:49:30 -0000 Received: from mailint04.vodafone.com (mailint04.vodafone.com [195.232.244.201]) by mailout01.vodafone.com (Postfix) with ESMTP id 3rydL20sCvz2252; Mon, 25 Jul 2016 12:49:30 +0200 (CEST) Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailint04.vodafone.com (Postfix) with ESMTP id 3rydL15q19zfbyt; Mon, 25 Jul 2016 12:49:29 +0200 (CEST) Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 3rydL15jXLzfbyh; Mon, 25 Jul 2016 12:49:29 +0200 (CEST) Received: from VOEXM17W.internal.vodafone.com ([169.254.1.98]) by VOEXC04W.internal.vodafone.com ([145.230.101.24]) with mapi id 14.03.0224.002; Mon, 25 Jul 2016 12:49:29 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: "Eggert, Lars" , Mikael Abrahamsson Thread-Topic: [Spud] No. Operators don't need SPUD for mobile network management Thread-Index: AQHR417a6fHOussdkESy63TPP6D+eKAi2e8AgAADS4CAAAHZAIAAAWYAgAABnYCABhldgA== Date: Mon, 25 Jul 2016 10:49:28 +0000 Message-ID: References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Frode Kileng , "spud@ietf.org" Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 10:49:35 -0000 Another operator here: I like the notion of PLUS being used to hint to the= TCP sender regarding network radio cell conditions, i.e. mobile throughput= guidance[1]. So network information being sent out to help tune cwnd. For sender to network: If there are ways to safely indicate open/close, 'dr= op me/queue me when I hit congestion', and 'I am a retransmitted packet' th= en that would be of interest too. But I fully respect the privacy concerns = that were raised at the BoF, and would be happy to see a limited scope acco= rdingly. All best, Kevin Vodafone [1] https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput-guidanc= e/=20 -----Original Message----- From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: 21 July 2016 16:33 To: Mikael Abrahamsson Cc: Frode Kileng; spud@ietf.org Subject: Re: [Spud] No. Operators don't need SPUD for mobile network manage= ment On 2016-07-21, at 17:27, Mikael Abrahamsson wrote: > If there are no flags, I can't differentiate an incoming new connection I= nternet->UE (that I want to allow), from a backscatter packet (that I want = to drop). We probably have different opinions on how important it is for a firewall t= o be able to drop backscatter vs. the ability for an app to benefit from 0-= RTT. (Cue Lorenzo). Lars From nobody Mon Jul 25 09:19:01 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E23512B04D for ; Mon, 25 Jul 2016 09:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qz9D6a3Gkmjq for ; Mon, 25 Jul 2016 09:18:58 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 114D712D0E6 for ; Mon, 25 Jul 2016 09:18:58 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id l72so259335653oig.2 for ; Mon, 25 Jul 2016 09:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ve7Y9p+1RiUnP5AMOWlYZJtl8YDeLLeghNV+B7Ii28g=; b=qbXSWAftJ+BwE85FOE2UHbWsvA5+q9zUvvQEy/Wlc5ApiH8/4b+6s/eq0OkKgttvjP NcUXinW3Sl8EGNMzyuUgABj2BDIyL18Qs1fgY5ufX627hSoWI4AXxz6na3FwWWqlkrLw D2t0OCv7rJ/7hENrx7E9x8VVi9BfjktHaaaig7etJ9vAaD8uU8rROuoG1tXTNxE7jfa8 hKv/RXtPRRBZrPEshGlPVja+2qm4YPJYr+ByGC38HD9hH/+nBspXZOF3iz8oJzFLKiK3 KS7lIHVvdcGFgce5CB4ssccEYQYK3P9TL1z63Kl+t13vQnZqnMfUuqFtEXbkQRf+u/xq eVUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ve7Y9p+1RiUnP5AMOWlYZJtl8YDeLLeghNV+B7Ii28g=; b=T6UcEJOb3BYTMzclsHWuO8NGJZvsblxW6pBywpG1KAajNtsd/Ss9/x3QoaaZqwk6tS LpC+GBcHT9a8zO9bh/Xd/RvCNJjqT9EmoTLqA9d1nyEhQ2k+yIIUYSsFtY7xXpha8xCJ hkJ+uTiJ/2swpAxp/TUF9kPR0ytFfcLYsrV0bC4mlpTAiINX+RF7QfQo0rsIfRXxVZNw 6pJpo2VMbiOCcvknbAK2Re2BEcORisLvvKF67AKIjAIdx08bIZlEB1XKbPILhrqcEXF6 fxJkqmXcFCTVeVbipF0Ms9yNl1Bg8mozSgHVMl34SQ1Q1mcCYJdqKg3bOl1fict42H6I RPag== X-Gm-Message-State: AEkooutgycTRVZ9a6CH0c0kiA3KttQPPXwpK94//H991CGjEaKSweXjmAObQzDo/725dsoRdEn6O1AWd+L3hwg== X-Received: by 10.202.59.68 with SMTP id i65mr8703235oia.61.1469463537264; Mon, 25 Jul 2016 09:18:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.222.213 with HTTP; Mon, 25 Jul 2016 09:18:27 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Mon, 25 Jul 2016 09:18:27 -0700 Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=001a113cf36a2650150538782492 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Thoughts on the privacy concerns expressed at the BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 16:19:00 -0000 --001a113cf36a2650150538782492 Content-Type: text/plain; charset=UTF-8 Small comment in-line. On Sun, Jul 24, 2016 at 5:00 AM, Kyle Rose wrote: > Following the BoF, I spoke with several folks who hummed "no" to the first > question on privacy grounds. There were two main concerns I heard voiced: > concrete issues with standardizing a mechanism for passing arbitrary > metadata, and the more amorphous problem of the wise not being able to see > all ends. > > The concrete concerns are straightforward to understand, even for those > who don't agree: at least from my perspective, dismissals of the form "But > they (operators, governments, etc.) can already add arbitrary metadata!" > fail to take into account that an internet standard for adding arbitrary > metadata to client requests > The intent, at least of the proponents, was never to allow for arbitrary metadata. As Brian and Mirja mentioned in the BoF, the intent was to limit the values to those in an IANA registry, and to require standardization of values added to the registry. Of course, the IETF has no regulatory power and no protocol police, so there remains a risk; previous attempts to use IANA for enforcement have not all ended well. > makes it much easier for governments and others to coerce users into > adding identifying information to every packet and know that it will > survive end-to-end, and interoperate universally, over the entire internet > and not just within the source networks. > Again, as Brian pointed out, we are not talking about field lengths here that could serve this identifying function by themselves we are talking about field lengths sufficient for expressing a small number of signals to the path. > > That means, for instance, not having to strip proprietary encapsulation at > exchanges/peering points, or to build and maintain proprietary software and > network hardware: this potentially creates a glide path to global user > activity tracking, something I suspect most government officials would love > to have. End-to-end survivability is a property that PLUS (probably?) needs > if it is going to be useful, but is something we don't want for arbitrary > extra-protocol metadata that may have nothing to do with traffic management > or routing. A too-general mechanism is disqualifying on these grounds. > > I am not so sure that government officials want to have a system in which insertion is under the control of the end systems, which this proposes. Transparency to the end systems is one of the properties we are trying to achieve. It may not be enough, of course, but it should be noted. regards, Ted > To the second hum ("If scope were restricted to flow state semantics and > multi-path, would that be agreeable?"), it's not clear to me how much of > the objection comprised general resistance to giving any useful information > to middle boxes to prevent ossification, versus to concerns that even those > limited semantics could still be used to invade users' privacy (versus > other concerns). While I am concerned about further ossification of the > protocol stack, the latter issue is more troubling to me because the > privacy implications of even a few bits of metadata are still unclear in > this early stage of recognition of the existence of pervasive surveillance. > We don't want to standardize something that turns out, for example, to be a > side channel for identifying information when transmitted in large enough > quantities. Mathematical/statistical guidance here would be particularly > helpful. > > All that having been said, on the other side are concerns that if we don't > standardize something the demand won't simply disappear: like NAT, refusal > to cough up an acceptable official standard doesn't mean that a worse de > facto standard won't emerge. It's not entirely clear to me how analogous > the two situations are, or how likely this outcome is, but it is a valid > concern. > > I am not firmly against PLUS, but I won't support any proposal that > doesn't adequately address these issues. What I need is either a convincing > argument that my privacy concerns are crap (however unlikely that seems > now), or a protocol proposal narrowly-tailored enough that I'm convinced > abuse won't be possible. > > Kyle > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > > --001a113cf36a2650150538782492 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Small comment in-line.

On Sun, Jul 24, 2016 at 5:00= AM, Kyle Rose <krose@krose.org> wrote:
Following the BoF, I spoke with several folks who hummed &quo= t;no" to the first question on privacy grounds. There were two main co= ncerns I heard voiced: concrete issues with standardizing a mechanism for p= assing arbitrary metadata, and the more amorphous problem of the wise not b= eing able to see all ends.

The concrete concerns are straightf= orward to understand, even for those who don't agree: at least from my = perspective, dismissals of the form "But they (operators, governments,= etc.) can already add arbitrary metadata!" fail to take into account = that an internet standard for adding arbitrary metadata to client requests =

The intent, at least of the proponen= ts, was never to allow for arbitrary metadata.=C2=A0 As Brian and Mirja men= tioned in the BoF, the intent was to limit the values to those in an IANA r= egistry, and to require standardization of values added to the registry.=C2= =A0 Of course, the IETF has no regulatory power and no protocol police, so = there remains a risk; previous attempts to use IANA for enforcement have no= t all ended well.=C2=A0
=C2=A0
makes it much easier for governments and others to coerce user= s into adding identifying information to every packet and know that it will= survive end-to-end, and interoperate universally, over the entire internet= and not just within the source networks.

Again, as Brian pointed out, we are not talking about field length= s here that could serve this identifying function by themselves=C2=A0 we ar= e talking about field lengths sufficient for expressing a small number of s= ignals to the path.=C2=A0
=C2=A0

That means, for instance, not having to strip= proprietary encapsulation at exchanges/peering points, or to build and mai= ntain proprietary software and network hardware: this potentially creates a= glide path to global user activity tracking, something I suspect most gove= rnment officials would love to have. End-to-end survivability is a=20 property that PLUS (probably?) needs if it is going to be useful, but is so= mething we don't want for=20 arbitrary extra-protocol metadata that may have nothing to do with=20 traffic management or routing. A too-general mechanism is disqualifying on = these grounds.

<= div>I am not so sure that government officials want to have a system in whi= ch insertion is under the control of the end systems, which this proposes.= =C2=A0 Transparency to the end systems is one of the properties we are tryi= ng to achieve.=C2=A0 It may not be enough, of course, but it should be note= d.

regards,

Ted

=C2= =A0
To = the second hum ("If scope were restricted to flow state semantic= s and multi-path, would that be agreeable?"), it's not clear to me= how much of the objection comprised general resistance to giving any usefu= l information to middle boxes to prevent ossification, versus to concerns t= hat even those limited semantics could still be used to invade users' p= rivacy (versus other concerns). While I am concerned about further ossifica= tion of the protocol stack, the latter issue is more troubling to me becaus= e the privacy implications of even a few bits of metadata are still unclear= in this early stage of recognition of the existence of pervasive surveilla= nce. We don't want to standardize something that turns out, for example= , to be a side channel for identifying information when transmitted in larg= e enough quantities. Mathematical/statistical guidance here would be partic= ularly helpful.

All that having been said, o= n the other side are concerns that if we don't standardize something th= e demand won't simply disappear: like NAT, refusal to cough up an accep= table official standard doesn't mean that a worse de facto standard won= 't emerge. It's not entirely clear to me how analogous the two situ= ations are, or how likely this outcome is, but it is a valid concern.

I am not firmly against PLUS, but I won't support a= ny proposal that doesn't adequately address these issues. What I need is either a convincing argument that my privacy concerns are crap (ho= wever unlikely that seems now), or a protocol proposal narrowly-tailored enough that I'm convinced=20 abuse won't be possible.=

=
Kyle

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud


--001a113cf36a2650150538782492-- From nobody Mon Jul 25 13:20:34 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F41012D9EB for ; Mon, 25 Jul 2016 13:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 eBqj9Ntkr_ZB for ; Mon, 25 Jul 2016 13:20:30 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5525312D9EE for ; Mon, 25 Jul 2016 13:20:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 94065D930E; Mon, 25 Jul 2016 22:20:28 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eEdBPeaa6+Zj; Mon, 25 Jul 2016 22:20:28 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2F62.dip0.t-ipconnect.de [93.236.47.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 33DC8D930D; Mon, 25 Jul 2016 22:20:28 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 25 Jul 2016 22:20:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kyle Rose X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] Thoughts on the privacy concerns expressed at the BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 20:20:33 -0000 Hi Kyle, thanks for bring up this discussion again on the list and stating your = view point here. I think we really need some more discussion to come to = a common view point on what is possible today, where the problems are, = how we can improve today=E2=80=99s situation and how we can instruct = current and future protocol development in the IETF to address these = concern in a constructive manner. Please see further, more detailed = comments below. =20 > Am 24.07.2016 um 14:00 schrieb Kyle Rose : >=20 > Following the BoF, I spoke with several folks who hummed "no" to the = first question on privacy grounds. There were two main concerns I heard = voiced: concrete issues with standardizing a mechanism for passing = arbitrary metadata, and the more amorphous problem of the wise not being = able to see all ends. >=20 > The concrete concerns are straightforward to understand, even for = those who don't agree: at least from my perspective, dismissals of the = form "But they (operators, governments, etc.) can already add arbitrary = metadata!" fail to take into account that an internet standard for = adding arbitrary metadata to client requests makes it much easier for = governments and others to coerce users into adding identifying = information to every packet and know that it will survive end-to-end, = and interoperate universally, over the entire internet and not just = within the source networks. As mentioned by Ted, this is actually not what we propose. The mechanism = we propose is exposing information under endpoint control which is a = very important point here. The endpoint has to add an option to send (or = request) a specific bit of information (which also must be registered by = IANA with IESG approval). This is just the same as TCP options or IP = option headers. The only difference is that PLUS has a MAC which allows = detection of middlebox manipulation (which is not the case for other = existing protocols such as TCP options). This is another a very big and = important aspect of what we propose with PLUS as our goal is to encrypt = everything above PLUS including the TCP header and TCP options in = future. Especially encrypting TCP option is important because TCP = options provide much less control than what we propose with PLUS today = which is a problem (especially as currently still unto 90% of the = traffic is TCP). So I actually though we are on the same page here and = have a common goal.=20 As you probably know from tcpinc discussions it is today not possible to = just encrypt the whole TCP header because this will lead to huge = deployment problem (and incentive people to actively block encryption), = however, providing a replacement mechanism that actually gives the = control really back to the endpoint and provides the needed (not privacy = sensitive) information in the network is the goal here. (This also = enables protocol innovation again because at this point the network does = not need to know anymore which protocol is used, which makes it even = more save).=20 Of course this can be used to also add additional information that we = don=E2=80=99t have today in the TCP header (however, we can also define = new TCP options or IP headers or HTTP extension... and there are = existing bad examples=E2=80=A6 or just use them with out an RFC or = simply register an experimental TCP Option and use it forever and ship = products with it... or... or... or=E2=80=A6). However, the goals is to = provide information which can actually be used make the network work = better. Similar as some information that we are exposing today (such as = port numbers and/or timestamps), the information we are looking for = should in it self not be privacy sensitive and by using a new approach = for exposing we can even take additional care now to make sure this = information cannot be used in such a way (which is not the case for TCP = timestamps today as the clock used might identify the client). Designing = this now with a strong privacy awareness can also just improve the = situation compared to what we have right now. >=20 > That means, for instance, not having to strip proprietary = encapsulation at exchanges/peering points, or to build and maintain = proprietary software and network hardware: this potentially creates a = glide path to global user activity tracking, something I suspect most = government officials would love to have. End-to-end survivability is a = property that PLUS (probably?) needs if it is going to be useful, but is = something we don't want for arbitrary extra-protocol metadata that may = have nothing to do with traffic management or routing. A too-general = mechanism is disqualifying on these grounds. I=E2=80=99m not sure I understand this point fully because PLUS is an = end-to-end protocol (this is why we discuss it in the transport area) = and as today for all other traffic the packet length is limited by the = path MTU. So adding additional data, that is not requested by the = client, provides the same difficulties with the same solution that we = have or may not have today. Only that PLUS makes any unwanted mangling = detectable by the endpoint, which is usually not possible today. >=20 > To the second hum ("If scope were restricted to flow state semantics = and multi-path, would that be agreeable?"), it's not clear to me how = much of the objection comprised general resistance to giving any useful = information to middle boxes to prevent ossification Explicitly talking to middleboxes has two aspects: 1) Middleboxes do not = need to makes assumption about what the end-point is doing based on = random information that is visible, and 2) by providing these = information the service the network provides can actually be improved.=20= > , versus to concerns that even those limited semantics could still be = used to invade users' privacy (versus other concerns). None of the use cases we discuss in draft-kuehlewind-spud-use-cases = propose that privacy sensitive data should be exposed. I think there are = many good example where exposing information about traffic semantics and = characteristic on a high level that is useful for the network, is = possible and can help a lot, both the user experience and network = management.=20 We do understand from the BoF that the scope is not well enough defined = yet (mostly from other comments not related to privacy thought) and we = will work on this, probably by restricting the scope to an initially set = of use cases that provide the most deployment incentives, such as NAT = traversal and diagnosability. > While I am concerned about further ossification of the protocol stack, = the latter issue is more troubling to me because the privacy = implications of even a few bits of metadata are still unclear in this = early stage of recognition of the existence of pervasive surveillance. This argument is for me so high level that I think it can be used to = stop nearly all work in the IETF, at least all work in transport.=20 As I said in the beginning, I think we need to get a common = understanding here, and then work together on new protocols and = mechanisms. Just blocking work from the beginning seems rather = counter-productive to me. =20 > We don't want to standardize something that turns out, for example, to = be a side channel for identifying information when transmitted in large = enough quantities. Mathematical/statistical guidance here would be = particularly helpful. Today this is possible. TCP timestamps is a simple example. TCP = timestamps are an important tool for TCP, however, they are also used = for in network measurements (as they are visible). Would we have given = network operators a useful tool for measurements in the first place, = they would not need to misuse TCP timestamps. Would we have thought = about TCP timestamps in the first place such that they can not be used = as an identifier, we would not have this problem already today. Let=E2=80=99= s please fix this now! >=20 > All that having been said, on the other side are concerns that if we = don't standardize something the demand won't simply disappear: like NAT, = refusal to cough up an acceptable official standard doesn't mean that a = worse de facto standard won't emerge. It's not entirely clear to me how = analogous the two situations are, or how likely this outcome is, but it = is a valid concern. I really share this concern! >=20 > I am not firmly against PLUS, but I won't support any proposal that = doesn't adequately address these issues. What I need is either a = convincing argument that my privacy concerns are crap (however unlikely = that seems now), or a protocol proposal narrowly-tailored enough that = I'm convinced abuse won't be possible. These privacy concerns are not crap but the situation today is already = bad and we propose something that can actually improve the situation. I = don=E2=80=99t think there is a perfect solution, especially as it hard = to think about all bad ideas people might have in future. However, I = don=E2=80=99t think it=E2=80=99s the right way forward to use these = concerns to block needed work. Mirja >=20 > Kyle > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Tue Jul 26 06:47:49 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A7312DACE for ; Tue, 26 Jul 2016 06:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 lpxVWi5oRKXm for ; Tue, 26 Jul 2016 06:47:47 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A7A12DDB2 for ; Tue, 26 Jul 2016 06:34:18 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Tue, 26 Jul 2016 09:34:17 -0400 From: Dave Dolson To: "spud@ietf.org" Thread-Topic: Thoughts on monitoring a network of only UDP traffic Thread-Index: AdHnQmgJlLiAfPGVT1Gzv/XBTpMRpQ== Date: Tue, 26 Jul 2016 13:34:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E983104168Bwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [Spud] Thoughts on monitoring a network of only UDP traffic X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 13:47:48 -0000 --_000_E8355113905631478EFF04F5AA706E983104168Bwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Consider a thought experiment for the year 2025... - you are operating a network in a post-TCP world where PLUS and QUIC are s= tandard - all of the internet traffic is IP/UDP on arbitrary ports with encrypted p= ayload - you would like to know whether the network is functioning properly - does the network have enough capacity? - what latency are users/servers receiving? - is there a DDoS attack in progress? - are there rogue stack implementations that don't properly back off und= er congestion? Today in 2016 operators can measure the health of the network by at least t= hese methods: - TCP round-trip time, such as absolute time to complete aspects of the 3-w= ay handshake. - TCP packet loss and retransmission, measured by tracking sequence numbers - DNS response time (by correlating answers to queries) - various protocol-aware voice quality and video quality measures Even if you are using UDP protocols on the internet, you are benefiting fro= m the TCP measurements that are proxy for the overall quality. Of course none of these were designed (as far as I know) with this use in m= ind... If TCP is to be replaced, we need to think about how what an operator can u= se in place of the TCP measurements to assess network health. This is an opportunity to provide more explicit information to the network,= *designed* for operations, (and not necessarily the same information used = for end-point control.) - should end-points expose sequence numbers and/or explicit loss informatio= n? - should packets expose tokens that can be used to measure round-trip infor= mation? - should senders be permitted to expose authenticating information to assis= t DDoS scrubbing? - could senders expose something that is difficult to fake? - could there be a voluntary "debug mode" allowing network operators to col= lect a *lot* of information when users call the help desk? And in the PLUS spirit, these could be optional, provided enough other traf= fic contained this information to provide enough samples for the operator. Just as the presence of TCP allows all traffic to be managed, those exposin= g measurement information will benefit those that choose not to. Thinking along these lines makes me in favor of PLUS but not a PLUS that is= restricted to tube open/close. I think there is a great opportunity to improve *both* privacy and network = management. Of course I'm also curious to hear how others expect networks to be managed= in an all-UDP world. -Dave --_000_E8355113905631478EFF04F5AA706E983104168Bwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Consider a thought experiment for the year 2025̷= 0;

- you are operating a network in a post-TCP world wh= ere PLUS and QUIC are standard

- all of the internet traffic is IP/UDP on arbitrary= ports with encrypted payload

- you would like to know whether the network is func= tioning properly

   - does the network have enough capacity= ?

   - what latency are users/servers receiv= ing?

   - is there a DDoS attack in progress?

   - are there rogue stack implementations= that don’t properly back off under congestion?

 

Today in 2016 operators can measure the health of th= e network by at least these methods:

- TCP round-trip time, such as absolute time to comp= lete aspects of the 3-way handshake.

- TCP packet loss and retransmission, measured by tr= acking sequence numbers

- DNS response time (by correlating answers to queri= es)

- various protocol-aware voice quality and video qua= lity measures

 

Even if you are using UDP protocols on the internet,= you are benefiting from the TCP measurements that are proxy for the overal= l quality.

Of course none of these were designed (as far as I k= now) with this use in mind…

 

If TCP is to be replaced, we need to think about how= what an operator can use in place of the TCP measurements to assess networ= k health.

 

This is an opportunity to provide more explicit info= rmation to the network, *designed* for operations, (and not necessar= ily the same information used for end-point control.)

- should end-points expose sequence numbers and/or e= xplicit loss information?

- should packets expose tokens that can be used to m= easure round-trip information?

- should senders be permitted to expose authenticati= ng information to assist DDoS scrubbing?

   - could senders expose something that i= s difficult to fake?

- could there be a voluntary “debug mode”= ; allowing network operators to collect a *lot* of information when = users call the help desk?

 

And in the PLUS spirit, these could be optional, pro= vided enough other traffic contained this information to provide enough sam= ples for the operator.

Just as the presence of TCP allows all traffic to be= managed, those exposing measurement information will benefit those that ch= oose not to.

 

Thinking along these lines makes me in favor of PLUS= but not a PLUS that is restricted to tube open/close.

I think there is a great opportunity to improve *= both* privacy and network management.

 

Of course I’m also curious to hear how others = expect networks to be managed in an all-UDP world.

 

-Dave

 

 

 

--_000_E8355113905631478EFF04F5AA706E983104168Bwtlexchp2sandvi_-- From nobody Tue Jul 26 10:46:27 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553F612D882 for ; Tue, 26 Jul 2016 10:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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 oV6KW3U2SgwK for ; Tue, 26 Jul 2016 10:46:23 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0123.outbound.protection.outlook.com [104.47.38.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F5112D87F for ; Tue, 26 Jul 2016 10:46:20 -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=jyntoJmZFJx0SOp8KA9Fiao36Lr8r/XDIyBKDzjZ4N4=; b=KJOZYphBdthGRHXtNXqcsDvTaqIGxV1vMYR4UouVwWc8fn1LNtGc3IxyMyFYRDA9eqsYbmwgRva7cYpXJ7psDfQOGFUAkUxEd94PNjfswGP2R6+yYWGxEjSlH8olNavVlkE0lBKTqr9quD8yOIrM9GSmh9YZSPVYtRTBvaQ+B2Y= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Tue, 26 Jul 2016 17:46:17 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0549.016; Tue, 26 Jul 2016 17:46:17 +0000 From: Christian Huitema To: "Smith, Kevin, (R&D) Vodafone Group" , "Eggert, Lars" , Mikael Abrahamsson Thread-Topic: [Spud] No. Operators don't need SPUD for mobile network management Thread-Index: AQHR417XM+OLp574lU2NA11SMaga06Ai+3YAgAADS4CAAAHZAIAAAWYAgAABnYCABfoTAIACBBtg Date: Tue, 26 Jul 2016 17:46:17 +0000 Message-ID: References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:2::14d] x-ms-office365-filtering-correlation-id: 34c9559c-19a4-406c-5cca-08d3b57cbf41 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 6:QrevvIHvi3FlJcFkFFaC0GasRLXA8HdNsWsCNlBGkPLTg2Got41N7jDUMPaU5Ku0CGOMnxHzoDMBoLy7mpblWlceH90PfRbKLQZTStIpaelPoq1x5wF9jR6zIXTog2SSfnQFhiRQ+m0QzcBo+gTpLlP1k/YBwDcg3XagB98FOaLrNzq1UviAGcZm4ff7Pqe5i+4KgBZbfq1z5Xtpq7w/kJ8C1WCAVJIN0BU8yRIbSQ3im+KERzX/5R6uuyYGzFccY3zRKV2HYOYojtMuWVEwFgxv92g9fM0IxvtuCjxIaIBIZw3BCVcCx7rICtJw6YqwCVuNF1ASoRTbdQlvDvJVbQ==; 5:yxln3G7+Ii2Ber9XFPciwfOTj01t2flgD78W/kY1KMsFm19Unpi0MX8kpQRb1MyKby6WetMjSGHVNgq3zFV+P+48GnXOARPY0TbZwt4BO8jE1nLtRC45aowl8CGWhI28RSM+WA3JMiNQHGBTLDq1sQ==; 24:kjCHbgb/Wi+hjyccWAaUiofCDno7wNKGjZSXVd04r1wekxnZJSXVWrgswcgQPi/8ukpYsBzUEXM1Fef7GFQ2SS9JP0oMcn3QEwqqzoOeLdI=; 7:4FNI6qh3sXnRk9W4stXHNP4Vrl7bgNYY7Opx+olI28ucWOb4/+JErMSKhaDbbRicIrhmtnaFyEBFkI4jN7FgNIdvA4FUYjBTwBJcl5k0UlHF4ZAW0OWl30pCJ5qjN1xL5WzfvnsC5UXhzXskFardKRSX+FECOJMnd6BUdJqAYxgusZ8SZYEKXBO582NTaltgwyap4RHeolSwjdve6+/q3pCPbxSt8oWdjXq0e8xg1VujbfzU1JPEgwpWYTLE/4TJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(24454002)(189002)(377454003)(8936002)(81156014)(33656002)(81166006)(10400500002)(5005710100001)(10290500002)(8990500004)(5002640100001)(8666005)(189998001)(10090500001)(11100500001)(92566002)(68736007)(9686002)(586003)(6116002)(102836003)(93886004)(106116001)(2906002)(4326007)(105586002)(106356001)(87936001)(3280700002)(101416001)(2900100001)(74316002)(86612001)(2950100001)(5003600100003)(7696003)(7736002)(122556002)(3660700001)(7846002)(5001770100001)(97736004)(305945005)(76576001)(99286002)(86362001)(54356999)(50986999)(77096005)(76176999)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 17:46:17.7314 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654 Archived-At: Cc: Frode Kileng , "spud@ietf.org" Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 17:46:25 -0000 On Monday, July 25, 2016 3:49 AM, Kevin Smith wrote: >=20 > Another operator here: I like the notion of PLUS being used to hint to t= he TCP > sender regarding network radio cell conditions, i.e. mobile throughput > guidance[1]. So network information being sent out to help tune cwnd. Isn't that already available from the modem? > For sender to network: If there are ways to safely indicate open/close, '= drop > me/queue me when I hit congestion', and 'I am a retransmitted packet' the= n > that would be of interest too. But I fully respect the privacy concerns t= hat were > raised at the BoF, and would be happy to see a limited scope accordingly. We are most likely to get consensus on simple issues like DDOS prevention a= nd NAT traversal. The endpoints cannot really fight DDOS all by themselves,= the damage is already done by the time the packets reach them, so this is = certainly an area where there is a desire to collaborate. Currently the end= points keep sending "keep alive" traffic every 15 to 30 seconds to maintain= the state in the NAT and firewalls; finding something better would be nice= . -- Christian Huitema From nobody Tue Jul 26 12:50:54 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B74D12D177; Tue, 26 Jul 2016 12:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkEtOMJN51gC; Tue, 26 Jul 2016 12:50:51 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 3BE6312D59E; Tue, 26 Jul 2016 12:50:51 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id p74so16009684qka.0; Tue, 26 Jul 2016 12:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=qobuvECvGW1pRv/COT1zf79NXG70GczlWfN2b35423g=; b=XmYLHQaxfeq+RIorzAY2D2rzuuTtt3V0wN4xP5+Lm3MN0PQ8K0VKgLesVyvLK+aTb2 DUvaVhvyW4Y1Fdw8SIyHm7myDoRea5pZaZ7eo6I04m3V02ukESCxFU3AhPnHmqNwZsw8 Zw7mo1Ph8XfbqSmYLOHvfDZjN9gM58sAIvE59IRCVIGQZusrJTPXFlEA4QHiD4whu+fN FzZH1UXorUbOzMvo3VxIHZfasGIIxTqpCCP/u8s0AHjFZK1L35aePLkYvHFpWVLsFQvI 2QpS4MndxwFin7Rdqe1wpSecWZJ0Tj9OFQKzk1jccxV47bpL2vha/z4nnI0R6vFO/J69 eZPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=qobuvECvGW1pRv/COT1zf79NXG70GczlWfN2b35423g=; b=Il/0E6oaFRdxt1N0PeEqyxuKxWpTQ5abPNHgZTjEw/uMBqfPIHBnjlVSmnHjDYAMsP cIQ9OSPty5iqAH49J/NGalNGFPqmeogQMHV+mc8YrATBb1ETS0zCI5lvUfNR/WV4Gmd3 qDTQVcR4eWQugAXuKBixPkn0MpARby7oYHDr0P+QaB2vjv1kmVFGLV9rmxA2wEvjhZ81 +8wh3c/VRFp+VWe2NU5roDMMrogW1ZPG+3GIYbt0yHi5jrONTAvWU71QFRUnSJcq+hbG loLsvKcyAmu5PNzrNFmtWGppga39CIWdBk/OSM0PqXeujGXN1xcjdKSJq8eogMwn5kfW 1FBg== X-Gm-Message-State: AEkoout3RaEsWkGurCM9qFH8c3FPBZ30quu4RcvUfuSzgw9ZPe4GYspesKLJ6J6lRkFqCQ== X-Received: by 10.55.68.81 with SMTP id r78mr31937530qka.129.1469562650239; Tue, 26 Jul 2016 12:50:50 -0700 (PDT) Received: from bos-mpy2z.kendall.corp.akamai.com ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id c23sm1523413qtc.45.2016.07.26.12.50.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jul 2016 12:50:49 -0700 (PDT) From: Aaron Falk Content-Type: multipart/alternative; boundary="Apple-Mail=_FEEB3424-75B6-437E-AB14-6B8041FF9635" Date: Tue, 26 Jul 2016 15:50:49 -0400 Message-Id: To: spud Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: plus-chairs@ietf.org Subject: [Spud] draft PLUS BoF minutes posted X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 19:50:52 -0000 --Apple-Mail=_FEEB3424-75B6-437E-AB14-6B8041FF9635 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The notes from the PLUS BoF have been posted as draft minutes. Please = send substantive corrections to this list. Nits may be sent to the = chairs. https://www.ietf.org/proceedings/96/minutes/minutes-96-plus = =E2=80=94aaron & natasha= --Apple-Mail=_FEEB3424-75B6-437E-AB14-6B8041FF9635 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The notes from the PLUS BoF have been posted as draft = minutes.  Please send substantive corrections to this list. =  Nits may be sent to the chairs.

https://www.ietf.org/proceedings/96/minutes/minutes-96-plus=

=E2=80=94aaron = & natasha
= --Apple-Mail=_FEEB3424-75B6-437E-AB14-6B8041FF9635-- From nobody Tue Jul 26 15:49:33 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3628D12DB04 for ; Tue, 26 Jul 2016 15:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 A-Vu45TfShm9 for ; Tue, 26 Jul 2016 15:49:29 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 5252A12DAEF for ; Tue, 26 Jul 2016 15:49:29 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DD93A42CC6608; Tue, 26 Jul 2016 22:49:22 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6QMnP9U015742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jul 2016 22:49:26 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6QMnNiZ000791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Jul 2016 00:49:23 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.83]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 27 Jul 2016 00:49:23 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Christian Huitema , "Smith, Kevin, (R&D) Vodafone Group" , "Eggert, Lars" , "Mikael Abrahamsson" Thread-Topic: [Spud] No. Operators don't need SPUD for mobile network management Thread-Index: AQHR54/zoXiKg1xI4UGhZUReLwJPDw== Date: Tue, 26 Jul 2016 22:49:22 +0000 Message-ID: References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <622E12F5FEA7B04EB755ED20211CD2DE@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Frode Kileng , "spud@ietf.org" Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 22:49:31 -0000 On 26/07/2016 18:46, "Spud on behalf of Christian Huitema" wrote: >On Monday, July 25, 2016 3:49 AM, Kevin Smith wrote: >>=20 >> Another operator here: I like the notion of PLUS being used to hint to >>the TCP >> sender regarding network radio cell conditions, i.e. mobile throughput >> guidance[1]. So network information being sent out to help tune cwnd. > >Isn't that already available from the modem? No, the UE only knows about its perceived radio quality. The effective amount of transport blocks (i.e., instantaneous throughput) assigned to a given UE is decided by the base station, taking into account the state of all the attached devices. From nobody Tue Jul 26 20:05:05 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD6E12B04B for ; Tue, 26 Jul 2016 20:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 m9TyzQaP3pTq for ; Tue, 26 Jul 2016 20:05:02 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 9233112D9AF for ; Tue, 26 Jul 2016 20:05:02 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id u186so132931079ita.0 for ; Tue, 26 Jul 2016 20:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cn8+VRHXVmEeuNWgSWAwwYWF+ONcMUZ7GqeNYLSKV5M=; b=QaEVV0rsaxA9ID/Qg/pn9d40HsP8sx9XUyZHeTj5yoUqwTcohuQs8cUDkGyRe6+sfz Ky+eMRvrihXxycylwyIvHikho4QwQEfns2r1WiKegphQMmO/KuduYLhrwfDdrhdZapYt z9c2BVc2VxUMhknT6RXU/vx/gVyHGTNbE/TkeMDzNO6XFJo7JyfxPAcs+gSSV+BTMMQp PYjEft020hw9Au9rBQL9eBem0d008EDY9EvANYQGs1I3Y0+Bdb/+a9/TZ9Z7ntP6ASZC q9e6LiJj6GvysGNvJ8ws3vmne5KrWXTxGmJ5j8EKq5BLGFO1ulaGrAyUKNmoOXl69dAg piig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cn8+VRHXVmEeuNWgSWAwwYWF+ONcMUZ7GqeNYLSKV5M=; b=IiIQC/i4AL+eR9z6EcECzjxT10NXIEfqN9MpTrb42C9he+5aeRzP1JKIrJ2VZCk8fu 97piwjZct4MVNZ+Ui8jcPlLY7YUAMCVOW0ktfvuN9gUP3fzUVKMzhDFjYy4COL/7+7MS QF6KCZ6gKycB1C8e0hyXYJsFZQ0VY9xXQ2eJlIclOWzWIuKV8kO+5TQHjZ+f5moHumgh 6qjlRpvJlUXxg3PQD2TFCgKrus2rPz/jmE020UN1/jG5yid/YV5K6Z0iUCpWtk7zwNzJ Uq+MR1dPpy0+AfFwRqNMlFXvd0ETYf5fQVgKKk+sz8XITwOmp6w+iChIekN35dHBDh2b tj8w== X-Gm-Message-State: AEkoout7dtAvCNIFXABOBjstiJdUdyAGNLia1KM314/+cQVH3JLSI2xQ9+wHczX2IrG6i6crRaGxa7s/uRdV7w== X-Received: by 10.36.14.193 with SMTP id 184mr31445979ite.91.1469588701671; Tue, 26 Jul 2016 20:05:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Tue, 26 Jul 2016 20:05:00 -0700 (PDT) In-Reply-To: References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> From: Tom Herbert Date: Tue, 26 Jul 2016 20:05:00 -0700 Message-ID: To: "Smith, Kevin, (R&D) Vodafone Group" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Frode Kileng , "spud@ietf.org" , "Eggert, Lars" , Mikael Abrahamsson Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 03:05:04 -0000 On Mon, Jul 25, 2016 at 3:49 AM, Smith, Kevin, (R&D) Vodafone Group wrote: > Another operator here: I like the notion of PLUS being used to hint to the TCP sender regarding network radio cell conditions, i.e. mobile throughput guidance[1]. So network information being sent out to help tune cwnd. > I am not a big fan of having middleboxes purposely parsing an modifying TCP options, but I do like security considerations of mobile guidance and hope that PLUS might adopt some of the same concepts. Specifically: "The protocol specified in this document assumes that a trustful relationship between the Throughput Guidance Provider and the TCP server has been formed" and "Throughput guidance is considered confidential information" and "The identity of the Mobile Throughput Guidance provider that injects the throughput guidance header must be explicitly known to the endpoint receiving the information." Tom From nobody Tue Jul 26 23:34:35 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6048C12DD45 for ; Tue, 26 Jul 2016 23:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1KrczXudQZ-z for ; Tue, 26 Jul 2016 23:34:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 7EB4112DCF7 for ; Tue, 26 Jul 2016 23:34:31 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 46BBC2C0C6336; Wed, 27 Jul 2016 06:34:27 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6R6YSBe025606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2016 06:34:28 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6R6YRlo023552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Jul 2016 08:34:27 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.83]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 27 Jul 2016 08:34:27 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Tom Herbert , "Smith, Kevin, (R&D) Vodafone Group" Thread-Topic: [Spud] No. Operators don't need SPUD for mobile network management Thread-Index: AQHR59Dr+i1xEn5sN0mq+YBB2mmKsA== Date: Wed, 27 Jul 2016 06:34:26 +0000 Message-ID: References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C578D9A3107504B9392E8E441398382@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Frode Kileng , Mikael Abrahamsson , "Eggert, Lars" , "spud@ietf.org" Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 06:34:33 -0000 On 27/07/2016 04:05, "Spud on behalf of Tom Herbert" wrote: >On Mon, Jul 25, 2016 at 3:49 AM, Smith, Kevin, (R&D) Vodafone Group > wrote: >> Another operator here: I like the notion of PLUS being used to hint to >>the TCP sender regarding network radio cell conditions, i.e. mobile >>throughput guidance[1]. So network information being sent out to help >>tune cwnd. >> >I am not a big fan of having middleboxes purposely parsing an >modifying TCP options, but I do like security considerations of mobile >guidance and hope that PLUS might adopt some of the same concepts. >Specifically: > >"The protocol specified in this document assumes that a trustful >relationship between the Throughput Guidance Provider and the TCP >server has been formed" > >and > >"Throughput guidance is considered confidential information" > >and > >"The identity of the Mobile Throughput Guidance provider that injects >the throughput guidance header must be explicitly known to the >endpoint receiving the information." These security & privacy considerations are MTG-specific. If (as I do wish) MTG is ported to PLUS, MTG will have to define how security & privacy of its own vocabulary is achieved. Section 6.3 of draft-trammel-spud-reqs already has text that takes this scenario into consideration: [...] SPUD should support different levels of trust than the default ("untrusted, but presumed honest due to limitations on the signaling vocabulary") and fully-authenticated; From nobody Wed Jul 27 00:13:07 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2D312D1DA for ; Wed, 27 Jul 2016 00:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.322 X-Spam-Level: X-Spam-Status: No, score=-14.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Xc9SVevyOHMo for ; Wed, 27 Jul 2016 00:13:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC52A12D197 for ; Wed, 27 Jul 2016 00:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2132; q=dns/txt; s=iport; t=1469603584; x=1470813184; h=date:from:to:subject:message-id:mime-version; bh=vMM4aw0qx9S6cnnSHbCJ2yBPkatP0y0RsJFC2VMmh5E=; b=TZRFEiHr+aDdh6QWyaN3OZ3jGBvT0U6DXuQhkLZIat5e+XHGPsxi2Bij Tgy/3SfFx4bNMXq9uzq4UvcwQ2eC6ctTWYtC+Z/jNBqjLSsxxnH0g4eO0 O8RwvXrhhST0ZJqNpFLGh3mtjJ5/0b9bOEFFW+quuAixE15G/b227kFHS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAgDeXZhX/4cNJK1egz9WfAG2bYIPg?= =?us-ascii?q?X0khyg4FAEBAQEBAQFdHAuFChNaITQFSYhEDp0ZnUUBAQEBAQUBAQEBAQEBIIp?= =?us-ascii?q?3gUqCSBACAYNHgi8FjwqKJ4YYiFoKgWxOhAyIeZAlHjaEGBwyAYhAAQEB?= X-IronPort-AV: E=Sophos;i="5.28,428,1464652800"; d="scan'208";a="133983539" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jul 2016 07:13:04 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6R7D3QM013167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jul 2016 07:13:04 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6R7D35Y012038 for ; Wed, 27 Jul 2016 00:13:03 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6R7D39e012037 for spud@ietf.org; Wed, 27 Jul 2016 00:13:03 -0700 Date: Wed, 27 Jul 2016 00:13:03 -0700 From: Toerless Eckert To: "spud@ietf.org" Message-ID: <20160727071303.GC21039@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 07:13:06 -0000 Wrt to these mail threads: Is there any way how the process can be improved ? I think it's a frustrating waste of time to have proponents and opponents volunteer a lot of good or bad insight/opinions, but nothing of this gets put into persistent documentation (draft -> RFC). Or at worst only the folks who want a WG have the job have to try to figure out of to create something that persists and the opponents can just continue to reject those texts claiming they've not been included in the work. I think we are seeing so much controversy about the pro and cons of exposing various parts of the communication to the network path and/or modifying them in middleboxes, that we MUST have a WG that is at least capturing and structuring that discussion and making both sides contribute to the work of detailing the claims made and responding to the other side. Example: "government will abuse this". Ok, please explain in enough detail the most easily described, in your opinion most likely workflow how this would look like. And then lets describe if/how this compares with pre-existing alternatives for the government to achieve this (eg: tracking at app level). Or please explain how removing all options of observation does not cause regression on the ability to manage networks or even worse options of perpass (eg: http://queue.acm.org/detail.cfm?id=2904894 as pointed out before). And a lot more similar questions. It just does IMHO not make sense to ask these questions/have that discussion purely in email without an RFC target to put it in and both sides having ownership of the result. I am also concerned that without such written analsysis, its not even possible for ADs (or other readers) to technically vet any possible protocol constructive charter goals. Instead, its going to be a lot easier to just make decisions based on counting a rough mayority of opposition. But that would be rejecting work (for which there is a sufficient amount of interest) primarily based on a mayority of IMHO not technically well enough substantiated opposition. Cheers Toerless From nobody Wed Jul 27 01:12:14 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C0B12DD5B for ; Wed, 27 Jul 2016 01:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.907 X-Spam-Level: X-Spam-Status: No, score=-3.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 FTHcxEy84bUd for ; Wed, 27 Jul 2016 01:12:09 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B50912DD4D for ; Wed, 27 Jul 2016 01:12:08 -0700 (PDT) Received: from smtptc.telefonica.com (tgtim3c04.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C0F2188646; Wed, 27 Jul 2016 10:12:05 +0200 (CEST) Received: from ESTGVMSP110.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP110", Issuer "ESTGVMSP110" (not verified)) by smtptc.telefonica.com (Postfix) with ESMTPS id A740A88642; Wed, 27 Jul 2016 10:12:05 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.53) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 27 Jul 2016 10:12:03 +0200 Received: from AM4PR0601MB2161.eurprd06.prod.outlook.com (10.167.123.150) by AM4PR0601MB2164.eurprd06.prod.outlook.com (10.167.123.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 27 Jul 2016 08:12:01 +0000 Received: from AM4PR0601MB2161.eurprd06.prod.outlook.com ([10.167.123.150]) by AM4PR0601MB2161.eurprd06.prod.outlook.com ([10.167.123.150]) with mapi id 15.01.0549.014; Wed, 27 Jul 2016 08:12:01 +0000 From: "Diego R. Lopez" To: Toerless Eckert Thread-Topic: [Spud] No. Operators don't need SPUD for mobile network management Thread-Index: AQHR59ZQAZ9dSVphdk+nxEZCFW2nwaAr7WwA Date: Wed, 27 Jul 2016 08:12:01 +0000 Message-ID: <555AC66B-A749-4BC2-9BDF-F17BBCC10519@telefonica.com> References: <20160727071303.GC21039@cisco.com> In-Reply-To: <20160727071303.GC21039@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [88.29.212.221] x-ms-office365-filtering-correlation-id: 26175e5f-1bcd-43f4-8cd1-08d3b5f5aff3 x-microsoft-exchange-diagnostics: 1; AM4PR0601MB2164; 6:+Pbk9XhHVJW1J7pPFHf1e8ZW0wgvriKlCVPfHnD6Pyc5iYYzMjixtl4Ttd7GBoaGdSDsyfo5b6JwYwzZTksbIwj4YK5FzUehXEI4CZ8/5g/y5lxorHkP0qhIgl0l53B+k0ZbqKqoQDgYc6Hijt6uIDGa4YFubBD2Y78wN+6sR8GYOWp+TVvPfGp/t0jGrGejZaR+NlZlbuPuQFICUqeEPtQUUwb1EsH2CabdTYMqSQ+TBGMdVSukWgKTinJjByHCvZ2fNTp8fpeqdfGMdP1aRct9xS1VG1vsMwtRuXU8b7E=; 5:pgNQUXhRY01XKHpOwuaT9qIa5nxIqRUb3rU/sta8aOou9ZeEP1b0GZHilPKdyr+ixwsUcLbWKWSpU0evXaerUtbmvg0WoX35lHZJ4biwhsASQxOz9Ah2+zgYQOBo/RTxiy8MG53nZMyMfrB3mI4SbQ==; 24:ayvrakzjC9LrEdQDrWvdO0ZizTB0Mvy6nB2rwZXm0UTeh4P7VZR+EDZASf9/+93N9XfhWOEg3u3NuNVF6HVjY/hvqjcSN5Yh1uXfgpF9Iqw=; 7:yX6E2IZsf3Ea7t6wFx+8UMo3ZcXLAros/IXfOhhDUm7YiP4LuQkiYSAAj5BJ7ZmAyyIWadUd54qRbRHd6iBjxdhkEMA0iNoSGP/fw8Vyk13BUmmzNNDGd1iy/aZdVIivPwlePOYIebg3MV0HcqfxHBo17+wQy1P4N2eB5CvFxGPGl5jYxeVjc1vfm3jDCAmS32EFKVfh7E3XgNoPXP3v2mJ2CIg27ChZPHXRPcpIOnD+Qy1l3Lva4dUl8m69AMOm x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR0601MB2164; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006)(40392960112811)(271806183753584)(95692535739014)(155532106045638)(213716511872227); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM4PR0601MB2164; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0601MB2164; x-forefront-prvs: 0016DEFF96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(199003)(252514010)(24454002)(189002)(110136002)(36756003)(106116001)(106356001)(122556002)(10400500002)(87936001)(86362001)(105586002)(11100500001)(19617315012)(189998001)(97736004)(66066001)(81166006)(50986999)(8936002)(19580395003)(76176999)(19580405001)(68736007)(4326007)(81156014)(7846002)(2900100001)(101416001)(16236675004)(3660700001)(77096005)(3846002)(2906002)(15975445007)(5002640100001)(82746002)(7906003)(83716003)(33656002)(586003)(2950100001)(102836003)(7736002)(92566002)(6116002)(3280700002)(54356999)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR0601MB2164; H:AM4PR0601MB2161.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_555AC66BA7494BC29BDFF17BBCC10519telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2016 08:12:01.0518 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0601MB2164 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 08:12:12 -0000 --_000_555AC66BA7494BC29BDFF17BBCC10519telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree with Toerless here. There is a lot of arguments going back and fort= h and recording them in a structured way would (1) provide a very valuable = input for this and future discussions on this matter (that for sure will ha= ppen), and (2) avoid the kind of incomplete and/or emotionally loaded state= ments (like the one Toerless pointed) that are common in this kind of discu= ssions. Be goode, On 27 Jul 2016, at 09:13 , Toerless Eckert > wrote: Wrt to these mail threads: Is there any way how the process can be improved= ? I think it's a frustrating waste of time to have proponents and opponents volunteer a lot of good or bad insight/opinions, but nothing of this gets put into persistent documentation (draft -> RFC). Or at worst only the folks who want a WG have the job have to try to figure out of to create something that persists and the opponents can just continue to rejec= t those texts claiming they've not been included in the work. I think we are seeing so much controversy about the pro and cons of exposing various parts of the communication to the network path and/or modifying them in middleboxes, that we MUST have a WG that is at least capturing and structuring that discussion and making both sides contribute to the work of detailing the claims made and responding to the other side. Example: "government will abuse this". Ok, please explain in enough detail the most easily described, in your opinion most likely workflow how this wo= uld look like. And then lets describe if/how this compares with pre-existing alternatives for the government to achieve this (eg: tracking at app level)= . Or please explain how removing all options of observation does not cause regression on the ability to manage networks or even worse options of perpa= ss (eg: http://queue.acm.org/detail.cfm?id=3D2904894 as pointed out before). A= nd a lot more similar questions. It just does IMHO not make sense to ask these questions/have that discussio= n purely in email without an RFC target to put it in and both sides having ow= nership of the result. I am also concerned that without such written analsysis, its not even possible for ADs (or other readers) to technically vet any possible protoco= l constructive charter goals. Instead, its going to be a lot easier to just make decisions based on counting a rough mayority of opposition. But that would be rejecting wor= k (for which there is a sufficient amount of interest) primarily based on a m= ayority of IMHO not technically well enough substantiated opposition. Cheers Toerless _______________________________________________ Spud mailing list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_555AC66BA7494BC29BDFF17BBCC10519telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <35BB0C44E55F1940B7AD3C8B0186645A@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable I agree with Toerless here. There is a lot of arguments going back and fort= h and recording them in a structured way would (1) provide a very valuable = input for this and future discussions on this matter (that for sure will ha= ppen), and (2) avoid the kind of incomplete and/or emotionally loaded statements (like the one Toerless poi= nted) that are common in this kind of discussions.

Be goode,

On 27 Jul 2016, at 09:13 , Toerless Eckert <eckert@cisco.com> wrote:

Wrt to these mail threads: Is there any way how the process= can be improved ?

I think it's a frustrating waste of time to have proponents and opponents <= br class=3D""> volunteer a lot of good or bad insight/opinions, but nothing of this gets put into persistent documentation (draft -> RFC). Or at worst only the folks who want a WG have the job have to try to figure out of to
create something that persists and the opponents can just continue to rejec= t
those texts claiming they've not been included in the work.

I think we are seeing so much controversy about the pro and cons of
exposing various parts of the communication to the network path and/or
modifying them in middleboxes, that we MUST have a WG that is at
least capturing and structuring that discussion and making both sides
contribute to the work of detailing the claims made and responding to the other side.

Example: "government will abuse this". Ok, please explain in enou= gh detail
the most easily described, in your opinion most likely workflow how this wo= uld
look like. And then lets describe if/how this compares with pre-existing alternatives for the government to achieve this (eg: tracking at app level)= .
Or please explain how removing all options of observation does not cause regression on the ability to manage networks or even worse options of perpa= ss
(eg: ht= tp://queue.acm.org/detail.cfm?id=3D2904894 as pointed out before). And<= br class=3D""> a lot more similar questions.

It just does IMHO not make sense to ask these questions/have that discussio= n
purely in email without an RFC target to put it in and both sides having ow= nership
of the result.

I am also concerned that without such written analsysis, its not even
possible for ADs (or other readers) to technically vet any possible protoco= l
constructive charter goals.

Instead, its going to be a lot easier to just make decisions based
on counting a rough mayority of opposition. But that would be rejecting wor= k
(for which there is a sufficient amount of interest) primarily based on a m= ayority
of IMHO not technically well enough substantiated opposition.

Cheers
   Toerless

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.= es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_555AC66BA7494BC29BDFF17BBCC10519telefonicacom_-- From nobody Wed Jul 27 07:42:01 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDB112D914 for ; Wed, 27 Jul 2016 07:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 ympEFofCtr_8 for ; Wed, 27 Jul 2016 07:41:57 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 83F5712D913 for ; Wed, 27 Jul 2016 07:41:57 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id x25so30896349qtx.2 for ; Wed, 27 Jul 2016 07:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G9b2SIkzt80kGYC1oVKAz2vDn0wNhXzaOeYUu8kstI0=; b=YoE3ko+Ab4asoU1EJu65yNq//ahbs1OplWwNIBPKKjATLZYAxX4+WY26dzBSt/LRdv Xt5TGSDFL89iHaQezvAUR5M2/d/hGD58MJIEr/hP8UjjeD8ThZ1kRmE0EBC8NbFeFuua POOpbO9FvprZcExpBZXNowJqx8yaNNfH8BJno= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G9b2SIkzt80kGYC1oVKAz2vDn0wNhXzaOeYUu8kstI0=; b=N6yt5UeXpvwnTHCBoaOmKn+64V2iB3kNbssYHx9VXL5T0xAfjSsLKRGawmkmbqTZtf m4YlQl1lYZXUdv5UpjTeUZa2tnFKNEj7CAGDmaO8udaHpYIaP0k2RTvFvOICR+rL923o 5VGYhKsXX7jlDT1A65Rev9hBVDtQhwSf5r87GrselPNBsFB6wrfrDr23KuTO921Lawr4 A82OoZMrgNWMv86ohPXsCgbGJwjE/xqLk7Zw1c+J9tChQbgk7Ypno7m5sXO6NsF0uSH2 4eHog0uBv2s9g7FvROiw0RyhK32I4xeQjMniTYEpGpr3hzzJUFVRxaH4a6I+M5y8d0Gv vtUA== X-Gm-Message-State: AEkooutY9+DvCcQMKzfTNp7ojgdPM86pWTYlF1WJTupD26eBPTil38u78kMSFZj9SqDuTS7rGbJ5E5vZNUDEog== X-Received: by 10.237.36.38 with SMTP id r35mr49676663qtc.3.1469630516533; Wed, 27 Jul 2016 07:41:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.94.70 with HTTP; Wed, 27 Jul 2016 07:41:55 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: From: Kyle Rose Date: Wed, 27 Jul 2016 10:41:55 -0400 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=001a113d3aace3f53c05389f0413 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Thoughts on the privacy concerns expressed at the BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 14:42:00 -0000 --001a113d3aace3f53c05389f0413 Content-Type: text/plain; charset=UTF-8 (Forgot to respond to all.) On Mon, Jul 25, 2016 at 12:18 PM, Ted Hardie wrote: > Again, as Brian pointed out, we are not talking about field lengths here > that could serve this identifying function by themselves we are talking > about field lengths sufficient for expressing a small number of signals to > the path. > I think part of my hesitation results from my inability to think of any way to express this in a meaningful way in the charter. The draft charter says: q( Endpoint verification of signaling integrity, careful design of minimal data structures, and restrictive policies for registration of signals can help to meet this goal. ) and refers to Mirja's use cases document, but provides no explicit guidance around what "minimal" means in an absolute sense, not with respect to an individual use case . And I'm not sure it can or should get any more specific (it is a charter, after all, not a technical draft or protocol proposal), which leads to a dilemma: by not being more explicitly limiting about total information per packet, are we setting ourselves up for a situation in which the WG subordinates privacy to other goals and produces and successfully deploys something too expressive, some time after which users and governments end up in a game of chicken (idiom: driving two cars toward each other at high speed, with the first driver to veer off the loser) when some government bets that access to content is worth more than the end-to-end integrity protection mandated by PLUS, leading it to hijacking a valid PLUS field without endpoint cooperation, essentially telling users "If you want access, you need to turn off integrity protection"? Seems far-fetched now, but it takes only a critical mass of impairment before users are required to comply just to interoperate: it doesn't even have to result from laws in one's own country. Pretty sure this shouldn't be addressed in the charter as a specific number of bits, but I think you'd resolve a lot of fears of abuse by somehow constraining the field space and the number of fields per-packet. (The amount of data implied by "In-Band Measurement" jumped out at me as problematic, for example.) And yeah, I get that this directly implies additional potential for ossification. There are a huge number of tradeoffs here, and there's no way to know we've made the right ones until long after the decision has been made, but can we look at the proposed use cases and decide which need to coexist in a single packet, and which maybe expose too much space? The other side of this (what can PLUS do *for* privacy?) I'll address in my response to Mirja. Kyle --001a113d3aace3f53c05389f0413 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Forgot to respond to all.)

On Mon, Jul 2= 5, 2016 at 12:18 PM, Ted Hardie <ted.ietf@gmail.com> wrote:=
Again, as Brian pointed out, we are not talking about field lengt= hs here that could serve this identifying function by themselves=C2=A0 we a= re talking about field lengths sufficient for expressing a small number of = signals to the path.=C2=A0

I think part of my hesitation results f= rom my inability to think of any way to express this in a meaningful way in the charter. The draft=20 charter says:

q( Endpoint verification of signaling=20 integrity, careful design of minimal data structures, and restrictive=20 policies for registration of signals can help to meet this goal. )

<= /div>
and refers to Mirja's use cases document, but provides no explicit guidanc= e around what "minimal" means in an absolute sense, not with respe= ct to=20 an individual use case . And I'm not sure it can or should get any more= =20 specific (it is a charter, after all, not a technical draft or protocol=20 proposal), which leads to a dilemma: by not being more explicitly=20 limiting about total information per packet, are we setting ourselves up for a situation in which the WG subordinates privacy to other goals and produces and successfully deploys something too expressive, some time=20 after which users and governments end up in a game of chicken (idiom:=20 driving two cars toward each other at high speed, with the first driver=20 to veer off the loser) when some government bets that access to content=20 is worth more than the end-to-end integrity protection mandated by PLUS, leading it to hijacking a valid PLUS field without endpoint=20 cooperation, essentially telling users "If you want access, you need t= o=20 turn off integrity protection"? Seems far-fetched now, but it takes on= ly a critical mass of impairment before users are required to comply just=20 to interoperate: it doesn't even have to result from laws in one's = own=20 country.

Pretty sure this shouldn't be=20 addressed in the charter as a specific number of bits, but I think you'= d resolve a lot of fears of abuse by somehow constraining the field space and the number of fields per-packet. (The amount of data implied by=20 "In-Band Measurement" jumped out at me as problematic, for exampl= e.) And yeah, I get that this directly implies additional potential for=20 ossification. There are a huge number of tradeoffs here, and there's no= =20 way to know we've made the right ones until long after the decision has= =20 been made, but can we look at the proposed use cases and decide which=20 need to coexist in a single packet, and which maybe expose too much=20 space?

The other side of this (what can PLUS do *fo= r* privacy?) I'll address in my response to Mirja.

Kyle
--001a113d3aace3f53c05389f0413-- From nobody Wed Jul 27 07:48:38 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F5112DAD0 for ; Wed, 27 Jul 2016 07:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 loSwkcseD5tp for ; Wed, 27 Jul 2016 07:48:29 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 C5C7B12D85A for ; Wed, 27 Jul 2016 07:48:28 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id s63so36183698qkb.2 for ; Wed, 27 Jul 2016 07:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eevFpP3gE2qFBVyyA1i0VZ8M/h2G/lopzmzC56oC/6s=; b=X0EDlWx3G8gghWc6rQv0lhp455fKfOzkz+CQtlhRSIQq4cQFjOL8JHiSLgNFI6cBnf +XnO024fbM8UARdUJ09rs82K+Q7KzbOzRBT7IvQ+ww9Xt5VBUrTjgooDmsQbc/OKYF13 CYtJC2qJ8PY+eCNPPEx5v69qX8sD1chKj/0Io= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eevFpP3gE2qFBVyyA1i0VZ8M/h2G/lopzmzC56oC/6s=; b=Kb3L1XtUYAB8uxPeohXBm78w9AhumkgbI2nFPJP2S+IIxdjZfFrrcbKAQM4UQT26ZW ORlSxKfRe/kThqLRtKMykK/8hHBf3E2qnG/rtrCLG5oF/3xNRXiB5ZMDxEnOFDQe1jH9 MFrO7hKyqXLhhge2FKnd1sT4fEo2mnHEh1ykvS/bzzvsLzRWkEDyA/2O9tak3SHtNSKz 94umz/ICVWz+vjtMf715SkpKUH8NLvxIBN41BstUsIrJmnBV8iQsziO3zmTVh1Z6I59M vwt5lFOOstBFGTREHH4InQauIY4yT0zGTsxM1y58xXynNGrVjwjfZ4+LoHwNMGmscGWs tR8A== X-Gm-Message-State: AEkoouv9qyRVR4YrXSWlxyPTYI2hYsHMG/UhFqEHwTuw1U2zvez896Xz8Iq5u2NGk7jDtDBK1Pws8axFX52vCg== X-Received: by 10.55.70.22 with SMTP id t22mr35501301qka.171.1469630907888; Wed, 27 Jul 2016 07:48:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.94.70 with HTTP; Wed, 27 Jul 2016 07:48:27 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: From: Kyle Rose Date: Wed, 27 Jul 2016 10:48:27 -0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a114ab99c3764ec05389f1c9f Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] Thoughts on the privacy concerns expressed at the BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 14:48:37 -0000 --001a114ab99c3764ec05389f1c9f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 25, 2016 at 4:20 PM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > As mentioned by Ted, this is actually not what we propose. The mechanism > we propose is exposing information under endpoint control which is a very > important point here. The endpoint has to add an option to send (or > request) a specific bit of information (which also must be registered by > IANA with IESG approval). This is just the same as TCP options or IP opti= on > headers. The only difference is that PLUS has a MAC which allows detectio= n > of middlebox manipulation (which is not the case for other existing > protocols such as TCP options). This is another a very big and important > aspect of what we propose with PLUS as our goal is to encrypt everything > above PLUS including the TCP header and TCP options in future. Especially > encrypting TCP option is important because TCP options provide much less > control than what we propose with PLUS today which is a problem (especial= ly > as currently still unto 90% of the traffic is TCP). So I actually though = we > are on the same page here and have a common goal. > > As you probably know from tcpinc discussions it is today not possible to > just encrypt the whole TCP header because this will lead to huge deployme= nt > problem (and incentive people to actively block encryption), however, > providing a replacement mechanism that actually gives the control really > back to the endpoint and provides the needed (not privacy sensitive) > information in the network is the goal here. (This also enables protocol > innovation again because at this point the network does not need to know > anymore which protocol is used, which makes it even more save). > > Of course this can be used to also add additional information that we > don=E2=80=99t have today in the TCP header (however, we can also define n= ew TCP > options or IP headers or HTTP extension... and there are existing bad > examples=E2=80=A6 or just use them with out an RFC or simply register an > experimental TCP Option and use it forever and ship products with it... > or... or... or=E2=80=A6). However, the goals is to provide information wh= ich can > actually be used make the network work better. Similar as some informatio= n > that we are exposing today (such as port numbers and/or timestamps), the > information we are looking for should in it self not be privacy sensitive > and by using a new approach for exposing we can even take additional care > now to make sure this information cannot be used in such a way (which is > not the case for TCP timestamps today as the clock used might identify th= e > client). Designing this now with a strong privacy awareness can also just > improve the situation compared to what we have right now. > I totally buy the positives here, and I think maybe more language pitching and justifying this as at-worst an even trade of privacy concerns by removing some existing, completely-unprotected covert/side channels and replacing them with only exactly what the path needs to know (humbly, from our always limited technical perspective) in order to manage flows in a world in which the entire internet is running over UDP is part of what is missing from the proposed charter. I had a long talk about my post with Aaron Falk on Monday, and as a result of that conversation I became hopeful that much more information about data flows could be obscured in a PLUS-enabled internet than is possible today, perhaps even to the point of obscuring source addresses and making flows and maybe even individual packets to busy endpoints hard to correlate without tap points at every router on the internet doing collective traffic analysis. That's a long way off, but that is a future many would like to see. "We don't think this has any additional privacy impact" is a much weaker statement than "This can be the foundation for much greater privacy of metadata, not just of payload", and is more prone to FUD because it puts you on a defensive footing against many possible (and vague) lines of attack, and the burden of proof is always on those proposing changes. Thinking ahead to what we want the internet to look like in 20 years is a prerequisite to making sure that what we're doing lays just enough groundwork to make that possible, and is something that I think many privacy advocates could get on board with. (I do also want to add that I recognize a bit of cognitive dissonance in myself, as I've repeatedly expressed skepticism about adding real privacy at the routing layers on the public internet, versus private networks on top of that, like TOR. That said, the antecedents of that skepticism may not be true in a 2036 internet, so systematically strengthening the desirable properties of the internet's foundations is likely not to be wasted work, as long as we have a reasonable idea of where we're headed.) Kyle --001a114ab99c3764ec05389f1c9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 25, 2016 at 4:20 PM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
As mentioned by Ted, this is actually not what we propose. The mechanis= m we propose is exposing information under endpoint control which is a very= important point here. The endpoint has to add an option to send (or reques= t) a specific bit of information (which also must be registered by IANA wit= h IESG approval). This is just the same as TCP options or IP option headers= . The only difference is that PLUS has a MAC which allows detection of midd= lebox manipulation (which is not the case for other existing protocols such= as TCP options). This is another a very big and important aspect of what w= e propose with PLUS as our goal is to encrypt everything above PLUS includi= ng the TCP header and TCP options in future. Especially encrypting TCP opti= on is important because TCP options provide much less control than what we = propose with PLUS today which is a problem (especially as currently still u= nto 90% of the traffic is TCP). So I actually though we are on the same pag= e here and have a common goal.

As you probably know from tcpinc discussions it is today not possible to ju= st encrypt the whole TCP header because this will lead to huge deployment p= roblem (and incentive people to actively block encryption), however, provid= ing a replacement mechanism that actually gives the control really back to = the endpoint and provides the needed (not privacy sensitive) information in= the network is the goal here. (This also enables protocol innovation again= because at this point the network does not need to know anymore which prot= ocol is used, which makes it even more save).

Of course this can be used to also add additional information that we don= =E2=80=99t have today in the TCP header (however, we can also define new TC= P options or IP headers or HTTP extension... and there are existing bad exa= mples=E2=80=A6 or just use them with out an RFC or simply register an exper= imental TCP Option and use it forever and ship products with it... or... or= ... or=E2=80=A6). However, the goals is to provide information which can ac= tually be used make the network work better. Similar as some information th= at we are exposing today (such as port numbers and/or timestamps), the info= rmation we are looking for should in it self not be privacy sensitive and b= y using a new approach for exposing we can even take additional care now to= make sure this information cannot be used in such a way (which is not the = case for TCP timestamps today as the clock used might identify the client).= Designing this now with a strong privacy awareness can also just improve t= he situation compared to what we have right now.

<= /div>
I totally buy the positives here, and I think maybe more language= pitching and justifying this as at-worst an even trade of privacy concerns= by removing some existing, completely-unprotected covert/side channels and= replacing them with only exactly what the path needs to know (humbly, from= our always limited technical perspective) in order to manage flows in a wo= rld in which the entire internet is running over UDP is part of what is mis= sing from the proposed charter.

I had a long talk about m= y post with Aaron Falk on Monday, and as a result of that conversation I be= came hopeful that much more information about data flows could be obscured = in a PLUS-enabled internet than is possible today, perhaps even to the poin= t of obscuring source addresses and making flows and maybe even individual = packets to busy endpoints hard to correlate without tap points at every rou= ter on the internet doing collective traffic analysis. That's a long wa= y off, but that is a future many would like to see.

"= ;We don't think this has any additional privacy impact" is a much = weaker statement than "This can be the foundation for much greater pri= vacy of metadata, not just of payload", and is more prone to FUD becau= se it puts you on a defensive footing against many possible (and vague) lin= es of attack, and the burden of proof is always on those proposing changes.= Thinking ahead to what we want the internet to look like in 20 years is a = prerequisite to making sure that what we're doing lays just enough grou= ndwork to make that possible, and is something that I think many privacy ad= vocates could get on board with.

(I do also want to add t= hat I recognize a bit of cognitive dissonance in myself, as I've repeat= edly expressed skepticism about adding real privacy at the routing layers o= n the public internet, versus private networks on top of that, like TOR. Th= at said, the antecedents of that skepticism may not be true in a 2036 inter= net, so systematically strengthening the desirable properties of the intern= et's foundations is likely not to be wasted work, as long as we have a = reasonable idea of where we're headed.)

Kyle
--001a114ab99c3764ec05389f1c9f-- From nobody Wed Jul 27 13:38:17 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC6812D8E2 for ; Wed, 27 Jul 2016 13:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=no 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 J2kNHCURSfGV for ; Wed, 27 Jul 2016 13:38:14 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE0C12D935 for ; Wed, 27 Jul 2016 13:31:02 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0294.000; Wed, 27 Jul 2016 16:31:01 -0400 From: Dave Dolson To: Kyle Rose , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [Spud] Thoughts on the privacy concerns expressed at the BoF Thread-Index: AQHR5aL1133o2aIqhUudmizaaMH5m6Ap276AgALH54CAABFdEA== Date: Wed, 27 Jul 2016 20:31:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9831044800wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Thoughts on the privacy concerns expressed at the BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 20:38:16 -0000 --_000_E8355113905631478EFF04F5AA706E9831044800wtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S3lsZSBSb3NlIHNhaWQ6DQrigJzigKZJIGJlY2FtZSBob3BlZnVsIHRoYXQgbXVjaCBtb3JlIGlu Zm9ybWF0aW9uIGFib3V0IGRhdGEgZmxvd3MgY291bGQgYmUgb2JzY3VyZWQgaW4gYSBQTFVTLWVu YWJsZWQgaW50ZXJuZXQgdGhhbiBpcyBwb3NzaWJsZSB0b2RheSwgcGVyaGFwcyBldmVuIHRvIHRo ZSBwb2ludCBvZiBvYnNjdXJpbmcgc291cmNlIGFkZHJlc3NlcyBhbmQgbWFraW5nIGZsb3dzIGFu ZCBtYXliZSBldmVuIGluZGl2aWR1YWwgcGFja2V0cyB0byBidXN5IGVuZHBvaW50cyBoYXJkIHRv IGNvcnJlbGF0ZeKApuKAnQ0KDQpUaGUgYWJpbGl0eSB0byBvYnNjdXJlIHNvdXJjZSBhZGRyZXNz ZXMgb3BlbnMgYSBodWdlIGF0dGFjayBzdXJmYWNlIGZvciBERG9TIGF0dGFja3MsIHNpbmNlIHRo ZXJlIGlzIG5vIHdheSB0byBpbXBsZW1lbnQgQkNQIDM4IChOZXR3b3JrIEluZ3Jlc3MgRmlsdGVy aW5nKS4NCg0KRnVydGhlcm1vcmUsIHRvIG15IGtub3dsZWRnZSwgRERvUyBhdHRhY2tzIGFyZSBt b3N0IGVmZmVjdGl2ZWx5IHNjcnViYmVkIHByZWNpc2VseSBieSBjb3JyZWxhdGluZyBpbmJvdW5k IHBhY2tldHMgd2l0aCBvdXRib3VuZCBwYWNrZXRzIHRoYXQgYXJlIGV2aWRlbmNlIHRoZSBwcm90 ZWN0ZWQgc2VydmljZSBkZXNpcmVzIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIHNlbmRlci4NCihJ IHN1cHBvc2UgYSBzY3J1YmJlciBjb3VsZCBzaW1wbHkgZGlzY2FyZCBtb3N0IHNvdXJjZS1vYnNj dXJlZCB0cmFmZmljLikNCg0KUHJpdmFjeSBpcyBvbmUgc2lkZSBvZiBzZWN1cml0eSwgYnV0IHRo ZSBhYmlsaXR5IHRvIHJlc2lzdCBhdHRhY2tzIGlzIGFub3RoZXIgaW1wb3J0YW50IGFzcGVjdC4g QXMgZmFyIGFzIEkga25vdywgbm8gb25lIGhhcyBmaWd1cmVkIG91dCBob3cgdG8gbWl0aWdhdGUg RERvUyBhdHRhY2tzIGF0IHRoZSByZWNlaXZpbmcgZW5kLXBvaW50Lg0KDQpJ4oCZbSBob3Bpbmcg dGhpcyBncm91cCBjYW4gYXQgbGVhc3QgYWdyZWUgdGhhdCBtaXRpZ2F0aW5nIEREb1MgYXR0YWNr cyBpcyBhIGxlZ2l0aW1hdGUgcm9sZSBvZiBkZXZpY2VzIGluIHRoZSBuZXR3b3JrLg0KDQoNCi1E YXZlDQoNCg0KDQpGcm9tOiBTcHVkIFttYWlsdG86c3B1ZC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgS3lsZSBSb3NlDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjcsIDIwMTYgMTA6NDgg QU0NClRvOiBNaXJqYSBLw7xobGV3aW5kDQpDYzogc3B1ZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtTcHVkXSBUaG91Z2h0cyBvbiB0aGUgcHJpdmFjeSBjb25jZXJucyBleHByZXNzZWQgYXQgdGhl IEJvRg0KDQpPbiBNb24sIEp1bCAyNSwgMjAxNiBhdCA0OjIwIFBNLCBNaXJqYSBLw7xobGV3aW5k IDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPG1haWx0bzptaXJqYS5rdWVobGV3aW5k QHRpay5lZS5ldGh6LmNoPj4gd3JvdGU6DQpBcyBtZW50aW9uZWQgYnkgVGVkLCB0aGlzIGlzIGFj dHVhbGx5IG5vdCB3aGF0IHdlIHByb3Bvc2UuIFRoZSBtZWNoYW5pc20gd2UgcHJvcG9zZSBpcyBl eHBvc2luZyBpbmZvcm1hdGlvbiB1bmRlciBlbmRwb2ludCBjb250cm9sIHdoaWNoIGlzIGEgdmVy eSBpbXBvcnRhbnQgcG9pbnQgaGVyZS4gVGhlIGVuZHBvaW50IGhhcyB0byBhZGQgYW4gb3B0aW9u IHRvIHNlbmQgKG9yIHJlcXVlc3QpIGEgc3BlY2lmaWMgYml0IG9mIGluZm9ybWF0aW9uICh3aGlj aCBhbHNvIG11c3QgYmUgcmVnaXN0ZXJlZCBieSBJQU5BIHdpdGggSUVTRyBhcHByb3ZhbCkuIFRo aXMgaXMganVzdCB0aGUgc2FtZSBhcyBUQ1Agb3B0aW9ucyBvciBJUCBvcHRpb24gaGVhZGVycy4g VGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0aGF0IFBMVVMgaGFzIGEgTUFDIHdoaWNoIGFsbG93cyBk ZXRlY3Rpb24gb2YgbWlkZGxlYm94IG1hbmlwdWxhdGlvbiAod2hpY2ggaXMgbm90IHRoZSBjYXNl IGZvciBvdGhlciBleGlzdGluZyBwcm90b2NvbHMgc3VjaCBhcyBUQ1Agb3B0aW9ucykuIFRoaXMg aXMgYW5vdGhlciBhIHZlcnkgYmlnIGFuZCBpbXBvcnRhbnQgYXNwZWN0IG9mIHdoYXQgd2UgcHJv cG9zZSB3aXRoIFBMVVMgYXMgb3VyIGdvYWwgaXMgdG8gZW5jcnlwdCBldmVyeXRoaW5nIGFib3Zl IFBMVVMgaW5jbHVkaW5nIHRoZSBUQ1AgaGVhZGVyIGFuZCBUQ1Agb3B0aW9ucyBpbiBmdXR1cmUu IEVzcGVjaWFsbHkgZW5jcnlwdGluZyBUQ1Agb3B0aW9uIGlzIGltcG9ydGFudCBiZWNhdXNlIFRD UCBvcHRpb25zIHByb3ZpZGUgbXVjaCBsZXNzIGNvbnRyb2wgdGhhbiB3aGF0IHdlIHByb3Bvc2Ug d2l0aCBQTFVTIHRvZGF5IHdoaWNoIGlzIGEgcHJvYmxlbSAoZXNwZWNpYWxseSBhcyBjdXJyZW50 bHkgc3RpbGwgdW50byA5MCUgb2YgdGhlIHRyYWZmaWMgaXMgVENQKS4gU28gSSBhY3R1YWxseSB0 aG91Z2ggd2UgYXJlIG9uIHRoZSBzYW1lIHBhZ2UgaGVyZSBhbmQgaGF2ZSBhIGNvbW1vbiBnb2Fs Lg0KDQpBcyB5b3UgcHJvYmFibHkga25vdyBmcm9tIHRjcGluYyBkaXNjdXNzaW9ucyBpdCBpcyB0 b2RheSBub3QgcG9zc2libGUgdG8ganVzdCBlbmNyeXB0IHRoZSB3aG9sZSBUQ1AgaGVhZGVyIGJl Y2F1c2UgdGhpcyB3aWxsIGxlYWQgdG8gaHVnZSBkZXBsb3ltZW50IHByb2JsZW0gKGFuZCBpbmNl bnRpdmUgcGVvcGxlIHRvIGFjdGl2ZWx5IGJsb2NrIGVuY3J5cHRpb24pLCBob3dldmVyLCBwcm92 aWRpbmcgYSByZXBsYWNlbWVudCBtZWNoYW5pc20gdGhhdCBhY3R1YWxseSBnaXZlcyB0aGUgY29u dHJvbCByZWFsbHkgYmFjayB0byB0aGUgZW5kcG9pbnQgYW5kIHByb3ZpZGVzIHRoZSBuZWVkZWQg KG5vdCBwcml2YWN5IHNlbnNpdGl2ZSkgaW5mb3JtYXRpb24gaW4gdGhlIG5ldHdvcmsgaXMgdGhl IGdvYWwgaGVyZS4gKFRoaXMgYWxzbyBlbmFibGVzIHByb3RvY29sIGlubm92YXRpb24gYWdhaW4g YmVjYXVzZSBhdCB0aGlzIHBvaW50IHRoZSBuZXR3b3JrIGRvZXMgbm90IG5lZWQgdG8ga25vdyBh bnltb3JlIHdoaWNoIHByb3RvY29sIGlzIHVzZWQsIHdoaWNoIG1ha2VzIGl0IGV2ZW4gbW9yZSBz YXZlKS4NCg0KT2YgY291cnNlIHRoaXMgY2FuIGJlIHVzZWQgdG8gYWxzbyBhZGQgYWRkaXRpb25h bCBpbmZvcm1hdGlvbiB0aGF0IHdlIGRvbuKAmXQgaGF2ZSB0b2RheSBpbiB0aGUgVENQIGhlYWRl ciAoaG93ZXZlciwgd2UgY2FuIGFsc28gZGVmaW5lIG5ldyBUQ1Agb3B0aW9ucyBvciBJUCBoZWFk ZXJzIG9yIEhUVFAgZXh0ZW5zaW9uLi4uIGFuZCB0aGVyZSBhcmUgZXhpc3RpbmcgYmFkIGV4YW1w bGVz4oCmIG9yIGp1c3QgdXNlIHRoZW0gd2l0aCBvdXQgYW4gUkZDIG9yIHNpbXBseSByZWdpc3Rl ciBhbiBleHBlcmltZW50YWwgVENQIE9wdGlvbiBhbmQgdXNlIGl0IGZvcmV2ZXIgYW5kIHNoaXAg cHJvZHVjdHMgd2l0aCBpdC4uLiBvci4uLiBvci4uLiBvcuKApikuIEhvd2V2ZXIsIHRoZSBnb2Fs cyBpcyB0byBwcm92aWRlIGluZm9ybWF0aW9uIHdoaWNoIGNhbiBhY3R1YWxseSBiZSB1c2VkIG1h a2UgdGhlIG5ldHdvcmsgd29yayBiZXR0ZXIuIFNpbWlsYXIgYXMgc29tZSBpbmZvcm1hdGlvbiB0 aGF0IHdlIGFyZSBleHBvc2luZyB0b2RheSAoc3VjaCBhcyBwb3J0IG51bWJlcnMgYW5kL29yIHRp bWVzdGFtcHMpLCB0aGUgaW5mb3JtYXRpb24gd2UgYXJlIGxvb2tpbmcgZm9yIHNob3VsZCBpbiBp dCBzZWxmIG5vdCBiZSBwcml2YWN5IHNlbnNpdGl2ZSBhbmQgYnkgdXNpbmcgYSBuZXcgYXBwcm9h Y2ggZm9yIGV4cG9zaW5nIHdlIGNhbiBldmVuIHRha2UgYWRkaXRpb25hbCBjYXJlIG5vdyB0byBt YWtlIHN1cmUgdGhpcyBpbmZvcm1hdGlvbiBjYW5ub3QgYmUgdXNlZCBpbiBzdWNoIGEgd2F5ICh3 aGljaCBpcyBub3QgdGhlIGNhc2UgZm9yIFRDUCB0aW1lc3RhbXBzIHRvZGF5IGFzIHRoZSBjbG9j ayB1c2VkIG1pZ2h0IGlkZW50aWZ5IHRoZSBjbGllbnQpLiBEZXNpZ25pbmcgdGhpcyBub3cgd2l0 aCBhIHN0cm9uZyBwcml2YWN5IGF3YXJlbmVzcyBjYW4gYWxzbyBqdXN0IGltcHJvdmUgdGhlIHNp dHVhdGlvbiBjb21wYXJlZCB0byB3aGF0IHdlIGhhdmUgcmlnaHQgbm93Lg0KDQpJIHRvdGFsbHkg YnV5IHRoZSBwb3NpdGl2ZXMgaGVyZSwgYW5kIEkgdGhpbmsgbWF5YmUgbW9yZSBsYW5ndWFnZSBw aXRjaGluZyBhbmQganVzdGlmeWluZyB0aGlzIGFzIGF0LXdvcnN0IGFuIGV2ZW4gdHJhZGUgb2Yg cHJpdmFjeSBjb25jZXJucyBieSByZW1vdmluZyBzb21lIGV4aXN0aW5nLCBjb21wbGV0ZWx5LXVu cHJvdGVjdGVkIGNvdmVydC9zaWRlIGNoYW5uZWxzIGFuZCByZXBsYWNpbmcgdGhlbSB3aXRoIG9u bHkgZXhhY3RseSB3aGF0IHRoZSBwYXRoIG5lZWRzIHRvIGtub3cgKGh1bWJseSwgZnJvbSBvdXIg YWx3YXlzIGxpbWl0ZWQgdGVjaG5pY2FsIHBlcnNwZWN0aXZlKSBpbiBvcmRlciB0byBtYW5hZ2Ug Zmxvd3MgaW4gYSB3b3JsZCBpbiB3aGljaCB0aGUgZW50aXJlIGludGVybmV0IGlzIHJ1bm5pbmcg b3ZlciBVRFAgaXMgcGFydCBvZiB3aGF0IGlzIG1pc3NpbmcgZnJvbSB0aGUgcHJvcG9zZWQgY2hh cnRlci4NCkkgaGFkIGEgbG9uZyB0YWxrIGFib3V0IG15IHBvc3Qgd2l0aCBBYXJvbiBGYWxrIG9u IE1vbmRheSwgYW5kIGFzIGEgcmVzdWx0IG9mIHRoYXQgY29udmVyc2F0aW9uIEkgYmVjYW1lIGhv cGVmdWwgdGhhdCBtdWNoIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgZGF0YSBmbG93cyBjb3VsZCBi ZSBvYnNjdXJlZCBpbiBhIFBMVVMtZW5hYmxlZCBpbnRlcm5ldCB0aGFuIGlzIHBvc3NpYmxlIHRv ZGF5LCBwZXJoYXBzIGV2ZW4gdG8gdGhlIHBvaW50IG9mIG9ic2N1cmluZyBzb3VyY2UgYWRkcmVz c2VzIGFuZCBtYWtpbmcgZmxvd3MgYW5kIG1heWJlIGV2ZW4gaW5kaXZpZHVhbCBwYWNrZXRzIHRv IGJ1c3kgZW5kcG9pbnRzIGhhcmQgdG8gY29ycmVsYXRlIHdpdGhvdXQgdGFwIHBvaW50cyBhdCBl dmVyeSByb3V0ZXIgb24gdGhlIGludGVybmV0IGRvaW5nIGNvbGxlY3RpdmUgdHJhZmZpYyBhbmFs eXNpcy4gVGhhdCdzIGEgbG9uZyB3YXkgb2ZmLCBidXQgdGhhdCBpcyBhIGZ1dHVyZSBtYW55IHdv dWxkIGxpa2UgdG8gc2VlLg0KIldlIGRvbid0IHRoaW5rIHRoaXMgaGFzIGFueSBhZGRpdGlvbmFs IHByaXZhY3kgaW1wYWN0IiBpcyBhIG11Y2ggd2Vha2VyIHN0YXRlbWVudCB0aGFuICJUaGlzIGNh biBiZSB0aGUgZm91bmRhdGlvbiBmb3IgbXVjaCBncmVhdGVyIHByaXZhY3kgb2YgbWV0YWRhdGEs IG5vdCBqdXN0IG9mIHBheWxvYWQiLCBhbmQgaXMgbW9yZSBwcm9uZSB0byBGVUQgYmVjYXVzZSBp dCBwdXRzIHlvdSBvbiBhIGRlZmVuc2l2ZSBmb290aW5nIGFnYWluc3QgbWFueSBwb3NzaWJsZSAo YW5kIHZhZ3VlKSBsaW5lcyBvZiBhdHRhY2ssIGFuZCB0aGUgYnVyZGVuIG9mIHByb29mIGlzIGFs d2F5cyBvbiB0aG9zZSBwcm9wb3NpbmcgY2hhbmdlcy4gVGhpbmtpbmcgYWhlYWQgdG8gd2hhdCB3 ZSB3YW50IHRoZSBpbnRlcm5ldCB0byBsb29rIGxpa2UgaW4gMjAgeWVhcnMgaXMgYSBwcmVyZXF1 aXNpdGUgdG8gbWFraW5nIHN1cmUgdGhhdCB3aGF0IHdlJ3JlIGRvaW5nIGxheXMganVzdCBlbm91 Z2ggZ3JvdW5kd29yayB0byBtYWtlIHRoYXQgcG9zc2libGUsIGFuZCBpcyBzb21ldGhpbmcgdGhh dCBJIHRoaW5rIG1hbnkgcHJpdmFjeSBhZHZvY2F0ZXMgY291bGQgZ2V0IG9uIGJvYXJkIHdpdGgu DQooSSBkbyBhbHNvIHdhbnQgdG8gYWRkIHRoYXQgSSByZWNvZ25pemUgYSBiaXQgb2YgY29nbml0 aXZlIGRpc3NvbmFuY2UgaW4gbXlzZWxmLCBhcyBJJ3ZlIHJlcGVhdGVkbHkgZXhwcmVzc2VkIHNr ZXB0aWNpc20gYWJvdXQgYWRkaW5nIHJlYWwgcHJpdmFjeSBhdCB0aGUgcm91dGluZyBsYXllcnMg b24gdGhlIHB1YmxpYyBpbnRlcm5ldCwgdmVyc3VzIHByaXZhdGUgbmV0d29ya3Mgb24gdG9wIG9m IHRoYXQsIGxpa2UgVE9SLiBUaGF0IHNhaWQsIHRoZSBhbnRlY2VkZW50cyBvZiB0aGF0IHNrZXB0 aWNpc20gbWF5IG5vdCBiZSB0cnVlIGluIGEgMjAzNiBpbnRlcm5ldCwgc28gc3lzdGVtYXRpY2Fs bHkgc3RyZW5ndGhlbmluZyB0aGUgZGVzaXJhYmxlIHByb3BlcnRpZXMgb2YgdGhlIGludGVybmV0 J3MgZm91bmRhdGlvbnMgaXMgbGlrZWx5IG5vdCB0byBiZSB3YXN0ZWQgd29yaywgYXMgbG9uZyBh cyB3ZSBoYXZlIGEgcmVhc29uYWJsZSBpZGVhIG9mIHdoZXJlIHdlJ3JlIGhlYWRlZC4pDQoNCkt5 bGUNCg== --_000_E8355113905631478EFF04F5AA706E9831044800wtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5LeWxlIFJvc2Ugc2FpZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+4oCc4oCmPC9zcGFu PkkgYmVjYW1lIGhvcGVmdWwgdGhhdCBtdWNoIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgZGF0YSBm bG93cyBjb3VsZCBiZSBvYnNjdXJlZCBpbiBhIFBMVVMtZW5hYmxlZCBpbnRlcm5ldCB0aGFuIGlz IHBvc3NpYmxlIHRvZGF5LCBwZXJoYXBzIGV2ZW4gdG8gdGhlIHBvaW50IG9mIG9ic2N1cmluZyBz b3VyY2UgYWRkcmVzc2VzIGFuZCBtYWtpbmcNCiBmbG93cyBhbmQgbWF5YmUgZXZlbiBpbmRpdmlk dWFsIHBhY2tldHMgdG8gYnVzeSBlbmRwb2ludHMgaGFyZCB0byBjb3JyZWxhdGXigKbigJ08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFiaWxpdHkgdG8gb2JzY3VyZSBzb3VyY2UgYWRkcmVz c2VzIG9wZW5zIGEgaHVnZSBhdHRhY2sgc3VyZmFjZSBmb3IgRERvUyBhdHRhY2tzLCBzaW5jZSB0 aGVyZSBpcyBubyB3YXkgdG8gaW1wbGVtZW50IEJDUCAzOCAoTmV0d29yayBJbmdyZXNzIEZpbHRl cmluZykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZ1cnRoZXJtb3JlLCB0byBteSBrbm93bGVk Z2UsIEREb1MgYXR0YWNrcyBhcmUgbW9zdCBlZmZlY3RpdmVseSBzY3J1YmJlZCBwcmVjaXNlbHkg YnkgY29ycmVsYXRpbmcgaW5ib3VuZCBwYWNrZXRzIHdpdGggb3V0Ym91bmQgcGFja2V0cyB0aGF0 IGFyZSBldmlkZW5jZSB0aGUgcHJvdGVjdGVkIHNlcnZpY2UgZGVzaXJlcyB0byBjb21tdW5pY2F0 ZSB3aXRoIHRoZSBzZW5kZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4o SSBzdXBwb3NlIGEgc2NydWJiZXIgY291bGQgc2ltcGx5IGRpc2NhcmQgbW9zdCBzb3VyY2Utb2Jz Y3VyZWQgdHJhZmZpYy4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByaXZhY3kgaXMgb25lIHNp ZGUgb2Ygc2VjdXJpdHksIGJ1dCB0aGUgYWJpbGl0eSB0byByZXNpc3QgYXR0YWNrcyBpcyBhbm90 aGVyIGltcG9ydGFudCBhc3BlY3QuIEFzIGZhciBhcyBJIGtub3csIG5vIG9uZSBoYXMgZmlndXJl ZCBvdXQgaG93IHRvIG1pdGlnYXRlIEREb1MgYXR0YWNrcyBhdCB0aGUgcmVjZWl2aW5nIGVuZC1w b2ludC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gaG9waW5nIHRoaXMgZ3JvdXAgY2Fu IGF0IGxlYXN0IGFncmVlIHRoYXQgbWl0aWdhdGluZyBERG9TIGF0dGFja3MgaXMgYSBsZWdpdGlt YXRlIHJvbGUgb2YgZGV2aWNlcyBpbiB0aGUgbmV0d29yay48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRGF2ZTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3B1ZCBbbWFpbHRvOnNwdWQtYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+S3lsZSBSb3NlPGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgSnVseSAyNywgMjAxNiAxMDo0OCBBTTxicj4NCjxiPlRvOjwvYj4gTWly amEgS8O8aGxld2luZDxicj4NCjxiPkNjOjwvYj4gc3B1ZEBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1NwdWRdIFRob3VnaHRzIG9uIHRoZSBwcml2YWN5IGNvbmNlcm5zIGV4cHJl c3NlZCBhdCB0aGUgQm9GPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBNb24sIEp1bCAyNSwgMjAxNiBhdCA0OjIwIFBNLCBNaXJqYSBLw7xobGV3aW5kICZs dDs8YSBocmVmPSJtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCIgdGFyZ2V0 PSJfYmxhbmsiPm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFzIG1lbnRpb25lZCBieSBUZWQsIHRoaXMgaXMgYWN0dWFsbHkgbm90IHdoYXQgd2Ug cHJvcG9zZS4gVGhlIG1lY2hhbmlzbSB3ZSBwcm9wb3NlIGlzIGV4cG9zaW5nIGluZm9ybWF0aW9u IHVuZGVyIGVuZHBvaW50IGNvbnRyb2wgd2hpY2ggaXMgYSB2ZXJ5IGltcG9ydGFudCBwb2ludCBo ZXJlLiBUaGUgZW5kcG9pbnQgaGFzIHRvIGFkZCBhbiBvcHRpb24gdG8gc2VuZCAob3IgcmVxdWVz dCkgYSBzcGVjaWZpYyBiaXQNCiBvZiBpbmZvcm1hdGlvbiAod2hpY2ggYWxzbyBtdXN0IGJlIHJl Z2lzdGVyZWQgYnkgSUFOQSB3aXRoIElFU0cgYXBwcm92YWwpLiBUaGlzIGlzIGp1c3QgdGhlIHNh bWUgYXMgVENQIG9wdGlvbnMgb3IgSVAgb3B0aW9uIGhlYWRlcnMuIFRoZSBvbmx5IGRpZmZlcmVu Y2UgaXMgdGhhdCBQTFVTIGhhcyBhIE1BQyB3aGljaCBhbGxvd3MgZGV0ZWN0aW9uIG9mIG1pZGRs ZWJveCBtYW5pcHVsYXRpb24gKHdoaWNoIGlzIG5vdCB0aGUgY2FzZSBmb3Igb3RoZXINCiBleGlz dGluZyBwcm90b2NvbHMgc3VjaCBhcyBUQ1Agb3B0aW9ucykuIFRoaXMgaXMgYW5vdGhlciBhIHZl cnkgYmlnIGFuZCBpbXBvcnRhbnQgYXNwZWN0IG9mIHdoYXQgd2UgcHJvcG9zZSB3aXRoIFBMVVMg YXMgb3VyIGdvYWwgaXMgdG8gZW5jcnlwdCBldmVyeXRoaW5nIGFib3ZlIFBMVVMgaW5jbHVkaW5n IHRoZSBUQ1AgaGVhZGVyIGFuZCBUQ1Agb3B0aW9ucyBpbiBmdXR1cmUuIEVzcGVjaWFsbHkgZW5j cnlwdGluZyBUQ1Agb3B0aW9uIGlzIGltcG9ydGFudA0KIGJlY2F1c2UgVENQIG9wdGlvbnMgcHJv dmlkZSBtdWNoIGxlc3MgY29udHJvbCB0aGFuIHdoYXQgd2UgcHJvcG9zZSB3aXRoIFBMVVMgdG9k YXkgd2hpY2ggaXMgYSBwcm9ibGVtIChlc3BlY2lhbGx5IGFzIGN1cnJlbnRseSBzdGlsbCB1bnRv IDkwJSBvZiB0aGUgdHJhZmZpYyBpcyBUQ1ApLiBTbyBJIGFjdHVhbGx5IHRob3VnaCB3ZSBhcmUg b24gdGhlIHNhbWUgcGFnZSBoZXJlIGFuZCBoYXZlIGEgY29tbW9uIGdvYWwuPGJyPg0KPGJyPg0K QXMgeW91IHByb2JhYmx5IGtub3cgZnJvbSB0Y3BpbmMgZGlzY3Vzc2lvbnMgaXQgaXMgdG9kYXkg bm90IHBvc3NpYmxlIHRvIGp1c3QgZW5jcnlwdCB0aGUgd2hvbGUgVENQIGhlYWRlciBiZWNhdXNl IHRoaXMgd2lsbCBsZWFkIHRvIGh1Z2UgZGVwbG95bWVudCBwcm9ibGVtIChhbmQgaW5jZW50aXZl IHBlb3BsZSB0byBhY3RpdmVseSBibG9jayBlbmNyeXB0aW9uKSwgaG93ZXZlciwgcHJvdmlkaW5n IGEgcmVwbGFjZW1lbnQgbWVjaGFuaXNtIHRoYXQNCiBhY3R1YWxseSBnaXZlcyB0aGUgY29udHJv bCByZWFsbHkgYmFjayB0byB0aGUgZW5kcG9pbnQgYW5kIHByb3ZpZGVzIHRoZSBuZWVkZWQgKG5v dCBwcml2YWN5IHNlbnNpdGl2ZSkgaW5mb3JtYXRpb24gaW4gdGhlIG5ldHdvcmsgaXMgdGhlIGdv YWwgaGVyZS4gKFRoaXMgYWxzbyBlbmFibGVzIHByb3RvY29sIGlubm92YXRpb24gYWdhaW4gYmVj YXVzZSBhdCB0aGlzIHBvaW50IHRoZSBuZXR3b3JrIGRvZXMgbm90IG5lZWQgdG8ga25vdyBhbnlt b3JlDQogd2hpY2ggcHJvdG9jb2wgaXMgdXNlZCwgd2hpY2ggbWFrZXMgaXQgZXZlbiBtb3JlIHNh dmUpLjxicj4NCjxicj4NCk9mIGNvdXJzZSB0aGlzIGNhbiBiZSB1c2VkIHRvIGFsc28gYWRkIGFk ZGl0aW9uYWwgaW5mb3JtYXRpb24gdGhhdCB3ZSBkb27igJl0IGhhdmUgdG9kYXkgaW4gdGhlIFRD UCBoZWFkZXIgKGhvd2V2ZXIsIHdlIGNhbiBhbHNvIGRlZmluZSBuZXcgVENQIG9wdGlvbnMgb3Ig SVAgaGVhZGVycyBvciBIVFRQIGV4dGVuc2lvbi4uLiBhbmQgdGhlcmUgYXJlIGV4aXN0aW5nIGJh ZCBleGFtcGxlc+KApiBvciBqdXN0IHVzZSB0aGVtIHdpdGggb3V0IGFuIFJGQyBvcg0KIHNpbXBs eSByZWdpc3RlciBhbiBleHBlcmltZW50YWwgVENQIE9wdGlvbiBhbmQgdXNlIGl0IGZvcmV2ZXIg YW5kIHNoaXAgcHJvZHVjdHMgd2l0aCBpdC4uLiBvci4uLiBvci4uLiBvcuKApikuIEhvd2V2ZXIs IHRoZSBnb2FscyBpcyB0byBwcm92aWRlIGluZm9ybWF0aW9uIHdoaWNoIGNhbiBhY3R1YWxseSBi ZSB1c2VkIG1ha2UgdGhlIG5ldHdvcmsgd29yayBiZXR0ZXIuIFNpbWlsYXIgYXMgc29tZSBpbmZv cm1hdGlvbiB0aGF0IHdlIGFyZSBleHBvc2luZw0KIHRvZGF5IChzdWNoIGFzIHBvcnQgbnVtYmVy cyBhbmQvb3IgdGltZXN0YW1wcyksIHRoZSBpbmZvcm1hdGlvbiB3ZSBhcmUgbG9va2luZyBmb3Ig c2hvdWxkIGluIGl0IHNlbGYgbm90IGJlIHByaXZhY3kgc2Vuc2l0aXZlIGFuZCBieSB1c2luZyBh IG5ldyBhcHByb2FjaCBmb3IgZXhwb3Npbmcgd2UgY2FuIGV2ZW4gdGFrZSBhZGRpdGlvbmFsIGNh cmUgbm93IHRvIG1ha2Ugc3VyZSB0aGlzIGluZm9ybWF0aW9uIGNhbm5vdCBiZSB1c2VkIGluIHN1 Y2gNCiBhIHdheSAod2hpY2ggaXMgbm90IHRoZSBjYXNlIGZvciBUQ1AgdGltZXN0YW1wcyB0b2Rh eSBhcyB0aGUgY2xvY2sgdXNlZCBtaWdodCBpZGVudGlmeSB0aGUgY2xpZW50KS4gRGVzaWduaW5n IHRoaXMgbm93IHdpdGggYSBzdHJvbmcgcHJpdmFjeSBhd2FyZW5lc3MgY2FuIGFsc28ganVzdCBp bXByb3ZlIHRoZSBzaXR1YXRpb24gY29tcGFyZWQgdG8gd2hhdCB3ZSBoYXZlIHJpZ2h0IG5vdy48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSB0b3RhbGx5IGJ1eSB0aGUgcG9zaXRp dmVzIGhlcmUsIGFuZCBJIHRoaW5rIG1heWJlIG1vcmUgbGFuZ3VhZ2UgcGl0Y2hpbmcgYW5kIGp1 c3RpZnlpbmcgdGhpcyBhcyBhdC13b3JzdCBhbiBldmVuIHRyYWRlIG9mIHByaXZhY3kgY29uY2Vy bnMgYnkgcmVtb3Zpbmcgc29tZSBleGlzdGluZywgY29tcGxldGVseS11bnByb3RlY3RlZCBjb3Zl cnQvc2lkZSBjaGFubmVscw0KIGFuZCByZXBsYWNpbmcgdGhlbSB3aXRoIG9ubHkgZXhhY3RseSB3 aGF0IHRoZSBwYXRoIG5lZWRzIHRvIGtub3cgKGh1bWJseSwgZnJvbSBvdXIgYWx3YXlzIGxpbWl0 ZWQgdGVjaG5pY2FsIHBlcnNwZWN0aXZlKSBpbiBvcmRlciB0byBtYW5hZ2UgZmxvd3MgaW4gYSB3 b3JsZCBpbiB3aGljaCB0aGUgZW50aXJlIGludGVybmV0IGlzIHJ1bm5pbmcgb3ZlciBVRFAgaXMg cGFydCBvZiB3aGF0IGlzIG1pc3NpbmcgZnJvbSB0aGUgcHJvcG9zZWQgY2hhcnRlci48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+SSBoYWQgYSBsb25nIHRhbGsgYWJvdXQgbXkgcG9zdCB3aXRoIEFh cm9uIEZhbGsgb24gTW9uZGF5LCBhbmQgYXMgYSByZXN1bHQgb2YgdGhhdCBjb252ZXJzYXRpb24g SSBiZWNhbWUgaG9wZWZ1bCB0aGF0IG11Y2ggbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBkYXRhIGZs b3dzIGNvdWxkIGJlIG9ic2N1cmVkIGluIGEgUExVUy1lbmFibGVkIGludGVybmV0IHRoYW4NCiBp cyBwb3NzaWJsZSB0b2RheSwgcGVyaGFwcyBldmVuIHRvIHRoZSBwb2ludCBvZiBvYnNjdXJpbmcg c291cmNlIGFkZHJlc3NlcyBhbmQgbWFraW5nIGZsb3dzIGFuZCBtYXliZSBldmVuIGluZGl2aWR1 YWwgcGFja2V0cyB0byBidXN5IGVuZHBvaW50cyBoYXJkIHRvIGNvcnJlbGF0ZSB3aXRob3V0IHRh cCBwb2ludHMgYXQgZXZlcnkgcm91dGVyIG9uIHRoZSBpbnRlcm5ldCBkb2luZyBjb2xsZWN0aXZl IHRyYWZmaWMgYW5hbHlzaXMuIFRoYXQncyBhDQogbG9uZyB3YXkgb2ZmLCBidXQgdGhhdCBpcyBh IGZ1dHVyZSBtYW55IHdvdWxkIGxpa2UgdG8gc2VlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4m cXVvdDtXZSBkb24ndCB0aGluayB0aGlzIGhhcyBhbnkgYWRkaXRpb25hbCBwcml2YWN5IGltcGFj dCZxdW90OyBpcyBhIG11Y2ggd2Vha2VyIHN0YXRlbWVudCB0aGFuICZxdW90O1RoaXMgY2FuIGJl IHRoZSBmb3VuZGF0aW9uIGZvciBtdWNoIGdyZWF0ZXIgcHJpdmFjeSBvZiBtZXRhZGF0YSwgbm90 IGp1c3Qgb2YgcGF5bG9hZCZxdW90OywgYW5kIGlzIG1vcmUgcHJvbmUgdG8gRlVEIGJlY2F1c2UN CiBpdCBwdXRzIHlvdSBvbiBhIGRlZmVuc2l2ZSBmb290aW5nIGFnYWluc3QgbWFueSBwb3NzaWJs ZSAoYW5kIHZhZ3VlKSBsaW5lcyBvZiBhdHRhY2ssIGFuZCB0aGUgYnVyZGVuIG9mIHByb29mIGlz IGFsd2F5cyBvbiB0aG9zZSBwcm9wb3NpbmcgY2hhbmdlcy4gVGhpbmtpbmcgYWhlYWQgdG8gd2hh dCB3ZSB3YW50IHRoZSBpbnRlcm5ldCB0byBsb29rIGxpa2UgaW4gMjAgeWVhcnMgaXMgYSBwcmVy ZXF1aXNpdGUgdG8gbWFraW5nIHN1cmUgdGhhdCB3aGF0DQogd2UncmUgZG9pbmcgbGF5cyBqdXN0 IGVub3VnaCBncm91bmR3b3JrIHRvIG1ha2UgdGhhdCBwb3NzaWJsZSwgYW5kIGlzIHNvbWV0aGlu ZyB0aGF0IEkgdGhpbmsgbWFueSBwcml2YWN5IGFkdm9jYXRlcyBjb3VsZCBnZXQgb24gYm9hcmQg d2l0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PihJIGRvIGFsc28gd2FudCB0byBhZGQgdGhhdCBJIHJlY29nbml6ZSBhIGJpdCBvZiBjb2duaXRp dmUgZGlzc29uYW5jZSBpbiBteXNlbGYsIGFzIEkndmUgcmVwZWF0ZWRseSBleHByZXNzZWQgc2tl cHRpY2lzbSBhYm91dCBhZGRpbmcgcmVhbCBwcml2YWN5IGF0IHRoZSByb3V0aW5nIGxheWVycyBv biB0aGUgcHVibGljIGludGVybmV0LCB2ZXJzdXMgcHJpdmF0ZSBuZXR3b3JrcyBvbiB0b3Agb2Yg dGhhdCwgbGlrZQ0KIFRPUi4gVGhhdCBzYWlkLCB0aGUgYW50ZWNlZGVudHMgb2YgdGhhdCBza2Vw dGljaXNtIG1heSBub3QgYmUgdHJ1ZSBpbiBhIDIwMzYgaW50ZXJuZXQsIHNvIHN5c3RlbWF0aWNh bGx5IHN0cmVuZ3RoZW5pbmcgdGhlIGRlc2lyYWJsZSBwcm9wZXJ0aWVzIG9mIHRoZSBpbnRlcm5l dCdzIGZvdW5kYXRpb25zIGlzIGxpa2VseSBub3QgdG8gYmUgd2FzdGVkIHdvcmssIGFzIGxvbmcg YXMgd2UgaGF2ZSBhIHJlYXNvbmFibGUgaWRlYSBvZiB3aGVyZSB3ZSdyZQ0KIGhlYWRlZC4pPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LeWxlPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E8355113905631478EFF04F5AA706E9831044800wtlexchp2sandvi_-- From nobody Wed Jul 27 13:52:51 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9B712DCEE for ; Wed, 27 Jul 2016 13:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 QffSxm9bVjP6 for ; Wed, 27 Jul 2016 13:52:46 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 E0F9112DD01 for ; Wed, 27 Jul 2016 13:52:45 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id o67so45682287qke.1 for ; Wed, 27 Jul 2016 13:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YJO/ej0NZ+kqPaYM39/7C+z9NqaCMbEY2aZ7Pb2ZYzY=; b=CJMK78CgHCoQ63os0r2y08dCR7IBSVKpwU5qWOvVZmprRLHBFVK391dSvG3os2sTNe H+JmQpbRlvQUK+IK9wIGOZJ7vt/qrFlHSY/RU7U63FKcxTBFlSKn1jLQBWN0Y/M7eNWi gIzm4dkFLRhKTRqq3uUtSF5CbWNq7Lp7WGKz8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YJO/ej0NZ+kqPaYM39/7C+z9NqaCMbEY2aZ7Pb2ZYzY=; b=e46uGLHZd4B2K2k0XilPxrkzBiqzGFsY3Q0sU/8G8Mhq72RsSbNG4Z7/3seAxT+mrh N5WwWpyH4AdjDVTWJxQbntnuMg/jRHsH8iMRyuHzvQmzwfjUxdkjFDR21Ol1KeHXXeF1 FxXd4ujQq7ipD+bGVzS3g5jjuodf8fGLhCfKFJvfZTXnAkKhuNwE0+b4nEV7b7vfZwDN sX6oZc40MOxhVR4JiyMst06ycWQJQTrYZX9/CeJS2eRCkkhprpK584lWFB8QMVUVCMM0 0Vj+fpklnBbp6EogYF+Pfm5XlXZYlG2deS+GTY3pODu8g17bX8FkRQ18UycnCyL3IStD dVEw== X-Gm-Message-State: AEkoouvCijv/E4qVNEUQOl5+TyGygxolx4hJe+YeTlULwzV70441H3Z8wWgdqJMltB9YonlgPlX2dCvrZ0mV1Q== X-Received: by 10.55.158.139 with SMTP id h133mr6530351qke.51.1469652765007; Wed, 27 Jul 2016 13:52:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.94.70 with HTTP; Wed, 27 Jul 2016 13:52:44 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: From: Kyle Rose Date: Wed, 27 Jul 2016 16:52:44 -0400 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=94eb2c075046007da20538a433be Archived-At: Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "spud@ietf.org" Subject: Re: [Spud] Thoughts on the privacy concerns expressed at the BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 20:52:49 -0000 --94eb2c075046007da20538a433be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Funny you should mention that. :-) When Aaron and I were talking about this earlier, we were basically throwing ideas around. When we got to this one, I mentioned how it would neuter BCP 38, but that DoS protection might be achievable via some other mechanism on a hypothetical future internet (especially since source address verification only helps with a subset of DoS attacks: the most difficult kind to deal with are those that are indistinguishable from legitimate traffic). At any rate, mentioning obscuring source addresses was not intended as a well-thought-out proposal to be drafted tomorrow and standardized next year, only as the kind of thing that might be appealing to privacy advocates, and possibly feasible on an internet that looks very different from today's. Just because I can't figure out how to do something doesn't mean it's impossible. Kyle On Wed, Jul 27, 2016 at 4:31 PM, Dave Dolson wrote: > Kyle Rose said: > > =E2=80=9C=E2=80=A6I became hopeful that much more information about data = flows could be > obscured in a PLUS-enabled internet than is possible today, perhaps even = to > the point of obscuring source addresses and making flows and maybe even > individual packets to busy endpoints hard to correlate=E2=80=A6=E2=80=9D > > > > The ability to obscure source addresses opens a huge attack surface for > DDoS attacks, since there is no way to implement BCP 38 (Network Ingress > Filtering). > > > > Furthermore, to my knowledge, DDoS attacks are most effectively scrubbed > precisely by correlating inbound packets with outbound packets that are > evidence the protected service desires to communicate with the sender. > > (I suppose a scrubber could simply discard most source-obscured traffic.) > > > > Privacy is one side of security, but the ability to resist attacks is > another important aspect. As far as I know, no one has figured out how to > mitigate DDoS attacks at the receiving end-point. > > > > I=E2=80=99m hoping this group can at least agree that mitigating DDoS att= acks is a > legitimate role of devices in the network. > > > > > > -Dave > > > > > > > > *From:* Spud [mailto:spud-bounces@ietf.org] *On Behalf Of *Kyle Rose > *Sent:* Wednesday, July 27, 2016 10:48 AM > *To:* Mirja K=C3=BChlewind > *Cc:* spud@ietf.org > *Subject:* Re: [Spud] Thoughts on the privacy concerns expressed at the > BoF > > > > On Mon, Jul 25, 2016 at 4:20 PM, Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> wrote: > > As mentioned by Ted, this is actually not what we propose. The mechanism > we propose is exposing information under endpoint control which is a very > important point here. The endpoint has to add an option to send (or > request) a specific bit of information (which also must be registered by > IANA with IESG approval). This is just the same as TCP options or IP opti= on > headers. The only difference is that PLUS has a MAC which allows detectio= n > of middlebox manipulation (which is not the case for other existing > protocols such as TCP options). This is another a very big and important > aspect of what we propose with PLUS as our goal is to encrypt everything > above PLUS including the TCP header and TCP options in future. Especially > encrypting TCP option is important because TCP options provide much less > control than what we propose with PLUS today which is a problem (especial= ly > as currently still unto 90% of the traffic is TCP). So I actually though = we > are on the same page here and have a common goal. > > As you probably know from tcpinc discussions it is today not possible to > just encrypt the whole TCP header because this will lead to huge deployme= nt > problem (and incentive people to actively block encryption), however, > providing a replacement mechanism that actually gives the control really > back to the endpoint and provides the needed (not privacy sensitive) > information in the network is the goal here. (This also enables protocol > innovation again because at this point the network does not need to know > anymore which protocol is used, which makes it even more save). > > Of course this can be used to also add additional information that we > don=E2=80=99t have today in the TCP header (however, we can also define n= ew TCP > options or IP headers or HTTP extension... and there are existing bad > examples=E2=80=A6 or just use them with out an RFC or simply register an > experimental TCP Option and use it forever and ship products with it... > or... or... or=E2=80=A6). However, the goals is to provide information wh= ich can > actually be used make the network work better. Similar as some informatio= n > that we are exposing today (such as port numbers and/or timestamps), the > information we are looking for should in it self not be privacy sensitive > and by using a new approach for exposing we can even take additional care > now to make sure this information cannot be used in such a way (which is > not the case for TCP timestamps today as the clock used might identify th= e > client). Designing this now with a strong privacy awareness can also just > improve the situation compared to what we have right now. > > > > I totally buy the positives here, and I think maybe more language pitchin= g > and justifying this as at-worst an even trade of privacy concerns by > removing some existing, completely-unprotected covert/side channels and > replacing them with only exactly what the path needs to know (humbly, fro= m > our always limited technical perspective) in order to manage flows in a > world in which the entire internet is running over UDP is part of what is > missing from the proposed charter. > > I had a long talk about my post with Aaron Falk on Monday, and as a resul= t > of that conversation I became hopeful that much more information about da= ta > flows could be obscured in a PLUS-enabled internet than is possible today= , > perhaps even to the point of obscuring source addresses and making flows > and maybe even individual packets to busy endpoints hard to correlate > without tap points at every router on the internet doing collective traff= ic > analysis. That's a long way off, but that is a future many would like to > see. > > "We don't think this has any additional privacy impact" is a much weaker > statement than "This can be the foundation for much greater privacy of > metadata, not just of payload", and is more prone to FUD because it puts > you on a defensive footing against many possible (and vague) lines of > attack, and the burden of proof is always on those proposing changes. > Thinking ahead to what we want the internet to look like in 20 years is a > prerequisite to making sure that what we're doing lays just enough > groundwork to make that possible, and is something that I think many > privacy advocates could get on board with. > > (I do also want to add that I recognize a bit of cognitive dissonance in > myself, as I've repeatedly expressed skepticism about adding real privacy > at the routing layers on the public internet, versus private networks on > top of that, like TOR. That said, the antecedents of that skepticism may > not be true in a 2036 internet, so systematically strengthening the > desirable properties of the internet's foundations is likely not to be > wasted work, as long as we have a reasonable idea of where we're headed.) > > > > Kyle > --94eb2c075046007da20538a433be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Funny you should mention that. :-)

<= /div>When Aaron and I were talking about this earlier, we were basically th= rowing ideas around. When we got to this one, I mentioned how it would neut= er BCP 38, but that DoS protection might be achievable via some other mecha= nism on a hypothetical future internet (especially since source address ver= ification only helps with a subset of DoS attacks: the most difficult kind = to deal with are those that are indistinguishable from legitimate traffic).=

At any rate, mentioning obscuring source addresses was not in= tended as a well-thought-out proposal to be drafted tomorrow and standardiz= ed next year, only as the kind of thing that might be appealing to privacy = advocates, and possibly feasible on an internet that looks very different f= rom today's. Just because I can't figure out how to do something do= esn't mean it's impossible.

Kyle


On Wed, Jul 27= , 2016 at 4:31 PM, Dave Dolson <ddolson@sandvine.com> wro= te:

Kyle Rose said:<= /u>

=E2=80=9C=E2=80=A6<= /span>I became hopeful that much more information about data flows could be= obscured in a PLUS-enabled internet than is possible today, perhaps even t= o the point of obscuring source addresses and making flows and maybe even individual packets to busy endpoints hard to correlat= e=E2=80=A6=E2=80=9D

=C2=A0

The ability to obscure source addresses opens a huge= attack surface for DDoS attacks, since there is no way to implement BCP 38= (Network Ingress Filtering).

=C2=A0

Furthermore, to my knowledge, DDoS attacks are most = effectively scrubbed precisely by correlating inbound packets with outbound= packets that are evidence the protected service desires to communicate wit= h the sender.

(I suppose a scrubber could simply discard most sour= ce-obscured traffic.)

=C2=A0

Privacy is one side of security, but the ability to = resist attacks is another important aspect. As far as I know, no one has fi= gured out how to mitigate DDoS attacks at the receiving end-point.

=C2=A0

I=E2=80=99m hoping this group can at least agree tha= t mitigating DDoS attacks is a legitimate role of devices in the network.

=C2=A0

=C2=A0

-Dave

=C2=A0

=C2=A0

=C2=A0

From: Spud [ma= ilto:spud-bounce= s@ietf.org] On Behalf Of Kyle Rose
Sent: Wednesday, July 27, 2016 10:48 AM
To: Mirja K=C3=BChlewind
Cc: spud@ietf.org=
Subject: Re: [Spud] Thoughts on the privacy concerns expressed at th= e BoF

=C2=A0

On Mon, Jul 25, 2016 at 4:20 PM, Mirja K=C3=BChlewin= d <= mirja.kuehlewind@tik.ee.ethz.ch> wrote:

As mentioned by Ted, this is actually not what we pr= opose. The mechanism we propose is exposing information under endpoint cont= rol which is a very important point here. The endpoint has to add an option= to send (or request) a specific bit of information (which also must be registered by IANA with IESG approval).= This is just the same as TCP options or IP option headers. The only differ= ence is that PLUS has a MAC which allows detection of middlebox manipulatio= n (which is not the case for other existing protocols such as TCP options). This is another a very big and im= portant aspect of what we propose with PLUS as our goal is to encrypt every= thing above PLUS including the TCP header and TCP options in future. Especi= ally encrypting TCP option is important because TCP options provide much less control than what we propose with PL= US today which is a problem (especially as currently still unto 90% of the = traffic is TCP). So I actually though we are on the same page here and have= a common goal.

As you probably know from tcpinc discussions it is today not possible to ju= st encrypt the whole TCP header because this will lead to huge deployment p= roblem (and incentive people to actively block encryption), however, provid= ing a replacement mechanism that actually gives the control really back to the endpoint and provides the ne= eded (not privacy sensitive) information in the network is the goal here. (= This also enables protocol innovation again because at this point the netwo= rk does not need to know anymore which protocol is used, which makes it even more save).

Of course this can be used to also add additional information that we don= =E2=80=99t have today in the TCP header (however, we can also define new TC= P options or IP headers or HTTP extension... and there are existing bad exa= mples=E2=80=A6 or just use them with out an RFC or simply register an experimental TCP Option and use it forever and ship pro= ducts with it... or... or... or=E2=80=A6). However, the goals is to provide= information which can actually be used make the network work better. Simil= ar as some information that we are exposing today (such as port numbers and/or timestamps), the information we are loo= king for should in it self not be privacy sensitive and by using a new appr= oach for exposing we can even take additional care now to make sure this in= formation cannot be used in such a way (which is not the case for TCP timestamps today as the clock used mi= ght identify the client). Designing this now with a strong privacy awarenes= s can also just improve the situation compared to what we have right now.

=C2=A0

I totally buy the pos= itives here, and I think maybe more language pitching and justifying this a= s at-worst an even trade of privacy concerns by removing some existing, com= pletely-unprotected covert/side channels and replacing them with only exactly what the path needs to know (humbly, = from our always limited technical perspective) in order to manage flows in = a world in which the entire internet is running over UDP is part of what is= missing from the proposed charter.

I had a long talk abo= ut my post with Aaron Falk on Monday, and as a result of that conversation = I became hopeful that much more information about data flows could be obscu= red in a PLUS-enabled internet than is possible today, perhaps even to the point of obscuring source addresses= and making flows and maybe even individual packets to busy endpoints hard = to correlate without tap points at every router on the internet doing colle= ctive traffic analysis. That's a long way off, but that is a future many would like to see.

"We don't th= ink this has any additional privacy impact" is a much weaker statement= than "This can be the foundation for much greater privacy of metadata= , not just of payload", and is more prone to FUD because it puts you on a defensive footing against many possible (and vague) lines= of attack, and the burden of proof is always on those proposing changes. T= hinking ahead to what we want the internet to look like in 20 years is a pr= erequisite to making sure that what we're doing lays just enough groundwork to make that possible, and is = something that I think many privacy advocates could get on board with.

(I do also want to add that I recognize a bit of cog= nitive dissonance in myself, as I've repeatedly expressed skepticism ab= out adding real privacy at the routing layers on the public internet, versu= s private networks on top of that, like TOR. That said, the antecedents of that skepticism may not be true in a 20= 36 internet, so systematically strengthening the desirable properties of th= e internet's foundations is likely not to be wasted work, as long as we= have a reasonable idea of where we're headed.)

=C2=A0

Kyle


--94eb2c075046007da20538a433be-- From nobody Thu Jul 28 08:02:58 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3B112D5D2 for ; Thu, 28 Jul 2016 08:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR6bE7QFKiID for ; Thu, 28 Jul 2016 08:02:55 -0700 (PDT) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 7184812B042 for ; Thu, 28 Jul 2016 08:02:55 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id j124so5079477ith.3 for ; Thu, 28 Jul 2016 08:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=2k20kGG/j2b0HOGDLbU/ZDOvHdVyBREYiX3JaqUHp3M=; b=VjEaegV575VFZuPOWgsm2psrpvHUmhThMQ2V/fcHa9RAzvrKcxqwND4beSus9P28xX MDKLR/E0eUyhJjCLqH52DYiv3EzbpI8PkX++3vWLgrj97T5bSymYe76nzNM/4vDcadEc phVGjvKH4B1SW7JYSiiRFGd/yTyMuqmKqJ+GuiPM8q5taJsLH/k98rSIMd+/394hPZzQ UVeuJZElOaFuIpiKC7OJ2CMsph/dA6+4YSI6V24/AXNRQ6A2wtn27eyjN9INvApo0PoK Vx8LqvF7n5AB5c9IGDc1te/T1K07MEoOqsvfHTVGd0ZWK1c5aMfdkeqrqEjhwtyuTYtK iacw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=2k20kGG/j2b0HOGDLbU/ZDOvHdVyBREYiX3JaqUHp3M=; b=KNUrgEvk38FRc1fcLj/R6nHf2Nq8so8HjKHxccf9US6eh4dWYcv6ZbR5CJucfOSOEp 559Oa4O3aT1rL0wUhVuWjuShLWo0qJJuRvd40B5vhz/qsByY+byPjtPsjVkp8qVqKbWU pDLjGAS4x89d/GacfOvSpEtqXE1YJAE/rHM5s6li5+N0l9mTzOtrc9+chP0VonQfqkbF oIzzEM1coiS3Wjrpld5l1+RL3zCXJMQbqUR4A+nf+y5cnO+nlw9B8s4OKEoh0kbjmCCX ZUpxLwhNS4JPSSmm42OtYoDwqT+tQCPL6YoVtA2BWOUCdpefXiuUE6aEdBfcpDirCAT1 Xcxw== X-Gm-Message-State: AEkoout124KVOq+dNPKWGrSOea6wSDoAwyIph799U6nePZGGwYUIwuQg64/tGzho3m+B462aor3z7Tu6j9rmKw== X-Received: by 10.36.123.139 with SMTP id q133mr38652391itc.10.1469718174764; Thu, 28 Jul 2016 08:02:54 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.107.137.69 with HTTP; Thu, 28 Jul 2016 08:02:54 -0700 (PDT) From: Erik Nygren Date: Thu, 28 Jul 2016 11:02:54 -0400 X-Google-Sender-Auth: Y79IIYOhKG7c6FDku0tVvIUuubg Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a1147584cba40a30538b36de9 Archived-At: Cc: Kyle Rose , spud@ietf.org Subject: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 15:02:57 -0000 --001a1147584cba40a30538b36de9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 25, 2016 at 4:20 PM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > As mentioned by Ted, this is actually not what we propose. The mechanism > we propose is exposing information under endpoint control which is a very > important point here. The endpoint has to add an option to send (or > request) a specific bit of information (which also must be registered by > IANA with IESG approval). This is just the same as TCP options or IP opti= on > headers. The only difference is that PLUS has a MAC which allows detectio= n > of middlebox manipulation (which is not the case for other existing > protocols such as TCP options). This is another a very big and important > aspect of what we propose with PLUS as our goal is to encrypt everything > above PLUS including the TCP header and TCP options in future. Especially > encrypting TCP option is important because TCP options provide much less > control than what we propose with PLUS today which is a problem (especial= ly > as currently still unto 90% of the traffic is TCP). So I actually though = we > are on the same page here and have a common goal. > I'm not sure that we get enough value out of extensibility or being overly generic here, at least for practical non-research purposes. If there is a tightly defined set of things allowed, we'll quickly ossify on these anyways. As firewall vendors will just bake in those registered by IANA when they ship their product and then we'll be right back where we are today with IPv6 extension headers. I'd propose that it may make more sense to define a fixed header prefix format that contains the right set of features needed to solve the problems of QUIC and WebRTC (and other future UDP protocols). Along with this, also define a common set of requirements for protocols using this header prefix (eg, around DDoS reflection prevention). Having a toolkit for things like handling connection ids in a way that support multipath mobility, stateless load-balancers, DDoS resiliance, and which minimize linkability would also be a nice-to-have to prevent each UDP protocol from having to come up with subtly different ways to solve this set of problems. For example, a bare minimum set of features might include: * Opportunistic signalling to middle-boxes (NATs and Firewalls) for when they can discard connection state. Unless we want to declare that new UDP protocols only work with IPv6 (worth seriously considering, but perhaps not realistic yet), there just aren't enough {IPv4,port} tuples available for NATs to support large numbers of users with large numbers of UDP connections without having crazy-short keep-alive lifetimes. Middle-boxes will always need to be aware that this is best-effort (the FINs can be dropped or lost or not sent by malicious clients, especially during multipath transitions) but this could make life much better for well-behaved clients and things like the existing NATs which use port ranges per client might encourage clients to be well-behaved here on average. * Negotiating initial PMTU/MSS. While clients will need to be able to probe up/down and respond to routing changes that change the PMTU, the TCP MSS mechanism and ability for middle boxes to decrement/clamp this value makes a big difference in how quickly clients behind tunnels can converge without losing round-trips or having very complicated probing. Especially if we want to be able to deploy jumbo-frames it will be important to have a mechanism here. * Sending signals in both directions that can be correlated to connections. Using ICMP/ICMPv6 may be a fine way to do this but having a common prefix for connection information that can be included in the message makes some things such as routing the messages through a load-balancer much more viable). * ... there may be a few others from the use-cases doc. Having a fixed header prefix format might also make it much more viable to implement with today's router/firewall hardware with just firmware/software updates which might make a big difference for medium-term uptake. It might be we can get away with something like: [MAGIC+VERSION] [CONNECTION_ID] [BITS_FOR_SYN_FIN] [MSS_DURING_NEGOTIATION_WHEN_SYN_IS_SET] [EXTENSION_SPACE_OSSIFICATION_MAY_NOT_PASS] It might be reasonable to allow for some padding space for future extension and research, but with the expectation that this will often get dropped/filtered and thus would be something clients would need to probe for (and is something people could find a way to do today regardless). Erik --001a1147584cba40a30538b36de9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 25, 2016 at 4:20 PM, Mirja K=C3=BChlewind <mirja.kue= hlewind@tik.ee.ethz.ch> wrote:
As mentioned by Ted, this is actually not what we propose. The mechanis= m we propose is exposing information under endpoint control which is a very= important point here. The endpoint has to add an option to send (or reques= t) a specific bit of information (which also must be registered by IANA wit= h IESG approval). This is just the same as TCP options or IP option headers= . The only difference is that PLUS has a MAC which allows detection of midd= lebox manipulation (which is not the case for other existing protocols such= as TCP options). This is another a very big and important aspect of what w= e propose with PLUS as our goal is to encrypt everything above PLUS includi= ng the TCP header and TCP options in future. Especially encrypting TCP opti= on is important because TCP options provide much less control than what we = propose with PLUS today which is a problem (especially as currently still u= nto 90% of the traffic is TCP). So I actually though we are on the same pag= e here and have a common goal.

I'm = not sure that we get enough value out of extensibility or being overly gene= ric here, at least for practical non-research purposes.=C2=A0 If there is a= tightly defined set of things allowed, we'll quickly ossify on these a= nyways.=C2=A0 As firewall vendors will just bake in those registered by IAN= A when they ship their product and then we'll be right back where we ar= e today with IPv6 extension headers.

I'd propose that= it may make more sense to define a fixed header prefix format that contain= s the right set of features needed to solve the problems of QUIC and WebRTC= (and other future UDP protocols).=C2=A0 Along with this, also define a com= mon set of requirements for protocols using this header prefix (eg, around = DDoS reflection prevention).

Having a toolkit for things = like handling connection ids in a way that support multipath mobility, stat= eless load-balancers, DDoS resiliance, and which minimize linkability would= also be a nice-to-have to prevent each UDP protocol from having to come up= with subtly different ways to solve this set of problems.
For example, a bare minimum set of features might include:
=

* Opportunistic signalling to middle-boxes (NATs = and Firewalls) for when they can discard connection state.=C2=A0 Unless we = want to declare that new UDP protocols only work with IPv6 (worth seriously= considering, but perhaps not realistic yet), there just aren't enough = {IPv4,port} tuples available for NATs to support large numbers of users wit= h large numbers of UDP connections without having crazy-short keep-alive li= fetimes.=C2=A0 Middle-boxes will always need to be aware that this is best-= effort (the FINs can be dropped or lost or not sent by malicious clients, e= specially during multipath transitions) but this could make life much bette= r for well-behaved clients and things like the existing NATs which use port= ranges per client might encourage clients to be well-behaved here on avera= ge.

* Negotiating initial PMTU/MSS.=C2=A0 While clients w= ill need to be able to probe up/down and respond to routing changes that ch= ange the PMTU, the TCP MSS mechanism and ability for middle boxes to decrem= ent/clamp this value makes a big difference in how quickly clients behind t= unnels can converge without losing round-trips or having very complicated p= robing.=C2=A0 Especially if we want to be able to deploy jumbo-frames it wi= ll be important to have a mechanism here.

* Se= nding signals in both directions that can be correlated to connections.=C2= =A0 Using ICMP/ICMPv6 may be a fine way to do this but having a common pref= ix for connection information that can be included in the message makes som= e things such as routing the messages through a load-balancer much more via= ble).

* ... there may be a few others from the= use-cases doc.

Having a fixed header prefix f= ormat might also make it much more viable to implement with today's rou= ter/firewall hardware with just firmware/software updates which might make = a big difference for medium-term uptake.
It might be we can g= et away with something like:

=C2=A0=C2=A0 [MAGIC+VERSION]= [CONNECTION_ID] [BITS_FOR_SYN_FIN]
=C2=A0=C2=A0 [MSS_DURING_NEGOTIATION= _WHEN_SYN_IS_SET]
=C2=A0=C2=A0 [EXTENSION_SPACE_OSSIFICATION_= MAY_NOT_PASS]

It might be reasonable to allow = for some padding space for future extension and research, but with the expe= ctation that this will often get dropped/filtered and thus would be somethi= ng clients would need to probe for (and is something people could find a wa= y to do today regardless).

=C2=A0=C2=A0=C2=A0 = Erik




=C2=A0
--001a1147584cba40a30538b36de9-- From nobody Thu Jul 28 08:24:03 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6D512D648 for ; Thu, 28 Jul 2016 08:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 K3_BluNhF8pd for ; Thu, 28 Jul 2016 08:23:59 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AE612D0B5 for ; Thu, 28 Jul 2016 08:23:58 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0294.000; Thu, 28 Jul 2016 11:23:57 -0400 From: Dave Dolson To: Erik Nygren , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) Thread-Index: AQHR6OEiIxuSeQh0Z0+bOsaZ6LcIY6At8qcA Date: Thu, 28 Jul 2016 15:23:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9831045CD8wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Cc: Kyle Rose , "spud@ietf.org" Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 15:24:01 -0000 --_000_E8355113905631478EFF04F5AA706E9831045CD8wtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVnYXJkaW5nIHRoZSBzdGF0ZSBrZXB0IGJ5IG1pZGRsZS1ib3hlcyBzdWNoIGFzIGZpcmV3YWxs czoNClRoZSB0aW1lb3V0IHNob3VsZCBiZSBzaG9ydCAoYSBmZXcgc2Vjb25kcykgdW50aWwgYSB0 aHJlZS13YXkgaGFuZHNoYWtlIGlzIGNvbXBsZXRlLiBUaGlzIGlzIHJlcXVpcmVkIHRvIGRlZmVu ZCBhZ2FpbnN0IGF0dGFja3Mgb24gc3RhdGUgbWVtb3J5IG9mIHRoZSBmaXJld2FsbC4NCg0KSW4g dGhlIHRocmVlLXdheSBoYW5kc2hha2U6DQotIFRoZSBzZXJ2ZXLigJlzIFNZTi1BQ0sgaW5kaWNh dGVzIHRoZSBzZXJ2ZXIgaXMgcmVhbCBhbmQgd2lsbGluZyB0byB0YWxrIHRvIHRoZSBjbGllbnQu DQotIHRoZSBjbGllbnTigJlzIEFDSyBvZiB0aGUgc2VydmVy4oCZcyBTWU4tQUNLIHByb3ZpZGVz IGV2aWRlbmNlIHRoZSBjbGllbnQgaXMgcmVhbCAodnMuIHNwb29mZWQpIGFuZCBoYXMgd2l0bmVz c2VkIHRoZSBTWU4tQUNLDQoNClRoZSByYW5kb20gc2VxdWVuY2UgbnVtYmVycyBhbmQgYWNrIG51 bWJlcnMgYXJlIHZhbHVhYmxlIGluIHRoaXMgcmVnYXJkLiBFLmcuLCBhIHNwb29maW5nIGRldmlj ZSBjYW5ub3Qgc2ltcGx5IHNlbmQgdGhlIGZpcnN0IGFuZCB0aGlyZCBwYWNrZXRzIGJlY2F1c2Ug dGhlIHRoaXJkIHBhY2tldCBtdXN0IGNvcnJlY3RseSBBQ0sgdGhlIHNlY29uZCBwYWNrZXQgZnJv bSB0aGUgc2VydmVyLg0KDQpPbmNlIGEgdGhyZWUtd2F5IGhhbmRzaGFrZSBpcyB3aXRuZXNzZWQs IFRDUCBzdGF0ZSB0aW1lb3V0IGNhbiBiZSBzZXZlcmFsIG1pbnV0ZXMuDQoNClRoZSBwcm9wb3Nh bCBiZWxvdyBkb2VzbuKAmXQgc2VlbSB0byBjb250YWluIGVub3VnaCBpbmZvcm1hdGlvbiBmb3Ig YSBmaXJld2FsbCB0byBrbm93IHRoZSBjbGllbnQgaXMgcmVhbC4NCkNvbnNpZGVyIGFkZGluZyBh IHJhbmRvbSBudW1iZXIgdGhhdCBlYWNoIHNpZGUgY2FuIGVjaG8gYmFjaz8gUGVyaGFwcyBhIGRp ZmZlcmVudCBjb25uZWN0aW9uLUlEIHBlciBkaXJlY3Rpb24/DQoNCi1EYXZlDQoNCg0KDQpGcm9t OiBTcHVkIFttYWlsdG86c3B1ZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpayBO eWdyZW4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDI4LCAyMDE2IDExOjAzIEFNDQpUbzogTWlyamEg S8O8aGxld2luZA0KQ2M6IEt5bGUgUm9zZTsgc3B1ZEBpZXRmLm9yZw0KU3ViamVjdDogW1NwdWRd IEJhcmUtbWluaW11bSBQTFVTICh3YXMgUmU6IFRob3VnaHRzIG9uIHRoZSBwcml2YWN5IGNvbmNl cm5zIGV4cHJlc3NlZCBhdCB0aGUgQm9GKQ0KDQpPbiBNb24sIEp1bCAyNSwgMjAxNiBhdCA0OjIw IFBNLCBNaXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPG1h aWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPj4gd3JvdGU6DQpBcyBtZW50aW9u ZWQgYnkgVGVkLCB0aGlzIGlzIGFjdHVhbGx5IG5vdCB3aGF0IHdlIHByb3Bvc2UuIFRoZSBtZWNo YW5pc20gd2UgcHJvcG9zZSBpcyBleHBvc2luZyBpbmZvcm1hdGlvbiB1bmRlciBlbmRwb2ludCBj b250cm9sIHdoaWNoIGlzIGEgdmVyeSBpbXBvcnRhbnQgcG9pbnQgaGVyZS4gVGhlIGVuZHBvaW50 IGhhcyB0byBhZGQgYW4gb3B0aW9uIHRvIHNlbmQgKG9yIHJlcXVlc3QpIGEgc3BlY2lmaWMgYml0 IG9mIGluZm9ybWF0aW9uICh3aGljaCBhbHNvIG11c3QgYmUgcmVnaXN0ZXJlZCBieSBJQU5BIHdp dGggSUVTRyBhcHByb3ZhbCkuIFRoaXMgaXMganVzdCB0aGUgc2FtZSBhcyBUQ1Agb3B0aW9ucyBv ciBJUCBvcHRpb24gaGVhZGVycy4gVGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0aGF0IFBMVVMgaGFz IGEgTUFDIHdoaWNoIGFsbG93cyBkZXRlY3Rpb24gb2YgbWlkZGxlYm94IG1hbmlwdWxhdGlvbiAo d2hpY2ggaXMgbm90IHRoZSBjYXNlIGZvciBvdGhlciBleGlzdGluZyBwcm90b2NvbHMgc3VjaCBh cyBUQ1Agb3B0aW9ucykuIFRoaXMgaXMgYW5vdGhlciBhIHZlcnkgYmlnIGFuZCBpbXBvcnRhbnQg YXNwZWN0IG9mIHdoYXQgd2UgcHJvcG9zZSB3aXRoIFBMVVMgYXMgb3VyIGdvYWwgaXMgdG8gZW5j cnlwdCBldmVyeXRoaW5nIGFib3ZlIFBMVVMgaW5jbHVkaW5nIHRoZSBUQ1AgaGVhZGVyIGFuZCBU Q1Agb3B0aW9ucyBpbiBmdXR1cmUuIEVzcGVjaWFsbHkgZW5jcnlwdGluZyBUQ1Agb3B0aW9uIGlz IGltcG9ydGFudCBiZWNhdXNlIFRDUCBvcHRpb25zIHByb3ZpZGUgbXVjaCBsZXNzIGNvbnRyb2wg dGhhbiB3aGF0IHdlIHByb3Bvc2Ugd2l0aCBQTFVTIHRvZGF5IHdoaWNoIGlzIGEgcHJvYmxlbSAo ZXNwZWNpYWxseSBhcyBjdXJyZW50bHkgc3RpbGwgdW50byA5MCUgb2YgdGhlIHRyYWZmaWMgaXMg VENQKS4gU28gSSBhY3R1YWxseSB0aG91Z2ggd2UgYXJlIG9uIHRoZSBzYW1lIHBhZ2UgaGVyZSBh bmQgaGF2ZSBhIGNvbW1vbiBnb2FsLg0KDQpJJ20gbm90IHN1cmUgdGhhdCB3ZSBnZXQgZW5vdWdo IHZhbHVlIG91dCBvZiBleHRlbnNpYmlsaXR5IG9yIGJlaW5nIG92ZXJseSBnZW5lcmljIGhlcmUs IGF0IGxlYXN0IGZvciBwcmFjdGljYWwgbm9uLXJlc2VhcmNoIHB1cnBvc2VzLiAgSWYgdGhlcmUg aXMgYSB0aWdodGx5IGRlZmluZWQgc2V0IG9mIHRoaW5ncyBhbGxvd2VkLCB3ZSdsbCBxdWlja2x5 IG9zc2lmeSBvbiB0aGVzZSBhbnl3YXlzLiAgQXMgZmlyZXdhbGwgdmVuZG9ycyB3aWxsIGp1c3Qg YmFrZSBpbiB0aG9zZSByZWdpc3RlcmVkIGJ5IElBTkEgd2hlbiB0aGV5IHNoaXAgdGhlaXIgcHJv ZHVjdCBhbmQgdGhlbiB3ZSdsbCBiZSByaWdodCBiYWNrIHdoZXJlIHdlIGFyZSB0b2RheSB3aXRo IElQdjYgZXh0ZW5zaW9uIGhlYWRlcnMuDQpJJ2QgcHJvcG9zZSB0aGF0IGl0IG1heSBtYWtlIG1v cmUgc2Vuc2UgdG8gZGVmaW5lIGEgZml4ZWQgaGVhZGVyIHByZWZpeCBmb3JtYXQgdGhhdCBjb250 YWlucyB0aGUgcmlnaHQgc2V0IG9mIGZlYXR1cmVzIG5lZWRlZCB0byBzb2x2ZSB0aGUgcHJvYmxl bXMgb2YgUVVJQyBhbmQgV2ViUlRDIChhbmQgb3RoZXIgZnV0dXJlIFVEUCBwcm90b2NvbHMpLiAg QWxvbmcgd2l0aCB0aGlzLCBhbHNvIGRlZmluZSBhIGNvbW1vbiBzZXQgb2YgcmVxdWlyZW1lbnRz IGZvciBwcm90b2NvbHMgdXNpbmcgdGhpcyBoZWFkZXIgcHJlZml4IChlZywgYXJvdW5kIEREb1Mg cmVmbGVjdGlvbiBwcmV2ZW50aW9uKS4NCkhhdmluZyBhIHRvb2xraXQgZm9yIHRoaW5ncyBsaWtl IGhhbmRsaW5nIGNvbm5lY3Rpb24gaWRzIGluIGEgd2F5IHRoYXQgc3VwcG9ydCBtdWx0aXBhdGgg bW9iaWxpdHksIHN0YXRlbGVzcyBsb2FkLWJhbGFuY2VycywgRERvUyByZXNpbGlhbmNlLCBhbmQg d2hpY2ggbWluaW1pemUgbGlua2FiaWxpdHkgd291bGQgYWxzbyBiZSBhIG5pY2UtdG8taGF2ZSB0 byBwcmV2ZW50IGVhY2ggVURQIHByb3RvY29sIGZyb20gaGF2aW5nIHRvIGNvbWUgdXAgd2l0aCBz dWJ0bHkgZGlmZmVyZW50IHdheXMgdG8gc29sdmUgdGhpcyBzZXQgb2YgcHJvYmxlbXMuDQoNCkZv ciBleGFtcGxlLCBhIGJhcmUgbWluaW11bSBzZXQgb2YgZmVhdHVyZXMgbWlnaHQgaW5jbHVkZToN Cg0KKiBPcHBvcnR1bmlzdGljIHNpZ25hbGxpbmcgdG8gbWlkZGxlLWJveGVzIChOQVRzIGFuZCBG aXJld2FsbHMpIGZvciB3aGVuIHRoZXkgY2FuIGRpc2NhcmQgY29ubmVjdGlvbiBzdGF0ZS4gIFVu bGVzcyB3ZSB3YW50IHRvIGRlY2xhcmUgdGhhdCBuZXcgVURQIHByb3RvY29scyBvbmx5IHdvcmsg d2l0aCBJUHY2ICh3b3J0aCBzZXJpb3VzbHkgY29uc2lkZXJpbmcsIGJ1dCBwZXJoYXBzIG5vdCBy ZWFsaXN0aWMgeWV0KSwgdGhlcmUganVzdCBhcmVuJ3QgZW5vdWdoIHtJUHY0LHBvcnR9IHR1cGxl cyBhdmFpbGFibGUgZm9yIE5BVHMgdG8gc3VwcG9ydCBsYXJnZSBudW1iZXJzIG9mIHVzZXJzIHdp dGggbGFyZ2UgbnVtYmVycyBvZiBVRFAgY29ubmVjdGlvbnMgd2l0aG91dCBoYXZpbmcgY3Jhenkt c2hvcnQga2VlcC1hbGl2ZSBsaWZldGltZXMuICBNaWRkbGUtYm94ZXMgd2lsbCBhbHdheXMgbmVl ZCB0byBiZSBhd2FyZSB0aGF0IHRoaXMgaXMgYmVzdC1lZmZvcnQgKHRoZSBGSU5zIGNhbiBiZSBk cm9wcGVkIG9yIGxvc3Qgb3Igbm90IHNlbnQgYnkgbWFsaWNpb3VzIGNsaWVudHMsIGVzcGVjaWFs bHkgZHVyaW5nIG11bHRpcGF0aCB0cmFuc2l0aW9ucykgYnV0IHRoaXMgY291bGQgbWFrZSBsaWZl IG11Y2ggYmV0dGVyIGZvciB3ZWxsLWJlaGF2ZWQgY2xpZW50cyBhbmQgdGhpbmdzIGxpa2UgdGhl IGV4aXN0aW5nIE5BVHMgd2hpY2ggdXNlIHBvcnQgcmFuZ2VzIHBlciBjbGllbnQgbWlnaHQgZW5j b3VyYWdlIGNsaWVudHMgdG8gYmUgd2VsbC1iZWhhdmVkIGhlcmUgb24gYXZlcmFnZS4NCiogTmVn b3RpYXRpbmcgaW5pdGlhbCBQTVRVL01TUy4gIFdoaWxlIGNsaWVudHMgd2lsbCBuZWVkIHRvIGJl IGFibGUgdG8gcHJvYmUgdXAvZG93biBhbmQgcmVzcG9uZCB0byByb3V0aW5nIGNoYW5nZXMgdGhh dCBjaGFuZ2UgdGhlIFBNVFUsIHRoZSBUQ1AgTVNTIG1lY2hhbmlzbSBhbmQgYWJpbGl0eSBmb3Ig bWlkZGxlIGJveGVzIHRvIGRlY3JlbWVudC9jbGFtcCB0aGlzIHZhbHVlIG1ha2VzIGEgYmlnIGRp ZmZlcmVuY2UgaW4gaG93IHF1aWNrbHkgY2xpZW50cyBiZWhpbmQgdHVubmVscyBjYW4gY29udmVy Z2Ugd2l0aG91dCBsb3Npbmcgcm91bmQtdHJpcHMgb3IgaGF2aW5nIHZlcnkgY29tcGxpY2F0ZWQg cHJvYmluZy4gIEVzcGVjaWFsbHkgaWYgd2Ugd2FudCB0byBiZSBhYmxlIHRvIGRlcGxveSBqdW1i by1mcmFtZXMgaXQgd2lsbCBiZSBpbXBvcnRhbnQgdG8gaGF2ZSBhIG1lY2hhbmlzbSBoZXJlLg0K DQoqIFNlbmRpbmcgc2lnbmFscyBpbiBib3RoIGRpcmVjdGlvbnMgdGhhdCBjYW4gYmUgY29ycmVs YXRlZCB0byBjb25uZWN0aW9ucy4gIFVzaW5nIElDTVAvSUNNUHY2IG1heSBiZSBhIGZpbmUgd2F5 IHRvIGRvIHRoaXMgYnV0IGhhdmluZyBhIGNvbW1vbiBwcmVmaXggZm9yIGNvbm5lY3Rpb24gaW5m b3JtYXRpb24gdGhhdCBjYW4gYmUgaW5jbHVkZWQgaW4gdGhlIG1lc3NhZ2UgbWFrZXMgc29tZSB0 aGluZ3Mgc3VjaCBhcyByb3V0aW5nIHRoZSBtZXNzYWdlcyB0aHJvdWdoIGEgbG9hZC1iYWxhbmNl ciBtdWNoIG1vcmUgdmlhYmxlKS4NCg0KKiAuLi4gdGhlcmUgbWF5IGJlIGEgZmV3IG90aGVycyBm cm9tIHRoZSB1c2UtY2FzZXMgZG9jLg0KDQpIYXZpbmcgYSBmaXhlZCBoZWFkZXIgcHJlZml4IGZv cm1hdCBtaWdodCBhbHNvIG1ha2UgaXQgbXVjaCBtb3JlIHZpYWJsZSB0byBpbXBsZW1lbnQgd2l0 aCB0b2RheSdzIHJvdXRlci9maXJld2FsbCBoYXJkd2FyZSB3aXRoIGp1c3QgZmlybXdhcmUvc29m dHdhcmUgdXBkYXRlcyB3aGljaCBtaWdodCBtYWtlIGEgYmlnIGRpZmZlcmVuY2UgZm9yIG1lZGl1 bS10ZXJtIHVwdGFrZS4NCkl0IG1pZ2h0IGJlIHdlIGNhbiBnZXQgYXdheSB3aXRoIHNvbWV0aGlu ZyBsaWtlOg0KICAgW01BR0lDK1ZFUlNJT05dIFtDT05ORUNUSU9OX0lEXSBbQklUU19GT1JfU1lO X0ZJTl0NCiAgIFtNU1NfRFVSSU5HX05FR09USUFUSU9OX1dIRU5fU1lOX0lTX1NFVF0NCiAgIFtF WFRFTlNJT05fU1BBQ0VfT1NTSUZJQ0FUSU9OX01BWV9OT1RfUEFTU10NCg0KSXQgbWlnaHQgYmUg cmVhc29uYWJsZSB0byBhbGxvdyBmb3Igc29tZSBwYWRkaW5nIHNwYWNlIGZvciBmdXR1cmUgZXh0 ZW5zaW9uIGFuZCByZXNlYXJjaCwgYnV0IHdpdGggdGhlIGV4cGVjdGF0aW9uIHRoYXQgdGhpcyB3 aWxsIG9mdGVuIGdldCBkcm9wcGVkL2ZpbHRlcmVkIGFuZCB0aHVzIHdvdWxkIGJlIHNvbWV0aGlu ZyBjbGllbnRzIHdvdWxkIG5lZWQgdG8gcHJvYmUgZm9yIChhbmQgaXMgc29tZXRoaW5nIHBlb3Bs ZSBjb3VsZCBmaW5kIGEgd2F5IHRvIGRvIHRvZGF5IHJlZ2FyZGxlc3MpLg0KDQogICAgRXJpaw0K DQoNCg0K --_000_E8355113905631478EFF04F5AA706E9831045CD8wtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRpbmcgdGhlIHN0YXRlIGtlcHQgYnkgbWlkZGxl LWJveGVzIHN1Y2ggYXMgZmlyZXdhbGxzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGUgdGltZW91dCBzaG91bGQgYmUgc2hvcnQgKGEgZmV3IHNlY29uZHMpIHVudGlsIGEgdGhyZWUt d2F5IGhhbmRzaGFrZSBpcyBjb21wbGV0ZS4gVGhpcyBpcyByZXF1aXJlZCB0byBkZWZlbmQgYWdh aW5zdCBhdHRhY2tzIG9uIHN0YXRlIG1lbW9yeSBvZiB0aGUgZmlyZXdhbGwuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J biB0aGUgdGhyZWUtd2F5IGhhbmRzaGFrZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ LSBUaGUgc2VydmVy4oCZcyBTWU4tQUNLIGluZGljYXRlcyB0aGUgc2VydmVyIGlzIHJlYWwgYW5k IHdpbGxpbmcgdG8gdGFsayB0byB0aGUgY2xpZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPi0gdGhlIGNsaWVudOKAmXMgQUNLIG9mIHRoZSBzZXJ2ZXLigJlzIFNZTi1BQ0sgcHJv dmlkZXMgZXZpZGVuY2UgdGhlIGNsaWVudCBpcyByZWFsICh2cy4gc3Bvb2ZlZCkgYW5kIGhhcyB3 aXRuZXNzZWQgdGhlIFNZTi1BQ0s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSByYW5kb20gc2VxdWVuY2UgbnVtYmVy cyBhbmQgYWNrIG51bWJlcnMgYXJlIHZhbHVhYmxlIGluIHRoaXMgcmVnYXJkLiBFLmcuLCBhIHNw b29maW5nIGRldmljZSBjYW5ub3Qgc2ltcGx5IHNlbmQgdGhlIGZpcnN0IGFuZCB0aGlyZCBwYWNr ZXRzIGJlY2F1c2UgdGhlDQogdGhpcmQgcGFja2V0IG11c3QgY29ycmVjdGx5IEFDSyB0aGUgc2Vj b25kIHBhY2tldCBmcm9tIHRoZSBzZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmNlIGEgdGhyZWUtd2F5IGhh bmRzaGFrZSBpcyB3aXRuZXNzZWQsIFRDUCBzdGF0ZSB0aW1lb3V0IGNhbiBiZSBzZXZlcmFsIG1p bnV0ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGUgcHJvcG9zYWwgYmVsb3cgZG9lc27igJl0IHNlZW0gdG8gY29u dGFpbiBlbm91Z2ggaW5mb3JtYXRpb24gZm9yIGEgZmlyZXdhbGwgdG8ga25vdyB0aGUgY2xpZW50 IGlzIHJlYWwuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgYWRkaW5n IGEgcmFuZG9tIG51bWJlciB0aGF0IGVhY2ggc2lkZSBjYW4gZWNobyBiYWNrPyBQZXJoYXBzIGEg ZGlmZmVyZW50IGNvbm5lY3Rpb24tSUQgcGVyIGRpcmVjdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1EYXZlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNwdWQgW21haWx0bzpzcHVkLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWsgTnlncmVuPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBKdWx5IDI4LCAyMDE2IDExOjAzIEFNPGJyPg0KPGI+VG86PC9iPiBNaXJqYSBL w7xobGV3aW5kPGJyPg0KPGI+Q2M6PC9iPiBLeWxlIFJvc2U7IHNwdWRAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW1NwdWRdIEJhcmUtbWluaW11bSBQTFVTICh3YXMgUmU6IFRob3VnaHRz IG9uIHRoZSBwcml2YWN5IGNvbmNlcm5zIGV4cHJlc3NlZCBhdCB0aGUgQm9GKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24s IEp1bCAyNSwgMjAxNiBhdCA0OjIwIFBNLCBNaXJqYSBLw7xobGV3aW5kICZsdDs8YSBocmVmPSJt YWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCIgdGFyZ2V0PSJfYmxhbmsiPm1p cmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIG1lbnRpb25lZCBieSBUZWQsIHRoaXMgaXMgYWN0 dWFsbHkgbm90IHdoYXQgd2UgcHJvcG9zZS4gVGhlIG1lY2hhbmlzbSB3ZSBwcm9wb3NlIGlzIGV4 cG9zaW5nIGluZm9ybWF0aW9uIHVuZGVyIGVuZHBvaW50IGNvbnRyb2wgd2hpY2ggaXMgYSB2ZXJ5 IGltcG9ydGFudCBwb2ludCBoZXJlLiBUaGUgZW5kcG9pbnQgaGFzIHRvIGFkZCBhbiBvcHRpb24g dG8gc2VuZCAob3IgcmVxdWVzdCkgYSBzcGVjaWZpYyBiaXQNCiBvZiBpbmZvcm1hdGlvbiAod2hp Y2ggYWxzbyBtdXN0IGJlIHJlZ2lzdGVyZWQgYnkgSUFOQSB3aXRoIElFU0cgYXBwcm92YWwpLiBU aGlzIGlzIGp1c3QgdGhlIHNhbWUgYXMgVENQIG9wdGlvbnMgb3IgSVAgb3B0aW9uIGhlYWRlcnMu IFRoZSBvbmx5IGRpZmZlcmVuY2UgaXMgdGhhdCBQTFVTIGhhcyBhIE1BQyB3aGljaCBhbGxvd3Mg ZGV0ZWN0aW9uIG9mIG1pZGRsZWJveCBtYW5pcHVsYXRpb24gKHdoaWNoIGlzIG5vdCB0aGUgY2Fz ZSBmb3Igb3RoZXINCiBleGlzdGluZyBwcm90b2NvbHMgc3VjaCBhcyBUQ1Agb3B0aW9ucykuIFRo aXMgaXMgYW5vdGhlciBhIHZlcnkgYmlnIGFuZCBpbXBvcnRhbnQgYXNwZWN0IG9mIHdoYXQgd2Ug cHJvcG9zZSB3aXRoIFBMVVMgYXMgb3VyIGdvYWwgaXMgdG8gZW5jcnlwdCBldmVyeXRoaW5nIGFi b3ZlIFBMVVMgaW5jbHVkaW5nIHRoZSBUQ1AgaGVhZGVyIGFuZCBUQ1Agb3B0aW9ucyBpbiBmdXR1 cmUuIEVzcGVjaWFsbHkgZW5jcnlwdGluZyBUQ1Agb3B0aW9uIGlzIGltcG9ydGFudA0KIGJlY2F1 c2UgVENQIG9wdGlvbnMgcHJvdmlkZSBtdWNoIGxlc3MgY29udHJvbCB0aGFuIHdoYXQgd2UgcHJv cG9zZSB3aXRoIFBMVVMgdG9kYXkgd2hpY2ggaXMgYSBwcm9ibGVtIChlc3BlY2lhbGx5IGFzIGN1 cnJlbnRseSBzdGlsbCB1bnRvIDkwJSBvZiB0aGUgdHJhZmZpYyBpcyBUQ1ApLiBTbyBJIGFjdHVh bGx5IHRob3VnaCB3ZSBhcmUgb24gdGhlIHNhbWUgcGFnZSBoZXJlIGFuZCBoYXZlIGEgY29tbW9u IGdvYWwuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkknbSBub3Qgc3VyZSB0aGF0IHdlIGdldCBlbm91Z2gg dmFsdWUgb3V0IG9mIGV4dGVuc2liaWxpdHkgb3IgYmVpbmcgb3Zlcmx5IGdlbmVyaWMgaGVyZSwg YXQgbGVhc3QgZm9yIHByYWN0aWNhbCBub24tcmVzZWFyY2ggcHVycG9zZXMuJm5ic3A7IElmIHRo ZXJlIGlzIGEgdGlnaHRseSBkZWZpbmVkIHNldCBvZiB0aGluZ3MgYWxsb3dlZCwgd2UnbGwgcXVp Y2tseSBvc3NpZnkNCiBvbiB0aGVzZSBhbnl3YXlzLiZuYnNwOyBBcyBmaXJld2FsbCB2ZW5kb3Jz IHdpbGwganVzdCBiYWtlIGluIHRob3NlIHJlZ2lzdGVyZWQgYnkgSUFOQSB3aGVuIHRoZXkgc2hp cCB0aGVpciBwcm9kdWN0IGFuZCB0aGVuIHdlJ2xsIGJlIHJpZ2h0IGJhY2sgd2hlcmUgd2UgYXJl IHRvZGF5IHdpdGggSVB2NiBleHRlbnNpb24gaGVhZGVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+SSdkIHByb3Bvc2UgdGhhdCBpdCBtYXkgbWFrZSBtb3JlIHNlbnNlIHRvIGRlZmluZSBhIGZp eGVkIGhlYWRlciBwcmVmaXggZm9ybWF0IHRoYXQgY29udGFpbnMgdGhlIHJpZ2h0IHNldCBvZiBm ZWF0dXJlcyBuZWVkZWQgdG8gc29sdmUgdGhlIHByb2JsZW1zIG9mIFFVSUMgYW5kIFdlYlJUQyAo YW5kIG90aGVyIGZ1dHVyZSBVRFAgcHJvdG9jb2xzKS4mbmJzcDsgQWxvbmcNCiB3aXRoIHRoaXMs IGFsc28gZGVmaW5lIGEgY29tbW9uIHNldCBvZiByZXF1aXJlbWVudHMgZm9yIHByb3RvY29scyB1 c2luZyB0aGlzIGhlYWRlciBwcmVmaXggKGVnLCBhcm91bmQgRERvUyByZWZsZWN0aW9uIHByZXZl bnRpb24pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGF2aW5nIGEgdG9vbGtpdCBmb3IgdGhpbmdzIGxpa2UgaGFuZGxpbmcgY29ubmVjdGlvbiBp ZHMgaW4gYSB3YXkgdGhhdCBzdXBwb3J0IG11bHRpcGF0aCBtb2JpbGl0eSwgc3RhdGVsZXNzIGxv YWQtYmFsYW5jZXJzLCBERG9TIHJlc2lsaWFuY2UsIGFuZCB3aGljaCBtaW5pbWl6ZSBsaW5rYWJp bGl0eSB3b3VsZCBhbHNvIGJlIGEgbmljZS10by1oYXZlIHRvIHByZXZlbnQgZWFjaCBVRFAgcHJv dG9jb2wgZnJvbQ0KIGhhdmluZyB0byBjb21lIHVwIHdpdGggc3VidGx5IGRpZmZlcmVudCB3YXlz IHRvIHNvbHZlIHRoaXMgc2V0IG9mIHByb2JsZW1zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZXhhbXBsZSwgYSBiYXJlIG1pbmltdW0g c2V0IG9mIGZlYXR1cmVzIG1pZ2h0IGluY2x1ZGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ KiBPcHBvcnR1bmlzdGljIHNpZ25hbGxpbmcgdG8gbWlkZGxlLWJveGVzIChOQVRzIGFuZCBGaXJl d2FsbHMpIGZvciB3aGVuIHRoZXkgY2FuIGRpc2NhcmQgY29ubmVjdGlvbiBzdGF0ZS4mbmJzcDsg VW5sZXNzIHdlIHdhbnQgdG8gZGVjbGFyZSB0aGF0IG5ldyBVRFAgcHJvdG9jb2xzIG9ubHkgd29y ayB3aXRoIElQdjYgKHdvcnRoIHNlcmlvdXNseSBjb25zaWRlcmluZywNCiBidXQgcGVyaGFwcyBu b3QgcmVhbGlzdGljIHlldCksIHRoZXJlIGp1c3QgYXJlbid0IGVub3VnaCB7SVB2NCxwb3J0fSB0 dXBsZXMgYXZhaWxhYmxlIGZvciBOQVRzIHRvIHN1cHBvcnQgbGFyZ2UgbnVtYmVycyBvZiB1c2Vy cyB3aXRoIGxhcmdlIG51bWJlcnMgb2YgVURQIGNvbm5lY3Rpb25zIHdpdGhvdXQgaGF2aW5nIGNy YXp5LXNob3J0IGtlZXAtYWxpdmUgbGlmZXRpbWVzLiZuYnNwOyBNaWRkbGUtYm94ZXMgd2lsbCBh bHdheXMgbmVlZCB0byBiZSBhd2FyZQ0KIHRoYXQgdGhpcyBpcyBiZXN0LWVmZm9ydCAodGhlIEZJ TnMgY2FuIGJlIGRyb3BwZWQgb3IgbG9zdCBvciBub3Qgc2VudCBieSBtYWxpY2lvdXMgY2xpZW50 cywgZXNwZWNpYWxseSBkdXJpbmcgbXVsdGlwYXRoIHRyYW5zaXRpb25zKSBidXQgdGhpcyBjb3Vs ZCBtYWtlIGxpZmUgbXVjaCBiZXR0ZXIgZm9yIHdlbGwtYmVoYXZlZCBjbGllbnRzIGFuZCB0aGlu Z3MgbGlrZSB0aGUgZXhpc3RpbmcgTkFUcyB3aGljaCB1c2UgcG9ydCByYW5nZXMgcGVyIGNsaWVu dA0KIG1pZ2h0IGVuY291cmFnZSBjbGllbnRzIHRvIGJlIHdlbGwtYmVoYXZlZCBoZXJlIG9uIGF2 ZXJhZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4qIE5lZ290aWF0aW5nIGluaXRpYWwgUE1UVS9NU1MuJm5ic3A7IFdoaWxlIGNsaWVudHMgd2ls bCBuZWVkIHRvIGJlIGFibGUgdG8gcHJvYmUgdXAvZG93biBhbmQgcmVzcG9uZCB0byByb3V0aW5n IGNoYW5nZXMgdGhhdCBjaGFuZ2UgdGhlIFBNVFUsIHRoZSBUQ1AgTVNTIG1lY2hhbmlzbSBhbmQg YWJpbGl0eSBmb3IgbWlkZGxlIGJveGVzIHRvIGRlY3JlbWVudC9jbGFtcCB0aGlzIHZhbHVlIG1h a2VzIGEgYmlnIGRpZmZlcmVuY2UNCiBpbiBob3cgcXVpY2tseSBjbGllbnRzIGJlaGluZCB0dW5u ZWxzIGNhbiBjb252ZXJnZSB3aXRob3V0IGxvc2luZyByb3VuZC10cmlwcyBvciBoYXZpbmcgdmVy eSBjb21wbGljYXRlZCBwcm9iaW5nLiZuYnNwOyBFc3BlY2lhbGx5IGlmIHdlIHdhbnQgdG8gYmUg YWJsZSB0byBkZXBsb3kganVtYm8tZnJhbWVzIGl0IHdpbGwgYmUgaW1wb3J0YW50IHRvIGhhdmUg YSBtZWNoYW5pc20gaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+KiBTZW5kaW5nIHNpZ25hbHMgaW4gYm90aCBkaXJlY3Rpb25zIHRoYXQg Y2FuIGJlIGNvcnJlbGF0ZWQgdG8gY29ubmVjdGlvbnMuJm5ic3A7IFVzaW5nIElDTVAvSUNNUHY2 IG1heSBiZSBhIGZpbmUgd2F5IHRvIGRvIHRoaXMgYnV0IGhhdmluZyBhIGNvbW1vbiBwcmVmaXgg Zm9yIGNvbm5lY3Rpb24gaW5mb3JtYXRpb24gdGhhdCBjYW4gYmUgaW5jbHVkZWQgaW4gdGhlIG1l c3NhZ2UgbWFrZXMgc29tZSB0aGluZ3Mgc3VjaA0KIGFzIHJvdXRpbmcgdGhlIG1lc3NhZ2VzIHRo cm91Z2ggYSBsb2FkLWJhbGFuY2VyIG11Y2ggbW9yZSB2aWFibGUpLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIC4uLiB0aGVyZSBtYXkgYmUg YSBmZXcgb3RoZXJzIGZyb20gdGhlIHVzZS1jYXNlcyBkb2MuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhdmluZyBhIGZpeGVkIGhlYWRlciBw cmVmaXggZm9ybWF0IG1pZ2h0IGFsc28gbWFrZSBpdCBtdWNoIG1vcmUgdmlhYmxlIHRvIGltcGxl bWVudCB3aXRoIHRvZGF5J3Mgcm91dGVyL2ZpcmV3YWxsIGhhcmR3YXJlIHdpdGgganVzdCBmaXJt d2FyZS9zb2Z0d2FyZSB1cGRhdGVzIHdoaWNoIG1pZ2h0IG1ha2UgYSBiaWcgZGlmZmVyZW5jZSBm b3IgbWVkaXVtLXRlcm0gdXB0YWtlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JdCBtaWdodCBi ZSB3ZSBjYW4gZ2V0IGF3YXkgd2l0aCBzb21ldGhpbmcgbGlrZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBbTUFHSUMmIzQz O1ZFUlNJT05dIFtDT05ORUNUSU9OX0lEXSBbQklUU19GT1JfU1lOX0ZJTl08YnI+DQombmJzcDsm bmJzcDsgW01TU19EVVJJTkdfTkVHT1RJQVRJT05fV0hFTl9TWU5fSVNfU0VUXTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IFtF WFRFTlNJT05fU1BBQ0VfT1NTSUZJQ0FUSU9OX01BWV9OT1RfUEFTU108bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgbWlnaHQgYmUgcmVhc29u YWJsZSB0byBhbGxvdyBmb3Igc29tZSBwYWRkaW5nIHNwYWNlIGZvciBmdXR1cmUgZXh0ZW5zaW9u IGFuZCByZXNlYXJjaCwgYnV0IHdpdGggdGhlIGV4cGVjdGF0aW9uIHRoYXQgdGhpcyB3aWxsIG9m dGVuIGdldCBkcm9wcGVkL2ZpbHRlcmVkIGFuZCB0aHVzIHdvdWxkIGJlIHNvbWV0aGluZyBjbGll bnRzIHdvdWxkIG5lZWQgdG8gcHJvYmUgZm9yIChhbmQgaXMgc29tZXRoaW5nIHBlb3BsZQ0KIGNv dWxkIGZpbmQgYSB3YXkgdG8gZG8gdG9kYXkgcmVnYXJkbGVzcykuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVyaWs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E8355113905631478EFF04F5AA706E9831045CD8wtlexchp2sandvi_-- From nobody Thu Jul 28 08:57:00 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90FD12D755 for ; Thu, 28 Jul 2016 08:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAFxlVfvw384 for ; Thu, 28 Jul 2016 08:56:56 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 3C00412D0DC for ; Thu, 28 Jul 2016 08:56:56 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id q83so104027015iod.1 for ; Thu, 28 Jul 2016 08:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nU09KPfypBW3/7E/CAdiZIBHJ1engxn+iX4FclcxXow=; b=S/fljSkHximpRcM2zxwx2qQZ4gJ/rYK2Y95KzReT9n38RJbLP0CJ3ZrpotxTq1uLrY zg47rD4+ExuSOPqwpW7hzBxGGZd+WmdJIE6p483dAIboFlmUPXbOrSF9/m6IDcJE2OQ5 baJNpSZ5zIWV8IBij+H7weBXp3SVUi2AfMTm8mLXgCepJiMUC3XPTUgo8quFlDU+A9vK 4vva50+DeKe44DwSe6eSjgPMfg4ZLgNAM+R5TiIedzWTR8G1q2FtdqBmfm895MtVWi6Z 4Y0I7ULyI7x0JGPIa6x2wBejJj8zFY0dijcVBztOnBYtY+unpvdiEGSUiwAo5gcmZXyY Pj3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nU09KPfypBW3/7E/CAdiZIBHJ1engxn+iX4FclcxXow=; b=FPVWDT41HL+M41IfWVnMYmh0yju4UcxTKqy9s3Bw9AZ68w4Q4j4wm+6sIbLGFUVFCW o65ZzXwiGbvbMhZzXSO1ZKrBS+mebfWymZc9DESeySlMe+8Gfy8w19L4utPf6SWn/I2O wFvJQEJAmyAgMRfwwDwlSRvyQn1e72CL6gf7sOf4Eb+HKbGu1NWL0diJKyvCKYYIvmOW ZqJzkI99pKBBFkxo4jytDROl/bngthIjs0chf1bDkHYB2DPD5NXa6pzP8EdOz+DA1qNj AiSLhF8om7LOxLshplgcq+fBhk6oMZcnlepVWLkPo+hXVVP48Hf8qVepUsvlB1OkwZbO aYoA== X-Gm-Message-State: AEkoouvivkAXSL63vOJxNuZRbzTEbPyfeAkwAILLrJo/hZQJGuqdWBzcJjZhwqys4Q6JQSTLNMjA0fuHaCtM9g== X-Received: by 10.107.44.66 with SMTP id s63mr39563161ios.186.1469721415531; Thu, 28 Jul 2016 08:56:55 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.107.137.69 with HTTP; Thu, 28 Jul 2016 08:56:54 -0700 (PDT) In-Reply-To: References: From: Erik Nygren Date: Thu, 28 Jul 2016 11:56:54 -0400 X-Google-Sender-Auth: QCmcqNotmA6bcQkN4L8tECNFHwc Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=001a11393e16e445c30538b42e1f Archived-At: Cc: Kyle Rose , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "spud@ietf.org" Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 15:56:59 -0000 --001a11393e16e445c30538b42e1f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is exactly the sort of thing that I think demonstrates the value of defining something here so we can have one mechanism that a bunch of UDP protocols can use to allow for several minute state timeouts. With TCP you need the sequence/ack numbers to get enough entropy due to the port number being only 16 bits. If the connection-id is 64 bits (or there are two 64-bit connection-ids in the packet, one contributed by each end-point) does this contribute enough entropy to prevent passive adversary close/reset attacks? It seems like active adversary close/reset attacks aren't possible to reliably defend against (without crypto between middle boxes and endpoint). A pattern that has been discussed that seems quite valuable would be to distribute additional connection-ids for mobility and resumption within the encrypted channel. This would allow for resumption, mobility, and periodically cranking the connection-id without linkability. Having a server-contributed component of the connection-id (perhaps an initial one in clear-text and later ones through the encrypted channel) could allow for stateless packet distribution by server-side load balancers and could also form part of a proof-of-address-ownership three-way-handshake mechanism to mitigate against DDoS reflection and spoofed source address attacks. Erik On Thu, Jul 28, 2016 at 11:23 AM, Dave Dolson wrote: > Regarding the state kept by middle-boxes such as firewalls: > > The timeout should be short (a few seconds) until a three-way handshake i= s > complete. This is required to defend against attacks on state memory of t= he > firewall. > > > > In the three-way handshake: > > - The server=E2=80=99s SYN-ACK indicates the server is real and willing t= o talk to > the client. > > - the client=E2=80=99s ACK of the server=E2=80=99s SYN-ACK provides evide= nce the client is > real (vs. spoofed) and has witnessed the SYN-ACK > > > > The random sequence numbers and ack numbers are valuable in this regard. > E.g., a spoofing device cannot simply send the first and third packets > because the third packet must correctly ACK the second packet from the > server. > > > > Once a three-way handshake is witnessed, TCP state timeout can be several > minutes. > > > > The proposal below doesn=E2=80=99t seem to contain enough information for= a > firewall to know the client is real. > > Consider adding a random number that each side can echo back? Perhaps a > different connection-ID per direction? > > > > -Dave > > > > > > > > *From:* Spud [mailto:spud-bounces@ietf.org] *On Behalf Of *Erik Nygren > *Sent:* Thursday, July 28, 2016 11:03 AM > *To:* Mirja K=C3=BChlewind > *Cc:* Kyle Rose; spud@ietf.org > *Subject:* [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy > concerns expressed at the BoF) > > > > On Mon, Jul 25, 2016 at 4:20 PM, Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> wrote: > > As mentioned by Ted, this is actually not what we propose. The mechanism > we propose is exposing information under endpoint control which is a very > important point here. The endpoint has to add an option to send (or > request) a specific bit of information (which also must be registered by > IANA with IESG approval). This is just the same as TCP options or IP opti= on > headers. The only difference is that PLUS has a MAC which allows detectio= n > of middlebox manipulation (which is not the case for other existing > protocols such as TCP options). This is another a very big and important > aspect of what we propose with PLUS as our goal is to encrypt everything > above PLUS including the TCP header and TCP options in future. Especially > encrypting TCP option is important because TCP options provide much less > control than what we propose with PLUS today which is a problem (especial= ly > as currently still unto 90% of the traffic is TCP). So I actually though = we > are on the same page here and have a common goal. > > > > I'm not sure that we get enough value out of extensibility or being overl= y > generic here, at least for practical non-research purposes. If there is = a > tightly defined set of things allowed, we'll quickly ossify on these > anyways. As firewall vendors will just bake in those registered by IANA > when they ship their product and then we'll be right back where we are > today with IPv6 extension headers. > > I'd propose that it may make more sense to define a fixed header prefix > format that contains the right set of features needed to solve the proble= ms > of QUIC and WebRTC (and other future UDP protocols). Along with this, al= so > define a common set of requirements for protocols using this header prefi= x > (eg, around DDoS reflection prevention). > > Having a toolkit for things like handling connection ids in a way that > support multipath mobility, stateless load-balancers, DDoS resiliance, an= d > which minimize linkability would also be a nice-to-have to prevent each U= DP > protocol from having to come up with subtly different ways to solve this > set of problems. > > > > For example, a bare minimum set of features might include: > > > > * Opportunistic signalling to middle-boxes (NATs and Firewalls) for when > they can discard connection state. Unless we want to declare that new UD= P > protocols only work with IPv6 (worth seriously considering, but perhaps n= ot > realistic yet), there just aren't enough {IPv4,port} tuples available for > NATs to support large numbers of users with large numbers of UDP > connections without having crazy-short keep-alive lifetimes. Middle-boxe= s > will always need to be aware that this is best-effort (the FINs can be > dropped or lost or not sent by malicious clients, especially during > multipath transitions) but this could make life much better for > well-behaved clients and things like the existing NATs which use port > ranges per client might encourage clients to be well-behaved here on > average. > > * Negotiating initial PMTU/MSS. While clients will need to be able to > probe up/down and respond to routing changes that change the PMTU, the TC= P > MSS mechanism and ability for middle boxes to decrement/clamp this value > makes a big difference in how quickly clients behind tunnels can converge > without losing round-trips or having very complicated probing. Especiall= y > if we want to be able to deploy jumbo-frames it will be important to have= a > mechanism here. > > > > * Sending signals in both directions that can be correlated to > connections. Using ICMP/ICMPv6 may be a fine way to do this but having a > common prefix for connection information that can be included in the > message makes some things such as routing the messages through a > load-balancer much more viable). > > > > * ... there may be a few others from the use-cases doc. > > > > Having a fixed header prefix format might also make it much more viable t= o > implement with today's router/firewall hardware with just firmware/softwa= re > updates which might make a big difference for medium-term uptake. > > It might be we can get away with something like: > > [MAGIC+VERSION] [CONNECTION_ID] [BITS_FOR_SYN_FIN] > [MSS_DURING_NEGOTIATION_WHEN_SYN_IS_SET] > > [EXTENSION_SPACE_OSSIFICATION_MAY_NOT_PASS] > > > > It might be reasonable to allow for some padding space for future > extension and research, but with the expectation that this will often get > dropped/filtered and thus would be something clients would need to probe > for (and is something people could find a way to do today regardless). > > > > Erik > > > > > --001a11393e16e445c30538b42e1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is exactly the sort of thing that I think d= emonstrates the value of defining something here so we can have one mechani= sm that a bunch of UDP protocols can use to allow for several minute state = timeouts.

With TCP you need the sequence/ack numbers to get en= ough entropy due to the port number being only 16 bits.=C2=A0 If the connec= tion-id is 64 bits (or there are two 64-bit connection-ids in the packet, o= ne contributed by each end-point) does this contribute enough entropy to pr= event passive adversary close/reset attacks?=C2=A0 It seems like active adv= ersary close/reset attacks aren't possible to reliably defend against (= without crypto between middle boxes and endpoint).

A patt= ern that has been discussed that seems quite valuable would be to distribut= e additional connection-ids for mobility and resumption within the encrypte= d channel.=C2=A0 This would allow for resumption, mobility, and periodicall= y cranking the connection-id without linkability.

Having = a server-contributed component of the connection-id (perhaps an initial one= in clear-text and later ones through the encrypted channel) could allow fo= r stateless packet distribution by server-side load balancers and could als= o form part of a proof-of-address-ownership three-way-handshake mechanism t= o mitigate against DDoS reflection and spoofed source address attacks.
<= /div>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik



On Thu, = Jul 28, 2016 at 11:23 AM, Dave Dolson <ddolson@sandvine.com> wrote:

Regarding the state kept = by middle-boxes such as firewalls:

The timeout should be sho= rt (a few seconds) until a three-way handshake is complete. This is require= d to defend against attacks on state memory of the firewall.<= /span>

=C2=A0

In the three-way handshak= e:

- The server=E2=80=99s SY= N-ACK indicates the server is real and willing to talk to the client.

- the client=E2=80=99s AC= K of the server=E2=80=99s SYN-ACK provides evidence the client is real (vs.= spoofed) and has witnessed the SYN-ACK

=C2=A0

The random sequence numbe= rs and ack numbers are valuable in this regard. E.g., a spoofing device can= not simply send the first and third packets because the third packet must correctly ACK the second packet from the server.<= u>

=C2=A0

Once a three-way handshak= e is witnessed, TCP state timeout can be several minutes.

=C2=A0

The proposal below doesn= =E2=80=99t seem to contain enough information for a firewall to know the cl= ient is real.

Consider adding a random = number that each side can echo back? Perhaps a different connection-ID per = direction?

=C2=A0

-Dave

=C2=A0

=C2=A0

=C2=A0

From: Spud [ma= ilto:spud-bounce= s@ietf.org] On Behalf Of Erik Nygren
Sent: Thursday, July 28, 2016 11:03 AM
To: Mirja K=C3=BChlewind
Cc: Kyle Rose; sp= ud@ietf.org
Subject: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy c= oncerns expressed at the BoF)

=C2=A0

On Mon, Jul 25, 2016 at 4:20 PM, Mirja K=C3=BChlewin= d <= mirja.kuehlewind@tik.ee.ethz.ch> wrote:

As mentioned by Ted, this is actually not what we pr= opose. The mechanism we propose is exposing information under endpoint cont= rol which is a very important point here. The endpoint has to add an option= to send (or request) a specific bit of information (which also must be registered by IANA with IESG approval).= This is just the same as TCP options or IP option headers. The only differ= ence is that PLUS has a MAC which allows detection of middlebox manipulatio= n (which is not the case for other existing protocols such as TCP options). This is another a very big and im= portant aspect of what we propose with PLUS as our goal is to encrypt every= thing above PLUS including the TCP header and TCP options in future. Especi= ally encrypting TCP option is important because TCP options provide much less control than what we propose with PL= US today which is a problem (especially as currently still unto 90% of the = traffic is TCP). So I actually though we are on the same page here and have= a common goal.

=C2=A0

I'm not sure that= we get enough value out of extensibility or being overly generic here, at = least for practical non-research purposes.=C2=A0 If there is a tightly defi= ned set of things allowed, we'll quickly ossify on these anyways.=C2=A0 As firewall vendors will just bake in those regist= ered by IANA when they ship their product and then we'll be right back = where we are today with IPv6 extension headers.

I'd propose that = it may make more sense to define a fixed header prefix format that contains= the right set of features needed to solve the problems of QUIC and WebRTC = (and other future UDP protocols).=C2=A0 Along with this, also define a common set of requirements for protocols using th= is header prefix (eg, around DDoS reflection prevention).

Having a toolkit for things like handling connection= ids in a way that support multipath mobility, stateless load-balancers, DD= oS resiliance, and which minimize linkability would also be a nice-to-have = to prevent each UDP protocol from having to come up with subtly different ways to solve this set of problems= .

=C2=A0

For example, a bare minimum set of features might in= clude:

=C2=A0

* Opportunistic signa= lling to middle-boxes (NATs and Firewalls) for when they can discard connec= tion state.=C2=A0 Unless we want to declare that new UDP protocols only wor= k with IPv6 (worth seriously considering, but perhaps not realistic yet), there just aren't enough {IPv4,port} t= uples available for NATs to support large numbers of users with large numbe= rs of UDP connections without having crazy-short keep-alive lifetimes.=C2= =A0 Middle-boxes will always need to be aware that this is best-effort (the FINs can be dropped or lost or not sent by m= alicious clients, especially during multipath transitions) but this could m= ake life much better for well-behaved clients and things like the existing = NATs which use port ranges per client might encourage clients to be well-behaved here on average.<= /p>

* Negotiating initial PMTU/MSS.=C2=A0 While clients = will need to be able to probe up/down and respond to routing changes that c= hange the PMTU, the TCP MSS mechanism and ability for middle boxes to decre= ment/clamp this value makes a big difference in how quickly clients behind tunnels can converge without losing round-tr= ips or having very complicated probing.=C2=A0 Especially if we want to be a= ble to deploy jumbo-frames it will be important to have a mechanism here.

=C2=A0

* Sending signals in both directions that can be cor= related to connections.=C2=A0 Using ICMP/ICMPv6 may be a fine way to do thi= s but having a common prefix for connection information that can be include= d in the message makes some things such as routing the messages through a load-balancer much more viable).<= u>

=C2=A0

* ... there may be a few others from the use-cases d= oc.

=C2=A0

Having a fixed header prefix format might also make = it much more viable to implement with today's router/firewall hardware = with just firmware/software updates which might make a big difference for m= edium-term uptake.

It might be we can ge= t away with something like:

=C2=A0=C2=A0 [MAGIC+VERSION] [CONNECTION_ID] [BITS_F= OR_SYN_FIN]
=C2=A0=C2=A0 [MSS_DURING_NEGOTIATION_WHEN_SYN_IS_SET]

=C2=A0=C2=A0 [EXTENSION_SPACE_OSSIFICATION_MAY_NOT_P= ASS]

=C2=A0

It might be reasonable to allow for some padding spa= ce for future extension and research, but with the expectation that this wi= ll often get dropped/filtered and thus would be something clients would nee= d to probe for (and is something people could find a way to do today regardless).

=C2=A0

=C2=A0=C2=A0=C2=A0 Er= ik



=C2=A0


--001a11393e16e445c30538b42e1f-- From nobody Thu Jul 28 09:23:04 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7747F12D8D5 for ; Thu, 28 Jul 2016 09:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 PUhGZKK6U2f0 for ; Thu, 28 Jul 2016 09:23:00 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 571F712D7E9 for ; Thu, 28 Jul 2016 09:22:57 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id 38so104410880iol.0 for ; Thu, 28 Jul 2016 09:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Cw3i/ejMK1wtm1/+iaEaeBJ8XYV4KpSdOy34wv7AEiE=; b=NVuH/N06FupYXVdvRSuzBKi4SQwhrjQNFxOn2X0kDghN0fA3+Yi1Y189fs4xnsKUc3 M33SC29E63JUb59UMojjpCIZblN4XzeLSzWV0qe6m/Mgc716PeqAj8fiOTL2iaUScXdi 9pKh5Oliko82yTU8x80tgk1NrLHFkcN4BT/6PvgBl16LZc4Kdqx1NVpjqjEgdsU+cVCp iU45xQvz1aSUhRwTW5j6SL0XtKszJJ1JYw1Y/nzXvNNFYqNXxTdk13kjBPkCMceAO2K8 993e1qYxANNLm0uSXt0W+HCg+pmW6YpWLhmoaLABovkcQyyr1hE1vnVjFFGwubu6hISQ oN9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Cw3i/ejMK1wtm1/+iaEaeBJ8XYV4KpSdOy34wv7AEiE=; b=SPM3glhgtFXeYkHKbwJ7BsK7FALykgx40hO/HOHXH3NHmyK+XeTQaE0J4ddN43KP9m Kx+vu1owbr9Cm/ycOmCFxPSd3iUQ1xUX5zqGgoZB1DFXZyqU/IMNXJgETunGm+CQf4t2 MyAbqUyXbBwBWtkR1fQ/pRTbDX7vYTM/wCSY0w1K6P+egKnl1BCsgLx30Vhguw1XFHW+ aCsLLoNsaa04KHekvqs/x63bE0WTuEleDCAplXuYyLxix8vBpcG9Dn+ncGqUL6ESm6AD a1SontgniK1iiKfbhGtGXbGO/3U72t121CjTFl3LDaETF9XpXepXs/ztlhwYPpKJfAnG JMdA== X-Gm-Message-State: AEkoousNcuGK8E09p+/4IqSv4ZpQk2/lWx4lSv8HFQ7Muh1Mq082tc/XyNkpeeL8tFH3umGnbS0nSW84bB1Icg== X-Received: by 10.107.25.75 with SMTP id 72mr39636128ioz.50.1469722976524; Thu, 28 Jul 2016 09:22:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Thu, 28 Jul 2016 09:22:55 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Thu, 28 Jul 2016 09:22:55 -0700 Message-ID: To: Erik Nygren Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Kyle Rose , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 16:23:02 -0000 On Thu, Jul 28, 2016 at 8:02 AM, Erik Nygren wrote: > On Mon, Jul 25, 2016 at 4:20 PM, Mirja K=C3=BChlewind > wrote: >> >> As mentioned by Ted, this is actually not what we propose. The mechanism >> we propose is exposing information under endpoint control which is a ver= y >> important point here. The endpoint has to add an option to send (or requ= est) >> a specific bit of information (which also must be registered by IANA wit= h >> IESG approval). This is just the same as TCP options or IP option header= s. >> The only difference is that PLUS has a MAC which allows detection of >> middlebox manipulation (which is not the case for other existing protoco= ls >> such as TCP options). This is another a very big and important aspect of >> what we propose with PLUS as our goal is to encrypt everything above PLU= S >> including the TCP header and TCP options in future. Especially encryptin= g >> TCP option is important because TCP options provide much less control th= an >> what we propose with PLUS today which is a problem (especially as curren= tly >> still unto 90% of the traffic is TCP). So I actually though we are on th= e >> same page here and have a common goal. > > > I'm not sure that we get enough value out of extensibility or being overl= y > generic here, at least for practical non-research purposes. If there is = a > tightly defined set of things allowed, we'll quickly ossify on these > anyways. As firewall vendors will just bake in those registered by IANA > when they ship their product and then we'll be right back where we are to= day > with IPv6 extension headers. > > I'd propose that it may make more sense to define a fixed header prefix > format that contains the right set of features needed to solve the proble= ms > of QUIC and WebRTC (and other future UDP protocols). Along with this, al= so > define a common set of requirements for protocols using this header prefi= x > (eg, around DDoS reflection prevention). > > Having a toolkit for things like handling connection ids in a way that > support multipath mobility, stateless load-balancers, DDoS resiliance, an= d > which minimize linkability would also be a nice-to-have to prevent each U= DP > protocol from having to come up with subtly different ways to solve this = set > of problems. > > For example, a bare minimum set of features might include: > > * Opportunistic signalling to middle-boxes (NATs and Firewalls) for when > they can discard connection state. Unless we want to declare that new UD= P > protocols only work with IPv6 (worth seriously considering, but perhaps n= ot > realistic yet), there just aren't enough {IPv4,port} tuples available for > NATs to support large numbers of users with large numbers of UDP connecti= ons > without having crazy-short keep-alive lifetimes. Middle-boxes will alway= s > need to be aware that this is best-effort (the FINs can be dropped or los= t > or not sent by malicious clients, especially during multipath transitions= ) > but this could make life much better for well-behaved clients and things > like the existing NATs which use port ranges per client might encourage > clients to be well-behaved here on average. > >From an application provider point of view, I am still very dubious of purposely exposing connection state so that anonymous middleboxes can track my connections. As pointed out at the mic during the PLUS BOF, firewalls currently assume that all packets go through their device-- if packets are routed to some random middlebox then my transport layer connection can be dropped by the device just because the middlebox doesn't have state. This breaks the E2E model of the Internet and kills our ability to use multipath and multihoming. Any device that assumes a singular path for a connection is therefore the problem; this is not a model that we want to perpetuate in PLUS. Tom From nobody Thu Jul 28 10:20:42 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDA512D59A for ; Thu, 28 Jul 2016 10:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 IpaEAKi3Bf7x for ; Thu, 28 Jul 2016 10:20:39 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E4C12D550 for ; Thu, 28 Jul 2016 10:20:39 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Thu, 28 Jul 2016 13:20:36 -0400 From: Dave Dolson To: Tom Herbert , Erik Nygren Thread-Topic: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) Thread-Index: AQHR6OEiIxuSeQh0Z0+bOsaZ6LcIY6AuSeOA//++pqA= Date: Thu, 28 Jul 2016 17:20:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Kyle Rose , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , spud Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 17:20:41 -0000 VG9tLA0KWWVzLCBmaXJld2FsbHMgZG8gYXNzdW1lIGFsbCBwYWNrZXRzIGdvIHRocm91Z2ggdGhl bS4gVGhpcyBpcyBob3cgdGhleQ0KcHJvdGVjdCBhIChzdHViKSBuZXR3b3JrLiBUaGV5IG11c3Qg YmUgZGVwbG95ZWQgc3VjaCB0aGF0IHRoaXMgaXMgdHJ1ZS4NCg0KVGhlIEUyRSBwcmluY2lwbGUs IEkgdGhpbmssIGlzIGludGVuZGVkIHRvIHByb3ZpZGUgYXBwbGljYXRpb24gZGV2ZWxvcGVycw0K d2l0aCBhIHZlcnkgdXNlZnVsIGFic3RyYWN0aW9uLCB0byBtYWtlIGl0IGVhc2llciB0byByZWFz b24gYWJvdXQgdGhlIG5ldHdvcmsuDQoNCkJ1dCBmb3IgbmV0d29yayBvcGVyYXRvcnMsIHRoZSBu ZXR3b3JrIGlzbid0IGFuIGFic3RyYWN0IHRoaW5nLg0KSXQgaXNuJ3QgYSBjbG91ZCB0aGF0IHBy b3ZpZGVzIGluZmluaXRlIGJhbmR3aWR0aCBiZXR3ZWVuIGFueSBwYWlyIG9mIG5vZGVzLg0KVGhl cmUgaGF2ZSBiZWVuIG1hbnkgY3JlYXRpdmUgaWRlYXMgYWJvdXQgaG93IHRvIGJ1aWxkIHN1Y2gg YSBuZXR3b3JrLA0Kd2hpY2ggaGF2ZSBiZWVuIGJlbmVmaWNpYWwgYnV0IGxlZCB0byBvc3NpZmlj YXRpb24uDQoNCkkgdGhpbmsgd2UgbmVlZCB0byB1bmRlcnN0YW5kIHdoYXQgaXMgdG8gYmUgdGhl IG5ldyBjb250cmFjdCBiZXR3ZWVuDQplbmRwb2ludHMgYW5kIHRoZSBuZXR3b3JrLCB0byBsaW1p dCB0aGUgImNyZWF0aXZpdHkiLg0KDQoNCi1EYXZlDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogU3B1ZCBbbWFpbHRvOnNwdWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFRvbSBIZXJiZXJ0DQpTZW50OiBUaHVyc2RheSwgSnVseSAyOCwgMjAxNiAxMjoyMyBQ TQ0KVG86IEVyaWsgTnlncmVuDQpDYzogS3lsZSBSb3NlOyBNaXJqYSBLw7xobGV3aW5kOyBzcHVk DQpTdWJqZWN0OiBSZTogW1NwdWRdIEJhcmUtbWluaW11bSBQTFVTICh3YXMgUmU6IFRob3VnaHRz IG9uIHRoZSBwcml2YWN5IGNvbmNlcm5zIGV4cHJlc3NlZCBhdCB0aGUgQm9GKQ0KDQpPbiBUaHUs IEp1bCAyOCwgMjAxNiBhdCA4OjAyIEFNLCBFcmlrIE55Z3JlbiA8ZXJpaytpZXRmQG55Z3Jlbi5v cmc+IHdyb3RlOg0KPiBPbiBNb24sIEp1bCAyNSwgMjAxNiBhdCA0OjIwIFBNLCBNaXJqYSBLw7xo bGV3aW5kDQo+IDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPiB3cm90ZToNCj4+DQo+ PiBBcyBtZW50aW9uZWQgYnkgVGVkLCB0aGlzIGlzIGFjdHVhbGx5IG5vdCB3aGF0IHdlIHByb3Bv c2UuIFRoZSBtZWNoYW5pc20NCj4+IHdlIHByb3Bvc2UgaXMgZXhwb3NpbmcgaW5mb3JtYXRpb24g dW5kZXIgZW5kcG9pbnQgY29udHJvbCB3aGljaCBpcyBhIHZlcnkNCj4+IGltcG9ydGFudCBwb2lu dCBoZXJlLiBUaGUgZW5kcG9pbnQgaGFzIHRvIGFkZCBhbiBvcHRpb24gdG8gc2VuZCAob3IgcmVx dWVzdCkNCj4+IGEgc3BlY2lmaWMgYml0IG9mIGluZm9ybWF0aW9uICh3aGljaCBhbHNvIG11c3Qg YmUgcmVnaXN0ZXJlZCBieSBJQU5BIHdpdGgNCj4+IElFU0cgYXBwcm92YWwpLiBUaGlzIGlzIGp1 c3QgdGhlIHNhbWUgYXMgVENQIG9wdGlvbnMgb3IgSVAgb3B0aW9uIGhlYWRlcnMuDQo+PiBUaGUg b25seSBkaWZmZXJlbmNlIGlzIHRoYXQgUExVUyBoYXMgYSBNQUMgd2hpY2ggYWxsb3dzIGRldGVj dGlvbiBvZg0KPj4gbWlkZGxlYm94IG1hbmlwdWxhdGlvbiAod2hpY2ggaXMgbm90IHRoZSBjYXNl IGZvciBvdGhlciBleGlzdGluZyBwcm90b2NvbHMNCj4+IHN1Y2ggYXMgVENQIG9wdGlvbnMpLiBU aGlzIGlzIGFub3RoZXIgYSB2ZXJ5IGJpZyBhbmQgaW1wb3J0YW50IGFzcGVjdCBvZg0KPj4gd2hh dCB3ZSBwcm9wb3NlIHdpdGggUExVUyBhcyBvdXIgZ29hbCBpcyB0byBlbmNyeXB0IGV2ZXJ5dGhp bmcgYWJvdmUgUExVUw0KPj4gaW5jbHVkaW5nIHRoZSBUQ1AgaGVhZGVyIGFuZCBUQ1Agb3B0aW9u cyBpbiBmdXR1cmUuIEVzcGVjaWFsbHkgZW5jcnlwdGluZw0KPj4gVENQIG9wdGlvbiBpcyBpbXBv cnRhbnQgYmVjYXVzZSBUQ1Agb3B0aW9ucyBwcm92aWRlIG11Y2ggbGVzcyBjb250cm9sIHRoYW4N Cj4+IHdoYXQgd2UgcHJvcG9zZSB3aXRoIFBMVVMgdG9kYXkgd2hpY2ggaXMgYSBwcm9ibGVtIChl c3BlY2lhbGx5IGFzIGN1cnJlbnRseQ0KPj4gc3RpbGwgdW50byA5MCUgb2YgdGhlIHRyYWZmaWMg aXMgVENQKS4gU28gSSBhY3R1YWxseSB0aG91Z2ggd2UgYXJlIG9uIHRoZQ0KPj4gc2FtZSBwYWdl IGhlcmUgYW5kIGhhdmUgYSBjb21tb24gZ29hbC4NCj4NCj4NCj4gSSdtIG5vdCBzdXJlIHRoYXQg d2UgZ2V0IGVub3VnaCB2YWx1ZSBvdXQgb2YgZXh0ZW5zaWJpbGl0eSBvciBiZWluZyBvdmVybHkN Cj4gZ2VuZXJpYyBoZXJlLCBhdCBsZWFzdCBmb3IgcHJhY3RpY2FsIG5vbi1yZXNlYXJjaCBwdXJw b3Nlcy4gIElmIHRoZXJlIGlzIGENCj4gdGlnaHRseSBkZWZpbmVkIHNldCBvZiB0aGluZ3MgYWxs b3dlZCwgd2UnbGwgcXVpY2tseSBvc3NpZnkgb24gdGhlc2UNCj4gYW55d2F5cy4gIEFzIGZpcmV3 YWxsIHZlbmRvcnMgd2lsbCBqdXN0IGJha2UgaW4gdGhvc2UgcmVnaXN0ZXJlZCBieSBJQU5BDQo+ IHdoZW4gdGhleSBzaGlwIHRoZWlyIHByb2R1Y3QgYW5kIHRoZW4gd2UnbGwgYmUgcmlnaHQgYmFj ayB3aGVyZSB3ZSBhcmUgdG9kYXkNCj4gd2l0aCBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzLg0KPg0K PiBJJ2QgcHJvcG9zZSB0aGF0IGl0IG1heSBtYWtlIG1vcmUgc2Vuc2UgdG8gZGVmaW5lIGEgZml4 ZWQgaGVhZGVyIHByZWZpeA0KPiBmb3JtYXQgdGhhdCBjb250YWlucyB0aGUgcmlnaHQgc2V0IG9m IGZlYXR1cmVzIG5lZWRlZCB0byBzb2x2ZSB0aGUgcHJvYmxlbXMNCj4gb2YgUVVJQyBhbmQgV2Vi UlRDIChhbmQgb3RoZXIgZnV0dXJlIFVEUCBwcm90b2NvbHMpLiAgQWxvbmcgd2l0aCB0aGlzLCBh bHNvDQo+IGRlZmluZSBhIGNvbW1vbiBzZXQgb2YgcmVxdWlyZW1lbnRzIGZvciBwcm90b2NvbHMg dXNpbmcgdGhpcyBoZWFkZXIgcHJlZml4DQo+IChlZywgYXJvdW5kIEREb1MgcmVmbGVjdGlvbiBw cmV2ZW50aW9uKS4NCj4NCj4gSGF2aW5nIGEgdG9vbGtpdCBmb3IgdGhpbmdzIGxpa2UgaGFuZGxp bmcgY29ubmVjdGlvbiBpZHMgaW4gYSB3YXkgdGhhdA0KPiBzdXBwb3J0IG11bHRpcGF0aCBtb2Jp bGl0eSwgc3RhdGVsZXNzIGxvYWQtYmFsYW5jZXJzLCBERG9TIHJlc2lsaWFuY2UsIGFuZA0KPiB3 aGljaCBtaW5pbWl6ZSBsaW5rYWJpbGl0eSB3b3VsZCBhbHNvIGJlIGEgbmljZS10by1oYXZlIHRv IHByZXZlbnQgZWFjaCBVRFANCj4gcHJvdG9jb2wgZnJvbSBoYXZpbmcgdG8gY29tZSB1cCB3aXRo IHN1YnRseSBkaWZmZXJlbnQgd2F5cyB0byBzb2x2ZSB0aGlzIHNldA0KPiBvZiBwcm9ibGVtcy4N Cj4NCj4gRm9yIGV4YW1wbGUsIGEgYmFyZSBtaW5pbXVtIHNldCBvZiBmZWF0dXJlcyBtaWdodCBp bmNsdWRlOg0KPg0KPiAqIE9wcG9ydHVuaXN0aWMgc2lnbmFsbGluZyB0byBtaWRkbGUtYm94ZXMg KE5BVHMgYW5kIEZpcmV3YWxscykgZm9yIHdoZW4NCj4gdGhleSBjYW4gZGlzY2FyZCBjb25uZWN0 aW9uIHN0YXRlLiAgVW5sZXNzIHdlIHdhbnQgdG8gZGVjbGFyZSB0aGF0IG5ldyBVRFANCj4gcHJv dG9jb2xzIG9ubHkgd29yayB3aXRoIElQdjYgKHdvcnRoIHNlcmlvdXNseSBjb25zaWRlcmluZywg YnV0IHBlcmhhcHMgbm90DQo+IHJlYWxpc3RpYyB5ZXQpLCB0aGVyZSBqdXN0IGFyZW4ndCBlbm91 Z2gge0lQdjQscG9ydH0gdHVwbGVzIGF2YWlsYWJsZSBmb3INCj4gTkFUcyB0byBzdXBwb3J0IGxh cmdlIG51bWJlcnMgb2YgdXNlcnMgd2l0aCBsYXJnZSBudW1iZXJzIG9mIFVEUCBjb25uZWN0aW9u cw0KPiB3aXRob3V0IGhhdmluZyBjcmF6eS1zaG9ydCBrZWVwLWFsaXZlIGxpZmV0aW1lcy4gIE1p ZGRsZS1ib3hlcyB3aWxsIGFsd2F5cw0KPiBuZWVkIHRvIGJlIGF3YXJlIHRoYXQgdGhpcyBpcyBi ZXN0LWVmZm9ydCAodGhlIEZJTnMgY2FuIGJlIGRyb3BwZWQgb3IgbG9zdA0KPiBvciBub3Qgc2Vu dCBieSBtYWxpY2lvdXMgY2xpZW50cywgZXNwZWNpYWxseSBkdXJpbmcgbXVsdGlwYXRoIHRyYW5z aXRpb25zKQ0KPiBidXQgdGhpcyBjb3VsZCBtYWtlIGxpZmUgbXVjaCBiZXR0ZXIgZm9yIHdlbGwt YmVoYXZlZCBjbGllbnRzIGFuZCB0aGluZ3MNCj4gbGlrZSB0aGUgZXhpc3RpbmcgTkFUcyB3aGlj aCB1c2UgcG9ydCByYW5nZXMgcGVyIGNsaWVudCBtaWdodCBlbmNvdXJhZ2UNCj4gY2xpZW50cyB0 byBiZSB3ZWxsLWJlaGF2ZWQgaGVyZSBvbiBhdmVyYWdlLg0KPg0KPkZyb20gYW4gYXBwbGljYXRp b24gcHJvdmlkZXIgcG9pbnQgb2YgdmlldywgSSBhbSBzdGlsbCB2ZXJ5IGR1YmlvdXMgb2YNCnB1 cnBvc2VseSBleHBvc2luZyBjb25uZWN0aW9uIHN0YXRlIHNvIHRoYXQgYW5vbnltb3VzIG1pZGRs ZWJveGVzIGNhbg0KdHJhY2sgbXkgY29ubmVjdGlvbnMuIEFzIHBvaW50ZWQgb3V0IGF0IHRoZSBt aWMgZHVyaW5nIHRoZSBQTFVTIEJPRiwNCmZpcmV3YWxscyBjdXJyZW50bHkgYXNzdW1lIHRoYXQg YWxsIHBhY2tldHMgZ28gdGhyb3VnaCB0aGVpciBkZXZpY2UtLQ0KaWYgcGFja2V0cyBhcmUgcm91 dGVkIHRvIHNvbWUgcmFuZG9tIG1pZGRsZWJveCB0aGVuIG15IHRyYW5zcG9ydCBsYXllcg0KY29u bmVjdGlvbiBjYW4gYmUgZHJvcHBlZCBieSB0aGUgZGV2aWNlIGp1c3QgYmVjYXVzZSB0aGUgbWlk ZGxlYm94DQpkb2Vzbid0IGhhdmUgc3RhdGUuIFRoaXMgYnJlYWtzIHRoZSBFMkUgbW9kZWwgb2Yg dGhlIEludGVybmV0IGFuZA0Ka2lsbHMgb3VyIGFiaWxpdHkgdG8gdXNlIG11bHRpcGF0aCBhbmQg bXVsdGlob21pbmcuIEFueSBkZXZpY2UgdGhhdA0KYXNzdW1lcyBhIHNpbmd1bGFyIHBhdGggZm9y IGEgY29ubmVjdGlvbiBpcyB0aGVyZWZvcmUgdGhlIHByb2JsZW07DQp0aGlzIGlzIG5vdCBhIG1v ZGVsIHRoYXQgd2Ugd2FudCB0byBwZXJwZXR1YXRlIGluIFBMVVMuDQoNClRvbQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU3B1ZCBtYWlsaW5nIGxp c3QNClNwdWRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3B1ZA0K From nobody Thu Jul 28 11:17:37 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965FB12DB86 for ; Thu, 28 Jul 2016 11:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 2LwgNdqAw-eO for ; Thu, 28 Jul 2016 11:17:33 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 B9A4B12DB8D for ; Thu, 28 Jul 2016 11:17:29 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id f6so174509694ith.1 for ; Thu, 28 Jul 2016 11:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=B4x34olIjqeWr2IMILdcKrCiXOwQR7TJ9cwovHsiB04=; b=XFOHnvlXUTpNESl0qmmo16UZKscIdpnlX8wLXDLyYFs3C8XzsTFiyAiA1FRsZ8hyOJ BJ0rPDDTrZj+3w1+sVOuEwk1bWp5M0daY6fJylIbrPccC87GIphvfmt7nguQ6Q0HcBQv 0zo33iUIgNw13rMj90ulPPwNqsgzIg1baV+yq4Vzwz8XmtiARj6feM934E0qefjK8yvU 6lbXrM6xkNr44aSs+w162CIjFBLDzpYEPWcPluUKDJRq3AYa0rjDBlTu+PIzMU2ESq6+ hpvCVqoJSiGNGdsz3EZZEme4UICvRmQ9p32Zc0l3PeCcScShrYEx9y+UgQ5ta/UTOdyv LglA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=B4x34olIjqeWr2IMILdcKrCiXOwQR7TJ9cwovHsiB04=; b=fOstj1zOTVMcPrKM90RgvPYCGK6R0/iGdK5IlXXY0Kbka7efPIkRnY6F3X51cltTjZ nIZ0H4mCboGVUst6H2GwujVIlCykzDC5VKCDwQJAByQHL8Dvh9Tq5xJltfCYftLjxm84 VYDXoFnRoZ24dGykEXQTKRgUFGqapyLeOALRiUgpovFYfNPDDRKL6eDDlZ7RgeF0c3N2 XNkELssN5stMw3J0Rje7tFH/8CxgxhICUv/gwy3JPHMJLHG5mFd3n9I6yFIUlsrM2Ohg rkfZotX4YH0WrcO6qBys9jSORojvzahXWA9DSWHMh+GtcL2KMwu7jXvjLHLodlX6lUMZ DrNw== X-Gm-Message-State: ALyK8tKPV3sISNAdBna0iHJIQCM3lAArUxt+CsSiCz3eqJQN0fXj/iY9PKV5g2du5NHLhIRvdLctWK886Vifqw== X-Received: by 10.36.80.2 with SMTP id m2mr51119129itb.37.1469729848895; Thu, 28 Jul 2016 11:17:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Thu, 28 Jul 2016 11:17:28 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Thu, 28 Jul 2016 11:17:28 -0700 Message-ID: To: Dave Dolson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Erik Nygren , Kyle Rose , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 18:17:35 -0000 On Thu, Jul 28, 2016 at 10:20 AM, Dave Dolson wrote: > Tom, > Yes, firewalls do assume all packets go through them. This is how they > protect a (stub) network. They must be deployed such that this is true. > > The E2E principle, I think, is intended to provide application developers > with a very useful abstraction, to make it easier to reason about the net= work. > The abstraction is only useful up to the point that networks preserve the model. If the network breaks the model in ad hoc ways that forces the application to try to compensate with more ad hoc mechanisms or just stop innovating altogether as we see happened with protocol ossification. > But for network operators, the network isn't an abstract thing. I think that would more appropriately be stated that for network operators *their* network isn't an abstract thing. We haven't particularly seem a lot of consistency how different operators run their networks. > It isn't a cloud that provides infinite bandwidth between any pair of nod= es. > There have been many creative ideas about how to build such a network, > which have been beneficial but led to ossification. > Some of this creativity is beneficial, but it is also true that some has also been malevolent. The problem from an application point of view is that we have no insight as to what is being done with the data being exposed. The only recourse we have to eliminate malicious use and stop protocol ossification is to hide as much as possible from the network-- this is why we want to encrypt the transport layer in the first place. > I think we need to understand what is to be the new contract between > endpoints and the network, to limit the "creativity". > "contract" is a key word here. If there is an explicit trust relationship with guarantees established between end nodes and devices in the attached network, then there is a much better chance we (application providers) would be willing to share transport layer information (this the philosophy in the mobile guidance). Volunteering arbitrary transport layer information to the network on the off chance that some anonymous device we don't even know exists might find it useful still seems like a big stretch to me. Tom > > -Dave > > > > -----Original Message----- > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Tom Herbert > Sent: Thursday, July 28, 2016 12:23 PM > To: Erik Nygren > Cc: Kyle Rose; Mirja K=C3=BChlewind; spud > Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy co= ncerns expressed at the BoF) > > On Thu, Jul 28, 2016 at 8:02 AM, Erik Nygren wrote= : >> On Mon, Jul 25, 2016 at 4:20 PM, Mirja K=C3=BChlewind >> wrote: >>> >>> As mentioned by Ted, this is actually not what we propose. The mechanis= m >>> we propose is exposing information under endpoint control which is a ve= ry >>> important point here. The endpoint has to add an option to send (or req= uest) >>> a specific bit of information (which also must be registered by IANA wi= th >>> IESG approval). This is just the same as TCP options or IP option heade= rs. >>> The only difference is that PLUS has a MAC which allows detection of >>> middlebox manipulation (which is not the case for other existing protoc= ols >>> such as TCP options). This is another a very big and important aspect o= f >>> what we propose with PLUS as our goal is to encrypt everything above PL= US >>> including the TCP header and TCP options in future. Especially encrypti= ng >>> TCP option is important because TCP options provide much less control t= han >>> what we propose with PLUS today which is a problem (especially as curre= ntly >>> still unto 90% of the traffic is TCP). So I actually though we are on t= he >>> same page here and have a common goal. >> >> >> I'm not sure that we get enough value out of extensibility or being over= ly >> generic here, at least for practical non-research purposes. If there is= a >> tightly defined set of things allowed, we'll quickly ossify on these >> anyways. As firewall vendors will just bake in those registered by IANA >> when they ship their product and then we'll be right back where we are t= oday >> with IPv6 extension headers. >> >> I'd propose that it may make more sense to define a fixed header prefix >> format that contains the right set of features needed to solve the probl= ems >> of QUIC and WebRTC (and other future UDP protocols). Along with this, a= lso >> define a common set of requirements for protocols using this header pref= ix >> (eg, around DDoS reflection prevention). >> >> Having a toolkit for things like handling connection ids in a way that >> support multipath mobility, stateless load-balancers, DDoS resiliance, a= nd >> which minimize linkability would also be a nice-to-have to prevent each = UDP >> protocol from having to come up with subtly different ways to solve this= set >> of problems. >> >> For example, a bare minimum set of features might include: >> >> * Opportunistic signalling to middle-boxes (NATs and Firewalls) for when >> they can discard connection state. Unless we want to declare that new U= DP >> protocols only work with IPv6 (worth seriously considering, but perhaps = not >> realistic yet), there just aren't enough {IPv4,port} tuples available fo= r >> NATs to support large numbers of users with large numbers of UDP connect= ions >> without having crazy-short keep-alive lifetimes. Middle-boxes will alwa= ys >> need to be aware that this is best-effort (the FINs can be dropped or lo= st >> or not sent by malicious clients, especially during multipath transition= s) >> but this could make life much better for well-behaved clients and things >> like the existing NATs which use port ranges per client might encourage >> clients to be well-behaved here on average. >> > >From an application provider point of view, I am still very dubious of > purposely exposing connection state so that anonymous middleboxes can > track my connections. As pointed out at the mic during the PLUS BOF, > firewalls currently assume that all packets go through their device-- > if packets are routed to some random middlebox then my transport layer > connection can be dropped by the device just because the middlebox > doesn't have state. This breaks the E2E model of the Internet and > kills our ability to use multipath and multihoming. Any device that > assumes a singular path for a connection is therefore the problem; > this is not a model that we want to perpetuate in PLUS. > > Tom > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Fri Jul 29 05:06:22 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184E812B044 for ; Fri, 29 Jul 2016 05:06:21 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains application/pgp-encrypted,.asc,UNDECIPHERABLE X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENCRYPTED_MESSAGE=-1, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Qpj2Ufzwjz1g for ; Fri, 29 Jul 2016 05:06:19 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 87C8812DDF8 for ; Fri, 29 Jul 2016 05:06:17 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 9F5C61A10E9; Fri, 29 Jul 2016 14:06:15 +0200 (CEST) X-Should-Pgp-Sign: YES X-Pgp-Agent: GPGMail X-Apple-Mail-Remote-Attachments: YES X-Should-Pgp-Encrypt: NO In-Reply-To: X-Uniform-Type-Identifier: com.apple.mail-draft Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Apple-Base-Url: x-msg://34/ Date: Fri, 29 Jul 2016 12:57:23 +0200 Content-Description: OpenPGP encrypted message Message-Id: <89CE79B8-0FA3-424D-9184-B202A4BD380E@trammell.ch> To: Erik Nygren Content-Transfer-Encoding: 7bit From: Brian Trammell References: Content-Type: multipart/encrypted; boundary="Apple-Mail=_1BE0255C-C299-4D71-94DA-718AC4E2A584"; protocol="application/pgp-encrypted"; X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Kyle Rose , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Dave Dolson , "spud@ietf.org" Subject: [Spud] ***UNCHECKED*** Re: Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 12:06:21 -0000 This is an OpenPGP/MIME encrypted message (RFC 2440 and 3156) --Apple-Mail=_1BE0255C-C299-4D71-94DA-718AC4E2A584 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-encrypted Content-Description: PGP/MIME Versions Identification Version: 1 --Apple-Mail=_1BE0255C-C299-4D71-94DA-718AC4E2A584 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=encrypted.asc Content-Type: application/octet-stream; name=encrypted.asc Content-Description: OpenPGP encrypted message -----BEGIN PGP MESSAGE----- Comment: GPGTools - https://gpgtools.org hQIMA7MdurcgXtzeAQ/8Cp6+txB0JGhjvUeHKXmzdNg47QmY7ahqLgBh4twfJba2 vS4rRsnexjqYoYyJr8k1KkoXskkg4IKLRH4Vhegwd/14p9+mybFK83NBq80pcrPB 3uJZ0z2DopIM9YX34s9p9/RPGpBd0F/IJrtks5Q3eqT2BPARNt2DujSLMUHG4ZM0 8vrtlGGmPWZ56BcUAU6e/wS7ofUayXFwfZIg3rp1NUhh1okampot2d5779qs0+G4 UXTRjWu/je3kRZVhla9NpVdiaIk7OgUpfFm0bqGNCK+IBfO9Llj2/oU/kyq+GCmt o3iQW4ZlGXuasfHO/o5UPNmHY8OpK1oWe+Cz8fXFVxhkQF52Mxl27JFlEb+EopQb C6S99RayTHO9spGpQs2SnRLyhC+JmZanzaUN7O7ytvc5sZ6sQ76X9QwJIqHp97SJ xrKMgaeQ6s0HoKL+8My7i8VwMGuMcL15wsRvckNtH/qiaxQ3E6pD0ZSJikM5wd3j oNW1OJ8YmuBD+xhWvc7P9VoLjHIwIwJRbbGOA3wfNaTumffRJ5cHdP60Vr6KAgJO y3bgRUMsYbAGU88pPj2w1+WuExP1CzOhLOkgBe9+Q1PpAqDB3leQXzKWs5SIs9Ow 5f2EutelXdONcPqxhxc/tYVDQrL48azv7vZSVkk5aDnrZs1a6XUAx9EmiQz9zVPS 7AEXlpOb2chjmfktXWYOWYKsXEhziXOaq7fN4LFgeOEveqPXvl0+6anXbHGrNUi3 yze/r39lIPPa6XqICerNI2n/xPJLhj7BiscJUs+Ih+a9MrnKfdatL19L9tbe9uQd Ub+Qu0H3JwJbIrOpCc/IU9ff2k86T6VZerEPgOZLwL5JGDCkx1JZxLT791318XfQ EgMevY3x8CPhAQdI/Y2iFxsuStVLdc8MHH+SXKOwzjOMlYAoOcA+fK/17n4PP7TY A6N09LnUjzwm9ydxutVxxWmGTxyCNt5+HCWeUH1H1AfnR+YmW0WstXXuFHcfTnS7 9f0ywWwARUDC8uS/iGQ1KWP3GEGsT6tKFaSR6sFO3oXC0vZFaHzATus44a39j0ot sV9f7uBR0b6L4h1UqUT71OK9Wox/t8kcVYHiV239UcQfIbLZdA/oivq+HS8fZBa1 9+bhuiPcKdGZCnIbL32qg8GnHRc5QXNNKDnzb58rHOLYpRQ9os3DEtS6Gn+FS/x4 Qk4s7tUe6An5KpC+UMGN1tr5N4iBUF7olRMxE9lBB2XOpDvE5j10D6MVhMxjz9Kz m0nWtzAx3k32zZdj+o0Wp5Gw6wokpf/OoskOpHBlL7c76l8cgLQzZY0eor93uRt4 XrFfy+JJ05R9vtzJDj0hQCzWlHaol7/qRAmCusDyB54eSrNPM9s0Wj98JrU6ythh TMfQ9HkcT3BQ1TL7oKBpWWVoUkm1JTbGQSiYTN/yWgpKtm+Sk3KZxN+Kc8XZ+ckn VzLSFP3nkSkhbY/vvjNtGOXonJgqmCNCUL8P1v+suUW9U9YjcuG5WMr+RtyR1LH3 pPst/GK5JYIA44LrSBcYil6ctZMQtncwjOsEU8XybYzHF/FZ/JForanPAo6+azWe 2sDFxarPXWHAzz/GN1KAczeUZOz2qHZGwjnpqzBqUmLHs7WOQsM9KZOJB1cssb5J 5qK96AiaIpCrALjd1A5P9BDMlq0SxdpwusrHsMG3VkGyo1KlW5gyp6POn6vOO+O3 5AzQtP6Pd2lmdWL42QQTopgyKAuE8k3G7MX5DTaTmW0sLp8MO/FV7CJwlg1JxI4m 4qibPfPPA8Q+tZxhMdOo2uLaYkyIj7qH9xkYS8c3cQjnCjiq3ePq40GXxSb1rRb6 +TYS93/tGRdovTA+362ziTf2Wu3X9EDiZ8dEXIul+ESC285Md0gB9qPu5Z+DVUFp YmtJ6m1Y5uBEWNPa/PDS474WHKNIHqb5BhhTZArm06PceMshqQg9unvUypdA+2HP OjSfXM5MPoXjE6ZahXsZFBWmuJJHJbNdgpXJINufzfFttC8qvpuCXQgrRMXP+STB PZTuPBzkW6e6rLkegQy4VCiAdm+x8LvKIoyaGWGzQBM/rgq80zFhqa4KHhJgNVKo oLMpl6Fooh06RScLB6vTAHH2SNfe/6c5i3R/WLp9/nhgh19IJeGKbxlLMZagvlu4 RpEf7G9i7IH0pLoDs8tVM1DsLr8/sTd+NClMs0EiN7+oQ4gPmp2WVneEQYqC5/Fd DgVMRDRCGien0iEL7E0OQOnq/Peic5AWUKWzMigNeZbGlFgI4lUB6/FT9Lr2TNsI 7JbvxYIbVMzz0fP3WC9k54T/DSn3MXPcVdzkOYxvYA5brJi3Qe39m1UYBZYSVPsB TL/krrv9tiq019AkQKq4lBqf+3L0rClVVFViLAI4M77teH5FUniGcNW5GVXYO+BQ DUfaEbFf+3QB+eDfNmzcB1PtTNwgbWVWTU3n1iWfH/1b1O+++ongIikj5PcnRxwv WosIk4U/xcPJv2eOc0FanEsVRuj1MQ220JjvbMit3ulJrhJFB1TI68EbEohaqJXd 9+25fDor+m8PfStw+pLRfxF8clEHTjVWNt1217NMkgG0IanEkx5NK1DA1xtk/DLd NqPiggd7/skbj2+0Kq9K5HRum23lZyFKShrAL3+Pb/+ZrN2FCcVmvObW4wEflX05 CrZO/zzeHBokVRizgP7FmiYoE1G7AmDaM7L81NCgDV5IurtdI0R4v5WwQ/F8vvzN 0Tl6hAa/ixeNP0ya0fVSi2D6EhqW88l6CPWz0ZWxeqEV45qQcOTn+WK3P02RjcGD 5k4B5/OvDfnA2CpRj64m+3RTHnXjy6hPt8/+CABWqli0f6wg/NNdAyujXkCwikli phUXHvaOl3fcfZuf53Lss0uGGPEopJzYAJYaNcD8qsVgWZyWYp3Fm6fwk3KwrMZ3 xHaphqNqg7ZLekdYepAkdkZP227aYfFFxgGyGrALdp3fYWJD+0xlSkF01ifyLW2T JzgYEY1or7W4w888o3CKiXElvT6I72hDDuFhq2ht6xq/vB9c+nZXy+BoKNruS+GA IVWxUKTcXFI7JbhBjIqEJlpMM2xHEls3HtDQe9W7jH840HYs6vzmIBp6eOhod6aq QiSiIyEpLDaehnAEatNzc0YuWKe/z9ZKwABv1WQP/OFAEXrqyC7vGdHOvP6zRYww GF9liNL4hyfIEjVrWC4bBJ+SssD5AcYOIB+9/+b8uI9dVQGfRyyj377taCWBQu5e F90gUwW4oJbAL3OqqHZPKSzlEGQBH2p1I4jvL6STpB9XQ1h4sis+v4jGix/ZAP8S 1LBnH+itapLYyDhqpZIAWOWLFNLrNqA4S9k2eisyD+dxS9c+krlpVsuO9Pap3818 lLPheK62+HiHWp7ExBzdmvgZHgAk8OWA0kP5AnBPDc/kgHv3RSVEGNat2ZwLVoD0 X5gnKMqVlG3AiBhi7itA/NRY+buQFUEeStUzfGQ+p2zC9e2WgBRrZJSGAVn6PjTH awJ9sQRSi1eHzzn4r5AMWeyw3mQjpHzeLFq5Rd9v6sDvo6R0tjqkobaelxI/DP02 4R7zgvzrPRNg9kF7M8gJH4zbhMMtEOvrVWinMxszy6f1vr2K/LRIX1Go+CCxNSda yqlTcjpfRNORU0JXVwXqJOZAFKzITUOtWjERLnbchYX0guGnX5DLx79UyuPbz+zJ yeEddvSyVN/XxwgzvYzsKb7vDilgjDnVgDd16Vlw/qeJ7MeUnawRcpo1P+NzCc9H XRMoISlMErXTAztIKyo27XooHfhV1FcIzFECom8Hz2LiNPjk1PwW63QZ0G0PkGVP Wt9BKJXqsREOOd+hsFQxSIl6c7Wsw5QdT5Q2QoJHVC2e7J0nO6d5HMAxDFKekxob nCgcdaL+0Iqp/uVSZ/FJuxZ8MLmYhsQpycsOPw0Un9LJWCI70NUUoTjN/nbVC8+m mkh+Djxge6LThYNGYLOapvy1slHYi8jU4s/ldjXhGNlmuWSY5p6vwqD7gezCZ4VK jIIf7yzl6WPmaxsKaxvhA08HIcQrbTiiChg9JAk0l+Gr4NgNpAE3xUAtHlJfTrbK XqM4hfACdQoBrsDS+9f5NwzcKqBrj/VMu3UikTQo3sinujv6si/ooqvBs+rIb8BC aXZyUbRfDpPnUk/+M+Gn7JZgBG7plXNk8UBDSk+WRzfipnMWd40JgesKqvPOOErJ cbV/9m9nDuzpVYJJuQ/h/jnW8NxJksfJw6LzSO5TxJAtTbN65xMlK3eZ+zrHqNtZ boJH1ow9P9iS6dtBSaX4flC6bSkKLjuzo2tfWOBnafuwDSRFz3urT6NQ8ZjboR/p 0SAIskq5nFMjj5lnm2Nk63ikrUBM1mg2gcP5Is4iv/57cMHqmZKGqQY/u0psOTx5 Tt94d9TtKdZ8bFYLVfeNtuz6aruJ4bhSacGCj8DGjC2FTl6xO05Lx8mraBrTqA18 5kl+dDJbpZL3vfpxRuogKbMwlqNuv66CfFLP3vHR0NxGXFcpvOxU03Y6uvUozqOp 6zLRh+/LK2t43ENKyef9q1JgcCUCsWC+hfmyS+CjxI1n+N+Fmdp8t1QC2hlBBFOY F0FSTeJDkEkW6jPWqV0X/CXDF4i42U2laRj4hT6TCHZSKT2ll/oTiXA8njBhHxI3 d+FwCHLAnQ/Sqm5OhROote6EdujqoChyO9Q+nDrlCe30xD21Kuk2/l+2/d8YXT9c Di8JZuPq/lqW9zy4X1MG2idz7/8FXybK9yXXQUymZtsZM+a5zfOTu2kAKzPARUYc NjDub2lLDKflTnPVCCTJDH/vgcut0rvuX4n5s59M9O1IJ1ULAnzzCzGrU/XoLspq /2V2joCR1oSKoFs9Qj7X2zUtG61iEqqm00Vuzbm7zWwjW+bWKH9XsOChShugl85z v9DWozXH8DTUI1uvSYRA4hz1cSAWDlWD5d6y1EN2ik3HO2PncaMoGW+Cm0XIDSJd N3G5TW9O65oGQP80LKSD9ZSY/6EX+R5CtrOcqex389MfJ+hPz7PNCHEpr8FRueAE 8oO2UC4hA+tx9ZL60hlnkrpf+AueLTcJomnwyf92Y1F1xaCrskUm31LIeCZejs82 GygsvqkCk5/wE8uZdhtr+Hi6d3Cis+DRi18wQLHteGu1Nfp6GoeczG+Bb74x7R5n 15JvS0YMyDAKnlGG7arq9l57dw7BlOKljsVjw0j65g/8eAwNIoE/kIzQGhVLqAYN a3UAWr2ZklHyM3nzowoTWUVsXcndAJGzPyJvaLfQUmAZmAo2QSVaahc5gYRr5ie2 ivO2xYuFGxRW0zIaFJyWb1w3D13iE0EGjhG43Ljcj7l2QNyuHjiiu2o6PHtl64+z HNlsP0lewhpy7aApvG774CfVXs8sNWyxLH5Mif+q335FA0jPT4VhpAEGDuG84OIO Y0daz0kIecFDaZivqYFxqjVmA65YTAr4roMZKQSJ+GboUmH2kY8KIrjiCR5xM9RC E/XBg3xlxH6WJPItyA3yTMn792bWTX+CNOF9bZEnuUdjXpjgaZjA9XHBxL0o/iqN TrfgKZCIu0ULNLQv71g+dJU+ZxYhxqCY1PiMkneDqFYCXxcxD2u/byjhAOktFdBK DbOohNEz+qfx3bWqkfyBHspinqQhVxS8Qep2oXOYmUcC/oaLgdzlLEuzEup1s7/f 3b/THRoMN5AqDknd7dswIHnduq2qaj5YgScN3DJOucJX+MVIXBj6Kx2nGS9izCMS QnJABfz/KMSL0LOffLYnMPY3yNHgQs1HNoxv81kGxZ1xB4PhrIzFGY4qCNZ5hdhq HLsI3tAYvk6FmnIw8uVE0D1L89pqLEeHSFHVmhHrRADlSMO/UFiSxUKjTrxLLUzf tGLn+tB+qYoyLfI2AgJRUxRwCcB6uJccS1Z2geNkUDNDWFwAa34rMon+leSACH1G v5dCiMUeApZ8V5s+ayky2CDOMJ9JGdbH3VtzqOlZQh1kPg3hkT2ow/I4Yg2l2JD3 7DfEJcr6u+RNH5MMha1FF4fXIaLrxYs608uswlNKYVS5fz2VjR46uWu42KZJJybo M8f7O2xGffvmhHUfCGmP2Bi/c1oM66C9rW7/zFXdxR2CO5NDU7BNr8Dhk+wxJ/bi WNO/TiBXdjgxCMfATWUW41WG9OhzDuE5jXL18jzl00LSPtwlyupSjayoVopZiE2P 8l5JnwZo0VbqDGNOcipC/3MXjG1B3gZOfyCSaOmV+yq8aTepoXPxTjWgBJHGUWbd 7CfzonblXBnefaPKM08kcfjMM8VgK69uez23b/odS9STvDcsduV+FI5qyUhFQvTA AIVxmd06beA= =QYYN -----END PGP MESSAGE----- --Apple-Mail=_1BE0255C-C299-4D71-94DA-718AC4E2A584-- From nobody Fri Jul 29 05:18:27 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0846012D0B0 for ; Fri, 29 Jul 2016 05:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 klYoSBh2Zj3D for ; Fri, 29 Jul 2016 05:18:24 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D21D12B044 for ; Fri, 29 Jul 2016 05:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2884; q=dns/txt; s=iport; t=1469794703; x=1471004303; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=7/1kEY0c9rzIyxxdZ6FZlF0OX2NhvnIPoUmH/B8PKh4=; b=Z0PWWTSu+TvS/ESeDv7dDcv3vf5hTHLNVYRUI6eLJCggWBCogE2pKSXD Ah2Ffvuw2TPXyhA+ucz8l3irc+2KPvqOs3AjFrBLhlRzOuTtxgDXQxyY3 wB0S/pSzcGvYr6UgoDKygG+VecN4Wb269+PCs5Pp7KbvUnUquoofwfenq k=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXBgBmSJtX/xbLJq1dhEW3SoQMhh0Cg?= =?us-ascii?q?X4BAQEBAQFeJ4RdAQUjVhALGCoCAlcGAQwIAQEViBiuIo1wAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBEQ6IIgiCTYdBgloBBJkzgzqBcIlUiVSFbJApVIISHBeBNzqIRAEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.28,439,1464652800"; d="asc'?scan'208";a="639979851" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jul 2016 12:18:21 +0000 Received: from [10.61.231.99] ([10.61.231.99]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6TCILnS029076; Fri, 29 Jul 2016 12:18:21 GMT To: Tom Herbert , Dave Dolson References: From: Eliot Lear Message-ID: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> Date: Fri, 29 Jul 2016 14:18:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="89CL9Bd4Xtpgcb70vaMWSpAFTWulw1Pim" Archived-At: Cc: Erik Nygren , Kyle Rose , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 12:18:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --89CL9Bd4Xtpgcb70vaMWSpAFTWulw1Pim Content-Type: multipart/mixed; boundary="J36gNkaP19Og0Ru7oFbMeqNhubK4eEXlx" From: Eliot Lear To: Tom Herbert , Dave Dolson Cc: Erik Nygren , Kyle Rose , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Message-ID: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) References: In-Reply-To: --J36gNkaP19Og0Ru7oFbMeqNhubK4eEXlx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tom, Something that did not get brought up at the BOF is nagging at me... On 7/28/16 8:17 PM, Tom Herbert wrote: > The abstraction is only useful up to the point that networks preserve > the model. If the network breaks the model in ad hoc ways that forces > the application to try to compensate with more ad hoc mechanisms or > just stop innovating altogether as we see happened with protocol > ossification. You write that as if it's a bad thing ;-) Some amount of protocol ossification is a GOOD thing. In particular, the calling interface for transports needs to be stable or source code will have no shelf life. The fact that TCP's calling interface has been SO stable for SO long has meant that a large code base did not require substantial maintenance just to keep doing the same thing it was doing. I see this as an exercise to determine what needs ossification and what does not, and there are extreme positions at both ends. Eliot --J36gNkaP19Og0Ru7oFbMeqNhubK4eEXlx-- --89CL9Bd4Xtpgcb70vaMWSpAFTWulw1Pim Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXm0mMAAoJEIe2a0bZ0nozdq8IALfsvyxHqAhcPQ0IVmUGF9S2 nZly2qB+lErBIF1v85tN6IBBsarh//3AEK2Ui4Tg/nd8fh+RMhDiOW9Hj9Hn5fUV lLACM2+knwGMSaw05rq6nQtyVFhNT0SaWQJqbAPb8ErbXShVhVEppQ5xhT8+EneP Qg6LLNb4k7sSIxNBh6Z8iQU96XqF/LNpmAJthQNwjtH8HwJ09PKZFSf4sMePULe0 GpL6fUo+Cwr7TLNHxM7QSHNZ6sNWoUXOzjrtL+AQ2QSOkgtdSve5NA4x6i0t65bw LJQsvl5DVrl4w7POaxbtsb1iTL8mSiqzG2ZpIbr3b2FmMJW/y0LD/vTIMbKpr9Y= =qHmZ -----END PGP SIGNATURE----- --89CL9Bd4Xtpgcb70vaMWSpAFTWulw1Pim-- From nobody Fri Jul 29 05:33:44 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7549612D0F8 for ; Fri, 29 Jul 2016 05:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 aSb31_1U5EoN for ; Fri, 29 Jul 2016 05:33:41 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 97F7C12B012 for ; Fri, 29 Jul 2016 05:33:41 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id A22661A13A3; Fri, 29 Jul 2016 14:33:40 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_12F76895-1192-4E0D-B5D2-4772C7FA22BB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 29 Jul 2016 14:33:39 +0200 Message-Id: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> To: spud , privsec-program@iab.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 12:33:43 -0000 --Apple-Mail=_12F76895-1192-4E0D-B5D2-4772C7FA22BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, During the PLUS BoF last week, concern was expressed that a generic = signaling mechanism such as proposed opened two new attack surfaces: (1) A method for endpoints to allow path elements to add non-integrity = protected signals presents a surface for metadata injection attacks, = where an entity who can place devices on a user's access network and has = information about the user's identity could exfiltrate that information = to third parties. For purposes of giving it a name, let's call this a = hypercookie injection attack ("hyper" since it exists in a space = completely inaccessible to the application). (2) Even if path elements are not allowed to say anything, a mechanism = to allow endpoints to add integrity-protected signals to their traffic = presents a surface for coercion attacks. An access provider can force a = user to tag traffic with their user ID or some other token (a signed = assertion that an advertisement has been viewed to the end, or maybe = even just straight-up bitcoins) in order to get "better" connectivity, = or even any connectivity at all. A more classically Orwellian dystopian = variant of this attack has a government requiring citizens to tag all = their outgoing traffic with some government-issued identifier. Let's = call this a hypercookie coercion attack. I am less concerned about the surface PLUS presents to these attacks = than those who have raised the concerns in the BoF and on the mailing = list, because the current Internet architecture is already quite = vulnerable to them. As I said during my presentation last Thursday, Ted = Hardie and I sat down to think about this at lunch a couple of months = ago, and found six ways one could execute hypercookie injection or = coercion today before our pizza showed up. I sat down a little longer to write these up. I found five more, without = even considering trivial out-of-band metadata leaks or steganographic = side channels. = https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta-00= is the result. The conclusion: these attacks are trivially easy to = execute today by exploiting the gap between valid TCP traffic and what = will be ignored by TCP-indifferent devices and endpoints, as well as all = those juicy bits IPv6 gives you. Unless we're willing to rely on the = widespread, altruistic deployment of stateful TCP firewalls to reject = traffic (I think we can use our experience with BCP38 as guidance as to = how well *that* will work, and in any case I think it would be kind of = rich for me of all people to recommend throwing more TCP-meddling = middleboxes into the mix) the only way I can see out is to add integrity = protection to all transport and network-layer headers, as well as = confidentiality protection to those headers the path does not need to = see. This is, of course, the whole point of PLUS. We can and should have a = discussion of what the endpoints should be able to say, and what the = endpoints should be able to let the path say. But if we're concerned = about this attack, the general approach is AFAICT the only way out. Cheers, Brian --Apple-Mail=_12F76895-1192-4E0D-B5D2-4772C7FA22BB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXm00kAAoJEIoSt78L6kaj0boP/RFGJYmQ/Z5VMcP+JFDqVfT9 7aITKYPdwpQ2ZpGh0LJdWHSTKK0KKgoBevOjN2vFDiIFwAMACxtZbn6zdYfqBfNP T2D6hmvPTywI1zkje7E5VvT5/JMGIx9b9e+OGyJZc/LWOmqZ2KBZloVWZK0HkgE/ C0vnoyp8osbRod1IcvSvlziQwMczlhTf/BmzM3jQW7c5+UGg7LjDw+LCVPSEUFxd ecIyO1UaYoxfd4avyvTVrHjXQFbpeIcFE2X+iZUc5UWmHZS/FQQj0yIMJ72iG5mQ eQV0UMjFGgSuGOyrT9M1mgOy5GoaRkebmXCI/KhU6gbuNvUdDnBBaXSkUZ8RSvON NdRojDegr4pKR2pwDSsmHvPAUdZzf6IhCsUQdgMIrv4ez4f3N/ucIWD+kRmwZjxE zrrjX3bc8M0wz5X0o3L5QoY1seXibBwEMknw6KZ4V2ij5bP6cpVBhHvw3xR5qxHx I0Y7avAT+z5pl7CqlzX2Eu1/hOQZCtLQ+Rqw+rFbksbVliQFZvmR8ZySNxkj1kRU Q8/OeWG8NHmC4vPyLlhqZOOpcz425a7BbXxgJ+3x4/YVgTe9gHp8pZ9mxLP9zqDf 6pIGSblda6JkgaJ/y6xtwv9/akTw1TVtYXryNrc7EFmI6uIeWhHvQDXE2GrRrtHl 2rSjH0ote78kb5U+biM3 =ogmv -----END PGP SIGNATURE----- --Apple-Mail=_12F76895-1192-4E0D-B5D2-4772C7FA22BB-- From nobody Fri Jul 29 05:36:25 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21D412D50C for ; Fri, 29 Jul 2016 05:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 039zMq1sA0Bm for ; Fri, 29 Jul 2016 05:36:21 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2429F12D1EB for ; Fri, 29 Jul 2016 05:36:21 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 710D41A13A3; Fri, 29 Jul 2016 14:35:50 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_34D0050B-7228-4011-B88A-CC53D8D365D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <89CE79B8-0FA3-424D-9184-B202A4BD380E@trammell.ch> Date: Fri, 29 Jul 2016 14:35:49 +0200 Message-Id: References: <89CE79B8-0FA3-424D-9184-B202A4BD380E@trammell.ch> To: Erik Nygren X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Kyle Rose , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Dave Dolson , "spud@ietf.org" Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 12:36:24 -0000 --Apple-Mail=_34D0050B-7228-4011-B88A-CC53D8D365D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, all, Oops, somehow GPGTools decided that message needed to be encrypted. Here = it is so that everyone can read it: > On 29 Jul 2016, at 12:57, Brian Trammell wrote: >=20 > hi Erik, all, >=20 > Still catching up on threads here. One point inline: >=20 >> On 28 Jul 2016, at 17:56, Erik Nygren wrote: >>=20 >> This is exactly the sort of thing that I think demonstrates the value = of defining something here so we can have one mechanism that a bunch of = UDP protocols can use to allow for several minute state timeouts. >>=20 >> With TCP you need the sequence/ack numbers to get enough entropy due = to the port number being only 16 bits. If the connection-id is 64 bits = (or there are two 64-bit connection-ids in the packet, one contributed = by each end-point) does this contribute enough entropy to prevent = passive adversary close/reset attacks? It seems like active adversary = close/reset attacks aren't possible to reliably defend against (without = crypto between middle boxes and endpoint). >=20 > See Luckie et al in IMC2015 "Resilience of Deployed TCP to Blind = Attacks" at http://www.caida.org/~mjl/pubs/blind.pdf. Summary: the = situation is pretty bleak for everything except BGP. The dominance of = relatively short TCP sessions in Internet traffic mitigates this = somewhat. >=20 > An explicit separation between integrity-protected, path-visible, and = confidentiality-protected, path-invisible communication in the transport = layer is necessary to remedy this situation. This is of course what = we're trying to do here. :) >=20 > Cheers, >=20 > Brian >=20 >> A pattern that has been discussed that seems quite valuable would be = to distribute additional connection-ids for mobility and resumption = within the encrypted channel. This would allow for resumption, = mobility, and periodically cranking the connection-id without = linkability. >>=20 >> Having a server-contributed component of the connection-id (perhaps = an initial one in clear-text and later ones through the encrypted = channel) could allow for stateless packet distribution by server-side = load balancers and could also form part of a proof-of-address-ownership = three-way-handshake mechanism to mitigate against DDoS reflection and = spoofed source address attacks. >>=20 >> Erik >>=20 >>=20 >>=20 >> On Thu, Jul 28, 2016 at 11:23 AM, Dave Dolson = wrote: >> Regarding the state kept by middle-boxes such as firewalls: >>=20 >> The timeout should be short (a few seconds) until a three-way = handshake is complete. This is required to defend against attacks on = state memory of the firewall. >>=20 >>=20 >>=20 >> In the three-way handshake: >>=20 >> - The server=E2=80=99s SYN-ACK indicates the server is real and = willing to talk to the client. >>=20 >> - the client=E2=80=99s ACK of the server=E2=80=99s SYN-ACK provides = evidence the client is real (vs. spoofed) and has witnessed the SYN-ACK >>=20 >>=20 >>=20 >> The random sequence numbers and ack numbers are valuable in this = regard. E.g., a spoofing device cannot simply send the first and third = packets because the third packet must correctly ACK the second packet = from the server. >>=20 >>=20 >>=20 >> Once a three-way handshake is witnessed, TCP state timeout can be = several minutes. >>=20 >>=20 >>=20 >> The proposal below doesn=E2=80=99t seem to contain enough information = for a firewall to know the client is real. >>=20 >> Consider adding a random number that each side can echo back? Perhaps = a different connection-ID per direction? >>=20 >>=20 >>=20 >> -Dave >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Erik Nygren >> Sent: Thursday, July 28, 2016 11:03 AM >> To: Mirja K=C3=BChlewind >> Cc: Kyle Rose; spud@ietf.org >> Subject: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy = concerns expressed at the BoF) >>=20 >>=20 >>=20 >> On Mon, Jul 25, 2016 at 4:20 PM, Mirja K=C3=BChlewind = wrote: >>=20 >> As mentioned by Ted, this is actually not what we propose. The = mechanism we propose is exposing information under endpoint control = which is a very important point here. The endpoint has to add an option = to send (or request) a specific bit of information (which also must be = registered by IANA with IESG approval). This is just the same as TCP = options or IP option headers. The only difference is that PLUS has a MAC = which allows detection of middlebox manipulation (which is not the case = for other existing protocols such as TCP options). This is another a = very big and important aspect of what we propose with PLUS as our goal = is to encrypt everything above PLUS including the TCP header and TCP = options in future. Especially encrypting TCP option is important because = TCP options provide much less control than what we propose with PLUS = today which is a problem (especially as currently still unto 90% of the = traffic is TCP). So I actually though we are on the same page here and = have a common goal. >>=20 >>=20 >>=20 >> I'm not sure that we get enough value out of extensibility or being = overly generic here, at least for practical non-research purposes. If = there is a tightly defined set of things allowed, we'll quickly ossify = on these anyways. As firewall vendors will just bake in those = registered by IANA when they ship their product and then we'll be right = back where we are today with IPv6 extension headers. >>=20 >> I'd propose that it may make more sense to define a fixed header = prefix format that contains the right set of features needed to solve = the problems of QUIC and WebRTC (and other future UDP protocols). Along = with this, also define a common set of requirements for protocols using = this header prefix (eg, around DDoS reflection prevention). >>=20 >> Having a toolkit for things like handling connection ids in a way = that support multipath mobility, stateless load-balancers, DDoS = resiliance, and which minimize linkability would also be a nice-to-have = to prevent each UDP protocol from having to come up with subtly = different ways to solve this set of problems. >>=20 >>=20 >>=20 >> For example, a bare minimum set of features might include: >>=20 >>=20 >>=20 >> * Opportunistic signalling to middle-boxes (NATs and Firewalls) for = when they can discard connection state. Unless we want to declare that = new UDP protocols only work with IPv6 (worth seriously considering, but = perhaps not realistic yet), there just aren't enough {IPv4,port} tuples = available for NATs to support large numbers of users with large numbers = of UDP connections without having crazy-short keep-alive lifetimes. = Middle-boxes will always need to be aware that this is best-effort (the = FINs can be dropped or lost or not sent by malicious clients, especially = during multipath transitions) but this could make life much better for = well-behaved clients and things like the existing NATs which use port = ranges per client might encourage clients to be well-behaved here on = average. >>=20 >> * Negotiating initial PMTU/MSS. While clients will need to be able = to probe up/down and respond to routing changes that change the PMTU, = the TCP MSS mechanism and ability for middle boxes to decrement/clamp = this value makes a big difference in how quickly clients behind tunnels = can converge without losing round-trips or having very complicated = probing. Especially if we want to be able to deploy jumbo-frames it = will be important to have a mechanism here. >>=20 >>=20 >>=20 >> * Sending signals in both directions that can be correlated to = connections. Using ICMP/ICMPv6 may be a fine way to do this but having = a common prefix for connection information that can be included in the = message makes some things such as routing the messages through a = load-balancer much more viable). >>=20 >>=20 >>=20 >> * ... there may be a few others from the use-cases doc. >>=20 >>=20 >>=20 >> Having a fixed header prefix format might also make it much more = viable to implement with today's router/firewall hardware with just = firmware/software updates which might make a big difference for = medium-term uptake. >>=20 >> It might be we can get away with something like: >>=20 >> [MAGIC+VERSION] [CONNECTION_ID] [BITS_FOR_SYN_FIN] >> [MSS_DURING_NEGOTIATION_WHEN_SYN_IS_SET] >>=20 >> [EXTENSION_SPACE_OSSIFICATION_MAY_NOT_PASS] >>=20 >>=20 >>=20 >> It might be reasonable to allow for some padding space for future = extension and research, but with the expectation that this will often = get dropped/filtered and thus would be something clients would need to = probe for (and is something people could find a way to do today = regardless). >>=20 >>=20 >>=20 >> Erik >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >=20 --Apple-Mail=_34D0050B-7228-4011-B88A-CC53D8D365D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXm02mAAoJEIoSt78L6kajrfoP/0rg9xS1gszULroR5NxYK7V0 +tOVk8dTBzO3qBuWFfM3OGbNpA4X2LdzGbOUAWpQ9djt5abEY9oBiZl8+tWBpHx6 B9hMVXjoBgffW7XCY8nrITpOeKmVnkiiDjjBnZecB+KXAWccM8JPnwvW5AahooCe 1/1xL3oL0Ldx03XS106kX9YLOOUWk3t6G68sE+EVZp5MjKkclM8A/HGzEQS9GsoB 6xYu8Pv5YmekEg8SOmXIDthkVDnJr8jaR9qzC9CqX6uhtI05FRJXEq4EMw4Vpxqo WAC8E6rdxdlWSZQdq86w2bfHJmZI3c/9/H+KxS8ycd9bCST5OOj9riJozC30KsAd wTwOMsuNtX4ObUPqKbcFFRCxbePG5SmtWCy51PDu4bWuc4iTTggWrEY5IqC6xyps Qi86bAipkMnxeLEEadaQCmCNHbKGPO2IGVXI4AvjiGXDnM4361LVbf6jahJTJ1z8 daTMD64t/TVA/uoNmCCxVmzjE3SsTJNRlaj1OJdKoUccbJKSrEbHxLlUXaKorsbh YpMTOE8HlFhANtt7ozgYHMj6/AXoWzPmrX5wGlNXeJt5TmDXSehO6DkGSF2pNCsJ 9e9Vpc83BcH1dJWi5gB9vUv15jt+a+HDTFX1Qjq8qn3W4/BngfvUIyvyS3NWwrWY bJw7gkhJg9PcuVer1wKg =E2yj -----END PGP SIGNATURE----- --Apple-Mail=_34D0050B-7228-4011-B88A-CC53D8D365D0-- From nobody Fri Jul 29 05:39:35 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7671712D638 for ; Fri, 29 Jul 2016 05:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 wqyGSQQ7O9in for ; Fri, 29 Jul 2016 05:39:32 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 CABC912D589 for ; Fri, 29 Jul 2016 05:39:31 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o67so89246381qke.1 for ; Fri, 29 Jul 2016 05:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NA7VWOqs2BMehd0+ok+xDIKJ8Sf/ULRf5ji7uZKI8LI=; b=bkHBkjRUS40cCkP8Z70sEql3z0AQeENCEJihZErDvDwByVOr9Rmikgjc65muMOe6Bs xaEGdC0m1y48fbVi5+l52BFp1BtX3InGuYdfiH7VEzYIplwePw3nr1lug2GcJPBZ3UTT pKurjzokOR4GZSIgyYS8gC+FGmASG/IsCQdNg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NA7VWOqs2BMehd0+ok+xDIKJ8Sf/ULRf5ji7uZKI8LI=; b=TvTWdUUBVeiYoWSVq3hm2utMONxALNa2XPLg6QbgJnTImUjSae0dE1WATm7BfpDzKL zc5AazzPnXlDOCCjHU/cNAoe1LRhqvFDKAShhkXqTB8YqXB8UZWcQkFI/LYxFXmM9Id+ bo9nUnPdSq1x5+bUh/dnLy0LyQOssG87k2mTi9iq1Npl8Z7F8R+qtobqohvSDo+xbuWx NjXodSHjfbEvlJiEf68gkJND7CwI2zNid74nNxdoL0Iu5W6T1rPeTwL+m3YL/zqgakHt c7aNdGuCIaQqLIxaJJ/Aw1AGxVfc646p9+p08xSd4QpQy5lgNWG2BIqziMlQg1TNpQqx cRJw== X-Gm-Message-State: AEkoousBoCOeoQX/cbpMUujn9aJmACFnz22zfJUfHghG4gm3kjwrPs/NT2dbd9l+gDfn3V6yjgLS16qIJTB6jA== X-Received: by 10.55.98.205 with SMTP id w196mr50156374qkb.65.1469795970934; Fri, 29 Jul 2016 05:39:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.94.70 with HTTP; Fri, 29 Jul 2016 05:39:30 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:55a1:ece1:303c:874b] In-Reply-To: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> References: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> From: Kyle Rose Date: Fri, 29 Jul 2016 08:39:30 -0400 Message-ID: To: Eliot Lear Content-Type: multipart/alternative; boundary=94eb2c056648bdb0820538c58a06 Archived-At: Cc: Tom Herbert , spud , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Dave Dolson , Erik Nygren Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 12:39:34 -0000 --94eb2c056648bdb0820538c58a06 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 29, 2016 at 8:18 AM, Eliot Lear wrote: > Hi Tom, > > Something that did not get brought up at the BOF is nagging at me... > > > On 7/28/16 8:17 PM, Tom Herbert wrote: > > The abstraction is only useful up to the point that networks preserve > > the model. If the network breaks the model in ad hoc ways that forces > > the application to try to compensate with more ad hoc mechanisms or > > just stop innovating altogether as we see happened with protocol > > ossification. > > You write that as if it's a bad thing ;-) > > Some amount of protocol ossification is a GOOD thing. In particular, > the calling interface for transports needs to be stable or source code > will have no shelf life. The fact that TCP's calling interface has been > SO stable for SO long has meant that a large code base did not require > substantial maintenance just to keep doing the same thing it was > doing. I see this as an exercise to determine what needs ossification > and what does not, and there are extreme positions at both ends. > I think this conflates two issues. I think of "ossification" as unintended structure that precludes development within the protocol stack, something I think is broadly accepted as a problem by people who are trying to improve the experience of users. What you are talking about here seems to be stability of the API for a specific protocol. Frankly, if we apply "ossification" to that then the term becomes overly broad and therefore meaningless. I don't think anyone is suggesting that all APIs should be randomly perturbed over time just to see what happens. No one is going to break the sockets API anytime soon, but having to develop a new API for modern protocols would be a nice problem to have. First, though, we need to figure out how to route those protocols through the boxes that right now assume the entire internet runs over a snapshot of TCP from 20 years ago. Kyle --94eb2c056648bdb0820538c58a06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 29, 2016 at 8:18 AM, Eliot Lear <lear@cisco.com> wrote:=
Hi Tom,

Something that did not get brought up at the BOF is nagging at me...


On 7/28/16 8:17 PM, Tom Herbert wrote:
> The abstraction is only useful up to the point that networks preserve<= br> > the model. If the network breaks the model in ad hoc ways that forces<= br> > the application to try to compensate with more ad hoc mechanisms or > just stop innovating altogether as we see happened with protocol
> ossification.

You write that as if it's a bad thing ;-)

Some amount of protocol ossification is a GOOD thing.=C2=A0 In particular,<= br> the calling interface for transports needs to be stable or source code
will have no shelf life.=C2=A0 The fact that TCP's calling interface ha= s been
SO stable for SO long has meant that a large code base did not require
substantial maintenance just to keep doing the same thing it was
doing.=C2=A0 =C2=A0I see this as an exercise to determine what needs ossifi= cation
and what does not, and there are extreme positions at both ends.

I think this conflates two issues. I think of &qu= ot;ossification" as unintended structure that precludes development wi= thin the protocol stack, something I think is broadly accepted as a problem= by people who are trying to improve the experience of users. What you are = talking about here seems to be stability of the API for a specific protocol= . Frankly, if we apply "ossification" to that then the term becom= es overly broad and therefore meaningless. I don't think anyone is sugg= esting that all APIs should be randomly perturbed over time just to see wha= t happens.

No one is going to break the sockets API anytime soon, bu= t having to develop a new API for modern protocols would be a nice problem = to have. First, though, we need to figure out how to route those protocols = through the boxes that right now assume the entire internet runs over a sna= pshot of TCP from 20 years ago.

Kyle
--94eb2c056648bdb0820538c58a06-- From nobody Fri Jul 29 06:01:19 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493B912DB85 for ; Fri, 29 Jul 2016 06:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 q7vvBv1DW_4M for ; Fri, 29 Jul 2016 06:01:17 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA5D12DBD9 for ; Fri, 29 Jul 2016 06:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4415; q=dns/txt; s=iport; t=1469797276; x=1471006876; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=pBOGZL1JeJyHUxV1FGYKzqhYj0SK5Nop5FyenBDFNnc=; b=cT8/5BfkjZ4itjOGo7XhF5+JBLLCEragLq0cru1EthazaJKsJPjUX0TJ yJSXaj+OOFHP3Z3WdQwNQcVr96gjoi8KoollfXbQYBzWEhInT4dgfx2K2 qAbfbDW2NeFPbDO5IOVwKWNo64qQYYgQkMamiBO3chjy7eKFMcaY5Mev9 s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzCwA6UptX/xbLJq1dhEW0VIJ2hAyGH?= =?us-ascii?q?QKBfgEBAQEBAV4nhF0BBSNWEAsEAQkKKgICVwYNCAEBiC2uRY1uAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBDg6IIoJVh0GCWgEEmTODOoFwiVSJVIVskClUgkWBNzqIH?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,439,1464652800"; d="asc'?scan'208,217";a="638163033" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jul 2016 13:01:14 +0000 Received: from [10.61.231.99] ([10.61.231.99]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6TD1EqK009820; Fri, 29 Jul 2016 13:01:14 GMT To: Kyle Rose References: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> From: Eliot Lear Message-ID: Date: Fri, 29 Jul 2016 15:01:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vMbfniG79rbviUJN99buDbJIWcmeWj9mu" Archived-At: Cc: Tom Herbert , spud , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Dave Dolson , Erik Nygren Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:01:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vMbfniG79rbviUJN99buDbJIWcmeWj9mu Content-Type: multipart/mixed; boundary="vDk4iUrxilorrH3oRBXL8Kpi2JWsQ3vBd" From: Eliot Lear To: Kyle Rose Cc: Tom Herbert , Dave Dolson , Erik Nygren , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Message-ID: Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) References: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> In-Reply-To: --vDk4iUrxilorrH3oRBXL8Kpi2JWsQ3vBd Content-Type: multipart/alternative; boundary="------------63BD0120CA121F5C24ACC667" This is a multi-part message in MIME format. --------------63BD0120CA121F5C24ACC667 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kyle, On 7/29/16 2:39 PM, Kyle Rose wrote: > > No one is going to break the sockets API anytime soon, but having to > develop a new API for modern protocols would be a nice problem to > have. First, though, we need to figure out how to route those > protocols through the boxes that right now assume the entire internet > runs over a snapshot of TCP from 20 years ago. > We now have platforms that lose backward compatibility in as little as a year. And so if a transport interface is being rev'd, a developer may be left to only guess at which point it will be stable. In as much as the semantics are changing, that's a problem. Eliot --------------63BD0120CA121F5C24ACC667 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Kyle,

On 7/29/16 2:39 PM, Kyle Rose wrote:

No one is going to break the sockets API anytime soon, but having to develop a new API for modern protocols would be a nice problem to have. First, though, we need to figure out how to route those protocols through the boxes that right now assume the entire internet runs over a snapshot of TCP from 20 years ago.


We now have platforms that lose backward compatibility in as little as a year.=C2=A0 And so if a transport interface is being rev'd, a developer may be left to only guess at which point it will be stable.=C2=A0 In as much as the semantics are changing, that's a prob= lem.

Eliot

--------------63BD0120CA121F5C24ACC667-- --vDk4iUrxilorrH3oRBXL8Kpi2JWsQ3vBd-- --vMbfniG79rbviUJN99buDbJIWcmeWj9mu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXm1OZAAoJEIe2a0bZ0nozqSgH+wd/+IMpY4FC4pw/z5DgpKPI HUuFSno2Xiv+aJjYBULlHGUNHoEhwfC9OdyBHPNKjNEb4260WLllsCEsfS+ia0Mu q3InjLlcCRReetbPB1+vYozkVSjdRe6OPK1eCP9TXT5uBaZ4qvI4y+KZtUo/GGY/ tK3BejwjFnoMEXWarrWzPEyXSsRO+LIQWp4xoVxV9d5h5OqAAbwiVhqQSw5r1/4n 8GzJf9NlbFxVJs8ROOR/4Z4s2G/4TJSzkeKbSZp9Va3J+j/wfZ7VjKBBIkgmaAY1 ByR17yipPcMeeaefXJz5xl83SXWRKRgNcY3wz/ofkAJqYYaqn9uxMu7LK3U23Ec= =rF0l -----END PGP SIGNATURE----- --vMbfniG79rbviUJN99buDbJIWcmeWj9mu-- From nobody Fri Jul 29 06:08:09 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7490912D5A3 for ; Fri, 29 Jul 2016 06:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 2bALdBh1feKf for ; Fri, 29 Jul 2016 06:08:06 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 226A112D0F9 for ; Fri, 29 Jul 2016 06:08:06 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id u25so65817005qtb.1 for ; Fri, 29 Jul 2016 06:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3PizhZfjZX00mQLgq12Qzw+N1KYWkaX66c33WLNATnk=; b=dQSW1FwxLJiYJBfAYaR096anKPPbObb1XVTqKWReJ+ikw7I5ic81yX+0nMeR4621R4 HWWEGBC/KhqHTp1SmWSSX8JO6csTt8aD7UTzWrNZmwksy05tLDHVBuSK3/KtkAKn40mG jb0p58yxxZK4XJnYsnLpPsgzXmIyq19nvu4oQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3PizhZfjZX00mQLgq12Qzw+N1KYWkaX66c33WLNATnk=; b=aMfrHb4V1Dq87qlBxkz+g+6wX00ldEMhjQcodEqD142HPpsKDXx5/Ywwp2GTj7eHdX 3+lnsdx3gl0xNVGjctzwHYERb8rLwjEh2ed+z0fVbqLYtbXGZR3epV8jI6k5LIavUYLt vX/1CGbLKaJXYh3/aSMpxJOhXuFTmDcU5Y3pyIO15VMzQbBbWAGrQO8jtAPqGeq828G7 993/Ozy0tToMvSU7T9ng7wcJprni1hU+KiE7kmF+m8x9+2abYL8OGS49D2CMAv8pHTO3 MgmKim5nRFBOjx0WvJ6gdHvKd2ITqIT8Jd0F039yiHYSgpAOpLc5katvb8PPhk3Fczj8 649g== X-Gm-Message-State: AEkoouuGsWmsnybUHduENOHSB6D/l4BdWXpeEBoZsAl2//y9bcusx9hkOR3JZu/PvTUOcK3QB8+r2ZAoFilnfg== X-Received: by 10.237.51.162 with SMTP id v31mr65361118qtd.1.1469797685151; Fri, 29 Jul 2016 06:08:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.94.70 with HTTP; Fri, 29 Jul 2016 06:08:04 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:55a1:ece1:303c:874b] In-Reply-To: References: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> From: Kyle Rose Date: Fri, 29 Jul 2016 09:08:04 -0400 Message-ID: To: Eliot Lear Content-Type: multipart/alternative; boundary=94eb2c124a32ea80070538c5f0ba Archived-At: Cc: Tom Herbert , spud , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Dave Dolson , Erik Nygren Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:08:07 -0000 --94eb2c124a32ea80070538c5f0ba Content-Type: text/plain; charset=UTF-8 On Fri, Jul 29, 2016 at 9:01 AM, Eliot Lear wrote: > Kyle, > On 7/29/16 2:39 PM, Kyle Rose wrote: > > > No one is going to break the sockets API anytime soon, but having to > develop a new API for modern protocols would be a nice problem to have. > First, though, we need to figure out how to route those protocols through > the boxes that right now assume the entire internet runs over a snapshot of > TCP from 20 years ago. > > > We now have platforms that lose backward compatibility in as little as a > year. And so if a transport interface is being rev'd, a developer may be > left to only guess at which point it will be stable. In as much as the > semantics are changing, that's a problem. > Are you referring to QUIC? What you highlight is precisely why Google did *not* take it to IETF too quickly: because they wanted to retain the ability to revise it quickly during a period of intense experimentation. No one here doubts that standardization necessarily brings stability in terms of backward compatibility to the API and wire protocol, but I imagine one of the things we'll be focusing on in the QUIC WG is how to enable future evolution within the constraint of interoperability with older versions. Kyle --94eb2c124a32ea80070538c5f0ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 29, 2016 at 9:01 AM, Eliot Lear <lear@cisco.com> wrote:=
=20 =20 =20

Kyle,

On 7/29/16 2:39 PM, Kyle Rose wrote:

No one is going to break the sockets API anytime soon, but having to develop a new API for modern protocols would be a nice problem to have. First, though, we need to figure out how to route those protocols through the boxes that right now assume the entire internet runs over a snapshot of TCP from 20 years ago.


 We now have platforms that lose backward compatibility in as little as a year.=C2=A0 And so if a transport interface is being rev'd, a developer may be left to only guess at which point it will be stable.=C2=A0 In as much as the semantics are changing, that's a pr= oblem.

Are you referring to QUIC? What you highlight is pr= ecisely why Google did *not* take it to IETF too quickly: because they want= ed to retain the ability to revise it quickly during a period of intense ex= perimentation. No one here doubts that standardization necessarily brings s= tability in terms of backward compatibility to the API and wire protocol, b= ut I imagine one of the things we'll be focusing on in the QUIC WG is h= ow to enable future evolution within the constraint of interoperability wit= h older versions.

Kyle
--94eb2c124a32ea80070538c5f0ba-- From nobody Fri Jul 29 06:17:18 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E67212D825 for ; Fri, 29 Jul 2016 06:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 w1Mc-INxe7wz for ; Fri, 29 Jul 2016 06:17:15 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0F98C12D60E for ; Fri, 29 Jul 2016 06:17:15 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 270BF1A0F8A; Fri, 29 Jul 2016 15:16:44 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_04873A7C-1E81-4511-B53F-42A757876B4C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Fri, 29 Jul 2016 15:16:43 +0200 Message-Id: <74798706-06D7-4C8C-891D-AF4D519B9D6F@trammell.ch> References: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> To: Kyle Rose X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Eliot Lear , Tom Herbert , Erik Nygren , =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud , Dave Dolson Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:17:17 -0000 --Apple-Mail=_04873A7C-1E81-4511-B53F-42A757876B4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Kyle, > On 29 Jul 2016, at 14:39, Kyle Rose wrote: >=20 >> On Fri, Jul 29, 2016 at 8:18 AM, Eliot Lear wrote: >> Hi Tom, >>=20 >> Something that did not get brought up at the BOF is nagging at me... >>=20 >>=20 >> On 7/28/16 8:17 PM, Tom Herbert wrote: >> > The abstraction is only useful up to the point that networks = preserve >> > the model. If the network breaks the model in ad hoc ways that = forces >> > the application to try to compensate with more ad hoc mechanisms or >> > just stop innovating altogether as we see happened with protocol >> > ossification. >>=20 >> You write that as if it's a bad thing ;-) >>=20 >> Some amount of protocol ossification is a GOOD thing. In particular, >> the calling interface for transports needs to be stable or source = code >> will have no shelf life. The fact that TCP's calling interface has = been >> SO stable for SO long has meant that a large code base did not = require >> substantial maintenance just to keep doing the same thing it was >> doing. I see this as an exercise to determine what needs = ossification >> and what does not, and there are extreme positions at both ends. >=20 > I think this conflates two issues. I think of "ossification" as = unintended structure that precludes development within the protocol = stack, something I think is broadly accepted as a problem by people who = are trying to improve the experience of users. What you are talking = about here seems to be stability of the API for a specific protocol. = Frankly, if we apply "ossification" to that then the term becomes overly = broad and therefore meaningless. I don't think anyone is suggesting that = all APIs should be randomly perturbed over time just to see what = happens. Some of it is stability of the API, some of it is the stability of the = what i'll call the "wire image": what the headers and behaviors look = like to an on-path device. I agree with Eliot that what we're trying to do here is re-ossify the = wire image *on purpose*, given the things we've learned since the 1980s = from the less intentional ossification that's happened since then. There = is a careful line to draw when doing this. It should be generic enough = that all the transport innovation we think we might want to do between = now and 2040 fits inside it. It should be restrictive enough that it = presents an improvement on the present state of the world with respect = to the types of shenanigans described in = https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta-00= . But if it's too restrictive, people will just find other ways to = implement the kinds of in-network functions they want to: cf. using the = QUIC version number as a QUIC magic number, for instance. > No one is going to break the sockets API anytime soon *ahem* https://www.ietf.org/proceedings/96/slides/slides-96-taps-2.pdf = *cough* -- I'm not saying we're going to be successful in breaking it, = but it *is* the other half of the problem we have today. Cheers, Brian > but having to develop a new API for modern protocols would be a nice = problem to have. First, though, we need to figure out how to route those = protocols through the boxes that right now assume the entire internet = runs over a snapshot of TCP from 20 years ago. >=20 > Kyle > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_04873A7C-1E81-4511-B53F-42A757876B4C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXm1c7AAoJEIoSt78L6kajOaYP/i2/ADX+U2EabCmKGawrGJEQ 322lkXGeD1tDwN0s9IabMsrXbmfwRhQzfV7eysou1e0wCIuiIGgninHSixUhwWEa OdNDa/mMxQ94VbQhZZSHeGVb8TYly1YB3OQtVEM6X8JHExWOIeAP5XQv3SLS6xcJ oZkclZcw4Nmbgcmc6rKw7A8ERvDkCw5/tnW6af4uV6BGX1nAUTl39799OoTDMFYo 8Vg3ivMt+16kWlBJc73qwqXJwTH6O+TmHmzh+WQ5zLf1+SOZp00fiaeMcsXGUVxL 2Ng0wiI61gSKEvxop4NTDSMvVad3ftgc3yRL/6DnSi051DEAVsHz4yq9pjjE5vK0 LvsoC1+KRwxkIdZlSGK/WxFs9rZVVi9CLjwIWFdFkJtpp+tXnCvGhz6m/Wjs94OK wsODnrWnVfMIdVhDtpYBbc0XMK2BaZE+XLQKha0CmwMGJnQ/OOHkJlzBkV0Wpwl3 jr5aDG/7xaCJpxo7f+/5bU7GYvA+lbZbeYKU20YpxsgvUStF2Lx5le1N5MQNzADq wDp+85a0sG1lH8C6AVx3T7VeeMK/ffkn/7ztr0RyI+/iiO9UAso6vog0ETHig0Vs F+1fQOn6Oxa09v7YuukQ/+Gtxk2Ia3tFyfechqIoWq0Mw84P3OEEn5h0vN1NNhgo qhoQIO8DjVxYmRt6SdyM =cnRQ -----END PGP SIGNATURE----- --Apple-Mail=_04873A7C-1E81-4511-B53F-42A757876B4C-- From nobody Fri Jul 29 06:23:33 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426C612D0EE for ; Fri, 29 Jul 2016 06:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 GZzTEkbXYKjT for ; Fri, 29 Jul 2016 06:23:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CE212D19B for ; Fri, 29 Jul 2016 06:23:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AC15FBE3F; Fri, 29 Jul 2016 14:23:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaQei0y98axH; Fri, 29 Jul 2016 14:23:19 +0100 (IST) Received: from [192.168.1.5] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E344CBE38; Fri, 29 Jul 2016 14:23:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469798599; bh=CZSOBYbfh7Zl7UJz6BWao3qbFV4bm3jlyNXdzazYxAg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=onEZBV17g1Y4SBsg3DnpmQKM2ukJ50Z7iepFvguNtPKoVcNkXoSQpK3myZ8wumJet Iw/oFX7A7aCqAL72BeY+n56k7bxCRK2vlWmBXEx67dDQg5tsaf9LM2AJOPUIOzfEL8 dbG8EAN7efruQrwc74VqkjUc2K+IdProZEMn5tYU= To: Brian Trammell , spud , privsec-program@iab.org References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 29 Jul 2016 14:23:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l6XqvB0vpMV68t0HNgn1K2iK9GQ7ufx44" Archived-At: Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:23:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l6XqvB0vpMV68t0HNgn1K2iK9GQ7ufx44 Content-Type: multipart/mixed; boundary="GcfTQU8PBSebRDb24q3H26oGTtHEVllH7" From: Stephen Farrell To: Brian Trammell , spud , privsec-program@iab.org Message-ID: Subject: Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> In-Reply-To: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> --GcfTQU8PBSebRDb24q3H26oGTtHEVllH7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brian, On 29/07/16 13:33, Brian Trammell wrote: > Greetings, all, >=20 > During the PLUS BoF last week, concern was expressed that a generic > signaling mechanism such as proposed opened two new attack surfaces: No necessarily "opened...new" perhaps more "risked making much more ubiquitous." At the meeting I didn't hear anyone claim these were new attacks. (I did hear you say they were not new.) >=20 > (1) A method for endpoints to allow path elements to add > non-integrity protected signals presents a surface for metadata > injection attacks, where an entity who can place devices on a user's > access network and has information about the user's identity could > exfiltrate that information to third parties. For purposes of giving > it a name, let's call this a hypercookie injection attack ("hyper" > since it exists in a space completely inaccessible to the > application). >=20 > (2) Even if path elements are not allowed to say anything, a > mechanism to allow endpoints to add integrity-protected signals to > their traffic presents a surface for coercion attacks. An access > provider can force a user to tag traffic with their user ID or some > other token (a signed assertion that an advertisement has been viewed > to the end, or maybe even just straight-up bitcoins) in order to get > "better" connectivity, or even any connectivity at all. A more > classically Orwellian dystopian variant of this attack has a > government requiring citizens to tag all their outgoing traffic with > some government-issued identifier. Let's call this a hypercookie > coercion attack. >=20 > I am less concerned about the surface PLUS presents to these attacks > than those who have raised the concerns in the BoF and on the mailing > list, because the current Internet architecture is already quite > vulnerable to them. As I said during my presentation last Thursday, > Ted Hardie and I sat down to think about this at lunch a couple of > months ago, and found six ways one could execute hypercookie > injection or coercion today before our pizza showed up. Wrt injection I can buy that totally. Having read your draft I don't find enough there to accept your assertion wrt coercion - ISTM that coercion attacks have not been analysed yet in your draft. As a side-note, meta-data doesn't have to be person-specific to be controversial - "over 18" and anything with similar semantics, e.g. "member of minority" can very clearly be equally or more damaging, yet totally non-identifying if the relevant set of folks is large enough. So I wonder if the "hypercookie" concept is even the right starting point here. And to the extent that PLUS could enable and standardise such things, that is, for me, a major reason to oppose PLUS. (That's a side-note for this email, but perhaps a quite fundamental thing to consider in the overall discussion.) >=20 > I sat down a little longer to write these up. I found five more, > without even considering trivial out-of-band metadata leaks or > steganographic side channels. > https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta= -00 > is the result. The conclusion: these attacks are trivially easy to > execute today by exploiting the gap between valid TCP traffic and > what will be ignored by TCP-indifferent devices and endpoints, as > well as all those juicy bits IPv6 gives you. Unless we're willing to > rely on the widespread, altruistic deployment of stateful TCP > firewalls to reject traffic (I think we can use our experience with > BCP38 as guidance as to how well *that* will work, and in any case I > think it would be kind of rich for me of all people to recommend > throwing more TCP-meddling middleboxes into the mix) the only way I > can see out is to add integrity protection to all transport and > network-layer headers, as well as confidentiality protection to those > headers the path does not need to see. I don't agree. Observatories seem to me like a mitigation that your draft does not consider. If the attacker here does not want to be seen to be attacking, then those can be effective. Should we standardise a method for such abuse, then I think it's quite possible the attacker may argue that their behaviour is not an attack as it's just a part of "the standard." Such a mitigation could be attempted against the attack in 4.1.3 of your draft for example so I disagree with the draft's assertion that "no user-initiated mitigation is possible" in that case at least and maybe others. I think it'd be a fine thing to see further analysis of the attacks and potential mitigations as your draft develops. >=20 > This is, of course, the whole point of PLUS. We can and should have a > discussion of what the endpoints should be able to say, and what the > endpoints should be able to let the path say. But if we're concerned > about this attack, the general approach is AFAICT the only way out. I disagree. And I think it was clear that a whole bunch of folks in the room last week also clearly disagreed. I believe your "only way out" conclusion isn't logically justified as the argument seems to ignore the downsides of standardising and thus legitimising "bad" behaviour including behaviours that your draft properly calls an attack. Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that we have different sets of sensible folks reaching diametrically opposed conclusions based on the same facts and arguments. Perhaps the tl;dr in your abstract may be a hint there - I do not think everything is ruined myself, so maybe one's level of opt/pess-imism affects one's view of the valid conclusions to reach in this space. Cheers, S. >=20 > Cheers, >=20 > Brian >=20 >=20 >=20 > _______________________________________________ Privsec-program > mailing list Privsec-program@iab.org=20 > https://www.iab.org/mailman/listinfo/privsec-program >=20 --GcfTQU8PBSebRDb24q3H26oGTtHEVllH7-- --l6XqvB0vpMV68t0HNgn1K2iK9GQ7ufx44 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXm1jFAAoJEC88hzaAX42iBoAH/2NrimGE7OTHZ2IvNxUYBEz6 0jhWahYQExa6gwHEqtoV4LdG0wh5M4V5fWybCBXU4qxDJL8yyP6F2etaZVgw5SxR nalrNCh1XzRybM/7bm17icTDZJXRW4weVQPugLYK1XqrhmgH40f5oIpmAeY78TW7 VxoaHdojUfc9aUdO89fYDmw31Po7wfZSsgjmX3QGNkQqgmdu49my4qQ44sXnxDgJ WsOP4ZDctfBBegjSelW6oKkUyLy5dZ5dH27bjLk3Gol60ohieC1wwdMQA7vnhe5D kXTIVX5XDPW61NHAl4ldFyiXzdhEDPxcwXxFOS0yPjO0gMAbw2fn/GqIqXq0lrM= =hHrL -----END PGP SIGNATURE----- --l6XqvB0vpMV68t0HNgn1K2iK9GQ7ufx44-- From nobody Fri Jul 29 06:27:17 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF97012D0BF for ; Fri, 29 Jul 2016 06:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 x_XzrInHPqS7 for ; Fri, 29 Jul 2016 06:27:15 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF89612D63F for ; Fri, 29 Jul 2016 06:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6856; q=dns/txt; s=iport; t=1469798833; x=1471008433; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=mRFreQbQ3GfRqC5wiCB+jR6+vd+Cl33dUo24d/2ZPVE=; b=Nu6d5AD28Ou8/anY1Jk9Q5GgLR+Ev0sqWadbzRqeLCkUlrEi9DVMui0j /PhlCQKrHmIZZwEDIuO9pRXg0gxkuzh9iorh16gbnjohMB4G6ZkHO12Eg Li1zfEsw/7S2qKw/kNOBRRMDzmI4BU7gZt1zOxhc4mFm3QQ7rqvR0uwGp k=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1CwCJWJtX/xbLJq1dhEVStAKCdoQMh?= =?us-ascii?q?h0CgWcRAQEBAQEBAV0nhF0BBSNWEAsECgonAwICRhEGDQYCAQGILa5QjW8BAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEODogiglWHQYJaAQSZM4M6gXCJVIlUhWyMMYN4N?= =?us-ascii?q?CCCRYE3OjKHawEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,439,1464652800"; d="asc'?scan'208,217";a="679702316" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jul 2016 13:27:10 +0000 Received: from [10.61.231.99] ([10.61.231.99]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6TDRA17019494; Fri, 29 Jul 2016 13:27:10 GMT To: Kyle Rose References: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> From: Eliot Lear Message-ID: Date: Fri, 29 Jul 2016 15:27:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gHuXXq2Iw3okfS2gwCEqwRpw6tPLpBhSu" Archived-At: Cc: Tom Herbert , spud , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Dave Dolson , Erik Nygren Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:27:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gHuXXq2Iw3okfS2gwCEqwRpw6tPLpBhSu Content-Type: multipart/mixed; boundary="UaEHKRJowjVAaM0Gjo4c53HPQ0D0PLuMr" From: Eliot Lear To: Kyle Rose Cc: Tom Herbert , Dave Dolson , Erik Nygren , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Message-ID: Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) References: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> In-Reply-To: --UaEHKRJowjVAaM0Gjo4c53HPQ0D0PLuMr Content-Type: multipart/alternative; boundary="------------3617B746477C528BD83BE14F" This is a multi-part message in MIME format. --------------3617B746477C528BD83BE14F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/29/16 3:08 PM, Kyle Rose wrote: > On Fri, Jul 29, 2016 at 9:01 AM, Eliot Lear > wrote: > > Kyle, > > On 7/29/16 2:39 PM, Kyle Rose wrote: >> >> No one is going to break the sockets API anytime soon, but having >> to develop a new API for modern protocols would be a nice problem >> to have. First, though, we need to figure out how to route those >> protocols through the boxes that right now assume the entire >> internet runs over a snapshot of TCP from 20 years ago. >> > > We now have platforms that lose backward compatibility in as > little as a year. And so if a transport interface is being rev'd, > a developer may be left to only guess at which point it will be > stable. In as much as the semantics are changing, that's a problem= =2E > > > Are you referring to QUIC? No. I am not. I am reflecting on how people may really have overlooked the value of ossification at the waist. But there is such a thing as overdoing it, and were I a transport developer I'd want things a little easier to change too. Yin/yang (no pun intended). Eliot --------------3617B746477C528BD83BE14F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 7/29/16 3:08 PM, Kyle Rose wrote:
On Fri, Jul 29, 2016 at 9:01 AM, Eliot Lear <lear@cis= co.com> wrote:

Kyle,

On 7/29/16 2:39 PM, Kyle Rose wrote:

No one is going to break the sockets API anytime soon, but having to develop a new API for modern protocols would be a nice problem to have. First, though, we need to figure out how to route those protocols through the boxes that right now assume the entire internet runs over a snapshot of TCP from 20 years ago.


 We now have platforms that lose backward compatibility in as little as a year.=C2=A0 And so if a transport interface is being rev'd, a developer may be left to only guess at which point it will be stable.=C2=A0= In as much as the semantics are changing, that's a problem.<= span class=3D"HOEnZb">

Are you referring to QUIC?

No.=C2=A0 I am not.=C2=A0 I am reflecting on how people may really ha= ve overlooked the value of ossification at the waist.=C2=A0 But there is= such a thing as overdoing it, and were I a transport developer I'd want things a little easier to change too.=C2=A0 Yin/yang (no pun intended).

Eliot


--------------3617B746477C528BD83BE14F-- --UaEHKRJowjVAaM0Gjo4c53HPQ0D0PLuMr-- --gHuXXq2Iw3okfS2gwCEqwRpw6tPLpBhSu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXm1mtAAoJEIe2a0bZ0nozAioH+wesF7SXYegI2ax8SQ//ZPSx zzCLkzcRJ+IZ1uBP7dw7+0Lk3X7LJwGQKW3QBJG8GasMjvLu1V5MnRpuoy10sSrT h58ZQZq8jBRn/1O24w+zptoe7no0CyHZcEp0YRYaMqqu1rzug4/z24cT4UdPSl1R vtwYadWHTNCzqd6xkAHxn+iokiznv3HVsvb870ckfDgo+PNwHeAn1gMijjfO5ZXe ORXvPz36CEjXwo9uDlVGZc05Qzgnb1/dlUSEV6qLZzwRRFufb6aKG820pKeFzLSd bq8FzFkpNhDyZUTfPDQXjGRiEmg6ZsU854eudAv2MX99X1e9zcGqYi4knb6B0mg= =WTO0 -----END PGP SIGNATURE----- --gHuXXq2Iw3okfS2gwCEqwRpw6tPLpBhSu-- From nobody Fri Jul 29 06:56:25 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240F312D0D3 for ; Fri, 29 Jul 2016 06:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 sfHJ6AnWTuXK for ; Fri, 29 Jul 2016 06:56:20 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 734DB12D09D for ; Fri, 29 Jul 2016 06:56:20 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id p74so91194612qka.0 for ; Fri, 29 Jul 2016 06:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ik+7Jf4vM1Xv9Gxdv0BzHn2rzp/lsBZ5gf8PjA6MWDI=; b=qZs0Ibwq/Q7kSFKqz8QPir6XnTW/ftleuyMHc8FkkaFVJAnFSpqqd9uMbbiT4VMBQV fLTruEhMESn6yU5J/67oNK/iH8jUHcz0RnelJsxCEnI49Aj3PrgHRWX7KN6/btqukaiI RE+6cDiwf9qj9FaRlRSXCKK9h4RwH9t7WOTJQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ik+7Jf4vM1Xv9Gxdv0BzHn2rzp/lsBZ5gf8PjA6MWDI=; b=JH/pqqmTXTxxaVtVrg9Sq4yN4p/pre9h54r1V7Y+306tXFK1W3huwbDPpqbNo63QXu A3W5aoJ6jDqscxKjYRdMY+/OWVKghc2ekq3JLjJn9IlyZf3w2wIhTDU2c9aTh8M/ViRT kjuFHanprdvNCvHWF7Jm52Vd4xHE4687eecCv1VBD8vnE9/Uc7o4b05/hXLeFOtYLaVa RvBGQ+hPBF/QCxo0wbR7qJ/n625B8JHi2AvaX4570Ie7HGHZLYAJTxW84VcnNjgnciLh S6ocSTwPgzIqFX1gBreGPYKlSLG/qa05hUHGZSip++xtPWqYOO4VzGSI6wQUPaFKVLMM LZaA== X-Gm-Message-State: AEkoouuUjGHyK2DLZzKTKjJYnAO4i51IJC2iTVsrYGOFakVxxc+H7R3stfxvh+CjGOgGI/v1e65X8XZTWud4jw== X-Received: by 10.55.25.102 with SMTP id k99mr6155237qkh.119.1469800578725; Fri, 29 Jul 2016 06:56:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.94.70 with HTTP; Fri, 29 Jul 2016 06:56:17 -0700 (PDT) X-Originating-IP: [2001:4878:8000:50:8177:dae3:6e7d:d228] In-Reply-To: <74798706-06D7-4C8C-891D-AF4D519B9D6F@trammell.ch> References: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> <74798706-06D7-4C8C-891D-AF4D519B9D6F@trammell.ch> From: Kyle Rose Date: Fri, 29 Jul 2016 09:56:17 -0400 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=001a11473a4862d45e0538c69dde Archived-At: Cc: Eliot Lear , Tom Herbert , Erik Nygren , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud , Dave Dolson Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:56:23 -0000 --001a11473a4862d45e0538c69dde Content-Type: text/plain; charset=UTF-8 On Fri, Jul 29, 2016 at 9:16 AM, Brian Trammell wrote: > Some of it is stability of the API, some of it is the stability of the > what i'll call the "wire image": what the headers and behaviors look like > to an on-path device. > > I agree with Eliot that what we're trying to do here is re-ossify the wire > image *on purpose*, given the things we've learned since the 1980s from the > less intentional ossification that's happened since then. There is a > careful line to draw when doing this. It should be generic enough that all > the transport innovation we think we might want to do between now and 2040 > fits inside it. It should be restrictive enough that it presents an > improvement on the present state of the world with respect to the types of > shenanigans described in > https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta-00. > But if it's too restrictive, people will just find other ways to implement > the kinds of in-network functions they want to: cf. using the QUIC version > number as a QUIC magic number, for instance. > Agreed. I think we're saying basically the same thing. I was merely suggesting that "ossification" as we've been using it applies to what you call the network image, not to the API for the protocols: those APIs are under the full control of each endpoint independently, so long as the underlying protocol can be expressed in terms of that API. (Extreme counterexample: trying to use sigaction/kill as an API to TCP. Maybe it could be done, but it sure would be limiting and pointless.) > No one is going to break the sockets API anytime soon > > *ahem* https://www.ietf.org/proceedings/96/slides/slides-96-taps-2.pdf > *cough* -- I'm not saying we're going to be successful in breaking it, but > it *is* the other half of the problem we have today. > This isn't breaking it: this is offering an alternative. I'm all for that, as long as telnet continues to work without source changes. Kyle --001a11473a4862d45e0538c69dde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 29, 2016 at 9:16 AM, Brian Trammell <ietf@trammell.ch> wrote:
Some o= f it is stability of the API, some of it is the stability of the what i'= ;ll call the "wire image": what the headers and behaviors look li= ke to an on-path device.

I agree with Eliot that what we're trying to do here is re-ossify the w= ire image *on purpose*, given the things we've learned since the 1980s = from the less intentional ossification that's happened since then. Ther= e is a careful line to draw when doing this. It should be generic enough th= at all the transport innovation we think we might want to do between now an= d 2040 fits inside it. It should be restrictive enough that it presents an = improvement on the present state of the world with respect to the types of = shenanigans described in h= ttps://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta-00. But if it's too restrictive, people will just find other ways to im= plement the kinds of in-network functions they want to: cf. using the QUIC = version number as a QUIC magic number, for instance.
> No one is going to break the sockets API anytime soon

*ahem* https://www.ietf.org/pr= oceedings/96/slides/slides-96-taps-2.pdf *cough* -- I'm not saying = we're going to be successful in breaking it, but it *is* the other half= of the problem we have today.

This isn= 't breaking it: this is offering an alternative. I'm all for that, = as long as telnet continues to work without source changes.

Kyle
--001a11473a4862d45e0538c69dde-- From nobody Fri Jul 29 07:48:42 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A757D12D75F for ; Fri, 29 Jul 2016 07:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 lCEaYyDSWcMx for ; Fri, 29 Jul 2016 07:48:38 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3358112D74F for ; Fri, 29 Jul 2016 07:48:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 70660D930B; Fri, 29 Jul 2016 16:48:36 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gUSqr38N72yE; Fri, 29 Jul 2016 16:48:36 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2F34.dip0.t-ipconnect.de [93.236.47.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CA0A1D9307; Fri, 29 Jul 2016 16:48:35 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 29 Jul 2016 16:48:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 14:48:40 -0000 Hi Stephen, I believe that what you think PLUS is, is not what we propose. Maybe we = did not make a great job so far to define PLUS narrowly enough but we = believe the actual protocol specification work should be done in a wg to = ensure that a broad community can participate, and all concern, = including privacy concerns, can be addressed. The point of draft-trammell-privsec-defeating-tcpip-meta is to further = explain that the things you describe as risks are nothing new. And by = new, we mean they are even standard-conform; because this is the main = point of your concern if I understand you correctly, right?=20 I assume your point is that we propose a protocol that is intended to = signal information from middleboxes to the endpoint (amongst other = features). I assume this based on the following statement you made: > Should > we standardise a method for such abuse, then I think it's quite > possible the attacker may argue that their behaviour is not an > attack as it's just a part of "the standard.=E2=80=9C and=20 > And to the extent that > PLUS could enable and standardise such things, that is, for me, > a major reason to oppose PLUS.=20 Otherwise can you please further explain what you mean by =E2=80=9Esuch = abuse=E2=80=9C and =E2=80=9Esuch things=E2=80=9C? If the thing you are concerned about in PLUS is, that we propose to = standardize =E2=80=9Aoption=E2=80=98 space that explicitly allows = middleboxes to add information to a packet, I guess you know that it is = possible to define an experimental TCP option (in the ISE stream) = without IESG approval that allows the insertion of private information = by middleboxes. Even thought TCP options are not intended to be altered = by network nodes, there is also no standard that forbids this. Let me say two things about what we ACTUALLY propose with PLUS: 1) We do NOT propose to add space to add arbitrary information. The = semantic of the field must be well-defined in an IESG approved RFC and = registered respectively. This will not only make it not-standard conform = to use such a field for something different, it also restrict the set of = valid values which then could even be checked by later middleboxes on = the path, and erased if needed. 2) Further only PLUS provides an additional function that allows to = detect any mangling of data/bits that was not intended. This is urgently = needed because all the TCP (and higher) layer mangling we see today is = the root cause for the problem we have right now. Further, I would like to say that not all middlebox mangling is = automatically bad or an attack. If we don=E2=80=99t provide a = standardized way to communicate with middleboxes, it will be even harder = to distinguish an attack from something that actually supports the = network service provided or even makes the services possible at all. = Without standardization there is no control at all. I don=E2=80=99t = think we can ignore what=E2=80=99s already happening the Internet any = further and providing standardized mechanisms to support the good = in-network functions is the only way to improve security for these = functions. To make this even more clear, you wrote: > the argument seems to ignore the downsides of standardising and thus > legitimising "bad" behaviour including behaviours that your draft > properly calls an attack. We not at all want to legitimate =E2=80=9Ebad=E2=80=9C behavior and I = really don=E2=80=99t know why you think that what we propose would do = so. We propose to standardize a protocol that allows middleboxes to = provide information they have been requested for (by the endhost). This = information is well define and under IESG approval. Any other use of = such a protocol will not be standard-conform and as bad as the misuse we = can see today with existing protocols. Mirja =20 > Am 29.07.2016 um 15:23 schrieb Stephen Farrell = : >=20 >=20 > Hi Brian, >=20 > On 29/07/16 13:33, Brian Trammell wrote: >> Greetings, all, >>=20 >> During the PLUS BoF last week, concern was expressed that a generic >> signaling mechanism such as proposed opened two new attack surfaces: >=20 > No necessarily "opened...new" perhaps more "risked making much > more ubiquitous." At the meeting I didn't hear anyone claim these > were new attacks. (I did hear you say they were not new.) >=20 >>=20 >> (1) A method for endpoints to allow path elements to add >> non-integrity protected signals presents a surface for metadata >> injection attacks, where an entity who can place devices on a user's >> access network and has information about the user's identity could >> exfiltrate that information to third parties. For purposes of giving >> it a name, let's call this a hypercookie injection attack ("hyper" >> since it exists in a space completely inaccessible to the >> application). >>=20 >> (2) Even if path elements are not allowed to say anything, a >> mechanism to allow endpoints to add integrity-protected signals to >> their traffic presents a surface for coercion attacks. An access >> provider can force a user to tag traffic with their user ID or some >> other token (a signed assertion that an advertisement has been viewed >> to the end, or maybe even just straight-up bitcoins) in order to get >> "better" connectivity, or even any connectivity at all. A more >> classically Orwellian dystopian variant of this attack has a >> government requiring citizens to tag all their outgoing traffic with >> some government-issued identifier. Let's call this a hypercookie >> coercion attack. >>=20 >> I am less concerned about the surface PLUS presents to these attacks >> than those who have raised the concerns in the BoF and on the mailing >> list, because the current Internet architecture is already quite >> vulnerable to them. As I said during my presentation last Thursday, >> Ted Hardie and I sat down to think about this at lunch a couple of >> months ago, and found six ways one could execute hypercookie >> injection or coercion today before our pizza showed up. >=20 > Wrt injection I can buy that totally. Having read your draft > I don't find enough there to accept your assertion wrt > coercion - ISTM that coercion attacks have not been analysed > yet in your draft. >=20 > As a side-note, meta-data doesn't have to be person-specific to > be controversial - "over 18" and anything with similar semantics, > e.g. "member of minority" can very clearly be equally or > more damaging, yet totally non-identifying if the relevant set of > folks is large enough. So I wonder if the "hypercookie" concept > is even the right starting point here. And to the extent that > PLUS could enable and standardise such things, that is, for me, > a major reason to oppose PLUS. (That's a side-note for this > email, but perhaps a quite fundamental thing to consider in the > overall discussion.) >=20 >>=20 >> I sat down a little longer to write these up. I found five more, >> without even considering trivial out-of-band metadata leaks or >> steganographic side channels. >> = https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta-00= >> is the result. The conclusion: these attacks are trivially easy to >> execute today by exploiting the gap between valid TCP traffic and >> what will be ignored by TCP-indifferent devices and endpoints, as >> well as all those juicy bits IPv6 gives you. Unless we're willing to >> rely on the widespread, altruistic deployment of stateful TCP >> firewalls to reject traffic (I think we can use our experience with >> BCP38 as guidance as to how well *that* will work, and in any case I >> think it would be kind of rich for me of all people to recommend >> throwing more TCP-meddling middleboxes into the mix) the only way I >> can see out is to add integrity protection to all transport and >> network-layer headers, as well as confidentiality protection to those >> headers the path does not need to see. >=20 > I don't agree. Observatories seem to me like a mitigation that > your draft does not consider. If the attacker here does not want > to be seen to be attacking, then those can be effective. Should > we standardise a method for such abuse, then I think it's quite > possible the attacker may argue that their behaviour is not an > attack as it's just a part of "the standard." >=20 > Such a mitigation could be attempted against the attack in 4.1.3 > of your draft for example so I disagree with the draft's assertion > that "no user-initiated mitigation is possible" in that case at > least and maybe others. >=20 > I think it'd be a fine thing to see further analysis of the attacks > and potential mitigations as your draft develops. >=20 >>=20 >> This is, of course, the whole point of PLUS. We can and should have a >> discussion of what the endpoints should be able to say, and what the >> endpoints should be able to let the path say. But if we're concerned >> about this attack, the general approach is AFAICT the only way out. >=20 > I disagree. And I think it was clear that a whole bunch of folks > in the room last week also clearly disagreed. >=20 > I believe your "only way out" conclusion isn't logically justified as > the argument seems to ignore the downsides of standardising and thus > legitimising "bad" behaviour including behaviours that your draft > properly calls an attack. >=20 > Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that we have > different sets of sensible folks reaching diametrically opposed > conclusions based on the same facts and arguments. Perhaps the tl;dr > in your abstract may be a hint there - I do not think everything > is ruined myself, so maybe one's level of opt/pess-imism affects > one's view of the valid conclusions to reach in this space. >=20 > Cheers, > S. >=20 >>=20 >> Cheers, >>=20 >> Brian >>=20 >>=20 >>=20 >> _______________________________________________ Privsec-program >> mailing list Privsec-program@iab.org=20 >> https://www.iab.org/mailman/listinfo/privsec-program >>=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Fri Jul 29 08:17:32 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC82312D186 for ; Fri, 29 Jul 2016 08:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 G4h78jC7rfro for ; Fri, 29 Jul 2016 08:17:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE0012D7AB for ; Fri, 29 Jul 2016 08:17:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0D00CBE39; Fri, 29 Jul 2016 16:17:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lay62GSkI-7R; Fri, 29 Jul 2016 16:17:19 +0100 (IST) Received: from [192.168.1.5] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A28EBE3F; Fri, 29 Jul 2016 16:17:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469805439; bh=vUxuZfYJ0sFNrGqaEOItLXoKbilTR49ArMXKaEGPX50=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YSzputTKkZey9GpBdMSzPu3BEv791U53TvljihkIgG9pjeQW6sGZFRZx6kQOZ8sLe uq9KY90sOwf6Vt/oFIn+cwm3/18CrFAk1wioGexsnFO2ALnVCIOrHzaoDC6IAFCrH8 hU+RK3bwS8gVDE615i1usK/2/hbDlLDQ8tJG/wA4= To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> Date: Fri, 29 Jul 2016 16:17:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010304020004040003050103" Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 15:17:31 -0000 This is a cryptographically signed message in MIME format. --------------ms010304020004040003050103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 29/07/16 15:48, Mirja K=C3=BChlewind wrote: > Hi Stephen, >=20 > I believe that what you think PLUS is, is not what we propose.=20 I'm pretty sure that's true - and is part of what puzzles me as I said before. > Maybe > we did not make a great job so far to define PLUS narrowly enough but > we believe the actual protocol specification work should be done in a > wg to ensure that a broad community can participate, and all concern, > including privacy concerns, can be addressed. I get that. Some folks however (and I'm not sure if I'd count myself amongst them yet or not) fear that any such WG has to end up as very privacy unfriendly if it remains transport agnostic. From that perspective, starting a WG would not make sense. >=20 > The point of draft-trammell-privsec-defeating-tcpip-meta is to > further explain that the things you describe as risks are nothing > new. And by new, we mean they are even standard-conform; because this > is the main point of your concern if I understand you correctly, > right? No. Brian's draft doesn't touch on the "over 18" type threat at all as I read it, so I don't accept the idea that the hypercookie is the right place from which to start to analyse the set of threats in this space. And there is IMO a real difference between our current/old set of protocols allowing bad behaviours vs. us defining a new protocol to explicitly enable those same bad behaviours. (It could be that not all of us agree that that is a real difference.) >=20 > I assume your point is that we propose a protocol that is intended to > signal information from middleboxes to the endpoint (amongst other > features). I assume this based on the following statement you made: >=20 >> Should we standardise a method for such abuse, then I think it's >> quite possible the attacker may argue that their behaviour is not >> an attack as it's just a part of "the standard.=E2=80=9C >=20 > and >=20 >> And to the extent that PLUS could enable and standardise such >> things, that is, for me, a major reason to oppose PLUS. >=20 > Otherwise can you please further explain what you mean by =E2=80=9Esuch= > abuse=E2=80=9C and =E2=80=9Esuch things=E2=80=9C? Sorry I don't get the question. (That is, I'm not clear if I do or do not agree with your assumptions, which are not clear to me;-) >=20 > If the thing you are concerned about in PLUS is, that we propose to > standardize =E2=80=9Aoption=E2=80=98 space that explicitly allows middl= eboxes to add > information to a packet, I guess you know that it is possible to > define an experimental TCP option (in the ISE stream) without IESG > approval that allows the insertion of private information by > middleboxes. Even thought TCP options are not intended to be altered > by network nodes, there is also no standard that forbids this. I am not arguing for a "MINUS" (a TBD acronym that'd be the antithesis of PLUS:-). >=20 > Let me say two things about what we ACTUALLY propose with PLUS: 1) We > do NOT propose to add space to add arbitrary information. The > semantic of the field must be well-defined in an IESG approved RFC > and registered respectively.=20 IMO that is not sufficient to allay my concern about "over 18" and the like. If we build it (the registry) then they will come (and ask for or squat on code points with horrible semantics). I can't see any way to avoid that other than never creating such a registry. > This will not only make it not-standard > conform to use such a field for something different, it also restrict > the set of valid values which then could even be checked by later > middleboxes on the path, and erased if needed.=20 Sure. But I remain convinced that any registry here is too dangerous and the above doesn't convince me otherwise. > 2) Further only PLUS > provides an additional function that allows to detect any mangling of > data/bits that was not intended. This is urgently needed because all > the TCP (and higher) layer mangling we see today is the root cause > for the problem we have right now. I don't get your point (2) sorry. Can you explain more? >=20 > Further, I would like to say that not all middlebox mangling is > automatically bad or an attack.=20 Of course. And I did not say that. I said that there are some bad behaviours in this space and we need to worry about us maybe legitimising those. > If we don=E2=80=99t provide a standardized > way to communicate with middleboxes, it will be even harder to > distinguish an attack from something that actually supports the > network service provided or even makes the services possible at all. > Without standardization there is no control at all. I don=E2=80=99t thi= nk we > can ignore what=E2=80=99s already happening the Internet any further an= d > providing standardized mechanisms to support the good in-network > functions is the only way to improve security for these functions. The above text seems indicative of understandable exasperation but I don't see how it's very useful for the discussion. >=20 > To make this even more clear, you wrote: >> the argument seems to ignore the downsides of standardising and >> thus legitimising "bad" behaviour including behaviours that your >> draft properly calls an attack. >=20 > We not at all want to legitimate =E2=80=9Ebad=E2=80=9C behavior and I r= eally don=E2=80=99t > know why you think that what we propose would do so. Sigh. I didn't personalise this (I hope! Apologies if I did by mistake) so I wasn't at all discussing what you or anyone wants or doesn't want. It is entirely possible to have good motivation for something that may have quite bad side-effects. And I still think that the arguments made by proponents of PLUS are ignoring the downsides. (And I do not mean that the people making those arguments are ignoring those downsides which would be a different statement.) > We propose to > standardize a protocol that allows middleboxes to provide information > they have been requested for (by the endhost). This information is > well define and under IESG approval. Any other use of such a protocol > will not be standard-conform and as bad as the misuse we can see > today with existing protocols. I think that just repeats earlier statements. S. >=20 > Mirja >=20 >=20 >=20 >> Am 29.07.2016 um 15:23 schrieb Stephen Farrell >> : >>=20 >>=20 >> Hi Brian, >>=20 >> On 29/07/16 13:33, Brian Trammell wrote: >>> Greetings, all, >>>=20 >>> During the PLUS BoF last week, concern was expressed that a >>> generic signaling mechanism such as proposed opened two new >>> attack surfaces: >>=20 >> No necessarily "opened...new" perhaps more "risked making much more >> ubiquitous." At the meeting I didn't hear anyone claim these were >> new attacks. (I did hear you say they were not new.) >>=20 >>>=20 >>> (1) A method for endpoints to allow path elements to add=20 >>> non-integrity protected signals presents a surface for metadata=20 >>> injection attacks, where an entity who can place devices on a >>> user's access network and has information about the user's >>> identity could exfiltrate that information to third parties. For >>> purposes of giving it a name, let's call this a hypercookie >>> injection attack ("hyper" since it exists in a space completely >>> inaccessible to the application). >>>=20 >>> (2) Even if path elements are not allowed to say anything, a=20 >>> mechanism to allow endpoints to add integrity-protected signals >>> to their traffic presents a surface for coercion attacks. An >>> access provider can force a user to tag traffic with their user >>> ID or some other token (a signed assertion that an advertisement >>> has been viewed to the end, or maybe even just straight-up >>> bitcoins) in order to get "better" connectivity, or even any >>> connectivity at all. A more classically Orwellian dystopian >>> variant of this attack has a government requiring citizens to tag >>> all their outgoing traffic with some government-issued >>> identifier. Let's call this a hypercookie coercion attack. >>>=20 >>> I am less concerned about the surface PLUS presents to these >>> attacks than those who have raised the concerns in the BoF and on >>> the mailing list, because the current Internet architecture is >>> already quite vulnerable to them. As I said during my >>> presentation last Thursday, Ted Hardie and I sat down to think >>> about this at lunch a couple of months ago, and found six ways >>> one could execute hypercookie injection or coercion today before >>> our pizza showed up. >>=20 >> Wrt injection I can buy that totally. Having read your draft I >> don't find enough there to accept your assertion wrt coercion - >> ISTM that coercion attacks have not been analysed yet in your >> draft. >>=20 >> As a side-note, meta-data doesn't have to be person-specific to be >> controversial - "over 18" and anything with similar semantics, e.g. >> "member of minority" can very clearly be equally or more >> damaging, yet totally non-identifying if the relevant set of folks >> is large enough. So I wonder if the "hypercookie" concept is even >> the right starting point here. And to the extent that PLUS could >> enable and standardise such things, that is, for me, a major reason >> to oppose PLUS. (That's a side-note for this email, but perhaps a >> quite fundamental thing to consider in the overall discussion.) >>=20 >>>=20 >>> I sat down a little longer to write these up. I found five more,=20 >>> without even considering trivial out-of-band metadata leaks or=20 >>> steganographic side channels.=20 >>> https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-me= ta-00 >>> >>>=20 is the result. The conclusion: these attacks are trivially easy to >>> execute today by exploiting the gap between valid TCP traffic >>> and what will be ignored by TCP-indifferent devices and >>> endpoints, as well as all those juicy bits IPv6 gives you. Unless >>> we're willing to rely on the widespread, altruistic deployment of >>> stateful TCP firewalls to reject traffic (I think we can use our >>> experience with BCP38 as guidance as to how well *that* will >>> work, and in any case I think it would be kind of rich for me of >>> all people to recommend throwing more TCP-meddling middleboxes >>> into the mix) the only way I can see out is to add integrity >>> protection to all transport and network-layer headers, as well as >>> confidentiality protection to those headers the path does not >>> need to see. >>=20 >> I don't agree. Observatories seem to me like a mitigation that your >> draft does not consider. If the attacker here does not want to be >> seen to be attacking, then those can be effective. Should we >> standardise a method for such abuse, then I think it's quite=20 >> possible the attacker may argue that their behaviour is not an=20 >> attack as it's just a part of "the standard." >>=20 >> Such a mitigation could be attempted against the attack in 4.1.3 of >> your draft for example so I disagree with the draft's assertion=20 >> that "no user-initiated mitigation is possible" in that case at=20 >> least and maybe others. >>=20 >> I think it'd be a fine thing to see further analysis of the >> attacks and potential mitigations as your draft develops. >>=20 >>>=20 >>> This is, of course, the whole point of PLUS. We can and should >>> have a discussion of what the endpoints should be able to say, >>> and what the endpoints should be able to let the path say. But if >>> we're concerned about this attack, the general approach is AFAICT >>> the only way out. >>=20 >> I disagree. And I think it was clear that a whole bunch of folks in >> the room last week also clearly disagreed. >>=20 >> I believe your "only way out" conclusion isn't logically justified >> as the argument seems to ignore the downsides of standardising and >> thus legitimising "bad" behaviour including behaviours that your >> draft properly calls an attack. >>=20 >> Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that we have=20 >> different sets of sensible folks reaching diametrically opposed=20 >> conclusions based on the same facts and arguments. Perhaps the >> tl;dr in your abstract may be a hint there - I do not think >> everything is ruined myself, so maybe one's level of opt/pess-imism >> affects one's view of the valid conclusions to reach in this >> space. >>=20 >> Cheers, S. >>=20 >>>=20 >>> Cheers, >>>=20 >>> Brian >>>=20 >>>=20 >>>=20 >>> _______________________________________________ Privsec-program=20 >>> mailing list Privsec-program@iab.org=20 >>> https://www.iab.org/mailman/listinfo/privsec-program >>>=20 >>=20 >> _______________________________________________ Spud mailing list=20 >> Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud >=20 --------------ms010304020004040003050103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3Mjkx NTE3MTlaMC8GCSqGSIb3DQEJBDEiBCC+0EFlzQukj9ta8nHODx3bAjB5t3OKAOQyPRZQ6O6n QzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQArOEShDCbXtqoTRLuNQF5/8VuCxCMguZSrdtU4ixrg1JnQ0ILkpVK7 ehAtTKDoY6X3gXnodMimAwgo5qFbu09m3gh1tWI9aHnQtDEFKoBW0Jjhzh45urRTb7zX/Ncx OZSoApfFVJpkcg22i5L3MGT8DE7fVOoVM0k/iCMzRzuflk/SsdFShwp1bHH3W8EGIAA2So7F lBdpDU2UxukgpMafeCDR+vxqdmlJKwFfL5hW8c/Rq5BBHv/+SVtsdBvAqljgaYCOL4yW42rV 1LI1hbJjtGTNKpTzoXLOu369RWj0aSBMOlJtnP8caeNt6tg/mlolUcIAWNn3d8k48Q0pqfYj AAAAAAAA --------------ms010304020004040003050103-- From nobody Fri Jul 29 08:49:53 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8526C12D669 for ; Fri, 29 Jul 2016 08:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 a8LHxdqOOtB4 for ; Fri, 29 Jul 2016 08:49:47 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 6939112D18F for ; Fri, 29 Jul 2016 08:49:47 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id q83so132796816iod.1 for ; Fri, 29 Jul 2016 08:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cLvx+iGBmTjF68FpIX64QLb0PoZjYRbJbY12MMXlpHg=; b=19CkmSejKhjnjn8/1OZcJauTMuSLkrlgexK5+GCUNQKddKadtad82igPoVDRlcPWy7 VYIobgyVqma1v4+SeL4bSTLpGHXugZdSlIjTUgRCyhROsiGekAi9Ru8AQt4rerV2tRlU gg/RjHnjyoMPgYCxo3kaDZjxAqTS4Tn9qnygzyEDp8gLvvj+1bpgLfG+iGBFhC27oiEp KJRW0ci2cdx/q0g7yUJ5+wl0IvBTi/jbuzrThoJQxuv8ToR6ywTDOxxFm1iQOL20oWsj KrjU3M7rMrvMeZtPkRLalSLrIFq1wnnCq1HHbzG4CFi9Vl6oZrU9wsxaQ5SRoauPNryX 3Jyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cLvx+iGBmTjF68FpIX64QLb0PoZjYRbJbY12MMXlpHg=; b=SdMcMT/reMIr/dMSlGw4H2SJRpNDmm46Vt6IozlCe1I3sEgpHPI3FjJYAEbSSoXyxS ksE4ruTedLQE3MIZTqL0AfuWgYWv93Rm6O/F3koPKOXzBNXF45H2K/B8+LpQHWyoypPW nIRjkucPPsK0IMgB7FHBM/egUpcdACFfZG49IZwrA5NC8yj8/bwQqvf9dSuGnKV34Gno p2Q7y7YZMTzncnVDnnwTohzpAS8prD84JLHwFp4XQrhyvGwNiVaAWlD53nO89LE58i9U 91qd9EmWM5gs78K57cdsltmiC9hsskoMMHItYfE9hf2LzHyBdGAGyXdaAX0CBnCcNV7z KH4A== X-Gm-Message-State: AEkoouuI0OESyWNe9yRn955FtulW2yRuvEhRVDQDS1BQnvaom+gk42X4KAmkQs18VNcurO8JDR3JU4j0yQYBcg== X-Received: by 10.107.11.74 with SMTP id v71mr50792582ioi.107.1469807386683; Fri, 29 Jul 2016 08:49:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Fri, 29 Jul 2016 08:49:46 -0700 (PDT) In-Reply-To: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> From: Tom Herbert Date: Fri, 29 Jul 2016 08:49:46 -0700 Message-ID: To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: privsec-program@iab.org, spud Subject: Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 15:49:49 -0000 On Fri, Jul 29, 2016 at 5:33 AM, Brian Trammell wrote: > Greetings, all, > > During the PLUS BoF last week, concern was expressed that a generic signa= ling mechanism such as proposed opened two new attack surfaces: > > (1) A method for endpoints to allow path elements to add non-integrity pr= otected signals presents a surface for metadata injection attacks, where an= entity who can place devices on a user's access network and has informatio= n about the user's identity could exfiltrate that information to third part= ies. For purposes of giving it a name, let's call this a hypercookie inject= ion attack ("hyper" since it exists in a space completely inaccessible to t= he application). > > (2) Even if path elements are not allowed to say anything, a mechanism to= allow endpoints to add integrity-protected signals to their traffic presen= ts a surface for coercion attacks. An access provider can force a user to t= ag traffic with their user ID or some other token (a signed assertion that = an advertisement has been viewed to the end, or maybe even just straight-up= bitcoins) in order to get "better" connectivity, or even any connectivity = at all. A more classically Orwellian dystopian variant of this attack has a= government requiring citizens to tag all their outgoing traffic with some = government-issued identifier. Let's call this a hypercookie coercion attack= . > > I am less concerned about the surface PLUS presents to these attacks than= those who have raised the concerns in the BoF and on the mailing list, bec= ause the current Internet architecture is already quite vulnerable to them.= As I said during my presentation last Thursday, Ted Hardie and I sat down = to think about this at lunch a couple of months ago, and found six ways one= could execute hypercookie injection or coercion today before our pizza sho= wed up. > Brian, I think there is a significant practical difference between the vulnerability of hypercookie injection in TCP/IP and what would be present in PLUS. In order to enforce a hypercookie injection in TCP one would need to change the TCP stack which typically necessitates a kernel change. In the PLUS world one would only need changes in the particular applications of interest, this is is a much easier task for the attacker. Now instead of having to deal with large OS vendors that vigorously defend privacy (e.g. Apple vs. FBI), authorities can go after much smaller players forcing them to either comply or cease operations. Putting control of information solely in the users hands is not necessarily a good thing. Tom From nobody Fri Jul 29 08:54:59 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E330C12B05C for ; Fri, 29 Jul 2016 08:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 nZOlfaomR-AZ for ; Fri, 29 Jul 2016 08:54:54 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F25E12B042 for ; Fri, 29 Jul 2016 08:54:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C77ADD930B; Fri, 29 Jul 2016 17:54:52 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tvKRzQqIrQXd; Fri, 29 Jul 2016 17:54:52 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2F34.dip0.t-ipconnect.de [93.236.47.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 761E2D9307; Fri, 29 Jul 2016 17:54:52 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> Date: Fri, 29 Jul 2016 17:54:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 15:54:58 -0000 Hi Stephen, I see registries as a needed and valuable part of our standardization = process. People ignoring registries as well as things that are = explicitly specified in a standards document is a different problem.=20 To answer your question below: >>=20 >> 2) Further only PLUS >> provides an additional function that allows to detect any mangling of >> data/bits that was not intended. This is urgently needed because all >> the TCP (and higher) layer mangling we see today is the root cause >> for the problem we have right now. >=20 > I don't get your point (2) sorry. Can you explain more? We explained this in the BoF and I believe I made this point very clear = in my last mail that I replied to Kyle. But let me state this bit again, = because it=E2=80=99s important. Today, there are a large amount of bits a middlebox can mangle with (as = described in draft-trammell-privsec-defeating-tcpip-meta which is not = even exhaustive). Most of the described ways to insert information into = a packet are not detectable, at least most of the ways described for TCP = because all information is in cleartext and the receiver does not know = what the sender has originally sent while the mangled information still = allows proper operation. What we propose is to a) encrypt all bits in the transport/TCP header, b) provide less bits in a PLUS header, that have been carefully = evaluated towards risks that we know today (but didn=E2=80=99t know when = we designed TCP), and c) a MAC that hashes all information provided in the PLUS header to be = able to detect mangling by the receiver (which can inform then the = sender using an encrypted channel). This also means that the endpoint = has the choice to not use PLUS (or any PLUS information fields) if = mangling is detected. All these points together, especially point c, makes the situation = compared to what we have today better and not worse! Mirja > Am 29.07.2016 um 17:17 schrieb Stephen Farrell = : >=20 >=20 > Hiya, >=20 > On 29/07/16 15:48, Mirja K=C3=BChlewind wrote: >> Hi Stephen, >>=20 >> I believe that what you think PLUS is, is not what we propose.=20 >=20 > I'm pretty sure that's true - and is part of what puzzles me > as I said before. >=20 >> Maybe >> we did not make a great job so far to define PLUS narrowly enough but >> we believe the actual protocol specification work should be done in a >> wg to ensure that a broad community can participate, and all concern, >> including privacy concerns, can be addressed. >=20 > I get that. Some folks however (and I'm not sure if I'd count myself > amongst them yet or not) fear that any such WG has to end up as very > privacy unfriendly if it remains transport agnostic. =46rom that > perspective, starting a WG would not make sense. >=20 >>=20 >> The point of draft-trammell-privsec-defeating-tcpip-meta is to >> further explain that the things you describe as risks are nothing >> new. And by new, we mean they are even standard-conform; because this >> is the main point of your concern if I understand you correctly, >> right? >=20 > No. Brian's draft doesn't touch on the "over 18" type threat at > all as I read it, so I don't accept the idea that the hypercookie > is the right place from which to start to analyse the set of > threats in this space. >=20 > And there is IMO a real difference between our current/old set > of protocols allowing bad behaviours vs. us defining a new > protocol to explicitly enable those same bad behaviours. (It could > be that not all of us agree that that is a real difference.) >=20 >>=20 >> I assume your point is that we propose a protocol that is intended to >> signal information from middleboxes to the endpoint (amongst other >> features). I assume this based on the following statement you made: >>=20 >>> Should we standardise a method for such abuse, then I think it's >>> quite possible the attacker may argue that their behaviour is not >>> an attack as it's just a part of "the standard.=E2=80=9C >>=20 >> and >>=20 >>> And to the extent that PLUS could enable and standardise such >>> things, that is, for me, a major reason to oppose PLUS. >>=20 >> Otherwise can you please further explain what you mean by =E2=80=9Esuch= >> abuse=E2=80=9C and =E2=80=9Esuch things=E2=80=9C? >=20 > Sorry I don't get the question. (That is, I'm not clear if I do > or do not agree with your assumptions, which are not clear to me;-) >=20 >>=20 >> If the thing you are concerned about in PLUS is, that we propose to >> standardize =E2=80=9Aoption=E2=80=98 space that explicitly allows = middleboxes to add >> information to a packet, I guess you know that it is possible to >> define an experimental TCP option (in the ISE stream) without IESG >> approval that allows the insertion of private information by >> middleboxes. Even thought TCP options are not intended to be altered >> by network nodes, there is also no standard that forbids this. >=20 > I am not arguing for a "MINUS" (a TBD acronym that'd be the antithesis > of PLUS:-). >=20 >>=20 >> Let me say two things about what we ACTUALLY propose with PLUS: 1) We >> do NOT propose to add space to add arbitrary information. The >> semantic of the field must be well-defined in an IESG approved RFC >> and registered respectively.=20 >=20 > IMO that is not sufficient to allay my concern about "over 18" and > the like. If we build it (the registry) then they will come (and ask > for or squat on code points with horrible semantics). I can't see > any way to avoid that other than never creating such a registry. >=20 >> This will not only make it not-standard >> conform to use such a field for something different, it also restrict >> the set of valid values which then could even be checked by later >> middleboxes on the path, and erased if needed.=20 >=20 > Sure. But I remain convinced that any registry here is too dangerous > and the above doesn't convince me otherwise. >=20 >> 2) Further only PLUS >> provides an additional function that allows to detect any mangling of >> data/bits that was not intended. This is urgently needed because all >> the TCP (and higher) layer mangling we see today is the root cause >> for the problem we have right now. >=20 > I don't get your point (2) sorry. Can you explain more? >=20 >>=20 >> Further, I would like to say that not all middlebox mangling is >> automatically bad or an attack.=20 >=20 > Of course. And I did not say that. I said that there are some > bad behaviours in this space and we need to worry about us maybe > legitimising those. >=20 >> If we don=E2=80=99t provide a standardized >> way to communicate with middleboxes, it will be even harder to >> distinguish an attack from something that actually supports the >> network service provided or even makes the services possible at all. >> Without standardization there is no control at all. I don=E2=80=99t = think we >> can ignore what=E2=80=99s already happening the Internet any further = and >> providing standardized mechanisms to support the good in-network >> functions is the only way to improve security for these functions. >=20 > The above text seems indicative of understandable exasperation but > I don't see how it's very useful for the discussion. >=20 >>=20 >> To make this even more clear, you wrote: >>> the argument seems to ignore the downsides of standardising and >>> thus legitimising "bad" behaviour including behaviours that your >>> draft properly calls an attack. >>=20 >> We not at all want to legitimate =E2=80=9Ebad=E2=80=9C behavior and I = really don=E2=80=99t >> know why you think that what we propose would do so. >=20 > Sigh. I didn't personalise this (I hope! Apologies if I did by > mistake) so I wasn't at all discussing what you or anyone wants or > doesn't want. It is entirely possible to have good motivation for > something that may have quite bad side-effects. >=20 > And I still think that the arguments made by proponents of PLUS > are ignoring the downsides. (And I do not mean that the people > making those arguments are ignoring those downsides which would > be a different statement.) >=20 >> We propose to >> standardize a protocol that allows middleboxes to provide information >> they have been requested for (by the endhost). This information is >> well define and under IESG approval. Any other use of such a protocol >> will not be standard-conform and as bad as the misuse we can see >> today with existing protocols. >=20 > I think that just repeats earlier statements. >=20 > S. >=20 >>=20 >> Mirja >>=20 >>=20 >>=20 >>> Am 29.07.2016 um 15:23 schrieb Stephen Farrell >>> : >>>=20 >>>=20 >>> Hi Brian, >>>=20 >>> On 29/07/16 13:33, Brian Trammell wrote: >>>> Greetings, all, >>>>=20 >>>> During the PLUS BoF last week, concern was expressed that a >>>> generic signaling mechanism such as proposed opened two new >>>> attack surfaces: >>>=20 >>> No necessarily "opened...new" perhaps more "risked making much more >>> ubiquitous." At the meeting I didn't hear anyone claim these were >>> new attacks. (I did hear you say they were not new.) >>>=20 >>>>=20 >>>> (1) A method for endpoints to allow path elements to add=20 >>>> non-integrity protected signals presents a surface for metadata=20 >>>> injection attacks, where an entity who can place devices on a >>>> user's access network and has information about the user's >>>> identity could exfiltrate that information to third parties. For >>>> purposes of giving it a name, let's call this a hypercookie >>>> injection attack ("hyper" since it exists in a space completely >>>> inaccessible to the application). >>>>=20 >>>> (2) Even if path elements are not allowed to say anything, a=20 >>>> mechanism to allow endpoints to add integrity-protected signals >>>> to their traffic presents a surface for coercion attacks. An >>>> access provider can force a user to tag traffic with their user >>>> ID or some other token (a signed assertion that an advertisement >>>> has been viewed to the end, or maybe even just straight-up >>>> bitcoins) in order to get "better" connectivity, or even any >>>> connectivity at all. A more classically Orwellian dystopian >>>> variant of this attack has a government requiring citizens to tag >>>> all their outgoing traffic with some government-issued >>>> identifier. Let's call this a hypercookie coercion attack. >>>>=20 >>>> I am less concerned about the surface PLUS presents to these >>>> attacks than those who have raised the concerns in the BoF and on >>>> the mailing list, because the current Internet architecture is >>>> already quite vulnerable to them. As I said during my >>>> presentation last Thursday, Ted Hardie and I sat down to think >>>> about this at lunch a couple of months ago, and found six ways >>>> one could execute hypercookie injection or coercion today before >>>> our pizza showed up. >>>=20 >>> Wrt injection I can buy that totally. Having read your draft I >>> don't find enough there to accept your assertion wrt coercion - >>> ISTM that coercion attacks have not been analysed yet in your >>> draft. >>>=20 >>> As a side-note, meta-data doesn't have to be person-specific to be >>> controversial - "over 18" and anything with similar semantics, e.g. >>> "member of minority" can very clearly be equally or more >>> damaging, yet totally non-identifying if the relevant set of folks >>> is large enough. So I wonder if the "hypercookie" concept is even >>> the right starting point here. And to the extent that PLUS could >>> enable and standardise such things, that is, for me, a major reason >>> to oppose PLUS. (That's a side-note for this email, but perhaps a >>> quite fundamental thing to consider in the overall discussion.) >>>=20 >>>>=20 >>>> I sat down a little longer to write these up. I found five more,=20 >>>> without even considering trivial out-of-band metadata leaks or=20 >>>> steganographic side channels.=20 >>>> = https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta-00= >>>>=20 >>>>=20 > is the result. The conclusion: these attacks are trivially easy to >>>> execute today by exploiting the gap between valid TCP traffic >>>> and what will be ignored by TCP-indifferent devices and >>>> endpoints, as well as all those juicy bits IPv6 gives you. Unless >>>> we're willing to rely on the widespread, altruistic deployment of >>>> stateful TCP firewalls to reject traffic (I think we can use our >>>> experience with BCP38 as guidance as to how well *that* will >>>> work, and in any case I think it would be kind of rich for me of >>>> all people to recommend throwing more TCP-meddling middleboxes >>>> into the mix) the only way I can see out is to add integrity >>>> protection to all transport and network-layer headers, as well as >>>> confidentiality protection to those headers the path does not >>>> need to see. >>>=20 >>> I don't agree. Observatories seem to me like a mitigation that your >>> draft does not consider. If the attacker here does not want to be >>> seen to be attacking, then those can be effective. Should we >>> standardise a method for such abuse, then I think it's quite=20 >>> possible the attacker may argue that their behaviour is not an=20 >>> attack as it's just a part of "the standard." >>>=20 >>> Such a mitigation could be attempted against the attack in 4.1.3 of >>> your draft for example so I disagree with the draft's assertion=20 >>> that "no user-initiated mitigation is possible" in that case at=20 >>> least and maybe others. >>>=20 >>> I think it'd be a fine thing to see further analysis of the >>> attacks and potential mitigations as your draft develops. >>>=20 >>>>=20 >>>> This is, of course, the whole point of PLUS. We can and should >>>> have a discussion of what the endpoints should be able to say, >>>> and what the endpoints should be able to let the path say. But if >>>> we're concerned about this attack, the general approach is AFAICT >>>> the only way out. >>>=20 >>> I disagree. And I think it was clear that a whole bunch of folks in >>> the room last week also clearly disagreed. >>>=20 >>> I believe your "only way out" conclusion isn't logically justified >>> as the argument seems to ignore the downsides of standardising and >>> thus legitimising "bad" behaviour including behaviours that your >>> draft properly calls an attack. >>>=20 >>> Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that we have=20 >>> different sets of sensible folks reaching diametrically opposed=20 >>> conclusions based on the same facts and arguments. Perhaps the >>> tl;dr in your abstract may be a hint there - I do not think >>> everything is ruined myself, so maybe one's level of opt/pess-imism >>> affects one's view of the valid conclusions to reach in this >>> space. >>>=20 >>> Cheers, S. >>>=20 >>>>=20 >>>> Cheers, >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ Privsec-program=20 >>>> mailing list Privsec-program@iab.org=20 >>>> https://www.iab.org/mailman/listinfo/privsec-program >>>>=20 >>>=20 >>> _______________________________________________ Spud mailing list=20 >>> Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud >>=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Fri Jul 29 08:58:29 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0486A12B068 for ; Fri, 29 Jul 2016 08:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 DeyM_dB-S6Ae for ; Fri, 29 Jul 2016 08:58:25 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 7661512B042 for ; Fri, 29 Jul 2016 08:58:24 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id f6so111839454ith.0 for ; Fri, 29 Jul 2016 08:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l6CZwz1NyGW1wu7Rd3ejz0+XHioTC++Fd+ZtwHPxRmY=; b=ioSTMAJPqbumcaUaSEf4za32yHPvOXuDqZGUjNx+T2MOHtTKHv1FaCI5LZkmbjqVgs RB0bvGiAtBtov7ghtQ0AsX/7BQggYsKbtR+xfv1l5Kjii3cCnFESvuObcDC2f6Megx1a N7aUPnHfuitfNxqsVCpXH892TL71IDRa9MUzlHLpmafOPkCFm0k2tthGjQxxedtqdvnP zqGgF90GP2xxn9Kr2/muXHig5ssHs4xrdCIcgSVQRXxpq1Q9saHrsh03eH9+a0Sc6RPj zRMMEAh0AWkVt4/UdJuUBmSRnr51ll6V19TZYyOPa76Zn7UigNbX33TZaHdYtnKOE8vy x4QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l6CZwz1NyGW1wu7Rd3ejz0+XHioTC++Fd+ZtwHPxRmY=; b=C0lB3rM2UUnzGxVQK6azbLXZiqErVy246OV0WxhJ32Svk5coVIV/EK2Me18PlRFBNl 6Q/2Z6av0GuxZ2VUpE8P/ED1smxxXd16elf85LVAJYlzHKorRPgpqg+mhak7VshOh5dx 9TA0VIDatoOTCj1Y/M6zSP+Jqb+Vcpu4jcBd6aePi0lzP6K/HO8BbjeWY2TWfAFUfZt6 cS2JVKBmytpQUW6dLheexsJfO2QEPA4S4Fsj/mnsYNQoHGlKm+BHE/SjjDO//q0kyacI ySKu2rzcp8nLQlOYD+NIAG8OAQZ6K93P24pwCnt8vKbTB9jf1q0eWFdD8IDYO2f7BiO+ /o+g== X-Gm-Message-State: AEkoousdTxyw0lFnojlM1aUJaVzhBT0dE10hLVvveVYAqHdyzybS1F+JOwm1a5WlTt1kLsg/hi9yS8RPBZ6VXw== X-Received: by 10.36.14.193 with SMTP id 184mr47436358ite.91.1469807903729; Fri, 29 Jul 2016 08:58:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Fri, 29 Jul 2016 08:58:23 -0700 (PDT) In-Reply-To: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> References: <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> From: Tom Herbert Date: Fri, 29 Jul 2016 08:58:23 -0700 Message-ID: To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Erik Nygren , Kyle Rose , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Dave Dolson , spud Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 15:58:26 -0000 On Fri, Jul 29, 2016 at 5:18 AM, Eliot Lear wrote: > Hi Tom, > > Something that did not get brought up at the BOF is nagging at me... > > > On 7/28/16 8:17 PM, Tom Herbert wrote: >> The abstraction is only useful up to the point that networks preserve >> the model. If the network breaks the model in ad hoc ways that forces >> the application to try to compensate with more ad hoc mechanisms or >> just stop innovating altogether as we see happened with protocol >> ossification. > > You write that as if it's a bad thing ;-) > > Some amount of protocol ossification is a GOOD thing. In particular, > the calling interface for transports needs to be stable or source code > will have no shelf life. The fact that TCP's calling interface has been > SO stable for SO long has meant that a large code base did not require > substantial maintenance just to keep doing the same thing it was > doing. I see this as an exercise to determine what needs ossification > and what does not, and there are extreme positions at both ends. > Note that I specifically referred to 'protocol' ossification not 'interface' ossification. In fact, the TCP sockets interface is constantly being extended. For instance, in order to make TCP Fast Open (TFO) work we needed to change the semantics of 'connect' call and allow sendmsg on an unconnected socket. Tom > Eliot > > From nobody Fri Jul 29 09:23:02 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2307412D7F1 for ; Fri, 29 Jul 2016 09:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 C6LAcRzHsSqB for ; Fri, 29 Jul 2016 09:22:58 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id F0F3C12D7D9 for ; Fri, 29 Jul 2016 09:22:57 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 5C22C1A0C60; Fri, 29 Jul 2016 18:22:56 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6E0BF960-CC03-4C87-AB51-E5780A116250"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Fri, 29 Jul 2016 18:22:55 +0200 Message-Id: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 16:23:00 -0000 --Apple-Mail=_6E0BF960-CC03-4C87-AB51-E5780A116250 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Stephen, > Hi Brian, >=20 > On 29/07/16 13:33, Brian Trammell wrote: >> Greetings, all, >>=20 >> During the PLUS BoF last week, concern was expressed that a generic >> signaling mechanism such as proposed opened two new attack surfaces: >=20 > No necessarily "opened...new" perhaps more "risked making much > more ubiquitous." At the meeting I didn't hear anyone claim these > were new attacks. (I did hear you say they were not new.) Point; shall we say "may widen two existing"? (Of course, I disagree = that PLUS does widen this surface, otherwise I could not in good = conscience work on it. I am afraid we simply have to agree to disagree = here, though.) >> (1) A method for endpoints to allow path elements to add >> non-integrity protected signals presents a surface for metadata >> injection attacks, where an entity who can place devices on a user's >> access network and has information about the user's identity could >> exfiltrate that information to third parties. For purposes of giving >> it a name, let's call this a hypercookie injection attack ("hyper" >> since it exists in a space completely inaccessible to the >> application). >>=20 >> (2) Even if path elements are not allowed to say anything, a >> mechanism to allow endpoints to add integrity-protected signals to >> their traffic presents a surface for coercion attacks. An access >> provider can force a user to tag traffic with their user ID or some >> other token (a signed assertion that an advertisement has been viewed >> to the end, or maybe even just straight-up bitcoins) in order to get >> "better" connectivity, or even any connectivity at all. A more >> classically Orwellian dystopian variant of this attack has a >> government requiring citizens to tag all their outgoing traffic with >> some government-issued identifier. Let's call this a hypercookie >> coercion attack. >>=20 >> I am less concerned about the surface PLUS presents to these attacks >> than those who have raised the concerns in the BoF and on the mailing >> list, because the current Internet architecture is already quite >> vulnerable to them. As I said during my presentation last Thursday, >> Ted Hardie and I sat down to think about this at lunch a couple of >> months ago, and found six ways one could execute hypercookie >> injection or coercion today before our pizza showed up. >=20 > Wrt injection I can buy that totally. Having read your draft > I don't find enough there to accept your assertion wrt > coercion - ISTM that coercion attacks have not been analysed > yet in your draft. Agreed that the analysis isn't where I'd like it to be yet. There are = two major reasons for this. One, this draft is focused on in-band abuse = of TCP and IP features (which seemed a good place to start) and it's not = clear to me that the real threat of coercion lies at this layer at all: = coercion attacks seem a lot easier to implement with out of band = techniques at the application layer. Second, with respect to the threat = at this layer, it seems that coercion attackers would want to be less = detectable, which expands the space of abuse to include low-frequency = temporal domain side channels and other quasi-in-band sorts of things. Coercion is at its heart a layer 9 attack, though, and a good analysis = of it that takes this into account would make the draft much better. = Happy to accept text on this. Need to get the source into a public = GitHub repo to send PRs against, first. > As a side-note, meta-data doesn't have to be person-specific to > be controversial - "over 18" and anything with similar semantics, > e.g. "member of minority" can very clearly be equally or > more damaging, yet totally non-identifying if the relevant set of > folks is large enough. Of course; this is an orthogonal question, though. Here we're = considering how many bits you can inject or leak. How many bits you need = is a question of how large the space of signals is. If what you're = concerned about is linkage on a very small number of bits, though, then = everything is even more ruined than we think. >> ... the only way I >> can see out is to add integrity protection to all transport and >> network-layer headers, as well as confidentiality protection to those >> headers the path does not need to see. >=20 > I don't agree. Observatories seem to me like a mitigation that > your draft does not consider. Good point. We should add large-scale Internet observatories to the list = of general mitigation approaches (Yay! more measurement to do!). This = scales a bit better than firewalls everywhere, but still requires you to = throw a lot of power and cooling at the problem if you're going to get = enough scale to make the attacks too dangerous to execute. > If the attacker here does not want > to be seen to be attacking, then those can be effective. Should > we standardise a method for such abuse, ... noting that one of the points of this draft is to make it clear that = we *have already standardized* at least eleven methods for such abuse = with the publication of RFCs 791, 3315, 4291, 6437, 6864, and 6994, = among others. These standards don't condone the abuse they enable, but = by having MUST NOT send / MUST ignore language, which remains good = engineering practice for interoperability, they *do* enable it, and in = terms of how much evil the abuse can result in, I don't see that there's = really any practical difference between the condoning and enabling. Methods for encrypting transport headers, whether specific to a single = transport protocol (QUIC) or generic (PLUS), would, however, make = injection impossible, not just somewhat-mitigatable. > then I think it's quite > possible the attacker may argue that their behaviour is not an > attack as it's just a part of "the standard." >=20 > Such a mitigation could be attempted against the attack in 4.1.3 > of your draft for example so I disagree with the draft's assertion > that "no user-initiated mitigation is possible" in that case at > least and maybe others. Whether an observatory counts as "user-initiated mitigation" or not is a = semantic quibble. Fine. > I think it'd be a fine thing to see further analysis of the attacks > and potential mitigations as your draft develops. An open invitation to all: text appreciated. :) One thing I do want to = do is some measurement to see on how many paths these work as = advertised. >> This is, of course, the whole point of PLUS. We can and should have a >> discussion of what the endpoints should be able to say, and what the >> endpoints should be able to let the path say. But if we're concerned >> about this attack, the general approach is AFAICT the only way out. >=20 > I disagree. Again, agreeing to disagree. But I think we also have a specific misunderstanding here: the point I = wanted make *here* was not "you need PLUS". (I think you do, but that's = a separate question.) The "general approach" I referred to (sorry for = not being more precise) is: "you *at the very least* need cryptographic = integrity protection of transport headers, with confidentiality = protection for things the path doesn't need to see". We can have honest disagreements about what the path needs to see and = doesn't, and we should do engineering analysis of the cost-risk-benefit = tradeoffs in order to resolve those disagreements. > Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that we have > different sets of sensible folks reaching diametrically opposed > conclusions based on the same facts and arguments. Perhaps the tl;dr > in your abstract may be a hint there - I do not think everything > is ruined myself, so maybe one's level of opt/pess-imism affects > one's view of the valid conclusions to reach in this space. I suspect I've spent a bit too much time staring at how TCP breaks over = my career, which is the source of my pessimism, on this particular = topic, at least. One purpose of the draft in its present state is that I realized during = the PLUS BoF that others may be making overly optimistic assumptions = about what the transport layer does and does not do as defined, and to = make sure that everyone who cares to read the draft has a shared = understanding of how TCP breaks, so they can make their own conclusions = about their own pessimism. I do hope that it can evolve into a = generalized guide to breaking brokenness for this particular set of = attacks, though. Thanks, cheers, Brian --Apple-Mail=_6E0BF960-CC03-4C87-AB51-E5780A116250 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXm4LgAAoJEIoSt78L6kaj/mgP/RXfd1jbS0v+JYGEf86xxRaE +g3j+xwS/b1ZBrbS3E9svnDRYU46nyghW920HD6tA3PEU2HS5HhVRa0/KDPA2Qo2 w7RQzhzPFui5qVOOp90R8k3D9kMNJd2StMzSDS+MVvi66tn9nYBYRjlAa3THpbi5 BP3lG+L/fUFPb21BMT0rIgWAGY6wD/UZ7uGyhr9xCKlLAiFQGP403hsF7gE1YTsW P8tV8A/wQw7gJQFWzfkhwsWxKbZZdHJyEHoPk4ko01X8JHZ+Y5NphNvNMowiincI naXLhYZIr+4rDUFYZtXo6DXoqvN3oQyYITxnlug7+N89gKntCa2qn2FHy1Je7QgU Q13h2gVdJOaLsNNgwzWJQxFRPPLNE83l3aJMttGdGmCRKpRKMm8m8yuIYM6I24Pl 3YuuLFdHiBOJfgHq9zqi6X/sgkDAB37ZqrpzfFHI5aXGTkLHEF+oA0SDaUOyCgNu 3XkXE5T1+vajGztBDzMXROqX9b6cT1MOEC5mjvEsw8b2Tu+xXcB2ROTAeOl53+Y3 XGkAsSDUpbpg1ORoH6wj+Gu/beOQlNJ8AzeQ4WCsoBPpgspHvLRID1nzcs31xdCV BZ3ALs8mmhRw+YBdvz2JnOB2mKFuJmUWTQK7yM7KEEfroFynPjQl7WTBGCT4ygEW vsIHDz+RI8dZBVj4LCjv =Ygq3 -----END PGP SIGNATURE----- --Apple-Mail=_6E0BF960-CC03-4C87-AB51-E5780A116250-- From nobody Fri Jul 29 09:29:36 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADAE12D80B for ; Fri, 29 Jul 2016 09:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VUbkG8DlXh-9 for ; Fri, 29 Jul 2016 09:29:33 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5FF12B00B for ; Fri, 29 Jul 2016 09:29:33 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 034071A0C60; Fri, 29 Jul 2016 18:29:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9C22C695-778A-433A-A961-A7266521ACBA"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Fri, 29 Jul 2016 18:29:32 +0200 Message-Id: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: privsec-program@iab.org, spud Subject: Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 16:29:36 -0000 --Apple-Mail=_9C22C695-778A-433A-A961-A7266521ACBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Tom, > On 29 Jul 2016, at 17:49, Tom Herbert wrote: >=20 > On Fri, Jul 29, 2016 at 5:33 AM, Brian Trammell = wrote: >> Greetings, all, >>=20 >> During the PLUS BoF last week, concern was expressed that a generic = signaling mechanism such as proposed opened two new attack surfaces: >>=20 >> (1) A method for endpoints to allow path elements to add = non-integrity protected signals presents a surface for metadata = injection attacks, where an entity who can place devices on a user's = access network and has information about the user's identity could = exfiltrate that information to third parties. For purposes of giving it = a name, let's call this a hypercookie injection attack ("hyper" since it = exists in a space completely inaccessible to the application). >>=20 >> (2) Even if path elements are not allowed to say anything, a = mechanism to allow endpoints to add integrity-protected signals to their = traffic presents a surface for coercion attacks. An access provider can = force a user to tag traffic with their user ID or some other token (a = signed assertion that an advertisement has been viewed to the end, or = maybe even just straight-up bitcoins) in order to get "better" = connectivity, or even any connectivity at all. A more classically = Orwellian dystopian variant of this attack has a government requiring = citizens to tag all their outgoing traffic with some government-issued = identifier. Let's call this a hypercookie coercion attack. >>=20 >> I am less concerned about the surface PLUS presents to these attacks = than those who have raised the concerns in the BoF and on the mailing = list, because the current Internet architecture is already quite = vulnerable to them. As I said during my presentation last Thursday, Ted = Hardie and I sat down to think about this at lunch a couple of months = ago, and found six ways one could execute hypercookie injection or = coercion today before our pizza showed up. >>=20 > Brian, >=20 > I think there is a significant practical difference between the > vulnerability of hypercookie injection in TCP/IP and what would be > present in PLUS. In order to enforce a hypercookie injection in TCP > one would need to change the TCP stack which typically necessitates a > kernel change. Nope. I don't need to touch the endpoints at all for an injection = attack. I just need one middlebox near the source to rewrite packets, = and (possibly) another one downstream to pick up the signals. (Okay, I = might need to hack the kernel on my middleboxes. But I get to do that. = They're mine. :) ) Some of these techniques work without kernel changes for coercion = attacks, too ("Use this DHCPv6 server to access the network while in the = territory of Oceania"). Others (ISN side channels) would require kernel = changes. (Exercise for exceptionally paranoid readers: demonstrate that = no shipping closed-source consumer stack uses initial sequence numbers = and legacy IP fragment identifiers as a side channel to expose metadata = to the path.) The whole point of the attacks as outlined is that the side channel is = either undetected by the destination, or that the malformed packets are = passed by the path and dropped by the destination. Cheers, Brian > In the PLUS world one would only need changes in the > particular applications of interest, this is is a much easier task for > the attacker. Now instead of having to deal with large OS vendors > that vigorously defend privacy (e.g. Apple vs. FBI), authorities can > go after much smaller players forcing them to either comply or cease > operations. Putting control of information solely in the users hands > is not necessarily a good thing. >=20 > Tom --Apple-Mail=_9C22C695-778A-433A-A961-A7266521ACBA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXm4RsAAoJEIoSt78L6kaj8i4QAMaH0YB02ddHVwLBD75toehi LfdW8RRrsugjSey2OJZKEiw0fJHUK8tIHEEEejt3FUr46hTwQgGSsrlpZjwmslpj 5JUNqsmV19sDzMfqM6R7Tl1U35T4Gl7QTg5/RsHN9RCbE0E3H5VVKu0cePdzHIB4 r4FhXew5BBBHh7dU3wvYEgpV6369r3KipqRi2mlW7YdrdxepH7AdENPad0hFTek2 28ZG86+FGbQxwUEbHBJQgU0/wL5ZLQqryXM7PglT/8Ld0nRedOkEOJ1vq9q98Itg TYYUJ5/kTW07+vTXZassEvPj13cFWnYM7tBkBLGq87Z6dVEN2qnKUd/e7dRudGa/ b3S9k0oelc/o8gFOeu3vS174NWlwkR5pyJGAsyl40Ff/0CqnSQ743AmBE96v6IiU kQ290i4pS6QoYh0Z+eHKUoDkGQVjkSTJSyuNNiJI75QYMjoaFZT47PlWJ7l5tvO8 swBWyrFbJahCuC+aZww7l/qyiwAKHgkbLLqsBkwejtY8IztTsgZkv9Evg27f18lY Y/OQrEgVQ+vxCBdQAxCVOsX2H3pY6XVF0y3V1D6HGf3YVslM58IGTGwcfgLW/m9p xyhzvSajswl+tcUYOaURcWYBzovEcJYKBz24elsMlu+7ADdm1GB3TV6R+b9iWWFd fuWO0wkLQ1WaYI82EGSX =9Wjc -----END PGP SIGNATURE----- --Apple-Mail=_9C22C695-778A-433A-A961-A7266521ACBA-- From nobody Fri Jul 29 10:13:10 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0B312DB6D for ; Fri, 29 Jul 2016 10:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 Z3JlNeyPYm3Y for ; Fri, 29 Jul 2016 10:13:07 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 D53C512DC0C for ; Fri, 29 Jul 2016 10:12:49 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id f6so197900963ith.1 for ; Fri, 29 Jul 2016 10:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SM03YCmB5I4O4s96Bm5o+MoBM0m9MOL1DjY2KjA5yHg=; b=gnWEaHyJLVrYqAyvIvSi3Axm87Z4fxwYs6UZ9r7wVBMT+DTjwf1q0+InqyG+Gu2fjQ IaVz9lRwAA1TvWFLs1VudLJKgQsVHGW60isvsG1a1TlR8KKilgxHhg+qW/9ACSpgVzAz kMtwtqRZYA5UUqC1l4iLKVhb1rE+zjDziHt24fnpM6I0HmTckuXXm84cAkfK3MShYgCr aB/gVSCJh84lt+RgZMoTZ1mv/0a+J2DjbhCoVkym/+/CfoPr1KFlWuwg99sNzr8OzFHb Tm8gj1/bQl/lAB2rJmkOW6R/WIh6Piuq7b0C1Md/1o2LN9GDg1/WbbqOlSqfHfz9h4Hg F+RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SM03YCmB5I4O4s96Bm5o+MoBM0m9MOL1DjY2KjA5yHg=; b=dE9h7rnJ1ZxHSx8eJmztUHk0SHTUqNtkX/T2j7sDKmRvvhRXpkgkJvtLoV1TYJ/yCK dtCowOVF5+KlLLZpOks8g/Mpg5EqdJrARPA+gZFh8asowdNRSFmDEAi3xyS/TiiAuhZh jSw//LROFCV6mXoNxSapkV5KAVxAXxEl0EbHQi1SXPRF8KjhLRHf918zXBfE6JdIXIk2 NjheCTuliUuPhnhphkEAUovOBn/OWya4/pD5THBRg6HkgO9g55+qNop07tjQn9Ga5Tce 1bgXkNYYRzMbBCUQ9QH2H293mBwf+3k0hNImLPfsEvMtyRbok2NnHgZMfR/AMPUEzFSd FExg== X-Gm-Message-State: AEkoouvxhN7mw2OY2DQ0lZSU5McwOmCJnW423Bmx4AHHNS44Ae/0Gfa5C4XwaV3xOsa4VLll3sUVwWzeE6DAeQ== X-Received: by 10.36.16.197 with SMTP id 188mr46929208ity.88.1469812368644; Fri, 29 Jul 2016 10:12:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Fri, 29 Jul 2016 10:12:48 -0700 (PDT) In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> From: Tom Herbert Date: Fri, 29 Jul 2016 10:12:48 -0700 Message-ID: To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: privsec-program@iab.org, spud Subject: Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 17:13:08 -0000 On Fri, Jul 29, 2016 at 9:29 AM, Brian Trammell wrote: > Hi, Tom, > >> On 29 Jul 2016, at 17:49, Tom Herbert wrote: >> >> On Fri, Jul 29, 2016 at 5:33 AM, Brian Trammell wrote= : >>> Greetings, all, >>> >>> During the PLUS BoF last week, concern was expressed that a generic sig= naling mechanism such as proposed opened two new attack surfaces: >>> >>> (1) A method for endpoints to allow path elements to add non-integrity = protected signals presents a surface for metadata injection attacks, where = an entity who can place devices on a user's access network and has informat= ion about the user's identity could exfiltrate that information to third pa= rties. For purposes of giving it a name, let's call this a hypercookie inje= ction attack ("hyper" since it exists in a space completely inaccessible to= the application). >>> >>> (2) Even if path elements are not allowed to say anything, a mechanism = to allow endpoints to add integrity-protected signals to their traffic pres= ents a surface for coercion attacks. An access provider can force a user to= tag traffic with their user ID or some other token (a signed assertion tha= t an advertisement has been viewed to the end, or maybe even just straight-= up bitcoins) in order to get "better" connectivity, or even any connectivit= y at all. A more classically Orwellian dystopian variant of this attack has= a government requiring citizens to tag all their outgoing traffic with som= e government-issued identifier. Let's call this a hypercookie coercion atta= ck. >>> >>> I am less concerned about the surface PLUS presents to these attacks th= an those who have raised the concerns in the BoF and on the mailing list, b= ecause the current Internet architecture is already quite vulnerable to the= m. As I said during my presentation last Thursday, Ted Hardie and I sat dow= n to think about this at lunch a couple of months ago, and found six ways o= ne could execute hypercookie injection or coercion today before our pizza s= howed up. >>> >> Brian, >> >> I think there is a significant practical difference between the >> vulnerability of hypercookie injection in TCP/IP and what would be >> present in PLUS. In order to enforce a hypercookie injection in TCP >> one would need to change the TCP stack which typically necessitates a >> kernel change. > > Nope. I don't need to touch the endpoints at all for an injection attack.= I just need one middlebox near the source to rewrite packets, and (possibl= y) another one downstream to pick up the signals. (Okay, I might need to ha= ck the kernel on my middleboxes. But I get to do that. They're mine. :) ) > Except that middelboxes presumably do not have access to the encrypted data so the amount of information they can derive from the packet is limited. The problem is when the application or user is being coerced and there is a readily available mechanism that facilitates that. For example, it seems very possible that a rich signaling mechanism implemented by the user could be used to enforce a backdoor to encryption. Tom From nobody Fri Jul 29 12:37:19 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE7112D833 for ; Fri, 29 Jul 2016 12:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 GmQRhUk8VuVn for ; Fri, 29 Jul 2016 12:37:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DADD12D80E for ; Fri, 29 Jul 2016 12:37:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A73B4BE3E; Fri, 29 Jul 2016 20:37:12 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5w_GJ1c8Pi2; Fri, 29 Jul 2016 20:37:10 +0100 (IST) Received: from [192.168.1.5] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 89450BE38; Fri, 29 Jul 2016 20:37:09 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469821029; bh=93BYsYl6hTErXneRa1jxDAvsChRKZhEyILWz0HkFDL8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=fxJDO0KBlxSosZz5JlL7dLvMcHjyqsrFBUgODvipQXFQMUFj+GmypvdmCWpI8iNt+ aVCJymItobj8kkSh6v2qECyOg7L21PTVR1HOC4sKtcnqb6wjzaNNqYavaXdCY1C73j mMfKzqWbVSOXvJ2o4a1lNL8kHZpFYkWgpZr8Wkrs= To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 29 Jul 2016 20:37:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070106010603070706080006" Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 19:37:18 -0000 This is a cryptographically signed message in MIME format. --------------ms070106010603070706080006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 29/07/16 16:54, Mirja K=C3=BChlewind wrote: > Hi Stephen, >=20 > I see registries as a needed and valuable part of our standardization > process. People ignoring registries as well as things that are > explicitly specified in a standards document is a different problem. Registries can be a useful way to support extensibility. They can also be a nuisance that allow for the promulgation of crazy ideas. And probably lots in between and all at once;-) None of the generalities above help in this specific case where I remain convinced that any extensible-generic-PLUS is liable to be highly dangerous. (And I'm unsure if a non-extensible-PLUS can be usefully transport independent.) >=20 >=20 > To answer your question below: >=20 >>>=20 >>> 2) Further only PLUS provides an additional function that allows >>> to detect any mangling of data/bits that was not intended. This >>> is urgently needed because all the TCP (and higher) layer >>> mangling we see today is the root cause for the problem we have >>> right now. >>=20 >> I don't get your point (2) sorry. Can you explain more? >=20 > We explained this in the BoF and I believe I made this point very > clear in my last mail that I replied to Kyle. But let me state this > bit again, because it=E2=80=99s important. >=20 > Today, there are a large amount of bits a middlebox can mangle with > (as described in draft-trammell-privsec-defeating-tcpip-meta which is > not even exhaustive). Most of the described ways to insert > information into a packet are not detectable, at least most of the > ways described for TCP because all information is in cleartext and > the receiver does not know what the sender has originally sent while > the mangled information still allows proper operation. The above is clear, thanks. And is what I got from the BoF too. > What we propose is to a) encrypt all bits in the transport/TCP > header,=20 Well, no, PLUS is not a proposal to do that iiuc - PLUS is a proposal to expose some information when such encryption is being done as defined by some other specification which is not PLUS. If my take there is wrong, I'd appreciate being corrected. I would have far less of an issue if e.g. QUIC or other transports defined in a transport-specific and non-extensible manner how the few bits of information that might be desirable for the path can be outside the confidentiality envelope. I can totally see how some architectural guidance and examples of the sometimes-subtle threats caused by exposing information were to be developed. PLUS however seems to be proposing to go beyond that and to define PDUs, which I think I'm nearly convinced is a bad plan and a path down which it may be better to not start. > b) provide less bits in a PLUS header, that have been > carefully evaluated towards risks that we know today (but didn=E2=80=99= t know > when we designed TCP), and c) a MAC that hashes all information > provided in the PLUS header to be able to detect mangling by the > receiver (which can inform then the sender using an encrypted > channel). This also means that the endpoint has the choice to not use > PLUS (or any PLUS information fields) if mangling is detected. >=20 > All these points together, especially point c, makes the situation > compared to what we have today better and not worse! I get that that's the argument for PLUS. I remain unconvinced by that argument for the reasons stated earlier. Cheers, S. >=20 > Mirja >=20 >=20 >=20 >=20 >> Am 29.07.2016 um 17:17 schrieb Stephen Farrell >> : >>=20 >>=20 >> Hiya, >>=20 >> On 29/07/16 15:48, Mirja K=C3=BChlewind wrote: >>> Hi Stephen, >>>=20 >>> I believe that what you think PLUS is, is not what we propose. >>=20 >> I'm pretty sure that's true - and is part of what puzzles me as I >> said before. >>=20 >>> Maybe we did not make a great job so far to define PLUS narrowly >>> enough but we believe the actual protocol specification work >>> should be done in a wg to ensure that a broad community can >>> participate, and all concern, including privacy concerns, can be >>> addressed. >>=20 >> I get that. Some folks however (and I'm not sure if I'd count >> myself amongst them yet or not) fear that any such WG has to end up >> as very privacy unfriendly if it remains transport agnostic. From >> that perspective, starting a WG would not make sense. >>=20 >>>=20 >>> The point of draft-trammell-privsec-defeating-tcpip-meta is to=20 >>> further explain that the things you describe as risks are >>> nothing new. And by new, we mean they are even standard-conform; >>> because this is the main point of your concern if I understand >>> you correctly, right? >>=20 >> No. Brian's draft doesn't touch on the "over 18" type threat at all >> as I read it, so I don't accept the idea that the hypercookie is >> the right place from which to start to analyse the set of threats >> in this space. >>=20 >> And there is IMO a real difference between our current/old set of >> protocols allowing bad behaviours vs. us defining a new protocol to >> explicitly enable those same bad behaviours. (It could be that not >> all of us agree that that is a real difference.) >>=20 >>>=20 >>> I assume your point is that we propose a protocol that is >>> intended to signal information from middleboxes to the endpoint >>> (amongst other features). I assume this based on the following >>> statement you made: >>>=20 >>>> Should we standardise a method for such abuse, then I think >>>> it's quite possible the attacker may argue that their behaviour >>>> is not an attack as it's just a part of "the standard.=E2=80=9C >>>=20 >>> and >>>=20 >>>> And to the extent that PLUS could enable and standardise such=20 >>>> things, that is, for me, a major reason to oppose PLUS. >>>=20 >>> Otherwise can you please further explain what you mean by =E2=80=9Esu= ch=20 >>> abuse=E2=80=9C and =E2=80=9Esuch things=E2=80=9C? >>=20 >> Sorry I don't get the question. (That is, I'm not clear if I do or >> do not agree with your assumptions, which are not clear to me;-) >>=20 >>>=20 >>> If the thing you are concerned about in PLUS is, that we propose >>> to standardize =E2=80=9Aoption=E2=80=98 space that explicitly allows = middleboxes >>> to add information to a packet, I guess you know that it is >>> possible to define an experimental TCP option (in the ISE stream) >>> without IESG approval that allows the insertion of private >>> information by middleboxes. Even thought TCP options are not >>> intended to be altered by network nodes, there is also no >>> standard that forbids this. >>=20 >> I am not arguing for a "MINUS" (a TBD acronym that'd be the >> antithesis of PLUS:-). >>=20 >>>=20 >>> Let me say two things about what we ACTUALLY propose with PLUS: >>> 1) We do NOT propose to add space to add arbitrary information. >>> The semantic of the field must be well-defined in an IESG >>> approved RFC and registered respectively. >>=20 >> IMO that is not sufficient to allay my concern about "over 18" and=20 >> the like. If we build it (the registry) then they will come (and >> ask for or squat on code points with horrible semantics). I can't >> see any way to avoid that other than never creating such a >> registry. >>=20 >>> This will not only make it not-standard conform to use such a >>> field for something different, it also restrict the set of valid >>> values which then could even be checked by later middleboxes on >>> the path, and erased if needed. >>=20 >> Sure. But I remain convinced that any registry here is too >> dangerous and the above doesn't convince me otherwise. >>=20 >>> 2) Further only PLUS provides an additional function that allows >>> to detect any mangling of data/bits that was not intended. This >>> is urgently needed because all the TCP (and higher) layer >>> mangling we see today is the root cause for the problem we have >>> right now. >>=20 >> I don't get your point (2) sorry. Can you explain more? >>=20 >>>=20 >>> Further, I would like to say that not all middlebox mangling is=20 >>> automatically bad or an attack. >>=20 >> Of course. And I did not say that. I said that there are some bad >> behaviours in this space and we need to worry about us maybe=20 >> legitimising those. >>=20 >>> If we don=E2=80=99t provide a standardized way to communicate with >>> middleboxes, it will be even harder to distinguish an attack from >>> something that actually supports the network service provided or >>> even makes the services possible at all. Without standardization >>> there is no control at all. I don=E2=80=99t think we can ignore what=E2= =80=99s >>> already happening the Internet any further and providing >>> standardized mechanisms to support the good in-network functions >>> is the only way to improve security for these functions. >>=20 >> The above text seems indicative of understandable exasperation but=20 >> I don't see how it's very useful for the discussion. >>=20 >>>=20 >>> To make this even more clear, you wrote: >>>> the argument seems to ignore the downsides of standardising >>>> and thus legitimising "bad" behaviour including behaviours that >>>> your draft properly calls an attack. >>>=20 >>> We not at all want to legitimate =E2=80=9Ebad=E2=80=9C behavior and I= really >>> don=E2=80=99t know why you think that what we propose would do so. >>=20 >> Sigh. I didn't personalise this (I hope! Apologies if I did by=20 >> mistake) so I wasn't at all discussing what you or anyone wants or=20 >> doesn't want. It is entirely possible to have good motivation for=20 >> something that may have quite bad side-effects. >>=20 >> And I still think that the arguments made by proponents of PLUS are >> ignoring the downsides. (And I do not mean that the people making >> those arguments are ignoring those downsides which would be a >> different statement.) >>=20 >>> We propose to standardize a protocol that allows middleboxes to >>> provide information they have been requested for (by the >>> endhost). This information is well define and under IESG >>> approval. Any other use of such a protocol will not be >>> standard-conform and as bad as the misuse we can see today with >>> existing protocols. >>=20 >> I think that just repeats earlier statements. >>=20 >> S. >>=20 >>>=20 >>> Mirja >>>=20 >>>=20 >>>=20 >>>> Am 29.07.2016 um 15:23 schrieb Stephen Farrell=20 >>>> : >>>>=20 >>>>=20 >>>> Hi Brian, >>>>=20 >>>> On 29/07/16 13:33, Brian Trammell wrote: >>>>> Greetings, all, >>>>>=20 >>>>> During the PLUS BoF last week, concern was expressed that a=20 >>>>> generic signaling mechanism such as proposed opened two new=20 >>>>> attack surfaces: >>>>=20 >>>> No necessarily "opened...new" perhaps more "risked making much >>>> more ubiquitous." At the meeting I didn't hear anyone claim >>>> these were new attacks. (I did hear you say they were not >>>> new.) >>>>=20 >>>>>=20 >>>>> (1) A method for endpoints to allow path elements to add=20 >>>>> non-integrity protected signals presents a surface for >>>>> metadata injection attacks, where an entity who can place >>>>> devices on a user's access network and has information about >>>>> the user's identity could exfiltrate that information to >>>>> third parties. For purposes of giving it a name, let's call >>>>> this a hypercookie injection attack ("hyper" since it exists >>>>> in a space completely inaccessible to the application). >>>>>=20 >>>>> (2) Even if path elements are not allowed to say anything, a >>>>> mechanism to allow endpoints to add integrity-protected >>>>> signals to their traffic presents a surface for coercion >>>>> attacks. An access provider can force a user to tag traffic >>>>> with their user ID or some other token (a signed assertion >>>>> that an advertisement has been viewed to the end, or maybe >>>>> even just straight-up bitcoins) in order to get "better" >>>>> connectivity, or even any connectivity at all. A more >>>>> classically Orwellian dystopian variant of this attack has a >>>>> government requiring citizens to tag all their outgoing >>>>> traffic with some government-issued identifier. Let's call >>>>> this a hypercookie coercion attack. >>>>>=20 >>>>> I am less concerned about the surface PLUS presents to these=20 >>>>> attacks than those who have raised the concerns in the BoF >>>>> and on the mailing list, because the current Internet >>>>> architecture is already quite vulnerable to them. As I said >>>>> during my presentation last Thursday, Ted Hardie and I sat >>>>> down to think about this at lunch a couple of months ago, and >>>>> found six ways one could execute hypercookie injection or >>>>> coercion today before our pizza showed up. >>>>=20 >>>> Wrt injection I can buy that totally. Having read your draft I=20 >>>> don't find enough there to accept your assertion wrt coercion >>>> - ISTM that coercion attacks have not been analysed yet in >>>> your draft. >>>>=20 >>>> As a side-note, meta-data doesn't have to be person-specific to >>>> be controversial - "over 18" and anything with similar >>>> semantics, e.g. "member of minority" can very clearly be >>>> equally or more damaging, yet totally non-identifying if the >>>> relevant set of folks is large enough. So I wonder if the >>>> "hypercookie" concept is even the right starting point here. >>>> And to the extent that PLUS could enable and standardise such >>>> things, that is, for me, a major reason to oppose PLUS. (That's >>>> a side-note for this email, but perhaps a quite fundamental >>>> thing to consider in the overall discussion.) >>>>=20 >>>>>=20 >>>>> I sat down a little longer to write these up. I found five >>>>> more, without even considering trivial out-of-band metadata >>>>> leaks or steganographic side channels.=20 >>>>> https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-= meta-00 >>>>> >>>>> >> >>>>>=20 is the result. The conclusion: these attacks are trivially easy to >>>>> execute today by exploiting the gap between valid TCP >>>>> traffic and what will be ignored by TCP-indifferent devices >>>>> and endpoints, as well as all those juicy bits IPv6 gives >>>>> you. Unless we're willing to rely on the widespread, >>>>> altruistic deployment of stateful TCP firewalls to reject >>>>> traffic (I think we can use our experience with BCP38 as >>>>> guidance as to how well *that* will work, and in any case I >>>>> think it would be kind of rich for me of all people to >>>>> recommend throwing more TCP-meddling middleboxes into the >>>>> mix) the only way I can see out is to add integrity=20 >>>>> protection to all transport and network-layer headers, as >>>>> well as confidentiality protection to those headers the path >>>>> does not need to see. >>>>=20 >>>> I don't agree. Observatories seem to me like a mitigation that >>>> your draft does not consider. If the attacker here does not >>>> want to be seen to be attacking, then those can be effective. >>>> Should we standardise a method for such abuse, then I think >>>> it's quite possible the attacker may argue that their behaviour >>>> is not an attack as it's just a part of "the standard." >>>>=20 >>>> Such a mitigation could be attempted against the attack in >>>> 4.1.3 of your draft for example so I disagree with the draft's >>>> assertion that "no user-initiated mitigation is possible" in >>>> that case at least and maybe others. >>>>=20 >>>> I think it'd be a fine thing to see further analysis of the=20 >>>> attacks and potential mitigations as your draft develops. >>>>=20 >>>>>=20 >>>>> This is, of course, the whole point of PLUS. We can and >>>>> should have a discussion of what the endpoints should be able >>>>> to say, and what the endpoints should be able to let the path >>>>> say. But if we're concerned about this attack, the general >>>>> approach is AFAICT the only way out. >>>>=20 >>>> I disagree. And I think it was clear that a whole bunch of >>>> folks in the room last week also clearly disagreed. >>>>=20 >>>> I believe your "only way out" conclusion isn't logically >>>> justified as the argument seems to ignore the downsides of >>>> standardising and thus legitimising "bad" behaviour including >>>> behaviours that your draft properly calls an attack. >>>>=20 >>>> Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that we >>>> have different sets of sensible folks reaching diametrically >>>> opposed conclusions based on the same facts and arguments. >>>> Perhaps the tl;dr in your abstract may be a hint there - I do >>>> not think everything is ruined myself, so maybe one's level of >>>> opt/pess-imism affects one's view of the valid conclusions to >>>> reach in this space. >>>>=20 >>>> Cheers, S. >>>>=20 >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Privsec-program mailing list Privsec-program@iab.org=20 >>>>> https://www.iab.org/mailman/listinfo/privsec-program >>>>>=20 >>>>=20 >>>> _______________________________________________ Spud mailing >>>> list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud >>>=20 >>=20 >> _______________________________________________ Spud mailing list=20 >> Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud >=20 > _______________________________________________ Privsec-program > mailing list Privsec-program@iab.org=20 > https://www.iab.org/mailman/listinfo/privsec-program >=20 --------------ms070106010603070706080006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3Mjkx OTM3MDRaMC8GCSqGSIb3DQEJBDEiBCAEyIQplLwzZbQ8Qwqi2Jg8O25DT1ET+4T7R5ag/bgk izBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAyGAzIYpOqpvaYI7KgbdjT6n1dF6j3QyuCg8InSLWrvLunQX4O3Ifo ya/b2WodfIKjWMG5oRUC9cVBBotr0li1u2wAmwxt97sG5zfrW8XMMuISR/hKOwWT0Nq5fMLN I2NyxQjdLPG4NMyQJX1x3SifkvAd0z9eCtQ1ewlcwH/Ou+Jzq02rlBfG55YkVK8GCFSMfvbm FGvMLiThO8vLpciwD7fRLX7Bw0QZtH12yUVbbqR7PSlxsSUsjfmH2LpWmTD10XdgX3OYwqo4 7Vy8J281+T8qyhalHgf06PcavQ7xUtWS5Y721mOvoHPIpx9OvKksyCYxN2ls3Jdx2qxi+GW7 AAAAAAAA --------------ms070106010603070706080006-- From nobody Fri Jul 29 12:52:24 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F6112DAFC for ; Fri, 29 Jul 2016 12:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 45kkD0Z9aSPq for ; Fri, 29 Jul 2016 12:52:21 -0700 (PDT) Received: from wp214.webpack.hosteurope.de (wp214.webpack.hosteurope.de [80.237.132.221]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27DD12DAEC for ; Fri, 29 Jul 2016 12:52:20 -0700 (PDT) Received: from [31.10.157.197] (helo=mairac.home); authenticated by wp214.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1bTDpT-0007MY-4S; Fri, 29 Jul 2016 21:52:19 +0200 To: Tom Herbert , Brian Trammell References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> From: Stephan Neuhaus Message-ID: <05118b58-8bf9-8abc-b6bf-2d2b0b79d8ef@artdecode.de> Date: Fri, 29 Jul 2016 21:52:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de;sten@artdecode.de;1469821941;2816ded2; Archived-At: Cc: spud Subject: Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 19:52:23 -0000 On 2016-07-29 19:12, Tom Herbert wrote: > On Fri, Jul 29, 2016 at 9:29 AM, Brian Trammell wrote: >> >> Nope. I don't need to touch the endpoints at all for an injection attack. I just need one middlebox near the source to rewrite packets, and (possibly) another one downstream to pick up the signals. (Okay, I might need to hack the kernel on my middleboxes. But I get to do that. They're mine. :) ) >> > Except that middelboxes presumably do not have access to the encrypted > data so the amount of information they can derive from the packet is > limited. The problem is when the application or user is being coerced > and there is a readily available mechanism that facilitates that. For > example, it seems very possible that a rich signaling mechanism > implemented by the user could be used to enforce a backdoor to > encryption. Now I'm confused. I thought that the situation that Brian was talking about is middleboxes fiddling with the packet headers, which are in plaintext, and not with the packet's payload which, as you say, may be encrypted. You seem to be saying that the amount of information that can be extracted from plaintext transport headers is limited, is that correct? Brian is also talking about the path; you seem to be talking about the endpoints, is that correct? If both these assumptions are correct, then I'd like to make three points. (If they're both wrong, please stop reading. If one is right and one is wrong, read only half of what follows. You choose which half :-) ) First, I do not agree that the amount of information in the transport headers is limited, which I assume means "of limited value". It's classic metadata and should be protected, if possible. That transport header is seen by many more boxes than the plaintext of the encrypted payload and thus the probability of someone siphoning it off are that much larger, precisely because it is valuable. Second, I'm not sure in what way "a rich signaling mechanism implemented by the user could be used to enforce a backdoor to encryption" or rather, I'm not sure how that is a problem enabled specifically by PLUS. If the "user" (which I understand to be an application running on top of a networking stack) wants to "backdoor its encryption" (i.e., leak key material), it can already do so today. For example, a suitably modified TLS library could stash the master secret at the end of a TLS message (may work with many applications, even without an equally compromised TLS library on the other end). Or it could silently always use DUAL_EC_DRBG (always works). Or ... Many of these would go undetected for a long time. The upshot is: once your endpoint is compromised, all bets are off anyway. And finally, have the impression that you think that PLUS is going to be this gigantic free-for-all, where every Joe, Dick, and Harry can annotate a packet in any way they please. If I understood the PLUS proponents correctly, this will not be the case. PLUS fields will be limited in number, space, and semantics, and they will (for the most part) be integrity-protected so that nothing on the path can fiddle with them without anyone noticing. To summarise: 1) If your endpoint is compromised, you're screwed anyway. 2) The total amount space that's available for undetected fiddling by a middlebox will perhaps not be zero, but it will be less than it is today. Fun, Stephan [Full disclosure: I'm working with Brian and Mirja on the MAMI project.] From nobody Fri Jul 29 13:17:18 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AE212D144 for ; Fri, 29 Jul 2016 13:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 5axH6tphzOiA for ; Fri, 29 Jul 2016 13:17:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9246A12D1CB for ; Fri, 29 Jul 2016 13:17:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 639F7BE3F; Fri, 29 Jul 2016 21:17:12 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkAvHCg4SAk4; Fri, 29 Jul 2016 21:17:07 +0100 (IST) Received: from [192.168.1.5] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 53306BE3E; Fri, 29 Jul 2016 21:17:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469823426; bh=iBUKao61ODrjs2cLAkuNpPO5jz8t6MhjrBiaYIE85Lw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ipdzZ1Nrz/SIoNQydzq4ArNt1DP7Sn/g4KUVxxN3h5tGwVtC0RRKXqdcU7s73Gu8D irEAP3KksSYohtwPhbNHT6JGqarAj+CBOiuuwhMo5Ol/2sxiunbDRlZAipmQIksvia clM+VM4tfrWSkqKp3ZN5yJl6QK5sJd27ZHGoXv6k= To: Brian Trammell References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <23ea44f5-d841-9406-6f7f-8fad27a5d66b@cs.tcd.ie> Date: Fri, 29 Jul 2016 21:17:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I6q3dw2xI35wxntvkmCw48JUqmnmq2m2R" Archived-At: Cc: privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 20:17:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I6q3dw2xI35wxntvkmCw48JUqmnmq2m2R Content-Type: multipart/mixed; boundary="aW7VpUtC4BBfaQi8aNxt8Xnib6rtRlvTu" From: Stephen Farrell To: Brian Trammell Cc: privsec-program@iab.org, spud Message-ID: <23ea44f5-d841-9406-6f7f-8fad27a5d66b@cs.tcd.ie> Subject: Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> In-Reply-To: --aW7VpUtC4BBfaQi8aNxt8Xnib6rtRlvTu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 29/07/16 17:22, Brian Trammell wrote: > hi Stephen, >=20 >> Hi Brian, >>=20 >> On 29/07/16 13:33, Brian Trammell wrote: >>> Greetings, all, >>>=20 >>> During the PLUS BoF last week, concern was expressed that a >>> generic signaling mechanism such as proposed opened two new >>> attack surfaces: >>=20 >> No necessarily "opened...new" perhaps more "risked making much more >> ubiquitous." At the meeting I didn't hear anyone claim these were >> new attacks. (I did hear you say they were not new.) >=20 > Point; shall we say "may widen two existing"? (Of course, I disagree > that PLUS does widen this surface, otherwise I could not in good > conscience work on it. I am afraid we simply have to agree to > disagree here, though.) Well, PLUS would have to minimally extend the attack surface at least in an xkcd-one-more-standard manner. One could still in good conscience argue for that though if one thought that the existence of the new, standard method for injecting meta-data meant that the overall amount of privacy unfriendly behaviour would be reduced. While that's an argument that could be made, I'd not be convinced by it unless we had evidence that standardising something like PLUS would result in just that changed behaviour, and I can't see that that's possible. >>> (1) A method for endpoints to allow path elements to add=20 >>> non-integrity protected signals presents a surface for metadata=20 >>> injection attacks, where an entity who can place devices on a >>> user's access network and has information about the user's >>> identity could exfiltrate that information to third parties. For >>> purposes of giving it a name, let's call this a hypercookie >>> injection attack ("hyper" since it exists in a space completely >>> inaccessible to the application). >>>=20 >>> (2) Even if path elements are not allowed to say anything, a=20 >>> mechanism to allow endpoints to add integrity-protected signals >>> to their traffic presents a surface for coercion attacks. An >>> access provider can force a user to tag traffic with their user >>> ID or some other token (a signed assertion that an advertisement >>> has been viewed to the end, or maybe even just straight-up >>> bitcoins) in order to get "better" connectivity, or even any >>> connectivity at all. A more classically Orwellian dystopian >>> variant of this attack has a government requiring citizens to tag >>> all their outgoing traffic with some government-issued >>> identifier. Let's call this a hypercookie coercion attack. >>>=20 >>> I am less concerned about the surface PLUS presents to these >>> attacks than those who have raised the concerns in the BoF and on >>> the mailing list, because the current Internet architecture is >>> already quite vulnerable to them. As I said during my >>> presentation last Thursday, Ted Hardie and I sat down to think >>> about this at lunch a couple of months ago, and found six ways >>> one could execute hypercookie injection or coercion today before >>> our pizza showed up. >>=20 >> Wrt injection I can buy that totally. Having read your draft I >> don't find enough there to accept your assertion wrt coercion - >> ISTM that coercion attacks have not been analysed yet in your >> draft. >=20 > Agreed that the analysis isn't where I'd like it to be yet. There are > two major reasons for this. One, this draft is focused on in-band > abuse of TCP and IP features (which seemed a good place to start) and > it's not clear to me that the real threat of coercion lies at this > layer at all: coercion attacks seem a lot easier to implement with > out of band techniques at the application layer.=20 Hmm, not sure myself. Worth pondering and (hey, your fav... :-) doing some measurement. > Second, with respect > to the threat at this layer, it seems that coercion attackers would > want to be less detectable, which expands the space of abuse to > include low-frequency temporal domain side channels and other > quasi-in-band sorts of things. There's a lot packed into the above sentence that I think may be usefully unpicked in future revisions of your draft. I'm not sure I agree about wanting to be less detectable - the common usage of outrageous terms and conditions is both detectable and fits here. > Coercion is at its heart a layer 9 attack, though, and a good > analysis of it that takes this into account would make the draft much > better. Happy to accept text on this. Need to get the source into a > public GitHub repo to send PRs against, first. >=20 >> As a side-note, meta-data doesn't have to be person-specific to be >> controversial - "over 18" and anything with similar semantics, e.g. >> "member of minority" can very clearly be equally or more >> damaging, yet totally non-identifying if the relevant set of folks >> is large enough. >=20 > Of course; this is an orthogonal question, though.=20 Yes and no. The question is a side-note in my mail but IMO crucial to the questions about PLUS overall. > Here we're > considering how many bits you can inject or leak. How many bits you > need is a question of how large the space of signals is. If what > you're concerned about is linkage on a very small number of bits, > though, then everything is even more ruined than we think. Well, I didn't agree that ruined is a good descriptor though:-) My point is that the entropy of the signal ought not be the only consideration - there have historically been some societies where just one bit (in-group/out-group) would have been sufficient to cause an awful lot of damage. I think we really do need to think hard about changes to the transport layer that might enable such discrimination at that layer and at such scale. >=20 > >=20 >>> ... the only way I can see out is to add integrity protection to >>> all transport and network-layer headers, as well as >>> confidentiality protection to those headers the path does not >>> need to see. >>=20 >> I don't agree. Observatories seem to me like a mitigation that your >> draft does not consider. >=20 > Good point. We should add large-scale Internet observatories to the > list of general mitigation approaches (Yay! more measurement to do!). > This scales a bit better than firewalls everywhere, but still > requires you to throw a lot of power and cooling at the problem if > you're going to get enough scale to make the attacks too dangerous to > execute. That's not clear to me at all. Some observatory functions may only require putting up a server that says what it sees, or even better building such features into loads of other servers that have a day job. Things like [1] and [2] aren't necessarily that expensive and can play their part here I think and even though observatory might not be the right term for those, such things can be part of the overall set of mitigations here. [1] http://ipv6-test.com/ (no working https, sorry:-) [2] https://dnsviz.net/ But yes, other observatories may be more expensive. >=20 >> If the attacker here does not want to be seen to be attacking, then >> those can be effective. Should we standardise a method for such >> abuse, >=20 > ... noting that one of the points of this draft is to make it clear > that we *have already standardized* at least eleven methods for such > abuse with the publication of RFCs 791, 3315, 4291, 6437, 6864, and > 6994, among others.=20 I would not use the above phrasing. I don't believe that the IETF intended to standardise the abuse-cases in all of those. I'm not even sure if the folks concerned thought of those abuses before it was too late. If there are cases where we did, documenting that would also be a fine thing for your draft to do, to help us understand how to not make those mistakes again. > These standards don't condone the abuse they > enable, but by having MUST NOT send / MUST ignore language, which > remains good engineering practice for interoperability, they *do* > enable it,=20 Right. Making that point in your draft (or wherever), may be quite valuable. (Maybe there's a statement or two to add to 3552bis on this topic as well?) > and in terms of how much evil the abuse can result in, I > don't see that there's really any practical difference between the > condoning and enabling. I do, as previously noted. >=20 > Methods for encrypting transport headers, whether specific to a > single transport protocol (QUIC) or generic (PLUS), would, however, > make injection impossible, not just somewhat-mitigatable. So a different question: what other protocol that is not QUIC is one where PLUS would be beneficial? And wouldn't the existence of PLUS and it's use with any protocol that didn't encrypt as much as QUIC represent a clear standardisation and extension of the bad features here? (I guess I may be partly asking if the SPUD/PLUS idea has been OBE here.) >=20 >> then I think it's quite possible the attacker may argue that their >> behaviour is not an attack as it's just a part of "the standard." >>=20 >> Such a mitigation could be attempted against the attack in 4.1.3 of >> your draft for example so I disagree with the draft's assertion=20 >> that "no user-initiated mitigation is possible" in that case at=20 >> least and maybe others. >=20 > Whether an observatory counts as "user-initiated mitigation" or not > is a semantic quibble. Fine. Some observatories are, some are not. One for 4.1.3 could well be user-initiated and cheap. That may well not be the case for others that could be useful against other of the attacks in your draft. >=20 >> I think it'd be a fine thing to see further analysis of the >> attacks and potential mitigations as your draft develops. >=20 > An open invitation to all: text appreciated. :) One thing I do want > to do is some measurement to see on how many paths these work as > advertised. >=20 >>> This is, of course, the whole point of PLUS. We can and should >>> have a discussion of what the endpoints should be able to say, >>> and what the endpoints should be able to let the path say. But if >>> we're concerned about this attack, the general approach is AFAICT >>> the only way out. >>=20 >> I disagree. >=20 > Again, agreeing to disagree. >=20 > But I think we also have a specific misunderstanding here: the point > I wanted make *here* was not "you need PLUS". (I think you do, but > that's a separate question.) The "general approach" I referred to > (sorry for not being more precise) is: "you *at the very least* need > cryptographic integrity protection of transport headers, with > confidentiality protection for things the path doesn't need to see". >=20 > We can have honest disagreements about what the path needs to see and > doesn't, and we should do engineering analysis of the > cost-risk-benefit tradeoffs in order to resolve those disagreements. Yes, discussions on the above can be had (and I'm sure you've been having 'em happily without me for quite a while:-). I don't however see how those discussions lead to a conclusion that there is value in an an attempt to provide an extensible and transport- independent solution. That last seems like maybe the least desirable approach one could take here as I think it leads to solutions that are most open to additional abuse. >=20 >> Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that we have=20 >> different sets of sensible folks reaching diametrically opposed=20 >> conclusions based on the same facts and arguments. Perhaps the >> tl;dr in your abstract may be a hint there - I do not think >> everything is ruined myself, so maybe one's level of opt/pess-imism >> affects one's view of the valid conclusions to reach in this >> space. >=20 > I suspect I've spent a bit too much time staring at how TCP breaks > over my career, which is the source of my pessimism, on this > particular topic, at least. Sure. The question is whether or not that's part of the reason we see folks coming to such different conclusions. I don't claim to know the answer btw;-) >=20 > One purpose of the draft in its present state is that I realized > during the PLUS BoF that others may be making overly optimistic > assumptions about what the transport layer does and does not do as > defined, and to make sure that everyone who cares to read the draft > has a shared understanding of how TCP breaks, so they can make their > own conclusions about their own pessimism. I do hope that it can > evolve into a generalized guide to breaking brokenness for this > particular set of attacks, though. Yeah, I think the evolution of your draft may be of value independent of PLUS. S. >=20 > Thanks, cheers, >=20 > Brian >=20 >=20 >=20 > _______________________________________________ Privsec-program > mailing list Privsec-program@iab.org=20 > https://www.iab.org/mailman/listinfo/privsec-program >=20 --aW7VpUtC4BBfaQi8aNxt8Xnib6rtRlvTu-- --I6q3dw2xI35wxntvkmCw48JUqmnmq2m2R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXm7nBAAoJEC88hzaAX42iE3QIAKUe7dUSvI12EM738KfsLrX6 IlyVNd6n/Nhqc8fWqGJiEy44t8hc6rBkrc2xGAaJrSYnOCExKRUz+xUloxjKD2Bl t0B/mNan+X1Vqz9ODydzPEy2INR6vAruC+N971x3+l/xFhkHXdYGBGOGi6DX52WJ VeSEKdK8Vq968HO7wJZTnA+OZVlCaC7/MmFMTV+LT+/0w6wibDJnc8KCzoOvLojR BRhVWydr3bAZp04cUkfE3oCqLp+0iLC4KdRYhOEXVHueCcpA2omADG2VepacR3KN OjZlC4Ong/hsc/fv5EBAZW+b8KV/3E4HJCRY1AfGJ0SZO3reeu/bh85O9PWCj6E= =nuIU -----END PGP SIGNATURE----- --I6q3dw2xI35wxntvkmCw48JUqmnmq2m2R-- From nobody Fri Jul 29 13:19:07 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D706C12D1CB for ; Fri, 29 Jul 2016 13:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 ABMhOF52wndi for ; Fri, 29 Jul 2016 13:19:00 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 832F512D144 for ; Fri, 29 Jul 2016 13:19:00 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id l65so120947827oib.1 for ; Fri, 29 Jul 2016 13:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aoYTLGgNtfdOLwLPY77z58tVhDW5HJ0uXBw6NbYT6tA=; b=U44vnZ9m9ojGJXWW2m9K09vcqxQheYjyFVwHWXL5Bcl/WdRI3En6zyQbC51VgmIJUf d841hRbjdXTmVkF6MSQmAj14Th15Mvz2limJl2PYuQuwamJdPNsboOcQmGuDVc8sJZyh xbmvij7puQB6G2qMQFDWF9VDzGTJ1yrqRC+002HgS8IIVZkXFuHbK0CYU16xV47TFwz7 OdEimcFIwEKc3I/UROvp9bY5oVUedTgpEhbQdplE3NwCsNrgEe8j7z7Plnh8jUcETKu1 Mv3V+G+wjc7F/YeMXImlctgL/PbO/TdtUyJt2dtfpogWw8neMRPJvfwj2C16dEZdAa7u wtbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aoYTLGgNtfdOLwLPY77z58tVhDW5HJ0uXBw6NbYT6tA=; b=b+MMK0cG7NwlLPkAoaph6HnjvcvwJPCNOGjuWcQvwYnFdGtaOQ0wzQwus5XaUXvdLm AKKR6EXRXejhym3R1L9nWD7R9/oPou3jJPGK2f18diy6l1ehm56wphMLLMQ1eilvsl5K jdDVz6y6/I61aISBM0kquPBaqfPYD533XRYsmVDH2U5L/kgXZir1lvySE9IPCKjPq8i7 RaMV32ttMCP5zuBFpoS9ADnM1v31LU488jP4Xu3RVi2qxIWA2s6T2uV2KCQyZJFPY9l0 kdHsPq7v3vNKixqezf29syFOjTc5We0WOkqc30ZcIvIPdINUxcimfIdIaJJsGLfsQRQq jzoQ== X-Gm-Message-State: AEkoouvp3s6p/AoKgars48fAt76I9qX67IMssJGIey0x2e8zPsngY2pP9+JsGbVHNu1YmhpgzXYwCtOsOi3EGA== X-Received: by 10.157.45.229 with SMTP id g92mr28166866otb.48.1469823539834; Fri, 29 Jul 2016 13:18:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.222.213 with HTTP; Fri, 29 Jul 2016 13:18:30 -0700 (PDT) In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> From: Ted Hardie Date: Fri, 29 Jul 2016 13:18:30 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c047984f976a00538cbf52a Archived-At: Cc: Brian Trammell , "privsec-program@iab.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 20:19:04 -0000 --94eb2c047984f976a00538cbf52a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 29, 2016 at 12:37 PM, Stephen Farrell wrote: > > Hiya, > > On 29/07/16 16:54, Mirja K=C3=BChlewind wrote: > > Hi Stephen, > > > > I see registries as a needed and valuable part of our standardization > > process. People ignoring registries as well as things that are > > explicitly specified in a standards document is a different problem. > > Registries can be a useful way to support extensibility. They can > also be a nuisance that allow for the promulgation of crazy ideas. > And probably lots in between and all at once;-) > > None of the generalities above help in this specific case where I > remain convinced that any extensible-generic-PLUS is liable to be > highly dangerous. (And I'm unsure if a non-extensible-PLUS can be > usefully transport independent.) > > So, it's not clear to me exactly what you mean by "transport independent" here, so let me drill down a bit. I think PLUS is proposed for a set of transports that use the UDP demux (and thanks to Stuart Cheshire for a useful shorthand for that function). It expects that those transports will integrity protect their transport headers and treat as confidential some aspects of their state exchange (a multiplexing transport, for example, might decide that the state of the flows being multiplexed should be confidential). A PLUS with very limited semantics (start, stop, delay tolerant, drop tolerant) would likely be broadly applicable to that class of transports and yet be transport independent (for that specific meaning of transport). The folks arguing for this have a set of concerns: *) Some useful path elements are impaired now, compared to previously. How can we safely repair that impairment? Where safely means: not restoring plaintext for inspection nor providing a worse-than-current side channel for identification. (I accept that analysing one against "current" requires understanding ease of attacking the side channel) *) If there is a new, popular transport protocol, how do we ensure that it does not end up as the new HTTP, used for a variety of things not because it is suitable on design fit but because it gets through the network? To put this another way, how do we make sure that the new design pattern given above opens innovation at that transport layer? While the proponents of PLUS believe that a substrate approach is the most deployable (because you can redefine things like SRTP to run over PLUS instead of bare UDP), we care much more that the approach meets those concerns than the approach be a substrate. If you want to call it a "design pattern" and implement it in a couple of candidates from that design pattern, fine. You end up describing the thing multiple times rather than once, but cut and paste is a fine tool. Does this description make sense to you? Or are we still a bit at cross purposes here? Ted --94eb2c047984f976a00538cbf52a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 29, 2016 at 12:37 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 29/07/16 16:54, Mirja K=C3=BChlewind wrote:
> Hi Stephen,
>
> I see registries as a needed and valuable part= of our standardization
> process. People ignoring registries as well as things that are
> explicitly specified in a standards document is a different problem.
Registries can be a useful way to support extensibility. They can also be a nuisance that allow for the promulgation of crazy ideas.
And probably lots in between and all at once;-)

None of the generalities above help in this specific case where I
remain convinced that any extensible-generic-PLUS is liable to be
highly dangerous. (And I'm unsure if a non-extensible-PLUS can be
usefully transport independent.)


So, it's not clear to me exactly what you mean by "transp= ort independent" here, so let me drill down a bit.=C2=A0 I think PLUS = is proposed for a set of transports that use the UDP demux (and thanks to S= tuart Cheshire for a useful shorthand for that function).=C2=A0 It expects = that those transports will integrity protect their transport headers and tr= eat as confidential some aspects of their state exchange (a multiplexing tr= ansport, for example, might decide that the state of the flows being multip= lexed should be confidential).=C2=A0 A PLUS with very limited semantics (st= art, stop, delay tolerant, drop tolerant) would likely be broadly applicabl= e to that class of transports and yet be transport independent (for that sp= ecific meaning of transport).

The = folks arguing for this have a set of concerns:=C2=A0

*) Some useful path elements are impaired now, compared = to previously.=C2=A0 How can we safely repair that impairment?=C2=A0 Where = safely means:=C2=A0 not restoring plaintext for inspection nor providing a = worse-than-current side channel for identification.=C2=A0 (I accept that an= alysing one against "current" requires understanding ease of atta= cking the side channel)

*) If there= is a new, popular transport protocol, how do we ensure that it does not en= d up as the new HTTP, used for a variety of things not because it is suitab= le on design fit but because it gets through the network?=C2=A0 To put this= another way, how do we make sure that the new design pattern given above o= pens innovation at that transport layer?

While the proponents of PLUS believe that a substrate approach is the= most deployable (because you can redefine things like SRTP to run over PLU= S instead of bare UDP), we care much more that the approach meets those con= cerns than the approach be a substrate.=C2=A0 If you want to call it a &quo= t;design pattern" and implement it in a couple of candidates from that= design pattern, fine.=C2=A0 You end up describing the thing multiple times= rather than once, but cut and paste is a fine tool.

Does this description make sense to you?=C2=A0 Or are we = still a bit at cross purposes here?

Ted

--94eb2c047984f976a00538cbf52a-- From nobody Fri Jul 29 13:40:50 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4949C12D88A for ; Fri, 29 Jul 2016 13:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Qfaq0XeWVIK1 for ; Fri, 29 Jul 2016 13:40:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4FA12D8AC for ; Fri, 29 Jul 2016 13:40:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7CE2EBE39; Fri, 29 Jul 2016 21:40:44 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_PVpakF09s9; Fri, 29 Jul 2016 21:40:42 +0100 (IST) Received: from [192.168.1.5] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 58399BE33; Fri, 29 Jul 2016 21:40:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469824842; bh=wQpnyIDPJir4M8iKdEyOY/HeASXWPERgcF4ZgoLxf5I=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=fbfnjUDMzlUN1UTeA+x4cZG0BY2J37I3/4eL6Cw92HeD4eLPII+Q/Qgbs+1xuUNqn fKNyNsclAPdhyqejLE3CO5oiy0ezzFIFLAUCIAMG7I83I9Z34A3d6Es9RYSEF6Xvyf jvpKUWB1nYNaooL2ofv4LHfrmULGVRISvnN8SNjg= To: Ted Hardie References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <205d99b2-4246-4a77-35f0-7c8a86a1ceed@cs.tcd.ie> Date: Fri, 29 Jul 2016 21:40:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040802080307010604050808" Archived-At: Cc: Brian Trammell , "privsec-program@iab.org" , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 20:40:49 -0000 This is a cryptographically signed message in MIME format. --------------ms040802080307010604050808 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 29/07/16 21:18, Ted Hardie wrote: > On Fri, Jul 29, 2016 at 12:37 PM, Stephen Farrell=20 > > wrote: >=20 >>=20 >> Hiya, >>=20 >> On 29/07/16 16:54, Mirja K=C3=BChlewind wrote: >>> Hi Stephen, >>>=20 >>> I see registries as a needed and valuable part of our=20 >>> standardization process. People ignoring registries as well as=20 >>> things that are explicitly specified in a standards document is a >>> different problem. >>=20 >> Registries can be a useful way to support extensibility. They can=20 >> also be a nuisance that allow for the promulgation of crazy ideas.=20 >> And probably lots in between and all at once;-) >>=20 >> None of the generalities above help in this specific case where I=20 >> remain convinced that any extensible-generic-PLUS is liable to be=20 >> highly dangerous. (And I'm unsure if a non-extensible-PLUS can be=20 >> usefully transport independent.) >>=20 >>=20 > So, it's not clear to me exactly what you mean by "transport=20 > independent" I guess I meant a future in which PLUS-defined PDUs are used as meta-data in/with various transport protocols. > here, so let me drill down a bit. I think PLUS is proposed for a set > of transports that use the UDP demux (and thanks to Stuart Cheshire > for a useful shorthand for that function). It expects that those > transports will integrity protect their transport headers and treat > as confidential some aspects of their state exchange (a multiplexing > transport, for example, might decide that the state of the flows > being multiplexed should be confidential). A PLUS with very limited > semantics (start, stop, delay tolerant, drop tolerant) would likely > be broadly applicable to that class of transports and yet be > transport independent (for that specific meaning of transport). If plus were limited to only emitting those signals then I'd be far less concerned. I think that would mean that there is no need for any extensibility and hence no registry. I do not claim to know if those and only those signals would be sufficiently useful to be adopted by transport protocols and implementations thereof. >=20 > The folks arguing for this have a set of concerns: >=20 > *) Some useful path elements are impaired now, compared to=20 > previously. FYI, I find the term "impaired" scarily vague in this context. It could mean anything from "0.1% less reliable" to "no longer allows me assert that the person using the machine is over 18." That lack of specificity and the absence iiuc of public data describing the claimed impairments damages the argument of the PLUS proponents here. > How can we safely repair that impairment? That depends on what is considered impairment and without a shared idea of that I don't think we can get to an answer. > Where safely means: not restoring > plaintext for inspection nor providing a worse-than-current side=20 > channel for identification. (I accept that analysing one against=20 > "current" requires understanding ease of attacking the side channel) >=20 > *) If there is a new, popular transport protocol, how do we ensure=20 > that it does not end up as the new HTTP, used for a variety of things > not because it is suitable on design fit but because it gets through > the network?=20 (Aside: if new transports are as successful as http, then we're making progress I think:-) > To put this another way, how do we make sure that the > new design pattern given above opens innovation at that transport > layer? >=20 > While the proponents of PLUS believe that a substrate approach is the > most deployable (because you can redefine things like SRTP to run > over PLUS instead of bare UDP), we care much more that the approach > meets those concerns than the approach be a substrate. If you want > to call it a "design pattern" and implement it in a couple of > candidates from that design pattern, fine. You end up describing the > thing multiple times rather than once, but cut and paste is a fine > tool. I agree with your last there. I actually think cut'n'paste is likely a better approach here - it means that one can evaluate the essential signals in each case, whereas the substrate/shim approach requires that one has that dangerous extensibility. And for what real value? >=20 > Does this description make sense to you? Or are we still a bit at=20 > cross purposes here? Aside from the vagueness in "impairment" I think I understand it yes. (And this may be a thing where it's possible to not be talking at cross purposes and yet still disagree as to whether there ought be any path forward at all for PLUS.) Cheers, S. >=20 > Ted >=20 >=20 >=20 > _______________________________________________ Privsec-program=20 > mailing list Privsec-program@iab.org=20 > https://www.iab.org/mailman/listinfo/privsec-program >=20 --------------ms040802080307010604050808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3Mjky MDQwNDJaMC8GCSqGSIb3DQEJBDEiBCASD1rjuKe3P1OF9IbHPzHr9KB8njtq9QZf0vOUs+ct LTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCgryS3VK4jYnkDUb4IHWpdwE98uL8m70e6icfq2sXJ6gMakwj6BhB/ w/5Nk3K5SjFkFa3nY+ZsDfxmM3iU2NAz18YA1eQSEsuzA7OhfCcEtjCJn5e9fWB8o4nZRmLk CMhHGtfUlXo/EgyCW2vJPAfzVImkORqVVTIsCeOsoEch5+lMMhArKC7KBsHEFnq/evYCkrK/ I/3FVNIpB8bTEXp1vEE28DSu5kVwNmK4Z5QjyLczGo3nrkrPVAFk4nLtBtkmP9BrqLS6AALf Z7mAIdxiqvrvmPMmFue0TtZQUmvxo66WWLjmwutz41wBDqu7mMkDmY8qKN5OzZ2P0XfZF8yj AAAAAAAA --------------ms040802080307010604050808-- From nobody Fri Jul 29 14:14:59 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A3A12D5FC for ; Fri, 29 Jul 2016 14:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 X2JAq3tuNVCZ for ; Fri, 29 Jul 2016 14:14:52 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 9BCFB12D531 for ; Fri, 29 Jul 2016 14:14:52 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id l65so122641648oib.1 for ; Fri, 29 Jul 2016 14:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l8njyNMulQn69BMMwp1BKkoudQmIxbpTnBFQLhdLusI=; b=jt4RvwpW4gZMoyn3G/wybpU8H3tJlan7P0ozIckbFS1V7Xw68FAPTvbbxvDPOtjZQi 2ciedOGAG/rUyRDoEp06mqRNMGwLxU7d8E1sxzy1jsDsyzO9gIbkiv9049TV1vgs7seZ 7vFppxrt4QQSq5nJ/6m189BPQKCAsWItYB4b//DUFPtXIpQI/6x0G7CTe2g2CUNnweld ftEWR9meuIkpwSh/nuN7k2HcapsKGtUb94esLEjLD8glAepjHGQl3BgkFEZFkXSaQvcC r8ZGDoSr1gzaCPo5gbs/qfHVPnHkASNmUFq7aZn8MusoYztQYGetJqHaMaBi0kbzj44A zGhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l8njyNMulQn69BMMwp1BKkoudQmIxbpTnBFQLhdLusI=; b=C/RXf69M1/QSCcmyF/C2DzxrO/wwqPIJUfeX+n7Ugozu4xr8fQwM4/Vpgstvi4pc97 y/g3W6Pfoxlw6wGCz9M+6YEBWi/6w9cBFd9Y6B+MfKiXwf+Nwyg3YlkyxVsbmh+kj0iZ xYJ06pAlgBRK4xnRloDRPamr82aZNJaE9aOEMBT++YCbGJ7W0aw4PtQ521S0jsgmwa6m dvPBDP6d7YGk01p8EE018N8L/1RVLtOs14+l8Ur3PGBIvRbfKkHppF1vCRNqJs40Pq3i sghscWYdNU8H2VVcj8vI8wvX3KCASPS8kVzGy/zEx+MssKZuay2qDWNlN0Hp+UDzPQHJ 0vvQ== X-Gm-Message-State: AEkoouvq4GoP1dGUdspHlBGGd5mOwxuwpovoj6u/7+GKB7So+xFUhfKHCrVPqwguQTlDzmZZxZ5k85ssqtFEjg== X-Received: by 10.202.68.6 with SMTP id r6mr26245296oia.53.1469826891964; Fri, 29 Jul 2016 14:14:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.222.213 with HTTP; Fri, 29 Jul 2016 14:14:22 -0700 (PDT) In-Reply-To: <205d99b2-4246-4a77-35f0-7c8a86a1ceed@cs.tcd.ie> References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <205d99b2-4246-4a77-35f0-7c8a86a1ceed@cs.tcd.ie> From: Ted Hardie Date: Fri, 29 Jul 2016 14:14:22 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113d6f46c6eb2f0538ccbd27 Archived-At: Cc: Brian Trammell , "privsec-program@iab.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 21:14:55 -0000 --001a113d6f46c6eb2f0538ccbd27 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 29, 2016 at 1:40 PM, Stephen Farrell wrote: > > Hiya, > > > > > The folks arguing for this have a set of concerns: > > > > *) Some useful path elements are impaired now, compared to > > previously. > > FYI, I find the term "impaired" scarily vague in this context. It could > mean anything from "0.1% less reliable" to "no longer allows me assert > that the person using the machine is over 18." That lack of specificity > and the absence iiuc of public data describing the claimed impairments > damages the argument of the PLUS proponents here. > > The specific impairments vary over the type of network, but the class is "consume more resources than previously". Resources here can be radio bandwidth, power from a total radio power budget, delay intolerant queue slots, state table size, and so on. Note that these impairments have implications for the end systems as well, as the hoary example of UDP heartbeat traffic and NAT state shows. > > How can we safely repair that impairment? > > That depends on what is considered impairment and without a shared idea > of that I don't think we can get to an answer. > > Does the class given above help? > > Where safely means: not restoring > > plaintext for inspection nor providing a worse-than-current side > > channel for identification. (I accept that analysing one against > > "current" requires understanding ease of attacking the side channel) > > > > *) If there is a new, popular transport protocol, how do we ensure > > that it does not end up as the new HTTP, used for a variety of things > > not because it is suitable on design fit but because it gets through > > the network? > > (Aside: if new transports are as successful as http, then we're making > progress I think:-) > > QUIC has that potential, if the race against HTTP/2 tests so far are any guide. > To put this another way, how do we make sure that the > > new design pattern given above opens innovation at that transport > > layer? > > > > While the proponents of PLUS believe that a substrate approach is the > > most deployable (because you can redefine things like SRTP to run > > over PLUS instead of bare UDP), we care much more that the approach > > meets those concerns than the approach be a substrate. If you want > > to call it a "design pattern" and implement it in a couple of > > candidates from that design pattern, fine. You end up describing the > > thing multiple times rather than once, but cut and paste is a fine > > tool. > > I agree with your last there. I actually think cut'n'paste is likely > a better approach here - it means that one can evaluate the essential > signals in each case, whereas the substrate/shim approach requires > that one has that dangerous extensibility. And for what real value? > > I'm not sure that the substrate/shim approach does require dangerous extensibility; if we limit it to get what's needed, we may avoid the danger. And the value is the usual: common libraries, common APIs, and common understandings of the threat model. > > > > Does this description make sense to you? Or are we still a bit at > > cross purposes here? > > Aside from the vagueness in "impairment" I think I understand it yes. > (And this may be a thing where it's possible to not be talking at > cross purposes and yet still disagree as to whether there ought be > any path forward at all for PLUS.) > > regards, Ted > Cheers, > S. > > > > > > Ted > > > > > > > > _______________________________________________ Privsec-program > > mailing list Privsec-program@iab.org > > https://www.iab.org/mailman/listinfo/privsec-program > > > > --001a113d6f46c6eb2f0538ccbd27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 29, 2016 at 1:40 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

>
> The folks arguing for this have a set of concerns:
>
> *) Some useful path elements are impaired now, compared to
> previously.

FYI, I find the term "impaired" scarily vague in this cont= ext. It could
mean anything from "0.1% less reliable" to "no longer allows= me assert
that the person using the machine is over 18." That lack of specificit= y
and the absence iiuc of public data describing the claimed impairments
damages the argument of the PLUS proponents here.


The specific i= mpairments vary over the type of network, but the class is "consume mo= re resources than previously".=C2=A0 Resources here can be radio bandw= idth, power from a total radio power budget, delay intolerant queue slots, = state table size, and so on.=C2=A0 Note that these impairments have implica= tions for the end systems as well, as the hoary example of UDP heartbeat tr= affic and NAT state shows.
=C2=A0
> How can we safely repair that impairment?

That depends on what is considered impairment and without a shared i= dea
of that I don't think we can get to an answer.

Does the class given above he= lp?

=C2=A0
> Where safely means:=C2=A0 not restoring
> plaintext for inspection nor providing a worse-than-current side
> channel for identification.=C2=A0 (I accept that analysing one against=
> "current" requires understanding ease of attacking the side = channel)
>
> *) If there is a new, popular transport protocol, how do we ensure
> that it does not end up as the new HTTP, used for a variety of things<= br> > not because it is suitable on design fit but because it gets through > the network?

(Aside: if new transports are as successful as http, then we're = making
progress I think:-)

=C2=A0
QUIC has= that potential, if the race against HTTP/2 tests so far are any guide.
=
> To put this another way, how do we make sure that the
> new design pattern given above opens innovation at that transport
> layer?
>
> While the proponents of PLUS believe that a substrate approach is the<= br> > most deployable (because you can redefine things like SRTP to run
> over PLUS instead of bare UDP), we care much more that the approach > meets those concerns than the approach be a substrate.=C2=A0 If you wa= nt
> to call it a "design pattern" and implement it in a couple o= f
> candidates from that design pattern, fine.=C2=A0 You end up describing= the
> thing multiple times rather than once, but cut and paste is a fine
> tool.

I agree with your last there. I actually think cut'n'paste i= s likely
a better approach here - it means that one can evaluate the essential
signals in each case, whereas the substrate/shim approach requires
that one has that dangerous extensibility. And for what real value?

I'm not sure that the sub= strate/shim approach does require dangerous extensibility; if we limit it t= o get what's needed, we may avoid the danger.=C2=A0 And the value is th= e usual:=C2=A0 common libraries, common APIs, and common understandings of = the threat model.=C2=A0
=C2=A0
>
> Does this description make sense to you?=C2=A0 Or are we still a bit a= t
> cross purposes here?

Aside from the vagueness in "impairment" I think I underst= and it yes.
(And this may be a thing where it's possible to not be talking at
cross purposes and yet still disagree as to whether there ought be
any path forward at all for PLUS.)


regards,

Ted
=C2= =A0
Cheers,
S.


>
> Ted
>
>
>
> _______________________________________________ Privsec-program
> mailing list Privsec-progra= m@iab.org
> https://www.iab.org/mailman/listinfo/priv= sec-program
>


--001a113d6f46c6eb2f0538ccbd27-- From nobody Fri Jul 29 14:23:30 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E875112D86F; Fri, 29 Jul 2016 14:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 XfZ8XkbIYU7b; Fri, 29 Jul 2016 14:23:28 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 E3C0E12D798; Fri, 29 Jul 2016 14:23:28 -0700 (PDT) Received: from [128.9.184.41] ([128.9.184.41]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6TLM6O3003747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 Jul 2016 14:22:09 -0700 (PDT) To: Brian Trammell , Stephen Farrell References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> From: Joe Touch Message-ID: <579BC8FC.2000005@isi.edu> Date: Fri, 29 Jul 2016 14:22:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 21:23:30 -0000 On 7/29/2016 9:22 AM, Brian Trammell wrote: > hi Stephen, > >> Hi Brian, >> >> On 29/07/16 13:33, Brian Trammell wrote: >>> Greetings, all, >>> >>> During the PLUS BoF last week, concern was expressed that a generic >>> signaling mechanism such as proposed opened two new attack surfaces: >> ... > Agreed that the analysis isn't where I'd like it to be yet. There are two major reasons for this. One, this draft is focused on in-band abuse of TCP and IP features (which seemed a good place to start) I don't think it is. A user who doesn't want this sort of vulnerability inside the messages they send needs to use integrity protection at least (perhaps also encryption). A user cannot prevent vulnerabilities in layers they can't control (e.g., along a tunnel used along a subset of the path). It's not productive to try to analyze the weaknesses of protocols that are not designed to be strong. They're weak. Move on, IMO. The alternative is "hey, it's weak - we should make it strong". Doing that ends up violating the Postel Principle. I.e., behaviors that are otherwise legitimate are suddenly interpreted as deliberate and malicious attacks when they were never specified as such. That's not helpful, IMO. Joe From nobody Fri Jul 29 14:40:05 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92ACD12D534 for ; Fri, 29 Jul 2016 14:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=no 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 iLK5hi6rZlJt for ; Fri, 29 Jul 2016 14:39:57 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5221812D112 for ; Fri, 29 Jul 2016 14:39:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 73B44D930C; Fri, 29 Jul 2016 23:39:55 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iES9mwsRc5TT; Fri, 29 Jul 2016 23:39:55 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2F34.dip0.t-ipconnect.de [93.236.47.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E6D9ED9304; Fri, 29 Jul 2016 23:39:54 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 29 Jul 2016 23:39:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 21:40:00 -0000 Hi Stephen, while I personally think that a good protocol design should be = extensible because that=E2=80=99s the lesson we learnt over many years = now (see draft-iab-protocol-transitions-02), I guess we simply have = different opinions here and should leave it stand like this. One point I want to clarify (as you asked for it): > Well, no, PLUS is not a proposal to do that iiuc - PLUS is a proposal > to expose some information when such encryption is being done as > defined by some other specification which is not PLUS. If my take > there is wrong, I'd appreciate being corrected. There are two aspects here: 1) PLUS requires the encryption context from the transport protocol. As = PLUS is not a transport protocol in itself, it e.g. cannot provide = reliable transmission, which also means it cannot negotiate any = encryption context in its own. That means it must use information given = from the transport protocol above. If the transport used does not have = any of these feature, we have to have another layer in between, namely = DTLS. 2) PLUS is a proposal to enable encryption of transport headers because = it is just not possible today to encrypt your transport header as it is. = Encryption of the TCP header was discussed in tcpinc and decided to not = do it because it would cause deployment problem. The minimum you have to = do to encrypt your transport header is encapsulation in UDP. However, = especially on port 80 this still can lead to blocking. Future providing = some information that helps firewalls to make decisions about which = traffic is legitimate vs. attack traffic, is necessary to at least = maintain the level of security that we have today. As you said in your mail to Ted, it is hard to decide now what the right = set of information is, and my personal opinion is that if we make a = decision now and provide no way to change anything later, we can just be = wrong. However, which information should be exposed (when, how and how often) = are questions for a wg, as well as any decision on extensibility or not. Mirja > Am 29.07.2016 um 21:37 schrieb Stephen Farrell = : >=20 >=20 > Hiya, >=20 > On 29/07/16 16:54, Mirja K=C3=BChlewind wrote: >> Hi Stephen, >>=20 >> I see registries as a needed and valuable part of our standardization >> process. People ignoring registries as well as things that are >> explicitly specified in a standards document is a different problem. >=20 > Registries can be a useful way to support extensibility. They can > also be a nuisance that allow for the promulgation of crazy ideas. > And probably lots in between and all at once;-) >=20 > None of the generalities above help in this specific case where I > remain convinced that any extensible-generic-PLUS is liable to be > highly dangerous. (And I'm unsure if a non-extensible-PLUS can be > usefully transport independent.) >=20 >>=20 >>=20 >> To answer your question below: >>=20 >>>>=20 >>>> 2) Further only PLUS provides an additional function that allows >>>> to detect any mangling of data/bits that was not intended. This >>>> is urgently needed because all the TCP (and higher) layer >>>> mangling we see today is the root cause for the problem we have >>>> right now. >>>=20 >>> I don't get your point (2) sorry. Can you explain more? >>=20 >> We explained this in the BoF and I believe I made this point very >> clear in my last mail that I replied to Kyle. But let me state this >> bit again, because it=E2=80=99s important. >>=20 >> Today, there are a large amount of bits a middlebox can mangle with >> (as described in draft-trammell-privsec-defeating-tcpip-meta which is >> not even exhaustive). Most of the described ways to insert >> information into a packet are not detectable, at least most of the >> ways described for TCP because all information is in cleartext and >> the receiver does not know what the sender has originally sent while >> the mangled information still allows proper operation. >=20 > The above is clear, thanks. And is what I got from the BoF too. >=20 >> What we propose is to a) encrypt all bits in the transport/TCP >> header,=20 >=20 > Well, no, PLUS is not a proposal to do that iiuc - PLUS is a proposal > to expose some information when such encryption is being done as > defined by some other specification which is not PLUS. If my take > there is wrong, I'd appreciate being corrected. >=20 > I would have far less of an issue if e.g. QUIC or other transports > defined in a transport-specific and non-extensible manner how the > few bits of information that might be desirable for the path can be > outside the confidentiality envelope. >=20 > I can totally see how some architectural guidance and examples of > the sometimes-subtle threats caused by exposing information were to > be developed. PLUS however seems to be proposing to go beyond that > and to define PDUs, which I think I'm nearly convinced is a bad plan > and a path down which it may be better to not start. >=20 >> b) provide less bits in a PLUS header, that have been >> carefully evaluated towards risks that we know today (but didn=E2=80=99= t know >> when we designed TCP), and c) a MAC that hashes all information >> provided in the PLUS header to be able to detect mangling by the >> receiver (which can inform then the sender using an encrypted >> channel). This also means that the endpoint has the choice to not use >> PLUS (or any PLUS information fields) if mangling is detected. >>=20 >> All these points together, especially point c, makes the situation >> compared to what we have today better and not worse! >=20 > I get that that's the argument for PLUS. I remain unconvinced by > that argument for the reasons stated earlier. >=20 > Cheers, > S. >=20 >=20 >>=20 >> Mirja >>=20 >>=20 >>=20 >>=20 >>> Am 29.07.2016 um 17:17 schrieb Stephen Farrell >>> : >>>=20 >>>=20 >>> Hiya, >>>=20 >>> On 29/07/16 15:48, Mirja K=C3=BChlewind wrote: >>>> Hi Stephen, >>>>=20 >>>> I believe that what you think PLUS is, is not what we propose. >>>=20 >>> I'm pretty sure that's true - and is part of what puzzles me as I >>> said before. >>>=20 >>>> Maybe we did not make a great job so far to define PLUS narrowly >>>> enough but we believe the actual protocol specification work >>>> should be done in a wg to ensure that a broad community can >>>> participate, and all concern, including privacy concerns, can be >>>> addressed. >>>=20 >>> I get that. Some folks however (and I'm not sure if I'd count >>> myself amongst them yet or not) fear that any such WG has to end up >>> as very privacy unfriendly if it remains transport agnostic. From >>> that perspective, starting a WG would not make sense. >>>=20 >>>>=20 >>>> The point of draft-trammell-privsec-defeating-tcpip-meta is to=20 >>>> further explain that the things you describe as risks are >>>> nothing new. And by new, we mean they are even standard-conform; >>>> because this is the main point of your concern if I understand >>>> you correctly, right? >>>=20 >>> No. Brian's draft doesn't touch on the "over 18" type threat at all >>> as I read it, so I don't accept the idea that the hypercookie is >>> the right place from which to start to analyse the set of threats >>> in this space. >>>=20 >>> And there is IMO a real difference between our current/old set of >>> protocols allowing bad behaviours vs. us defining a new protocol to >>> explicitly enable those same bad behaviours. (It could be that not >>> all of us agree that that is a real difference.) >>>=20 >>>>=20 >>>> I assume your point is that we propose a protocol that is >>>> intended to signal information from middleboxes to the endpoint >>>> (amongst other features). I assume this based on the following >>>> statement you made: >>>>=20 >>>>> Should we standardise a method for such abuse, then I think >>>>> it's quite possible the attacker may argue that their behaviour >>>>> is not an attack as it's just a part of "the standard.=E2=80=9C >>>>=20 >>>> and >>>>=20 >>>>> And to the extent that PLUS could enable and standardise such=20 >>>>> things, that is, for me, a major reason to oppose PLUS. >>>>=20 >>>> Otherwise can you please further explain what you mean by =E2=80=9Esu= ch=20 >>>> abuse=E2=80=9C and =E2=80=9Esuch things=E2=80=9C? >>>=20 >>> Sorry I don't get the question. (That is, I'm not clear if I do or >>> do not agree with your assumptions, which are not clear to me;-) >>>=20 >>>>=20 >>>> If the thing you are concerned about in PLUS is, that we propose >>>> to standardize =E2=80=9Aoption=E2=80=98 space that explicitly = allows middleboxes >>>> to add information to a packet, I guess you know that it is >>>> possible to define an experimental TCP option (in the ISE stream) >>>> without IESG approval that allows the insertion of private >>>> information by middleboxes. Even thought TCP options are not >>>> intended to be altered by network nodes, there is also no >>>> standard that forbids this. >>>=20 >>> I am not arguing for a "MINUS" (a TBD acronym that'd be the >>> antithesis of PLUS:-). >>>=20 >>>>=20 >>>> Let me say two things about what we ACTUALLY propose with PLUS: >>>> 1) We do NOT propose to add space to add arbitrary information. >>>> The semantic of the field must be well-defined in an IESG >>>> approved RFC and registered respectively. >>>=20 >>> IMO that is not sufficient to allay my concern about "over 18" and=20= >>> the like. If we build it (the registry) then they will come (and >>> ask for or squat on code points with horrible semantics). I can't >>> see any way to avoid that other than never creating such a >>> registry. >>>=20 >>>> This will not only make it not-standard conform to use such a >>>> field for something different, it also restrict the set of valid >>>> values which then could even be checked by later middleboxes on >>>> the path, and erased if needed. >>>=20 >>> Sure. But I remain convinced that any registry here is too >>> dangerous and the above doesn't convince me otherwise. >>>=20 >>>> 2) Further only PLUS provides an additional function that allows >>>> to detect any mangling of data/bits that was not intended. This >>>> is urgently needed because all the TCP (and higher) layer >>>> mangling we see today is the root cause for the problem we have >>>> right now. >>>=20 >>> I don't get your point (2) sorry. Can you explain more? >>>=20 >>>>=20 >>>> Further, I would like to say that not all middlebox mangling is=20 >>>> automatically bad or an attack. >>>=20 >>> Of course. And I did not say that. I said that there are some bad >>> behaviours in this space and we need to worry about us maybe=20 >>> legitimising those. >>>=20 >>>> If we don=E2=80=99t provide a standardized way to communicate with >>>> middleboxes, it will be even harder to distinguish an attack from >>>> something that actually supports the network service provided or >>>> even makes the services possible at all. Without standardization >>>> there is no control at all. I don=E2=80=99t think we can ignore = what=E2=80=99s >>>> already happening the Internet any further and providing >>>> standardized mechanisms to support the good in-network functions >>>> is the only way to improve security for these functions. >>>=20 >>> The above text seems indicative of understandable exasperation but=20= >>> I don't see how it's very useful for the discussion. >>>=20 >>>>=20 >>>> To make this even more clear, you wrote: >>>>> the argument seems to ignore the downsides of standardising >>>>> and thus legitimising "bad" behaviour including behaviours that >>>>> your draft properly calls an attack. >>>>=20 >>>> We not at all want to legitimate =E2=80=9Ebad=E2=80=9C behavior and = I really >>>> don=E2=80=99t know why you think that what we propose would do so. >>>=20 >>> Sigh. I didn't personalise this (I hope! Apologies if I did by=20 >>> mistake) so I wasn't at all discussing what you or anyone wants or=20= >>> doesn't want. It is entirely possible to have good motivation for=20 >>> something that may have quite bad side-effects. >>>=20 >>> And I still think that the arguments made by proponents of PLUS are >>> ignoring the downsides. (And I do not mean that the people making >>> those arguments are ignoring those downsides which would be a >>> different statement.) >>>=20 >>>> We propose to standardize a protocol that allows middleboxes to >>>> provide information they have been requested for (by the >>>> endhost). This information is well define and under IESG >>>> approval. Any other use of such a protocol will not be >>>> standard-conform and as bad as the misuse we can see today with >>>> existing protocols. >>>=20 >>> I think that just repeats earlier statements. >>>=20 >>> S. >>>=20 >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>=20 >>>>> Am 29.07.2016 um 15:23 schrieb Stephen Farrell=20 >>>>> : >>>>>=20 >>>>>=20 >>>>> Hi Brian, >>>>>=20 >>>>> On 29/07/16 13:33, Brian Trammell wrote: >>>>>> Greetings, all, >>>>>>=20 >>>>>> During the PLUS BoF last week, concern was expressed that a=20 >>>>>> generic signaling mechanism such as proposed opened two new=20 >>>>>> attack surfaces: >>>>>=20 >>>>> No necessarily "opened...new" perhaps more "risked making much >>>>> more ubiquitous." At the meeting I didn't hear anyone claim >>>>> these were new attacks. (I did hear you say they were not >>>>> new.) >>>>>=20 >>>>>>=20 >>>>>> (1) A method for endpoints to allow path elements to add=20 >>>>>> non-integrity protected signals presents a surface for >>>>>> metadata injection attacks, where an entity who can place >>>>>> devices on a user's access network and has information about >>>>>> the user's identity could exfiltrate that information to >>>>>> third parties. For purposes of giving it a name, let's call >>>>>> this a hypercookie injection attack ("hyper" since it exists >>>>>> in a space completely inaccessible to the application). >>>>>>=20 >>>>>> (2) Even if path elements are not allowed to say anything, a >>>>>> mechanism to allow endpoints to add integrity-protected >>>>>> signals to their traffic presents a surface for coercion >>>>>> attacks. An access provider can force a user to tag traffic >>>>>> with their user ID or some other token (a signed assertion >>>>>> that an advertisement has been viewed to the end, or maybe >>>>>> even just straight-up bitcoins) in order to get "better" >>>>>> connectivity, or even any connectivity at all. A more >>>>>> classically Orwellian dystopian variant of this attack has a >>>>>> government requiring citizens to tag all their outgoing >>>>>> traffic with some government-issued identifier. Let's call >>>>>> this a hypercookie coercion attack. >>>>>>=20 >>>>>> I am less concerned about the surface PLUS presents to these=20 >>>>>> attacks than those who have raised the concerns in the BoF >>>>>> and on the mailing list, because the current Internet >>>>>> architecture is already quite vulnerable to them. As I said >>>>>> during my presentation last Thursday, Ted Hardie and I sat >>>>>> down to think about this at lunch a couple of months ago, and >>>>>> found six ways one could execute hypercookie injection or >>>>>> coercion today before our pizza showed up. >>>>>=20 >>>>> Wrt injection I can buy that totally. Having read your draft I=20 >>>>> don't find enough there to accept your assertion wrt coercion >>>>> - ISTM that coercion attacks have not been analysed yet in >>>>> your draft. >>>>>=20 >>>>> As a side-note, meta-data doesn't have to be person-specific to >>>>> be controversial - "over 18" and anything with similar >>>>> semantics, e.g. "member of minority" can very clearly be >>>>> equally or more damaging, yet totally non-identifying if the >>>>> relevant set of folks is large enough. So I wonder if the >>>>> "hypercookie" concept is even the right starting point here. >>>>> And to the extent that PLUS could enable and standardise such >>>>> things, that is, for me, a major reason to oppose PLUS. (That's >>>>> a side-note for this email, but perhaps a quite fundamental >>>>> thing to consider in the overall discussion.) >>>>>=20 >>>>>>=20 >>>>>> I sat down a little longer to write these up. I found five >>>>>> more, without even considering trivial out-of-band metadata >>>>>> leaks or steganographic side channels.=20 >>>>>> = https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta-00= >>>>>>=20 >>>>>>=20 >>>=20 >>>>>>=20 > is the result. The conclusion: these attacks are trivially easy to >>>>>> execute today by exploiting the gap between valid TCP >>>>>> traffic and what will be ignored by TCP-indifferent devices >>>>>> and endpoints, as well as all those juicy bits IPv6 gives >>>>>> you. Unless we're willing to rely on the widespread, >>>>>> altruistic deployment of stateful TCP firewalls to reject >>>>>> traffic (I think we can use our experience with BCP38 as >>>>>> guidance as to how well *that* will work, and in any case I >>>>>> think it would be kind of rich for me of all people to >>>>>> recommend throwing more TCP-meddling middleboxes into the >>>>>> mix) the only way I can see out is to add integrity=20 >>>>>> protection to all transport and network-layer headers, as >>>>>> well as confidentiality protection to those headers the path >>>>>> does not need to see. >>>>>=20 >>>>> I don't agree. Observatories seem to me like a mitigation that >>>>> your draft does not consider. If the attacker here does not >>>>> want to be seen to be attacking, then those can be effective. >>>>> Should we standardise a method for such abuse, then I think >>>>> it's quite possible the attacker may argue that their behaviour >>>>> is not an attack as it's just a part of "the standard." >>>>>=20 >>>>> Such a mitigation could be attempted against the attack in >>>>> 4.1.3 of your draft for example so I disagree with the draft's >>>>> assertion that "no user-initiated mitigation is possible" in >>>>> that case at least and maybe others. >>>>>=20 >>>>> I think it'd be a fine thing to see further analysis of the=20 >>>>> attacks and potential mitigations as your draft develops. >>>>>=20 >>>>>>=20 >>>>>> This is, of course, the whole point of PLUS. We can and >>>>>> should have a discussion of what the endpoints should be able >>>>>> to say, and what the endpoints should be able to let the path >>>>>> say. But if we're concerned about this attack, the general >>>>>> approach is AFAICT the only way out. >>>>>=20 >>>>> I disagree. And I think it was clear that a whole bunch of >>>>> folks in the room last week also clearly disagreed. >>>>>=20 >>>>> I believe your "only way out" conclusion isn't logically >>>>> justified as the argument seems to ignore the downsides of >>>>> standardising and thus legitimising "bad" behaviour including >>>>> behaviours that your draft properly calls an attack. >>>>>=20 >>>>> Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that we >>>>> have different sets of sensible folks reaching diametrically >>>>> opposed conclusions based on the same facts and arguments. >>>>> Perhaps the tl;dr in your abstract may be a hint there - I do >>>>> not think everything is ruined myself, so maybe one's level of >>>>> opt/pess-imism affects one's view of the valid conclusions to >>>>> reach in this space. >>>>>=20 >>>>> Cheers, S. >>>>>=20 >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Privsec-program mailing list Privsec-program@iab.org=20 >>>>>> https://www.iab.org/mailman/listinfo/privsec-program >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ Spud mailing >>>>> list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud >>>>=20 >>>=20 >>> _______________________________________________ Spud mailing list=20 >>> Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud >>=20 >> _______________________________________________ Privsec-program >> mailing list Privsec-program@iab.org=20 >> https://www.iab.org/mailman/listinfo/privsec-program >>=20 >=20 From nobody Fri Jul 29 16:37:51 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857F312D956 for ; Fri, 29 Jul 2016 16:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 NpvB2B2BCgjT for ; Fri, 29 Jul 2016 16:37:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DB712D95F for ; Fri, 29 Jul 2016 16:37:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 92EC0BDF9; Sat, 30 Jul 2016 00:37:39 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hxc5mMjAMbNE; Sat, 30 Jul 2016 00:37:34 +0100 (IST) Received: from [192.168.1.5] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B1275BE3E; Sat, 30 Jul 2016 00:37:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469835454; bh=iMkY+rKsUAnccpChxAOptqaC5w4tYai9oCanp0EPmoY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=OJxxj7xaz1V2Ar2CyXyiqiatY+159jTM+/IGCK2el8AHFQsy+jIs/f1K3FbS7imqM 5uvccmLImrqfsE4AMM8MJoZhYjb61RPP3sd3OI44JZUTTpYNLHbv/0fyaoAKTxkj2F 2sw6dJfdIs2+Bnw6lnX4ZdjfeDFozwrN32D5m+3w= To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> Date: Sat, 30 Jul 2016 00:37:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000301070104020801010008" Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 23:37:46 -0000 This is a cryptographically signed message in MIME format. --------------ms000301070104020801010008 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 29/07/16 22:39, Mirja K=C3=BChlewind wrote: > Hi Stephen, >=20 > while I personally think that a good protocol design should be > extensible because that=E2=80=99s the lesson we learnt over many years = now > (see draft-iab-protocol-transitions-02), I guess we simply have > different opinions here and should leave it stand like this. Actually that's an interesting topic. For example the extent to which TLS ciphersuite's (lack of) structure influenced how we have now ended up with ~350 entries in that registry; the same actually goes for TLS extensions which have a truly horrible history (do you know the one about the extension just to ensure the ClientHello is not over N and less than M bytes? (Sorry, I forget the values of N and M, but it's hilarious;-)... and the impact of all that on the (in)security of the Internet... is something that could be the topic of an interesting, (if quite astoundingly arcane:-) debate. I also recall debates about how to usefully allow yet constrain extensibility in h2. Both TLS and HTTP are important protocols and the arguments for and against extensibility involved are I think quite tricky. I did btw take a quick flick over the IAB draft you mention above and I have to say I reckon it needs a lot of work - "Design for extensibility so that things can be fixed up later" is IMO almost nonsense, at least as (so baldly) stated. In this particular case, I think there is a very strong set of arguments for extremely constrained or no extensibility, perhaps even to the point of not even starting the work at all. >=20 > One point I want to clarify (as you asked for it): >=20 >> Well, no, PLUS is not a proposal to do that iiuc - PLUS is a >> proposal to expose some information when such encryption is being >> done as defined by some other specification which is not PLUS. If >> my take there is wrong, I'd appreciate being corrected. >=20 > There are two aspects here: >=20 > 1) PLUS requires the encryption context from the transport protocol. > As PLUS is not a transport protocol in itself, it e.g. cannot provide > reliable transmission, which also means it cannot negotiate any > encryption context in its own. That means it must use information > given from the transport protocol above. If the transport used does > not have any of these feature, we have to have another layer in > between, namely DTLS. The phrase "namely DTLS" makes it sound like there is a protocol proposal somewhere about. Is that the case? I don't think it helps the argument for PLUS to say "a WG should decide that" myself but I do understand the tactical logic that might quite reasonably end up with folks taking that kind of approach. (IOW, I think that the PLUS BoF would have had a better chance of success had there been a specific protocol starting point proposed but I understand the reasons why the proponents might have decided otherwise.) >=20 > 2) PLUS is a proposal to enable encryption of transport headers > because it is just not possible today to encrypt your transport > header as it is.=20 I think the above sentence isn't helpful. IPsec exists after all. And while I'm not arguing that IPsec is any part of the answer here (if there even exists an answer to whatever questions are being asked), I do think that it's important in this kind of discussion to be very careful with how we describe things. (Sorry for the quibble, but the point at issue is whether the PLUS proponents are or are not correct in concluding that the kind of design for which you are arguing is or is not necessary.) > Encryption of the TCP header was discussed in tcpinc > and decided to not do it because it would cause deployment problem. > The minimum you have to do to encrypt your transport header is > encapsulation in UDP. However, especially on port 80 this still can > lead to blocking. Future providing some information that helps > firewalls to make decisions about which traffic is legitimate vs. > attack traffic, is necessary to at least maintain the level of > security that we have today. There are far too many statements in the above that claim certainty in an uncertain world for my tastes. >=20 > As you said in your mail to Ted, it is hard to decide now what the > right set of information is, and my personal opinion is that if we > make a decision now and provide no way to change anything later, we > can just be wrong. Sure. But we could be wrong to even start that process, if it leads to the "over 18" problem down the road. I also note that I have yet to see any of the proponents of PLUS accept that that is a real problem with any extensible proposal in this space. That lack of acknowledgement of a real issue seems odd. (Apologies if I missed such an ack or if it preceded my interest in this topic.) >=20 > However, which information should be exposed (when, how and how > often) are questions for a wg, as well as any decision on > extensibility or not. I don't agree. The charter text that was input to the BoF was very specific that there would be a registry, and hence extensibility. I think that is sufficient reason to oppose the creation of a WG for this topic, for reasons already explained. Cheers, S. >=20 > Mirja >=20 >=20 >> Am 29.07.2016 um 21:37 schrieb Stephen Farrell >> : >>=20 >>=20 >> Hiya, >>=20 >> On 29/07/16 16:54, Mirja K=C3=BChlewind wrote: >>> Hi Stephen, >>>=20 >>> I see registries as a needed and valuable part of our >>> standardization process. People ignoring registries as well as >>> things that are explicitly specified in a standards document is a >>> different problem. >>=20 >> Registries can be a useful way to support extensibility. They can=20 >> also be a nuisance that allow for the promulgation of crazy ideas.=20 >> And probably lots in between and all at once;-) >>=20 >> None of the generalities above help in this specific case where I=20 >> remain convinced that any extensible-generic-PLUS is liable to be=20 >> highly dangerous. (And I'm unsure if a non-extensible-PLUS can be=20 >> usefully transport independent.) >>=20 >>>=20 >>>=20 >>> To answer your question below: >>>=20 >>>>>=20 >>>>> 2) Further only PLUS provides an additional function that >>>>> allows to detect any mangling of data/bits that was not >>>>> intended. This is urgently needed because all the TCP (and >>>>> higher) layer mangling we see today is the root cause for the >>>>> problem we have right now. >>>>=20 >>>> I don't get your point (2) sorry. Can you explain more? >>>=20 >>> We explained this in the BoF and I believe I made this point >>> very clear in my last mail that I replied to Kyle. But let me >>> state this bit again, because it=E2=80=99s important. >>>=20 >>> Today, there are a large amount of bits a middlebox can mangle >>> with (as described in draft-trammell-privsec-defeating-tcpip-meta >>> which is not even exhaustive). Most of the described ways to >>> insert information into a packet are not detectable, at least >>> most of the ways described for TCP because all information is in >>> cleartext and the receiver does not know what the sender has >>> originally sent while the mangled information still allows proper >>> operation. >>=20 >> The above is clear, thanks. And is what I got from the BoF too. >>=20 >>> What we propose is to a) encrypt all bits in the transport/TCP=20 >>> header, >>=20 >> Well, no, PLUS is not a proposal to do that iiuc - PLUS is a >> proposal to expose some information when such encryption is being >> done as defined by some other specification which is not PLUS. If >> my take there is wrong, I'd appreciate being corrected. >>=20 >> I would have far less of an issue if e.g. QUIC or other transports=20 >> defined in a transport-specific and non-extensible manner how the=20 >> few bits of information that might be desirable for the path can >> be outside the confidentiality envelope. >>=20 >> I can totally see how some architectural guidance and examples of=20 >> the sometimes-subtle threats caused by exposing information were >> to be developed. PLUS however seems to be proposing to go beyond >> that and to define PDUs, which I think I'm nearly convinced is a >> bad plan and a path down which it may be better to not start. >>=20 >>> b) provide less bits in a PLUS header, that have been carefully >>> evaluated towards risks that we know today (but didn=E2=80=99t know w= hen >>> we designed TCP), and c) a MAC that hashes all information=20 >>> provided in the PLUS header to be able to detect mangling by the=20 >>> receiver (which can inform then the sender using an encrypted=20 >>> channel). This also means that the endpoint has the choice to not >>> use PLUS (or any PLUS information fields) if mangling is >>> detected. >>>=20 >>> All these points together, especially point c, makes the >>> situation compared to what we have today better and not worse! >>=20 >> I get that that's the argument for PLUS. I remain unconvinced by=20 >> that argument for the reasons stated earlier. >>=20 >> Cheers, S. >>=20 >>=20 >>>=20 >>> Mirja >>>=20 >>>=20 >>>=20 >>>=20 >>>> Am 29.07.2016 um 17:17 schrieb Stephen Farrell=20 >>>> : >>>>=20 >>>>=20 >>>> Hiya, >>>>=20 >>>> On 29/07/16 15:48, Mirja K=C3=BChlewind wrote: >>>>> Hi Stephen, >>>>>=20 >>>>> I believe that what you think PLUS is, is not what we >>>>> propose. >>>>=20 >>>> I'm pretty sure that's true - and is part of what puzzles me as >>>> I said before. >>>>=20 >>>>> Maybe we did not make a great job so far to define PLUS >>>>> narrowly enough but we believe the actual protocol >>>>> specification work should be done in a wg to ensure that a >>>>> broad community can participate, and all concern, including >>>>> privacy concerns, can be addressed. >>>>=20 >>>> I get that. Some folks however (and I'm not sure if I'd count=20 >>>> myself amongst them yet or not) fear that any such WG has to >>>> end up as very privacy unfriendly if it remains transport >>>> agnostic. From that perspective, starting a WG would not make >>>> sense. >>>>=20 >>>>>=20 >>>>> The point of draft-trammell-privsec-defeating-tcpip-meta is >>>>> to further explain that the things you describe as risks are=20 >>>>> nothing new. And by new, we mean they are even >>>>> standard-conform; because this is the main point of your >>>>> concern if I understand you correctly, right? >>>>=20 >>>> No. Brian's draft doesn't touch on the "over 18" type threat at >>>> all as I read it, so I don't accept the idea that the >>>> hypercookie is the right place from which to start to analyse >>>> the set of threats in this space. >>>>=20 >>>> And there is IMO a real difference between our current/old set >>>> of protocols allowing bad behaviours vs. us defining a new >>>> protocol to explicitly enable those same bad behaviours. (It >>>> could be that not all of us agree that that is a real >>>> difference.) >>>>=20 >>>>>=20 >>>>> I assume your point is that we propose a protocol that is=20 >>>>> intended to signal information from middleboxes to the >>>>> endpoint (amongst other features). I assume this based on the >>>>> following statement you made: >>>>>=20 >>>>>> Should we standardise a method for such abuse, then I >>>>>> think it's quite possible the attacker may argue that their >>>>>> behaviour is not an attack as it's just a part of "the >>>>>> standard.=E2=80=9C >>>>>=20 >>>>> and >>>>>=20 >>>>>> And to the extent that PLUS could enable and standardise >>>>>> such things, that is, for me, a major reason to oppose >>>>>> PLUS. >>>>>=20 >>>>> Otherwise can you please further explain what you mean by >>>>> =E2=80=9Esuch abuse=E2=80=9C and =E2=80=9Esuch things=E2=80=9C? >>>>=20 >>>> Sorry I don't get the question. (That is, I'm not clear if I do >>>> or do not agree with your assumptions, which are not clear to >>>> me;-) >>>>=20 >>>>>=20 >>>>> If the thing you are concerned about in PLUS is, that we >>>>> propose to standardize =E2=80=9Aoption=E2=80=98 space that explicit= ly allows >>>>> middleboxes to add information to a packet, I guess you know >>>>> that it is possible to define an experimental TCP option (in >>>>> the ISE stream) without IESG approval that allows the >>>>> insertion of private information by middleboxes. Even thought >>>>> TCP options are not intended to be altered by network nodes, >>>>> there is also no standard that forbids this. >>>>=20 >>>> I am not arguing for a "MINUS" (a TBD acronym that'd be the=20 >>>> antithesis of PLUS:-). >>>>=20 >>>>>=20 >>>>> Let me say two things about what we ACTUALLY propose with >>>>> PLUS: 1) We do NOT propose to add space to add arbitrary >>>>> information. The semantic of the field must be well-defined >>>>> in an IESG approved RFC and registered respectively. >>>>=20 >>>> IMO that is not sufficient to allay my concern about "over 18" >>>> and the like. If we build it (the registry) then they will come >>>> (and ask for or squat on code points with horrible semantics). >>>> I can't see any way to avoid that other than never creating >>>> such a registry. >>>>=20 >>>>> This will not only make it not-standard conform to use such >>>>> a field for something different, it also restrict the set of >>>>> valid values which then could even be checked by later >>>>> middleboxes on the path, and erased if needed. >>>>=20 >>>> Sure. But I remain convinced that any registry here is too=20 >>>> dangerous and the above doesn't convince me otherwise. >>>>=20 >>>>> 2) Further only PLUS provides an additional function that >>>>> allows to detect any mangling of data/bits that was not >>>>> intended. This is urgently needed because all the TCP (and >>>>> higher) layer mangling we see today is the root cause for the >>>>> problem we have right now. >>>>=20 >>>> I don't get your point (2) sorry. Can you explain more? >>>>=20 >>>>>=20 >>>>> Further, I would like to say that not all middlebox mangling >>>>> is automatically bad or an attack. >>>>=20 >>>> Of course. And I did not say that. I said that there are some >>>> bad behaviours in this space and we need to worry about us >>>> maybe legitimising those. >>>>=20 >>>>> If we don=E2=80=99t provide a standardized way to communicate with = >>>>> middleboxes, it will be even harder to distinguish an attack >>>>> from something that actually supports the network service >>>>> provided or even makes the services possible at all. Without >>>>> standardization there is no control at all. I don=E2=80=99t think w= e >>>>> can ignore what=E2=80=99s already happening the Internet any furthe= r >>>>> and providing standardized mechanisms to support the good >>>>> in-network functions is the only way to improve security for >>>>> these functions. >>>>=20 >>>> The above text seems indicative of understandable exasperation >>>> but I don't see how it's very useful for the discussion. >>>>=20 >>>>>=20 >>>>> To make this even more clear, you wrote: >>>>>> the argument seems to ignore the downsides of >>>>>> standardising and thus legitimising "bad" behaviour >>>>>> including behaviours that your draft properly calls an >>>>>> attack. >>>>>=20 >>>>> We not at all want to legitimate =E2=80=9Ebad=E2=80=9C behavior and= I really=20 >>>>> don=E2=80=99t know why you think that what we propose would do so. >>>>=20 >>>> Sigh. I didn't personalise this (I hope! Apologies if I did by >>>> mistake) so I wasn't at all discussing what you or anyone >>>> wants or doesn't want. It is entirely possible to have good >>>> motivation for something that may have quite bad side-effects. >>>>=20 >>>> And I still think that the arguments made by proponents of PLUS >>>> are ignoring the downsides. (And I do not mean that the people >>>> making those arguments are ignoring those downsides which would >>>> be a different statement.) >>>>=20 >>>>> We propose to standardize a protocol that allows middleboxes >>>>> to provide information they have been requested for (by the=20 >>>>> endhost). This information is well define and under IESG=20 >>>>> approval. Any other use of such a protocol will not be=20 >>>>> standard-conform and as bad as the misuse we can see today >>>>> with existing protocols. >>>>=20 >>>> I think that just repeats earlier statements. >>>>=20 >>>> S. >>>>=20 >>>>>=20 >>>>> Mirja >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Am 29.07.2016 um 15:23 schrieb Stephen Farrell=20 >>>>>> : >>>>>>=20 >>>>>>=20 >>>>>> Hi Brian, >>>>>>=20 >>>>>> On 29/07/16 13:33, Brian Trammell wrote: >>>>>>> Greetings, all, >>>>>>>=20 >>>>>>> During the PLUS BoF last week, concern was expressed that >>>>>>> a generic signaling mechanism such as proposed opened two >>>>>>> new attack surfaces: >>>>>>=20 >>>>>> No necessarily "opened...new" perhaps more "risked making >>>>>> much more ubiquitous." At the meeting I didn't hear anyone >>>>>> claim these were new attacks. (I did hear you say they were >>>>>> not new.) >>>>>>=20 >>>>>>>=20 >>>>>>> (1) A method for endpoints to allow path elements to add >>>>>>> non-integrity protected signals presents a surface for=20 >>>>>>> metadata injection attacks, where an entity who can >>>>>>> place devices on a user's access network and has >>>>>>> information about the user's identity could exfiltrate >>>>>>> that information to third parties. For purposes of giving >>>>>>> it a name, let's call this a hypercookie injection attack >>>>>>> ("hyper" since it exists in a space completely >>>>>>> inaccessible to the application). >>>>>>>=20 >>>>>>> (2) Even if path elements are not allowed to say >>>>>>> anything, a mechanism to allow endpoints to add >>>>>>> integrity-protected signals to their traffic presents a >>>>>>> surface for coercion attacks. An access provider can >>>>>>> force a user to tag traffic with their user ID or some >>>>>>> other token (a signed assertion that an advertisement has >>>>>>> been viewed to the end, or maybe even just straight-up >>>>>>> bitcoins) in order to get "better" connectivity, or even >>>>>>> any connectivity at all. A more classically Orwellian >>>>>>> dystopian variant of this attack has a government >>>>>>> requiring citizens to tag all their outgoing traffic with >>>>>>> some government-issued identifier. Let's call this a >>>>>>> hypercookie coercion attack. >>>>>>>=20 >>>>>>> I am less concerned about the surface PLUS presents to >>>>>>> these attacks than those who have raised the concerns in >>>>>>> the BoF and on the mailing list, because the current >>>>>>> Internet architecture is already quite vulnerable to >>>>>>> them. As I said during my presentation last Thursday, Ted >>>>>>> Hardie and I sat down to think about this at lunch a >>>>>>> couple of months ago, and found six ways one could >>>>>>> execute hypercookie injection or coercion today before >>>>>>> our pizza showed up. >>>>>>=20 >>>>>> Wrt injection I can buy that totally. Having read your >>>>>> draft I don't find enough there to accept your assertion >>>>>> wrt coercion - ISTM that coercion attacks have not been >>>>>> analysed yet in your draft. >>>>>>=20 >>>>>> As a side-note, meta-data doesn't have to be >>>>>> person-specific to be controversial - "over 18" and >>>>>> anything with similar semantics, e.g. "member of >>>>>> minority" can very clearly be equally or more damaging, yet >>>>>> totally non-identifying if the relevant set of folks is >>>>>> large enough. So I wonder if the "hypercookie" concept is >>>>>> even the right starting point here. And to the extent that >>>>>> PLUS could enable and standardise such things, that is, for >>>>>> me, a major reason to oppose PLUS. (That's a side-note for >>>>>> this email, but perhaps a quite fundamental thing to >>>>>> consider in the overall discussion.) >>>>>>=20 >>>>>>>=20 >>>>>>> I sat down a little longer to write these up. I found >>>>>>> five more, without even considering trivial out-of-band >>>>>>> metadata leaks or steganographic side channels.=20 >>>>>>> https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpi= p-meta-00 >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>>=20 is the result. The conclusion: these attacks are trivially easy to >>>>>>> execute today by exploiting the gap between valid TCP=20 >>>>>>> traffic and what will be ignored by TCP-indifferent >>>>>>> devices and endpoints, as well as all those juicy bits >>>>>>> IPv6 gives you. Unless we're willing to rely on the >>>>>>> widespread, altruistic deployment of stateful TCP >>>>>>> firewalls to reject traffic (I think we can use our >>>>>>> experience with BCP38 as guidance as to how well *that* >>>>>>> will work, and in any case I think it would be kind of >>>>>>> rich for me of all people to recommend throwing more >>>>>>> TCP-meddling middleboxes into the mix) the only way I can >>>>>>> see out is to add integrity protection to all transport >>>>>>> and network-layer headers, as well as confidentiality >>>>>>> protection to those headers the path does not need to >>>>>>> see. >>>>>>=20 >>>>>> I don't agree. Observatories seem to me like a mitigation >>>>>> that your draft does not consider. If the attacker here >>>>>> does not want to be seen to be attacking, then those can be >>>>>> effective. Should we standardise a method for such abuse, >>>>>> then I think it's quite possible the attacker may argue >>>>>> that their behaviour is not an attack as it's just a part >>>>>> of "the standard." >>>>>>=20 >>>>>> Such a mitigation could be attempted against the attack in=20 >>>>>> 4.1.3 of your draft for example so I disagree with the >>>>>> draft's assertion that "no user-initiated mitigation is >>>>>> possible" in that case at least and maybe others. >>>>>>=20 >>>>>> I think it'd be a fine thing to see further analysis of the >>>>>> attacks and potential mitigations as your draft develops. >>>>>>=20 >>>>>>>=20 >>>>>>> This is, of course, the whole point of PLUS. We can and=20 >>>>>>> should have a discussion of what the endpoints should be >>>>>>> able to say, and what the endpoints should be able to let >>>>>>> the path say. But if we're concerned about this attack, >>>>>>> the general approach is AFAICT the only way out. >>>>>>=20 >>>>>> I disagree. And I think it was clear that a whole bunch of=20 >>>>>> folks in the room last week also clearly disagreed. >>>>>>=20 >>>>>> I believe your "only way out" conclusion isn't logically=20 >>>>>> justified as the argument seems to ignore the downsides of=20 >>>>>> standardising and thus legitimising "bad" behaviour >>>>>> including behaviours that your draft properly calls an >>>>>> attack. >>>>>>=20 >>>>>> Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that >>>>>> we have different sets of sensible folks reaching >>>>>> diametrically opposed conclusions based on the same facts >>>>>> and arguments. Perhaps the tl;dr in your abstract may be a >>>>>> hint there - I do not think everything is ruined myself, so >>>>>> maybe one's level of opt/pess-imism affects one's view of >>>>>> the valid conclusions to reach in this space. >>>>>>=20 >>>>>> Cheers, S. >>>>>>=20 >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________=20 >>>>>>> Privsec-program mailing list Privsec-program@iab.org=20 >>>>>>> https://www.iab.org/mailman/listinfo/privsec-program >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ Spud >>>>>> mailing list Spud@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/spud >>>>>=20 >>>>=20 >>>> _______________________________________________ Spud mailing >>>> list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud >>>=20 >>> _______________________________________________ Privsec-program=20 >>> mailing list Privsec-program@iab.org=20 >>> https://www.iab.org/mailman/listinfo/privsec-program >>>=20 >>=20 >=20 > _______________________________________________ Privsec-program > mailing list Privsec-program@iab.org=20 > https://www.iab.org/mailman/listinfo/privsec-program >=20 --------------ms000301070104020801010008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3Mjky MzM3MzNaMC8GCSqGSIb3DQEJBDEiBCAq7+xqAf6VktQh7lwfSZ5HBp1tJjgAVFKp1NvCSLy7 JzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAjXyPtY9bNcVh2dXTLOBNCD0M6AfTQDGxIhv0M83v1eWUmIuxlCwcL E2AoVj8GrM1OGXAjz2lOmdesI8Q0FwrGLElavvpNnQN9FuZ7eUlwyEKPKVhdzYEs+uMmabTz WClKpyzqU3w/DtING6m/mWTp7AvLB/UwObO75e3aEJRT7Y2JeBeq73mIiZ6i5FGmPfSVooku Y7JV1erUExsMQbr7AKvo9OL3kWI1bCsUZh8UA3D6AUQ2AyMvpagT+0lV2AoTTxgUD8pSb3if pFdL33z+JpN4mDy0GhNrPglb/JzoIvcV7QEx7WC30WVrrSLMOLhiBkDE9rttl0VE4vfbEzQg AAAAAAAA --------------ms000301070104020801010008-- From nobody Sat Jul 30 04:07:37 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525EA12D890 for ; Sat, 30 Jul 2016 04:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=no 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 D6f_A3WzVB5X for ; Sat, 30 Jul 2016 04:07:17 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D85312D126 for ; Sat, 30 Jul 2016 04:07:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id ACBB6D9315; Sat, 30 Jul 2016 13:07:14 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id szxCdlldg1kf; Sat, 30 Jul 2016 13:07:14 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2578.dip0.t-ipconnect.de [93.236.37.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4A18FD9314; Sat, 30 Jul 2016 13:07:14 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> Date: Sat, 30 Jul 2016 13:07:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 11:07:25 -0000 Hi again, see below. > Am 30.07.2016 um 01:37 schrieb Stephen Farrell = : >=20 >=20 > Hiya, >=20 > On 29/07/16 22:39, Mirja K=C3=BChlewind wrote: >> Hi Stephen, >>=20 >> while I personally think that a good protocol design should be >> extensible because that=E2=80=99s the lesson we learnt over many = years now >> (see draft-iab-protocol-transitions-02), I guess we simply have >> different opinions here and should leave it stand like this. >=20 > Actually that's an interesting topic. For example the extent to > which TLS ciphersuite's (lack of) structure influenced how we have > now ended up with ~350 entries in that registry; the same actually > goes for TLS extensions which have a truly horrible history (do you > know the one about the extension just to ensure the ClientHello is > not over N and less than M bytes? (Sorry, I forget the values of N > and M, but it's hilarious;-)... and the impact of all that on the > (in)security of the Internet... is something that could be the topic > of an interesting, (if quite astoundingly arcane:-) debate. I do see the problems that we have with extensibility and I agree that = any new protocol we design needs to consider the mechanism it uses for = extensibility carefully. However, I really don=E2=80=99t think that no = extensibility is the solution. I don=E2=80=99t think that security would = have been better, if TLS has decided for one ciphersuite at the = beginning without any option to ever change it=E2=80=A6=20 Further, the examples you talk about here actually have a very direct = impact on security and therefore privacy. If I think about TCP as = another example, we do have problem, e.g. option squatting, but the = extensibility we have is also key for the success of TCP. TCP would = already be dead if we would not have the window scaling option or SACK.=20= >=20 > I also recall debates about how to usefully allow yet constrain > extensibility in h2. >=20 > Both TLS and HTTP are important protocols and the arguments for > and against extensibility involved are I think quite tricky. >=20 > I did btw take a quick flick over the IAB draft you mention above > and I have to say I reckon it needs a lot of work - "Design for > extensibility so that things can be fixed up later" is IMO almost > nonsense, at least as (so baldly) stated. Yes, I agree that we probably need further discussion here and that = there are different ways to provide extensibility which probably would = be good to document. However, there might also not be the one and best = solution for all protocols on all layers. I guess we have to make = decisions on a case by case basis. In addition, I would like to mention that there is always a strong = desire in transport to miniziae the number of bits to use (as the = overhead multiples as the header will be in every packet). For me = that=E2=80=99s another reason to support extensibility to make sure that = really only those information you need right now show up in the header. >=20 > In this particular case, I think there is a very strong set of > arguments for extremely constrained or no extensibility, perhaps > even to the point of not even starting the work at all. I disagree. Enabling large scale encryption that is deployable is the = goal of PLUS. And this enables two things: increased security and = privacy, as well as transport evolution. For the first goal we need = encryption and maintain the status quo (regarding network = manageability), while for the second part, we envision the development = and use of new transports that enable new services. Not having a tool to = also enable some innovation in the network to support these services, = archives the goal only half way. >=20 >>=20 >> One point I want to clarify (as you asked for it): >>=20 >>> Well, no, PLUS is not a proposal to do that iiuc - PLUS is a >>> proposal to expose some information when such encryption is being >>> done as defined by some other specification which is not PLUS. If >>> my take there is wrong, I'd appreciate being corrected. >>=20 >> There are two aspects here: >>=20 >> 1) PLUS requires the encryption context from the transport protocol. >> As PLUS is not a transport protocol in itself, it e.g. cannot provide >> reliable transmission, which also means it cannot negotiate any >> encryption context in its own. That means it must use information >> given from the transport protocol above. If the transport used does >> not have any of these feature, we have to have another layer in >> between, namely DTLS. >=20 > The phrase "namely DTLS" makes it sound like there is a protocol > proposal somewhere about. Is that the case? I don't think it helps > the argument for PLUS to say "a WG should decide that" myself but > I do understand the tactical logic that might quite reasonably end > up with folks taking that kind of approach. (IOW, I think that the > PLUS BoF would have had a better chance of success had there been > a specific protocol starting point proposed but I understand the > reasons why the proponents might have decided otherwise.) Yes, we decided to not propose a protocol before the BoF because we = wanted to include the community in the design of such a probably = important change. We understood from all comments in the BoF that it = would be easier for the community to make a decision about the scope of = this work if there would be a concrete proposal, and we are working on = this. However, we=E2=80=99ve been talking about the use of DTLS above PLUS = since the beginning in the spud BoF in Dallas. We even talked about = using extensibility in DTLS to realize PLUS instead of designing an own = protocol. However, that has limitations. But it is clear that we need to = define PLUS with a tight relation to DTLS, while work on DTLS itself = should not be done in a new transport wg. That=E2=80=99s why the charter = says: "It will aim to work with working groups defining encryption = protocols (e.g. DTLS) which could be used for encryption of transport = protocols running over PLUS" >=20 >>=20 >> 2) PLUS is a proposal to enable encryption of transport headers >> because it is just not possible today to encrypt your transport >> header as it is.=20 >=20 > I think the above sentence isn't helpful. IPsec exists after all. > And while I'm not arguing that IPsec is any part of the answer here > (if there even exists an answer to whatever questions are being > asked), I do think that it's important in this kind of discussion > to be very careful with how we describe things. (Sorry for the > quibble, but the point at issue is whether the PLUS proponents are > or are not correct in concluding that the kind of design for > which you are arguing is or is not necessary.) Yes, form the technical point of view you have IPSec and yes, from a = technical point of view you can basically encrypt everything. However, = this sentence was made to talk about the more practical aspects of = deployability as it was further stated in the following sentences.=20 Please note that these practical deployment consideration also need to = consider that even a small amount of blocking might impact the revenue = of a service provider. Usually service providers cannot risk that some = of their costumer can no be served anymore at all or receive a worse = service than currently provided over TCP when deploying a new protocol. = That=E2=80=99s why e.g. QUIC implements a fallback to TCP. Given these = fallbacks to TCP need to exist, there is actually an incentive to simply = block (encrypted) traffic that a network provider does not want to = support. Therefore I think it=E2=80=99s extremely important to also = provide incentives to network operators to support new protocols. >=20 >> Encryption of the TCP header was discussed in tcpinc >> and decided to not do it because it would cause deployment problem. >> The minimum you have to do to encrypt your transport header is >> encapsulation in UDP. However, especially on port 80 this still can >> lead to blocking. Future providing some information that helps >> firewalls to make decisions about which traffic is legitimate vs. >> attack traffic, is necessary to at least maintain the level of >> security that we have today. >=20 > There are far too many statements in the above that claim > certainty in an uncertain world for my tastes. Yes, this is rather vague but that this is the main problem we have in = transport. A large point of your time in all transport wgs is discussing = about what is deployable and what not given the ossification we see = today. Unfortunately there is no complete view of what happen in the = Internet today. We have measurement data that address different angles = of the problem but naturally these data is all biased one or the other = way. This problem is why we have maprg and why we proposed PLUS as a way = forward to address ossification in the transport layer (probably by = replacing it with ossification in PLUS, which we call path layer). >=20 >>=20 >> As you said in your mail to Ted, it is hard to decide now what the >> right set of information is, and my personal opinion is that if we >> make a decision now and provide no way to change anything later, we >> can just be wrong. >=20 > Sure. But we could be wrong to even start that process, if it leads > to the "over 18" problem down the road. I also note that I have yet > to see any of the proponents of PLUS accept that that is a real > problem with any extensible proposal in this space. That lack of > acknowledgement of a real issue seems odd. (Apologies if I missed > such an ack or if it preceded my interest in this topic.) We do accept the problem and nearly all the work we did since the spud = BoF was addressing this problem. I don=E2=80=99t know why you think that = we would not (even) acknowledge the problem. I personally don=E2=80=99t = think there is a solution to fully solve the problem though and doing = nothing is also not an option because the situation is already bad. = However, I personally don=E2=80=99t think that extensibility in it self = is the problem. The problem is misuse of new and existing protocols = (that leads to (accidental or intentional) leakage of privacy-sensitve = information). I'm not sure if there is any solution to completely avoid = this misuse (it=E2=80=99s a cat-and-mouse game as the general attacker = vs. security problem), based on the Internet that we have today (there = might be clean slate solutions=E2=80=A6). But what we can do is to make = it harder and detectable. That=E2=80=99s the improvement we proposed = with PLUS compared to the status quo (which is basically TCP headers in = plain). Again, based on the current deployment it is easy to block new protocols = as we basically always can and need to fall back to TCP, and therefore = we need to provide network deployment incentives. >=20 >>=20 >> However, which information should be exposed (when, how and how >> often) are questions for a wg, as well as any decision on >> extensibility or not. >=20 > I don't agree. The charter text that was input to the BoF was very > specific that there would be a registry, and hence extensibility. > I think that is sufficient reason to oppose the creation of a WG > for this topic, for reasons already explained. Yes the charter say: "The working group's main output will be an experimental protocol = specification, together with an initial registry of types of information = that can be exposed using PLUS, clearly aligned to use cases determined = by the working group.=E2=80=9C But it also says:=20 "The working group will close if it is not able to come to consensus on = a protocol design to meet its goals.=E2=80=9C In any case, it=E2=80=99s the wgs decision what to do. I think this work is needed to address the ossification that we see = today by enabling large-scale encryption incl. the transport headers. I = think a new protocol is the most promising path to achieve large-scale = deployment. All details, including what will be exposed and what goes in = a registry or what not or nothing at all, should be discussed in a wg. I accept you opinion. And I guess we stated our view points clearly and = have to let it stand as it is now. However, without being disrespectful = but sharing your concerns about privacy (and protocol misuse), I = personally don=E2=80=99t think your arguments justify a request for = non-extensibility (even tough I would fully expect if a wg would decide = to go for an non-extensible approach), and taking this as an argument = for "not even starting the work at all=E2=80=9C (see above) does not = really makes sense for me. Sorry. Mirja >=20 > Cheers, > S. >=20 >>=20 >> Mirja >>=20 >>=20 >>> Am 29.07.2016 um 21:37 schrieb Stephen Farrell >>> : >>>=20 >>>=20 >>> Hiya, >>>=20 >>> On 29/07/16 16:54, Mirja K=C3=BChlewind wrote: >>>> Hi Stephen, >>>>=20 >>>> I see registries as a needed and valuable part of our >>>> standardization process. People ignoring registries as well as >>>> things that are explicitly specified in a standards document is a >>>> different problem. >>>=20 >>> Registries can be a useful way to support extensibility. They can=20 >>> also be a nuisance that allow for the promulgation of crazy ideas.=20= >>> And probably lots in between and all at once;-) >>>=20 >>> None of the generalities above help in this specific case where I=20 >>> remain convinced that any extensible-generic-PLUS is liable to be=20 >>> highly dangerous. (And I'm unsure if a non-extensible-PLUS can be=20 >>> usefully transport independent.) >>>=20 >>>>=20 >>>>=20 >>>> To answer your question below: >>>>=20 >>>>>>=20 >>>>>> 2) Further only PLUS provides an additional function that >>>>>> allows to detect any mangling of data/bits that was not >>>>>> intended. This is urgently needed because all the TCP (and >>>>>> higher) layer mangling we see today is the root cause for the >>>>>> problem we have right now. >>>>>=20 >>>>> I don't get your point (2) sorry. Can you explain more? >>>>=20 >>>> We explained this in the BoF and I believe I made this point >>>> very clear in my last mail that I replied to Kyle. But let me >>>> state this bit again, because it=E2=80=99s important. >>>>=20 >>>> Today, there are a large amount of bits a middlebox can mangle >>>> with (as described in draft-trammell-privsec-defeating-tcpip-meta >>>> which is not even exhaustive). Most of the described ways to >>>> insert information into a packet are not detectable, at least >>>> most of the ways described for TCP because all information is in >>>> cleartext and the receiver does not know what the sender has >>>> originally sent while the mangled information still allows proper >>>> operation. >>>=20 >>> The above is clear, thanks. And is what I got from the BoF too. >>>=20 >>>> What we propose is to a) encrypt all bits in the transport/TCP=20 >>>> header, >>>=20 >>> Well, no, PLUS is not a proposal to do that iiuc - PLUS is a >>> proposal to expose some information when such encryption is being >>> done as defined by some other specification which is not PLUS. If >>> my take there is wrong, I'd appreciate being corrected. >>>=20 >>> I would have far less of an issue if e.g. QUIC or other transports=20= >>> defined in a transport-specific and non-extensible manner how the=20 >>> few bits of information that might be desirable for the path can >>> be outside the confidentiality envelope. >>>=20 >>> I can totally see how some architectural guidance and examples of=20 >>> the sometimes-subtle threats caused by exposing information were >>> to be developed. PLUS however seems to be proposing to go beyond >>> that and to define PDUs, which I think I'm nearly convinced is a >>> bad plan and a path down which it may be better to not start. >>>=20 >>>> b) provide less bits in a PLUS header, that have been carefully >>>> evaluated towards risks that we know today (but didn=E2=80=99t know = when >>>> we designed TCP), and c) a MAC that hashes all information=20 >>>> provided in the PLUS header to be able to detect mangling by the=20 >>>> receiver (which can inform then the sender using an encrypted=20 >>>> channel). This also means that the endpoint has the choice to not >>>> use PLUS (or any PLUS information fields) if mangling is >>>> detected. >>>>=20 >>>> All these points together, especially point c, makes the >>>> situation compared to what we have today better and not worse! >>>=20 >>> I get that that's the argument for PLUS. I remain unconvinced by=20 >>> that argument for the reasons stated earlier. >>>=20 >>> Cheers, S. >>>=20 >>>=20 >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Am 29.07.2016 um 17:17 schrieb Stephen Farrell=20 >>>>> : >>>>>=20 >>>>>=20 >>>>> Hiya, >>>>>=20 >>>>> On 29/07/16 15:48, Mirja K=C3=BChlewind wrote: >>>>>> Hi Stephen, >>>>>>=20 >>>>>> I believe that what you think PLUS is, is not what we >>>>>> propose. >>>>>=20 >>>>> I'm pretty sure that's true - and is part of what puzzles me as >>>>> I said before. >>>>>=20 >>>>>> Maybe we did not make a great job so far to define PLUS >>>>>> narrowly enough but we believe the actual protocol >>>>>> specification work should be done in a wg to ensure that a >>>>>> broad community can participate, and all concern, including >>>>>> privacy concerns, can be addressed. >>>>>=20 >>>>> I get that. Some folks however (and I'm not sure if I'd count=20 >>>>> myself amongst them yet or not) fear that any such WG has to >>>>> end up as very privacy unfriendly if it remains transport >>>>> agnostic. =46rom that perspective, starting a WG would not make >>>>> sense. >>>>>=20 >>>>>>=20 >>>>>> The point of draft-trammell-privsec-defeating-tcpip-meta is >>>>>> to further explain that the things you describe as risks are=20 >>>>>> nothing new. And by new, we mean they are even >>>>>> standard-conform; because this is the main point of your >>>>>> concern if I understand you correctly, right? >>>>>=20 >>>>> No. Brian's draft doesn't touch on the "over 18" type threat at >>>>> all as I read it, so I don't accept the idea that the >>>>> hypercookie is the right place from which to start to analyse >>>>> the set of threats in this space. >>>>>=20 >>>>> And there is IMO a real difference between our current/old set >>>>> of protocols allowing bad behaviours vs. us defining a new >>>>> protocol to explicitly enable those same bad behaviours. (It >>>>> could be that not all of us agree that that is a real >>>>> difference.) >>>>>=20 >>>>>>=20 >>>>>> I assume your point is that we propose a protocol that is=20 >>>>>> intended to signal information from middleboxes to the >>>>>> endpoint (amongst other features). I assume this based on the >>>>>> following statement you made: >>>>>>=20 >>>>>>> Should we standardise a method for such abuse, then I >>>>>>> think it's quite possible the attacker may argue that their >>>>>>> behaviour is not an attack as it's just a part of "the >>>>>>> standard.=E2=80=9C >>>>>>=20 >>>>>> and >>>>>>=20 >>>>>>> And to the extent that PLUS could enable and standardise >>>>>>> such things, that is, for me, a major reason to oppose >>>>>>> PLUS. >>>>>>=20 >>>>>> Otherwise can you please further explain what you mean by >>>>>> =E2=80=9Esuch abuse=E2=80=9C and =E2=80=9Esuch things=E2=80=9C? >>>>>=20 >>>>> Sorry I don't get the question. (That is, I'm not clear if I do >>>>> or do not agree with your assumptions, which are not clear to >>>>> me;-) >>>>>=20 >>>>>>=20 >>>>>> If the thing you are concerned about in PLUS is, that we >>>>>> propose to standardize =E2=80=9Aoption=E2=80=98 space that = explicitly allows >>>>>> middleboxes to add information to a packet, I guess you know >>>>>> that it is possible to define an experimental TCP option (in >>>>>> the ISE stream) without IESG approval that allows the >>>>>> insertion of private information by middleboxes. Even thought >>>>>> TCP options are not intended to be altered by network nodes, >>>>>> there is also no standard that forbids this. >>>>>=20 >>>>> I am not arguing for a "MINUS" (a TBD acronym that'd be the=20 >>>>> antithesis of PLUS:-). >>>>>=20 >>>>>>=20 >>>>>> Let me say two things about what we ACTUALLY propose with >>>>>> PLUS: 1) We do NOT propose to add space to add arbitrary >>>>>> information. The semantic of the field must be well-defined >>>>>> in an IESG approved RFC and registered respectively. >>>>>=20 >>>>> IMO that is not sufficient to allay my concern about "over 18" >>>>> and the like. If we build it (the registry) then they will come >>>>> (and ask for or squat on code points with horrible semantics). >>>>> I can't see any way to avoid that other than never creating >>>>> such a registry. >>>>>=20 >>>>>> This will not only make it not-standard conform to use such >>>>>> a field for something different, it also restrict the set of >>>>>> valid values which then could even be checked by later >>>>>> middleboxes on the path, and erased if needed. >>>>>=20 >>>>> Sure. But I remain convinced that any registry here is too=20 >>>>> dangerous and the above doesn't convince me otherwise. >>>>>=20 >>>>>> 2) Further only PLUS provides an additional function that >>>>>> allows to detect any mangling of data/bits that was not >>>>>> intended. This is urgently needed because all the TCP (and >>>>>> higher) layer mangling we see today is the root cause for the >>>>>> problem we have right now. >>>>>=20 >>>>> I don't get your point (2) sorry. Can you explain more? >>>>>=20 >>>>>>=20 >>>>>> Further, I would like to say that not all middlebox mangling >>>>>> is automatically bad or an attack. >>>>>=20 >>>>> Of course. And I did not say that. I said that there are some >>>>> bad behaviours in this space and we need to worry about us >>>>> maybe legitimising those. >>>>>=20 >>>>>> If we don=E2=80=99t provide a standardized way to communicate = with=20 >>>>>> middleboxes, it will be even harder to distinguish an attack >>>>>> from something that actually supports the network service >>>>>> provided or even makes the services possible at all. Without >>>>>> standardization there is no control at all. I don=E2=80=99t think = we >>>>>> can ignore what=E2=80=99s already happening the Internet any = further >>>>>> and providing standardized mechanisms to support the good >>>>>> in-network functions is the only way to improve security for >>>>>> these functions. >>>>>=20 >>>>> The above text seems indicative of understandable exasperation >>>>> but I don't see how it's very useful for the discussion. >>>>>=20 >>>>>>=20 >>>>>> To make this even more clear, you wrote: >>>>>>> the argument seems to ignore the downsides of >>>>>>> standardising and thus legitimising "bad" behaviour >>>>>>> including behaviours that your draft properly calls an >>>>>>> attack. >>>>>>=20 >>>>>> We not at all want to legitimate =E2=80=9Ebad=E2=80=9C behavior = and I really=20 >>>>>> don=E2=80=99t know why you think that what we propose would do = so. >>>>>=20 >>>>> Sigh. I didn't personalise this (I hope! Apologies if I did by >>>>> mistake) so I wasn't at all discussing what you or anyone >>>>> wants or doesn't want. It is entirely possible to have good >>>>> motivation for something that may have quite bad side-effects. >>>>>=20 >>>>> And I still think that the arguments made by proponents of PLUS >>>>> are ignoring the downsides. (And I do not mean that the people >>>>> making those arguments are ignoring those downsides which would >>>>> be a different statement.) >>>>>=20 >>>>>> We propose to standardize a protocol that allows middleboxes >>>>>> to provide information they have been requested for (by the=20 >>>>>> endhost). This information is well define and under IESG=20 >>>>>> approval. Any other use of such a protocol will not be=20 >>>>>> standard-conform and as bad as the misuse we can see today >>>>>> with existing protocols. >>>>>=20 >>>>> I think that just repeats earlier statements. >>>>>=20 >>>>> S. >>>>>=20 >>>>>>=20 >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Am 29.07.2016 um 15:23 schrieb Stephen Farrell=20 >>>>>>> : >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi Brian, >>>>>>>=20 >>>>>>> On 29/07/16 13:33, Brian Trammell wrote: >>>>>>>> Greetings, all, >>>>>>>>=20 >>>>>>>> During the PLUS BoF last week, concern was expressed that >>>>>>>> a generic signaling mechanism such as proposed opened two >>>>>>>> new attack surfaces: >>>>>>>=20 >>>>>>> No necessarily "opened...new" perhaps more "risked making >>>>>>> much more ubiquitous." At the meeting I didn't hear anyone >>>>>>> claim these were new attacks. (I did hear you say they were >>>>>>> not new.) >>>>>>>=20 >>>>>>>>=20 >>>>>>>> (1) A method for endpoints to allow path elements to add >>>>>>>> non-integrity protected signals presents a surface for=20 >>>>>>>> metadata injection attacks, where an entity who can >>>>>>>> place devices on a user's access network and has >>>>>>>> information about the user's identity could exfiltrate >>>>>>>> that information to third parties. For purposes of giving >>>>>>>> it a name, let's call this a hypercookie injection attack >>>>>>>> ("hyper" since it exists in a space completely >>>>>>>> inaccessible to the application). >>>>>>>>=20 >>>>>>>> (2) Even if path elements are not allowed to say >>>>>>>> anything, a mechanism to allow endpoints to add >>>>>>>> integrity-protected signals to their traffic presents a >>>>>>>> surface for coercion attacks. An access provider can >>>>>>>> force a user to tag traffic with their user ID or some >>>>>>>> other token (a signed assertion that an advertisement has >>>>>>>> been viewed to the end, or maybe even just straight-up >>>>>>>> bitcoins) in order to get "better" connectivity, or even >>>>>>>> any connectivity at all. A more classically Orwellian >>>>>>>> dystopian variant of this attack has a government >>>>>>>> requiring citizens to tag all their outgoing traffic with >>>>>>>> some government-issued identifier. Let's call this a >>>>>>>> hypercookie coercion attack. >>>>>>>>=20 >>>>>>>> I am less concerned about the surface PLUS presents to >>>>>>>> these attacks than those who have raised the concerns in >>>>>>>> the BoF and on the mailing list, because the current >>>>>>>> Internet architecture is already quite vulnerable to >>>>>>>> them. As I said during my presentation last Thursday, Ted >>>>>>>> Hardie and I sat down to think about this at lunch a >>>>>>>> couple of months ago, and found six ways one could >>>>>>>> execute hypercookie injection or coercion today before >>>>>>>> our pizza showed up. >>>>>>>=20 >>>>>>> Wrt injection I can buy that totally. Having read your >>>>>>> draft I don't find enough there to accept your assertion >>>>>>> wrt coercion - ISTM that coercion attacks have not been >>>>>>> analysed yet in your draft. >>>>>>>=20 >>>>>>> As a side-note, meta-data doesn't have to be >>>>>>> person-specific to be controversial - "over 18" and >>>>>>> anything with similar semantics, e.g. "member of >>>>>>> minority" can very clearly be equally or more damaging, yet >>>>>>> totally non-identifying if the relevant set of folks is >>>>>>> large enough. So I wonder if the "hypercookie" concept is >>>>>>> even the right starting point here. And to the extent that >>>>>>> PLUS could enable and standardise such things, that is, for >>>>>>> me, a major reason to oppose PLUS. (That's a side-note for >>>>>>> this email, but perhaps a quite fundamental thing to >>>>>>> consider in the overall discussion.) >>>>>>>=20 >>>>>>>>=20 >>>>>>>> I sat down a little longer to write these up. I found >>>>>>>> five more, without even considering trivial out-of-band >>>>>>>> metadata leaks or steganographic side channels.=20 >>>>>>>> = https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta-00= >>>>>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>>>>>=20 >>>=20 >>>>>>>>=20 > is the result. The conclusion: these attacks are trivially easy to >>>>>>>> execute today by exploiting the gap between valid TCP=20 >>>>>>>> traffic and what will be ignored by TCP-indifferent >>>>>>>> devices and endpoints, as well as all those juicy bits >>>>>>>> IPv6 gives you. Unless we're willing to rely on the >>>>>>>> widespread, altruistic deployment of stateful TCP >>>>>>>> firewalls to reject traffic (I think we can use our >>>>>>>> experience with BCP38 as guidance as to how well *that* >>>>>>>> will work, and in any case I think it would be kind of >>>>>>>> rich for me of all people to recommend throwing more >>>>>>>> TCP-meddling middleboxes into the mix) the only way I can >>>>>>>> see out is to add integrity protection to all transport >>>>>>>> and network-layer headers, as well as confidentiality >>>>>>>> protection to those headers the path does not need to >>>>>>>> see. >>>>>>>=20 >>>>>>> I don't agree. Observatories seem to me like a mitigation >>>>>>> that your draft does not consider. If the attacker here >>>>>>> does not want to be seen to be attacking, then those can be >>>>>>> effective. Should we standardise a method for such abuse, >>>>>>> then I think it's quite possible the attacker may argue >>>>>>> that their behaviour is not an attack as it's just a part >>>>>>> of "the standard." >>>>>>>=20 >>>>>>> Such a mitigation could be attempted against the attack in=20 >>>>>>> 4.1.3 of your draft for example so I disagree with the >>>>>>> draft's assertion that "no user-initiated mitigation is >>>>>>> possible" in that case at least and maybe others. >>>>>>>=20 >>>>>>> I think it'd be a fine thing to see further analysis of the >>>>>>> attacks and potential mitigations as your draft develops. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> This is, of course, the whole point of PLUS. We can and=20 >>>>>>>> should have a discussion of what the endpoints should be >>>>>>>> able to say, and what the endpoints should be able to let >>>>>>>> the path say. But if we're concerned about this attack, >>>>>>>> the general approach is AFAICT the only way out. >>>>>>>=20 >>>>>>> I disagree. And I think it was clear that a whole bunch of=20 >>>>>>> folks in the room last week also clearly disagreed. >>>>>>>=20 >>>>>>> I believe your "only way out" conclusion isn't logically=20 >>>>>>> justified as the argument seems to ignore the downsides of=20 >>>>>>> standardising and thus legitimising "bad" behaviour >>>>>>> including behaviours that your draft properly calls an >>>>>>> attack. >>>>>>>=20 >>>>>>> Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that >>>>>>> we have different sets of sensible folks reaching >>>>>>> diametrically opposed conclusions based on the same facts >>>>>>> and arguments. Perhaps the tl;dr in your abstract may be a >>>>>>> hint there - I do not think everything is ruined myself, so >>>>>>> maybe one's level of opt/pess-imism affects one's view of >>>>>>> the valid conclusions to reach in this space. >>>>>>>=20 >>>>>>> Cheers, S. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________=20 >>>>>>>> Privsec-program mailing list Privsec-program@iab.org=20 >>>>>>>> https://www.iab.org/mailman/listinfo/privsec-program >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ Spud >>>>>>> mailing list Spud@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/spud >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ Spud mailing >>>>> list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud >>>>=20 >>>> _______________________________________________ Privsec-program=20 >>>> mailing list Privsec-program@iab.org=20 >>>> https://www.iab.org/mailman/listinfo/privsec-program >>>>=20 >>>=20 >>=20 >> _______________________________________________ Privsec-program >> mailing list Privsec-program@iab.org=20 >> https://www.iab.org/mailman/listinfo/privsec-program >>=20 >=20 From nobody Sat Jul 30 05:14:21 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780A212D8BD for ; Sat, 30 Jul 2016 05:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 ThERiMXtW--v for ; Sat, 30 Jul 2016 05:14:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D11B12D694 for ; Sat, 30 Jul 2016 05:14:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BBA11BE4D; Sat, 30 Jul 2016 13:14:16 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYDviq7sapqq; Sat, 30 Jul 2016 13:14:15 +0100 (IST) Received: from [192.168.1.5] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E593DBE33; Sat, 30 Jul 2016 13:14:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469880855; bh=O85+6v9B6p4SSM8pLCBGAGVVcgWbPQXsI3hM9EdJyzM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=d+fjRe1NOnZk64PriLvl4z//UNQn6210dvVR9Ym4lr9s0JkXfYm5kGxQuWxpIvFY0 ZJmxlJxALx0i4JcdGzH78o0IcBjQG7Vf4YSi311QxJYXfrCNTAECwl0ccsfDRMu6Tp 684UdZFp192a0HX5VApCn0Z8RwbsMtV8Nh+UMdAE= To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sat, 30 Jul 2016 13:14:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050606000503020200040808" Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 12:14:19 -0000 This is a cryptographically signed message in MIME format. --------------ms050606000503020200040808 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I agree with your conclusion that we seem to have clearly set out where we disagree without so far changing one another's conclusions. So I only have one more thing to add for now, which is about the form of, and not the content of, the discussion. You said: On 30/07/16 12:07, Mirja K=C3=BChlewind wrote: > Enabling large scale encryption that is deployable is the goal of > PLUS. And this enables two things: increased security and privacy, as > well as transport evolution. For the first goal we need encryption > and maintain the status quo (regarding network manageability), while > for the second part, we envision the development and use of new > transports that enable new services. Not having a tool to also enable > some innovation in the network to support these services, archives > the goal only half way. I'm fine with and fully accept the first sentence. The rest of that paragraph however seems to me to beg the question, that is, it assumes that a deployed PLUS-solution will be an overall good, when it is exactly that that I and others wish to question. I do think this is an issue in this discussion and was in the BoF - the proponents, being convinced that the solution is needed, assume that the solution is needed when answering those who are questioning whether we'd be better or worse off should PLUS be developed further. That's probably natural given folks have been working on SPUD/PLUS for some time, but it seems to me to hinder discussion with folks like me who are far from convinced that the envisaged solution is at all desirable. So my apologies for trying to drag you back to what you likely consider first principles you probably figured were done with a couple of years ago, but I think that's actually fair and to be expected when one has a BoF of this kind. Cheers, S. >=20 >>>=20 --------------ms050606000503020200040808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MzAx MjE0MTRaMC8GCSqGSIb3DQEJBDEiBCD3nITf2OIcDbZFVYqHpDRl/JzNb/mHtL3QpWehMqaq pTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAi0N7x73e2sRlG6wBX1D75yMf4uL41jjH6dvqDWFLozzVGXIsx9CQS LNPKu7FX3avAk4vXAutmKwriL3yjRMy/DJtgOoaPgaMAarCPk45hIokMW/MPH7vFBo1nynKr gG7eETJDIkY2D++kM3we7yu0SHpeC4bN8LcGUFbDt+B/cTuxK6B/tpwknDKNb48bP7vuo56i 3ZM+QYofgKyDXNGNXwV9KTC8Bg9J66qQrbA40zL48AgxW7qzm4b72RW4FN3n4MNwpZUWSTUe aEExi9qSeLl9WV6ohlZtL58HzoPaRu4wlykQ9igwhZuY6ASc/ZjKWkQs5fr5UpGHMCv6+kAi AAAAAAAA --------------ms050606000503020200040808-- From nobody Sat Jul 30 10:21:39 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E2C12D103 for ; Sat, 30 Jul 2016 10:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 LUx4V3N5Y0Fr for ; Sat, 30 Jul 2016 10:21:31 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 101C212D123 for ; Sat, 30 Jul 2016 10:21:31 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id f6so215457188ith.1 for ; Sat, 30 Jul 2016 10:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sOuicghCpYjlGwZmS0/l1BPv0z5Pb+TXJTf+ALKUXXQ=; b=AFZ4RF3/Zb6CGiJKVubhMhprqzIYRrLpQEUhl01TFxLIaLwbhF22FtL1HzHbB5nsI8 4H7QHyBiPEoPwV0qYoGMrH7HNqhU4xmUJY5w2oVVIiXLx3vkM//A4665h0kbyobJJmTn ftg1sknv1FVaR1P1/41D+3KOnB39U9/Ql4mqFoyhAuXCVnV1gCSTMIYj8S6fORi6uSsl w3OsAVAhMLvDZwOD7Epz1BHMjunLOj5qjdhQrJX8VT0L/U6TDLATCls8wZ3t8oEDVu74 UfdbicbqAkHbnfG/iCkLOIPf03J3O0vX89IjUMb2ktiG9eyzQ3GPSGN6ZGmoiREyzocN cGJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sOuicghCpYjlGwZmS0/l1BPv0z5Pb+TXJTf+ALKUXXQ=; b=f8+vCU5phqImVEve/EoNp/wWzg1+vsUFqRQEThnUYyoYyoARWkwnwNZcMW//EEiaHC 00lflZHGj5Kto1ENxordKON/Qir0E5SgnwmipJSF7d6dtaH+Y55CKMon+2fL0kWpdSS4 UU0Tfofnk6RVwiCKoZpy8Tlkvbwo3vJwdELZOjVuSdRpSQIMjMJSF1kLeSXHCLE6sWTV j5L9GrYICdvdEDXOiECbZEhny9SVbOfB2w+GhcvPWSzRVbnVPsy8KDqP/YLo6FIrGAOt vst9pD7WT0qIdcaruRvqCxbt9wL0LaZukriusgfk1+a8KJJ0VQFuD5UyKm9h8md6rluP 1Y9g== X-Gm-Message-State: AEkooushlfhMLpipmxG3suM5XU16jtm2HpbtL6y4KzUff4dxo01uwSc3HQ9iNNwQSwRTL2eSGKuIfZR3SkT28g== X-Received: by 10.36.103.214 with SMTP id u205mr6851854itc.88.1469899289272; Sat, 30 Jul 2016 10:21:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Sat, 30 Jul 2016 10:21:28 -0700 (PDT) In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> From: Tom Herbert Date: Sat, 30 Jul 2016 10:21:28 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud , Stephen Farrell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 17:21:34 -0000 On Sat, Jul 30, 2016 at 4:07 AM, Mirja K=C3=BChlewind wrote: > Hi again, > > see below. > >> Am 30.07.2016 um 01:37 schrieb Stephen Farrell : >> >> >> Hiya, >> >> On 29/07/16 22:39, Mirja K=C3=BChlewind wrote: >>> Hi Stephen, >>> >>> while I personally think that a good protocol design should be >>> extensible because that=E2=80=99s the lesson we learnt over many years = now >>> (see draft-iab-protocol-transitions-02), I guess we simply have >>> different opinions here and should leave it stand like this. >> >> Actually that's an interesting topic. For example the extent to >> which TLS ciphersuite's (lack of) structure influenced how we have >> now ended up with ~350 entries in that registry; the same actually >> goes for TLS extensions which have a truly horrible history (do you >> know the one about the extension just to ensure the ClientHello is >> not over N and less than M bytes? (Sorry, I forget the values of N >> and M, but it's hilarious;-)... and the impact of all that on the >> (in)security of the Internet... is something that could be the topic >> of an interesting, (if quite astoundingly arcane:-) debate. > > I do see the problems that we have with extensibility and I agree that an= y new protocol we design needs to consider the mechanism it uses for extens= ibility carefully. However, I really don=E2=80=99t think that no extensibil= ity is the solution. I don=E2=80=99t think that security would have been be= tter, if TLS has decided for one ciphersuite at the beginning without any o= ption to ever change it=E2=80=A6 > > Further, the examples you talk about here actually have a very direct imp= act on security and therefore privacy. If I think about TCP as another exam= ple, we do have problem, e.g. option squatting, but the extensibility we ha= ve is also key for the success of TCP. TCP would already be dead if we woul= d not have the window scaling option or SACK. > >> >> I also recall debates about how to usefully allow yet constrain >> extensibility in h2. >> >> Both TLS and HTTP are important protocols and the arguments for >> and against extensibility involved are I think quite tricky. >> >> I did btw take a quick flick over the IAB draft you mention above >> and I have to say I reckon it needs a lot of work - "Design for >> extensibility so that things can be fixed up later" is IMO almost >> nonsense, at least as (so baldly) stated. > > Yes, I agree that we probably need further discussion here and that there= are different ways to provide extensibility which probably would be good t= o document. However, there might also not be the one and best solution for = all protocols on all layers. I guess we have to make decisions on a case by= case basis. > > In addition, I would like to mention that there is always a strong desire= in transport to miniziae the number of bits to use (as the overhead multip= les as the header will be in every packet). For me that=E2=80=99s another r= eason to support extensibility to make sure that really only those informat= ion you need right now show up in the header. > >> >> In this particular case, I think there is a very strong set of >> arguments for extremely constrained or no extensibility, perhaps >> even to the point of not even starting the work at all. > > I disagree. Enabling large scale encryption that is deployable is the goa= l of PLUS. And this enables two things: increased security and privacy, as = well as transport evolution. For the first goal we need encryption and main= tain the status quo (regarding network manageability), while for the second= part, we envision the development and use of new transports that enable ne= w services. Not having a tool to also enable some innovation in the network= to support these services, archives the goal only half way. > I this is very debatable. The reason we want to encrypt the transport layer in the first place seems to get easily lost in these discussions; it is to hide transport layer information *from* the network. This prevents intrusiveness of the network in transport layers, stops middleboxes from trying to actively participate in transport layer protocols, and thus resolves one major source of protocol ossification and gets us back to the E2E model. The goal of encryption here is to change the status quo not maintain it! Tom >> >>> >>> One point I want to clarify (as you asked for it): >>> >>>> Well, no, PLUS is not a proposal to do that iiuc - PLUS is a >>>> proposal to expose some information when such encryption is being >>>> done as defined by some other specification which is not PLUS. If >>>> my take there is wrong, I'd appreciate being corrected. >>> >>> There are two aspects here: >>> >>> 1) PLUS requires the encryption context from the transport protocol. >>> As PLUS is not a transport protocol in itself, it e.g. cannot provide >>> reliable transmission, which also means it cannot negotiate any >>> encryption context in its own. That means it must use information >>> given from the transport protocol above. If the transport used does >>> not have any of these feature, we have to have another layer in >>> between, namely DTLS. >> >> The phrase "namely DTLS" makes it sound like there is a protocol >> proposal somewhere about. Is that the case? I don't think it helps >> the argument for PLUS to say "a WG should decide that" myself but >> I do understand the tactical logic that might quite reasonably end >> up with folks taking that kind of approach. (IOW, I think that the >> PLUS BoF would have had a better chance of success had there been >> a specific protocol starting point proposed but I understand the >> reasons why the proponents might have decided otherwise.) > > Yes, we decided to not propose a protocol before the BoF because we wante= d to include the community in the design of such a probably important chang= e. We understood from all comments in the BoF that it would be easier for t= he community to make a decision about the scope of this work if there would= be a concrete proposal, and we are working on this. > > However, we=E2=80=99ve been talking about the use of DTLS above PLUS sinc= e the beginning in the spud BoF in Dallas. We even talked about using exten= sibility in DTLS to realize PLUS instead of designing an own protocol. Howe= ver, that has limitations. But it is clear that we need to define PLUS with= a tight relation to DTLS, while work on DTLS itself should not be done in = a new transport wg. That=E2=80=99s why the charter says: "It will aim to wo= rk with working groups defining encryption protocols (e.g. DTLS) which coul= d be used for encryption of transport protocols running over PLUS" > >> >>> >>> 2) PLUS is a proposal to enable encryption of transport headers >>> because it is just not possible today to encrypt your transport >>> header as it is. >> >> I think the above sentence isn't helpful. IPsec exists after all. >> And while I'm not arguing that IPsec is any part of the answer here >> (if there even exists an answer to whatever questions are being >> asked), I do think that it's important in this kind of discussion >> to be very careful with how we describe things. (Sorry for the >> quibble, but the point at issue is whether the PLUS proponents are >> or are not correct in concluding that the kind of design for >> which you are arguing is or is not necessary.) > > Yes, form the technical point of view you have IPSec and yes, from a tech= nical point of view you can basically encrypt everything. However, this sen= tence was made to talk about the more practical aspects of deployability as= it was further stated in the following sentences. > > Please note that these practical deployment consideration also need to co= nsider that even a small amount of blocking might impact the revenue of a s= ervice provider. Usually service providers cannot risk that some of their c= ostumer can no be served anymore at all or receive a worse service than cur= rently provided over TCP when deploying a new protocol. That=E2=80=99s why = e.g. QUIC implements a fallback to TCP. Given these fallbacks to TCP need t= o exist, there is actually an incentive to simply block (encrypted) traffic= that a network provider does not want to support. Therefore I think it=E2= =80=99s extremely important to also provide incentives to network operators= to support new protocols. > >> >>> Encryption of the TCP header was discussed in tcpinc >>> and decided to not do it because it would cause deployment problem. >>> The minimum you have to do to encrypt your transport header is >>> encapsulation in UDP. However, especially on port 80 this still can >>> lead to blocking. Future providing some information that helps >>> firewalls to make decisions about which traffic is legitimate vs. >>> attack traffic, is necessary to at least maintain the level of >>> security that we have today. >> >> There are far too many statements in the above that claim >> certainty in an uncertain world for my tastes. > > Yes, this is rather vague but that this is the main problem we have in tr= ansport. A large point of your time in all transport wgs is discussing abou= t what is deployable and what not given the ossification we see today. Unfo= rtunately there is no complete view of what happen in the Internet today. W= e have measurement data that address different angles of the problem but na= turally these data is all biased one or the other way. This problem is why = we have maprg and why we proposed PLUS as a way forward to address ossifica= tion in the transport layer (probably by replacing it with ossification in = PLUS, which we call path layer). > >> >>> >>> As you said in your mail to Ted, it is hard to decide now what the >>> right set of information is, and my personal opinion is that if we >>> make a decision now and provide no way to change anything later, we >>> can just be wrong. >> >> Sure. But we could be wrong to even start that process, if it leads >> to the "over 18" problem down the road. I also note that I have yet >> to see any of the proponents of PLUS accept that that is a real >> problem with any extensible proposal in this space. That lack of >> acknowledgement of a real issue seems odd. (Apologies if I missed >> such an ack or if it preceded my interest in this topic.) > > We do accept the problem and nearly all the work we did since the spud Bo= F was addressing this problem. I don=E2=80=99t know why you think that we w= ould not (even) acknowledge the problem. I personally don=E2=80=99t think t= here is a solution to fully solve the problem though and doing nothing is a= lso not an option because the situation is already bad. However, I personal= ly don=E2=80=99t think that extensibility in it self is the problem. The pr= oblem is misuse of new and existing protocols (that leads to (accidental or= intentional) leakage of privacy-sensitve information). I'm not sure if the= re is any solution to completely avoid this misuse (it=E2=80=99s a cat-and-= mouse game as the general attacker vs. security problem), based on the Inte= rnet that we have today (there might be clean slate solutions=E2=80=A6). Bu= t what we can do is to make it harder and detectable. That=E2=80=99s the im= provement we proposed with PLUS compared to the status quo (which is basica= lly TCP headers in plain). > > Again, based on the current deployment it is easy to block new protocols = as we basically always can and need to fall back to TCP, and therefore we n= eed to provide network deployment incentives. > >> >>> >>> However, which information should be exposed (when, how and how >>> often) are questions for a wg, as well as any decision on >>> extensibility or not. >> >> I don't agree. The charter text that was input to the BoF was very >> specific that there would be a registry, and hence extensibility. >> I think that is sufficient reason to oppose the creation of a WG >> for this topic, for reasons already explained. > > Yes the charter say: > "The working group's main output will be an experimental protocol specifi= cation, together with an initial registry of types of information that can = be exposed using PLUS, clearly aligned to use cases determined by the worki= ng group.=E2=80=9C > > But it also says: > "The working group will close if it is not able to come to consensus on a= protocol design to meet its goals.=E2=80=9C > > In any case, it=E2=80=99s the wgs decision what to do. > > I think this work is needed to address the ossification that we see today= by enabling large-scale encryption incl. the transport headers. I think a = new protocol is the most promising path to achieve large-scale deployment. = All details, including what will be exposed and what goes in a registry or = what not or nothing at all, should be discussed in a wg. > > I accept you opinion. And I guess we stated our view points clearly and h= ave to let it stand as it is now. However, without being disrespectful but = sharing your concerns about privacy (and protocol misuse), I personally don= =E2=80=99t think your arguments justify a request for non-extensibility (ev= en tough I would fully expect if a wg would decide to go for an non-extensi= ble approach), and taking this as an argument for "not even starting the wo= rk at all=E2=80=9C (see above) does not really makes sense for me. Sorry. > > Mirja > > >> >> Cheers, >> S. >> >>> >>> Mirja >>> >>> >>>> Am 29.07.2016 um 21:37 schrieb Stephen Farrell >>>> : >>>> >>>> >>>> Hiya, >>>> >>>> On 29/07/16 16:54, Mirja K=C3=BChlewind wrote: >>>>> Hi Stephen, >>>>> >>>>> I see registries as a needed and valuable part of our >>>>> standardization process. People ignoring registries as well as >>>>> things that are explicitly specified in a standards document is a >>>>> different problem. >>>> >>>> Registries can be a useful way to support extensibility. They can >>>> also be a nuisance that allow for the promulgation of crazy ideas. >>>> And probably lots in between and all at once;-) >>>> >>>> None of the generalities above help in this specific case where I >>>> remain convinced that any extensible-generic-PLUS is liable to be >>>> highly dangerous. (And I'm unsure if a non-extensible-PLUS can be >>>> usefully transport independent.) >>>> >>>>> >>>>> >>>>> To answer your question below: >>>>> >>>>>>> >>>>>>> 2) Further only PLUS provides an additional function that >>>>>>> allows to detect any mangling of data/bits that was not >>>>>>> intended. This is urgently needed because all the TCP (and >>>>>>> higher) layer mangling we see today is the root cause for the >>>>>>> problem we have right now. >>>>>> >>>>>> I don't get your point (2) sorry. Can you explain more? >>>>> >>>>> We explained this in the BoF and I believe I made this point >>>>> very clear in my last mail that I replied to Kyle. But let me >>>>> state this bit again, because it=E2=80=99s important. >>>>> >>>>> Today, there are a large amount of bits a middlebox can mangle >>>>> with (as described in draft-trammell-privsec-defeating-tcpip-meta >>>>> which is not even exhaustive). Most of the described ways to >>>>> insert information into a packet are not detectable, at least >>>>> most of the ways described for TCP because all information is in >>>>> cleartext and the receiver does not know what the sender has >>>>> originally sent while the mangled information still allows proper >>>>> operation. >>>> >>>> The above is clear, thanks. And is what I got from the BoF too. >>>> >>>>> What we propose is to a) encrypt all bits in the transport/TCP >>>>> header, >>>> >>>> Well, no, PLUS is not a proposal to do that iiuc - PLUS is a >>>> proposal to expose some information when such encryption is being >>>> done as defined by some other specification which is not PLUS. If >>>> my take there is wrong, I'd appreciate being corrected. >>>> >>>> I would have far less of an issue if e.g. QUIC or other transports >>>> defined in a transport-specific and non-extensible manner how the >>>> few bits of information that might be desirable for the path can >>>> be outside the confidentiality envelope. >>>> >>>> I can totally see how some architectural guidance and examples of >>>> the sometimes-subtle threats caused by exposing information were >>>> to be developed. PLUS however seems to be proposing to go beyond >>>> that and to define PDUs, which I think I'm nearly convinced is a >>>> bad plan and a path down which it may be better to not start. >>>> >>>>> b) provide less bits in a PLUS header, that have been carefully >>>>> evaluated towards risks that we know today (but didn=E2=80=99t know w= hen >>>>> we designed TCP), and c) a MAC that hashes all information >>>>> provided in the PLUS header to be able to detect mangling by the >>>>> receiver (which can inform then the sender using an encrypted >>>>> channel). This also means that the endpoint has the choice to not >>>>> use PLUS (or any PLUS information fields) if mangling is >>>>> detected. >>>>> >>>>> All these points together, especially point c, makes the >>>>> situation compared to what we have today better and not worse! >>>> >>>> I get that that's the argument for PLUS. I remain unconvinced by >>>> that argument for the reasons stated earlier. >>>> >>>> Cheers, S. >>>> >>>> >>>>> >>>>> Mirja >>>>> >>>>> >>>>> >>>>> >>>>>> Am 29.07.2016 um 17:17 schrieb Stephen Farrell >>>>>> : >>>>>> >>>>>> >>>>>> Hiya, >>>>>> >>>>>> On 29/07/16 15:48, Mirja K=C3=BChlewind wrote: >>>>>>> Hi Stephen, >>>>>>> >>>>>>> I believe that what you think PLUS is, is not what we >>>>>>> propose. >>>>>> >>>>>> I'm pretty sure that's true - and is part of what puzzles me as >>>>>> I said before. >>>>>> >>>>>>> Maybe we did not make a great job so far to define PLUS >>>>>>> narrowly enough but we believe the actual protocol >>>>>>> specification work should be done in a wg to ensure that a >>>>>>> broad community can participate, and all concern, including >>>>>>> privacy concerns, can be addressed. >>>>>> >>>>>> I get that. Some folks however (and I'm not sure if I'd count >>>>>> myself amongst them yet or not) fear that any such WG has to >>>>>> end up as very privacy unfriendly if it remains transport >>>>>> agnostic. From that perspective, starting a WG would not make >>>>>> sense. >>>>>> >>>>>>> >>>>>>> The point of draft-trammell-privsec-defeating-tcpip-meta is >>>>>>> to further explain that the things you describe as risks are >>>>>>> nothing new. And by new, we mean they are even >>>>>>> standard-conform; because this is the main point of your >>>>>>> concern if I understand you correctly, right? >>>>>> >>>>>> No. Brian's draft doesn't touch on the "over 18" type threat at >>>>>> all as I read it, so I don't accept the idea that the >>>>>> hypercookie is the right place from which to start to analyse >>>>>> the set of threats in this space. >>>>>> >>>>>> And there is IMO a real difference between our current/old set >>>>>> of protocols allowing bad behaviours vs. us defining a new >>>>>> protocol to explicitly enable those same bad behaviours. (It >>>>>> could be that not all of us agree that that is a real >>>>>> difference.) >>>>>> >>>>>>> >>>>>>> I assume your point is that we propose a protocol that is >>>>>>> intended to signal information from middleboxes to the >>>>>>> endpoint (amongst other features). I assume this based on the >>>>>>> following statement you made: >>>>>>> >>>>>>>> Should we standardise a method for such abuse, then I >>>>>>>> think it's quite possible the attacker may argue that their >>>>>>>> behaviour is not an attack as it's just a part of "the >>>>>>>> standard.=E2=80=9C >>>>>>> >>>>>>> and >>>>>>> >>>>>>>> And to the extent that PLUS could enable and standardise >>>>>>>> such things, that is, for me, a major reason to oppose >>>>>>>> PLUS. >>>>>>> >>>>>>> Otherwise can you please further explain what you mean by >>>>>>> =E2=80=9Esuch abuse=E2=80=9C and =E2=80=9Esuch things=E2=80=9C? >>>>>> >>>>>> Sorry I don't get the question. (That is, I'm not clear if I do >>>>>> or do not agree with your assumptions, which are not clear to >>>>>> me;-) >>>>>> >>>>>>> >>>>>>> If the thing you are concerned about in PLUS is, that we >>>>>>> propose to standardize =E2=80=9Aoption=E2=80=98 space that explicit= ly allows >>>>>>> middleboxes to add information to a packet, I guess you know >>>>>>> that it is possible to define an experimental TCP option (in >>>>>>> the ISE stream) without IESG approval that allows the >>>>>>> insertion of private information by middleboxes. Even thought >>>>>>> TCP options are not intended to be altered by network nodes, >>>>>>> there is also no standard that forbids this. >>>>>> >>>>>> I am not arguing for a "MINUS" (a TBD acronym that'd be the >>>>>> antithesis of PLUS:-). >>>>>> >>>>>>> >>>>>>> Let me say two things about what we ACTUALLY propose with >>>>>>> PLUS: 1) We do NOT propose to add space to add arbitrary >>>>>>> information. The semantic of the field must be well-defined >>>>>>> in an IESG approved RFC and registered respectively. >>>>>> >>>>>> IMO that is not sufficient to allay my concern about "over 18" >>>>>> and the like. If we build it (the registry) then they will come >>>>>> (and ask for or squat on code points with horrible semantics). >>>>>> I can't see any way to avoid that other than never creating >>>>>> such a registry. >>>>>> >>>>>>> This will not only make it not-standard conform to use such >>>>>>> a field for something different, it also restrict the set of >>>>>>> valid values which then could even be checked by later >>>>>>> middleboxes on the path, and erased if needed. >>>>>> >>>>>> Sure. But I remain convinced that any registry here is too >>>>>> dangerous and the above doesn't convince me otherwise. >>>>>> >>>>>>> 2) Further only PLUS provides an additional function that >>>>>>> allows to detect any mangling of data/bits that was not >>>>>>> intended. This is urgently needed because all the TCP (and >>>>>>> higher) layer mangling we see today is the root cause for the >>>>>>> problem we have right now. >>>>>> >>>>>> I don't get your point (2) sorry. Can you explain more? >>>>>> >>>>>>> >>>>>>> Further, I would like to say that not all middlebox mangling >>>>>>> is automatically bad or an attack. >>>>>> >>>>>> Of course. And I did not say that. I said that there are some >>>>>> bad behaviours in this space and we need to worry about us >>>>>> maybe legitimising those. >>>>>> >>>>>>> If we don=E2=80=99t provide a standardized way to communicate with >>>>>>> middleboxes, it will be even harder to distinguish an attack >>>>>>> from something that actually supports the network service >>>>>>> provided or even makes the services possible at all. Without >>>>>>> standardization there is no control at all. I don=E2=80=99t think w= e >>>>>>> can ignore what=E2=80=99s already happening the Internet any furthe= r >>>>>>> and providing standardized mechanisms to support the good >>>>>>> in-network functions is the only way to improve security for >>>>>>> these functions. >>>>>> >>>>>> The above text seems indicative of understandable exasperation >>>>>> but I don't see how it's very useful for the discussion. >>>>>> >>>>>>> >>>>>>> To make this even more clear, you wrote: >>>>>>>> the argument seems to ignore the downsides of >>>>>>>> standardising and thus legitimising "bad" behaviour >>>>>>>> including behaviours that your draft properly calls an >>>>>>>> attack. >>>>>>> >>>>>>> We not at all want to legitimate =E2=80=9Ebad=E2=80=9C behavior and= I really >>>>>>> don=E2=80=99t know why you think that what we propose would do so. >>>>>> >>>>>> Sigh. I didn't personalise this (I hope! Apologies if I did by >>>>>> mistake) so I wasn't at all discussing what you or anyone >>>>>> wants or doesn't want. It is entirely possible to have good >>>>>> motivation for something that may have quite bad side-effects. >>>>>> >>>>>> And I still think that the arguments made by proponents of PLUS >>>>>> are ignoring the downsides. (And I do not mean that the people >>>>>> making those arguments are ignoring those downsides which would >>>>>> be a different statement.) >>>>>> >>>>>>> We propose to standardize a protocol that allows middleboxes >>>>>>> to provide information they have been requested for (by the >>>>>>> endhost). This information is well define and under IESG >>>>>>> approval. Any other use of such a protocol will not be >>>>>>> standard-conform and as bad as the misuse we can see today >>>>>>> with existing protocols. >>>>>> >>>>>> I think that just repeats earlier statements. >>>>>> >>>>>> S. >>>>>> >>>>>>> >>>>>>> Mirja >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 29.07.2016 um 15:23 schrieb Stephen Farrell >>>>>>>> : >>>>>>>> >>>>>>>> >>>>>>>> Hi Brian, >>>>>>>> >>>>>>>> On 29/07/16 13:33, Brian Trammell wrote: >>>>>>>>> Greetings, all, >>>>>>>>> >>>>>>>>> During the PLUS BoF last week, concern was expressed that >>>>>>>>> a generic signaling mechanism such as proposed opened two >>>>>>>>> new attack surfaces: >>>>>>>> >>>>>>>> No necessarily "opened...new" perhaps more "risked making >>>>>>>> much more ubiquitous." At the meeting I didn't hear anyone >>>>>>>> claim these were new attacks. (I did hear you say they were >>>>>>>> not new.) >>>>>>>> >>>>>>>>> >>>>>>>>> (1) A method for endpoints to allow path elements to add >>>>>>>>> non-integrity protected signals presents a surface for >>>>>>>>> metadata injection attacks, where an entity who can >>>>>>>>> place devices on a user's access network and has >>>>>>>>> information about the user's identity could exfiltrate >>>>>>>>> that information to third parties. For purposes of giving >>>>>>>>> it a name, let's call this a hypercookie injection attack >>>>>>>>> ("hyper" since it exists in a space completely >>>>>>>>> inaccessible to the application). >>>>>>>>> >>>>>>>>> (2) Even if path elements are not allowed to say >>>>>>>>> anything, a mechanism to allow endpoints to add >>>>>>>>> integrity-protected signals to their traffic presents a >>>>>>>>> surface for coercion attacks. An access provider can >>>>>>>>> force a user to tag traffic with their user ID or some >>>>>>>>> other token (a signed assertion that an advertisement has >>>>>>>>> been viewed to the end, or maybe even just straight-up >>>>>>>>> bitcoins) in order to get "better" connectivity, or even >>>>>>>>> any connectivity at all. A more classically Orwellian >>>>>>>>> dystopian variant of this attack has a government >>>>>>>>> requiring citizens to tag all their outgoing traffic with >>>>>>>>> some government-issued identifier. Let's call this a >>>>>>>>> hypercookie coercion attack. >>>>>>>>> >>>>>>>>> I am less concerned about the surface PLUS presents to >>>>>>>>> these attacks than those who have raised the concerns in >>>>>>>>> the BoF and on the mailing list, because the current >>>>>>>>> Internet architecture is already quite vulnerable to >>>>>>>>> them. As I said during my presentation last Thursday, Ted >>>>>>>>> Hardie and I sat down to think about this at lunch a >>>>>>>>> couple of months ago, and found six ways one could >>>>>>>>> execute hypercookie injection or coercion today before >>>>>>>>> our pizza showed up. >>>>>>>> >>>>>>>> Wrt injection I can buy that totally. Having read your >>>>>>>> draft I don't find enough there to accept your assertion >>>>>>>> wrt coercion - ISTM that coercion attacks have not been >>>>>>>> analysed yet in your draft. >>>>>>>> >>>>>>>> As a side-note, meta-data doesn't have to be >>>>>>>> person-specific to be controversial - "over 18" and >>>>>>>> anything with similar semantics, e.g. "member of >>>>>>>> minority" can very clearly be equally or more damaging, yet >>>>>>>> totally non-identifying if the relevant set of folks is >>>>>>>> large enough. So I wonder if the "hypercookie" concept is >>>>>>>> even the right starting point here. And to the extent that >>>>>>>> PLUS could enable and standardise such things, that is, for >>>>>>>> me, a major reason to oppose PLUS. (That's a side-note for >>>>>>>> this email, but perhaps a quite fundamental thing to >>>>>>>> consider in the overall discussion.) >>>>>>>> >>>>>>>>> >>>>>>>>> I sat down a little longer to write these up. I found >>>>>>>>> five more, without even considering trivial out-of-band >>>>>>>>> metadata leaks or steganographic side channels. >>>>>>>>> https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpi= p-meta-00 >>>>>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>> >>>>>>>>> >> is the result. The conclusion: these attacks are trivially easy to >>>>>>>>> execute today by exploiting the gap between valid TCP >>>>>>>>> traffic and what will be ignored by TCP-indifferent >>>>>>>>> devices and endpoints, as well as all those juicy bits >>>>>>>>> IPv6 gives you. Unless we're willing to rely on the >>>>>>>>> widespread, altruistic deployment of stateful TCP >>>>>>>>> firewalls to reject traffic (I think we can use our >>>>>>>>> experience with BCP38 as guidance as to how well *that* >>>>>>>>> will work, and in any case I think it would be kind of >>>>>>>>> rich for me of all people to recommend throwing more >>>>>>>>> TCP-meddling middleboxes into the mix) the only way I can >>>>>>>>> see out is to add integrity protection to all transport >>>>>>>>> and network-layer headers, as well as confidentiality >>>>>>>>> protection to those headers the path does not need to >>>>>>>>> see. >>>>>>>> >>>>>>>> I don't agree. Observatories seem to me like a mitigation >>>>>>>> that your draft does not consider. If the attacker here >>>>>>>> does not want to be seen to be attacking, then those can be >>>>>>>> effective. Should we standardise a method for such abuse, >>>>>>>> then I think it's quite possible the attacker may argue >>>>>>>> that their behaviour is not an attack as it's just a part >>>>>>>> of "the standard." >>>>>>>> >>>>>>>> Such a mitigation could be attempted against the attack in >>>>>>>> 4.1.3 of your draft for example so I disagree with the >>>>>>>> draft's assertion that "no user-initiated mitigation is >>>>>>>> possible" in that case at least and maybe others. >>>>>>>> >>>>>>>> I think it'd be a fine thing to see further analysis of the >>>>>>>> attacks and potential mitigations as your draft develops. >>>>>>>> >>>>>>>>> >>>>>>>>> This is, of course, the whole point of PLUS. We can and >>>>>>>>> should have a discussion of what the endpoints should be >>>>>>>>> able to say, and what the endpoints should be able to let >>>>>>>>> the path say. But if we're concerned about this attack, >>>>>>>>> the general approach is AFAICT the only way out. >>>>>>>> >>>>>>>> I disagree. And I think it was clear that a whole bunch of >>>>>>>> folks in the room last week also clearly disagreed. >>>>>>>> >>>>>>>> I believe your "only way out" conclusion isn't logically >>>>>>>> justified as the argument seems to ignore the downsides of >>>>>>>> standardising and thus legitimising "bad" behaviour >>>>>>>> including behaviours that your draft properly calls an >>>>>>>> attack. >>>>>>>> >>>>>>>> Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that >>>>>>>> we have different sets of sensible folks reaching >>>>>>>> diametrically opposed conclusions based on the same facts >>>>>>>> and arguments. Perhaps the tl;dr in your abstract may be a >>>>>>>> hint there - I do not think everything is ruined myself, so >>>>>>>> maybe one's level of opt/pess-imism affects one's view of >>>>>>>> the valid conclusions to reach in this space. >>>>>>>> >>>>>>>> Cheers, S. >>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Privsec-program mailing list Privsec-program@iab.org >>>>>>>>> https://www.iab.org/mailman/listinfo/privsec-program >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ Spud >>>>>>>> mailing list Spud@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/spud >>>>>>> >>>>>> >>>>>> _______________________________________________ Spud mailing >>>>>> list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud >>>>> >>>>> _______________________________________________ Privsec-program >>>>> mailing list Privsec-program@iab.org >>>>> https://www.iab.org/mailman/listinfo/privsec-program >>>>> >>>> >>> >>> _______________________________________________ Privsec-program >>> mailing list Privsec-program@iab.org >>> https://www.iab.org/mailman/listinfo/privsec-program >>> >> > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Sat Jul 30 11:24:18 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533A127078 for ; Sat, 30 Jul 2016 11:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 s_PVm_MLmJrW for ; Sat, 30 Jul 2016 11:24:15 -0700 (PDT) Received: from wp214.webpack.hosteurope.de (wp214.webpack.hosteurope.de [80.237.132.221]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C347312B008 for ; Sat, 30 Jul 2016 11:24:14 -0700 (PDT) Received: from [31.10.157.197] (helo=mairac.home); authenticated by wp214.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1bTYvj-0005mh-Qw; Sat, 30 Jul 2016 20:24:11 +0200 To: Tom Herbert , =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> From: Stephan Neuhaus Message-ID: <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> Date: Sat, 30 Jul 2016 20:24:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de;sten@artdecode.de;1469903054;2568057f; Archived-At: Cc: Brian Trammell , Stephen Farrell , spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 18:24:17 -0000 On 2016-07-30 19:21, Tom Herbert wrote: > I this is very debatable. The reason we want to encrypt the transport > layer in the first place seems to get easily lost in these > discussions; it is to hide transport layer information *from* the > network. This prevents intrusiveness of the network in transport > layers, stops middleboxes from trying to actively participate in > transport layer protocols, and thus resolves one major source of > protocol ossification and gets us back to the E2E model. PLUS offers mostly fields that are set by the endpoints and that are protected by MACs, so the can't be changed by middleboxes, at least not without the endpoint finding out. (There are a few fields that are supposed to enable signaling from the path to the endpoint(s) and these obviously need to be changeable by the middleboxes. These will be things such as "tell me the path MTU".) The PLUS fields will be stuff like "this packet starts a new flow", or "this packet ends a flow", and the read-only nature of these fields (unlike what we have now) means that middleboxes can not intrude, and they can't actively participate. This is exactly what you want, isn't it? Fun, Stephan Full disclosure: I'm working with Brian and Mirja on the MAMI project. From nobody Sat Jul 30 11:26:26 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B4912D5D0; Sat, 30 Jul 2016 11:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 e6Q3k3Cqtbby; Sat, 30 Jul 2016 11:26:24 -0700 (PDT) Received: from wp214.webpack.hosteurope.de (wp214.webpack.hosteurope.de [80.237.132.221]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098E712D190; Sat, 30 Jul 2016 11:26:24 -0700 (PDT) Received: from [31.10.157.197] (helo=mairac.home); authenticated by wp214.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1bTYxq-0006C0-As; Sat, 30 Jul 2016 20:26:22 +0200 To: Tom Herbert , =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> From: Stephan Neuhaus Message-ID: <5852b517-7b8f-97ef-d16a-e9fe99236cd4@artdecode.de> Date: Sat, 30 Jul 2016 20:26:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;sten@artdecode.de;1469903184;5f481e6e; Archived-At: Cc: Brian Trammell , privsec-program@iab.org, Stephen Farrell , spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 18:26:25 -0000 On 2016-07-30 19:21, Tom Herbert wrote: > [...] I should clarify: when I write "PLUS does this or that", what I mean is "it is my understanding from the discussions in which I have participated that PLUS will eventually enable doing this or that". I have no crystal ball, unfortunately. Fun, Stephan -- GPG key ID 4BDA81D3 fingerprint 5F88 399F 8811 72BE B36A FC93 4D13 FCB2 4BDA 81D3 From nobody Sat Jul 30 12:59:59 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FC412D10D for ; Sat, 30 Jul 2016 12:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 vApqiSL7vwNB for ; Sat, 30 Jul 2016 12:59:56 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 A3D9612D0AE for ; Sat, 30 Jul 2016 12:59:56 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id f6so136052921ith.0 for ; Sat, 30 Jul 2016 12:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QD3aKKeBvAQRyVM4TjSb7c2l44QCf+kSaDiyh+sg8AI=; b=Knk/HWSCWZY62OWMRRiLp2u8ahlwCTjlTUYHkS1BELvY9kKHr7i5zhTu4xluKCvJWo dOUaQvxNd4TKfbQMKoZzvL01dodeoEZ864Fr42BggeYt0bdGADVJg+pM1wwpUIO8uym3 cMf+AM3ExonXTescBBlGfzNpEchXV47Qa9Ls3Ggv8N6KseaqbeT3S2LwbKxEDIkyVdK3 +lKc0DlJJlVpwCENG5QVoVMparRNGOs7Oq+VoGhoxz3C6dgRXKvaqW35ToZhNkJ1kjF0 UdizP8XJBVh/qmA65+FaFlPLedjEps/2TT8UMAQavslUjQwqMu7JqWmOH+9Yhi5z+XlZ PMrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QD3aKKeBvAQRyVM4TjSb7c2l44QCf+kSaDiyh+sg8AI=; b=b1DmB24kqRkTyhUi5BV8md+WEBaC5gQXN7ZMgFXQX6edqAHAv21N6SHsi9TrgXpYhY R3xzxvSSX7RXSREkiqRMNaBkPcSw8B2MTe/xAC+uYE0ujlYKt/Nvv9vbSUDPp1Stfpyj Q5fmcMfR42UbUKBMEIEkQzxkHYJo60axgoxyTDZiA/5FJ6SpOpUhUO3pq/cFzYDaebA/ fujhpAqKv6IXv/e+zV3KcjBnb188M5KPswupVigzgEiViydU1Sbchb3oNe6Pub9BCT5c 9mGnG1lekHP7UKIHnjB0Q3COCmZgdI4skCgx2fSzj/0ALC/V79t0WyQ3AxYXusbd9RVM 10Yg== X-Gm-Message-State: AEkooutaH9/PSvNlBxEjkTrE4/jA1M2OLzta46ixMYqZ/8495mw9cb5IjCKRY3t/JXssQDKtfyVgp3/KFHVPVQ== X-Received: by 10.36.80.2 with SMTP id m2mr7558690itb.37.1469908795801; Sat, 30 Jul 2016 12:59:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Sat, 30 Jul 2016 12:59:54 -0700 (PDT) In-Reply-To: <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> From: Tom Herbert Date: Sat, 30 Jul 2016 12:59:54 -0700 Message-ID: To: Stephan Neuhaus Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Trammell , Stephen Farrell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 19:59:58 -0000 On Sat, Jul 30, 2016 at 11:24 AM, Stephan Neuhaus wrote: > On 2016-07-30 19:21, Tom Herbert wrote: >> I this is very debatable. The reason we want to encrypt the transport >> layer in the first place seems to get easily lost in these >> discussions; it is to hide transport layer information *from* the >> network. This prevents intrusiveness of the network in transport >> layers, stops middleboxes from trying to actively participate in >> transport layer protocols, and thus resolves one major source of >> protocol ossification and gets us back to the E2E model. > > PLUS offers mostly fields that are set by the endpoints and that are > protected by MACs, so the can't be changed by middleboxes, at least not > without the endpoint finding out. (There are a few fields that are > supposed to enable signaling from the path to the endpoint(s) and these > obviously need to be changeable by the middleboxes. These will be things > such as "tell me the path MTU".) > > The PLUS fields will be stuff like "this packet starts a new flow", or > "this packet ends a flow", and the read-only nature of these fields > (unlike what we have now) means that middleboxes can not intrude, and > they can't actively participate. This is exactly what you want, isn't it? > No, it's not. In fact, exposing flow start/stop information is a good example of something that facilitates intrusiveness by middleboxes at the transport layer. The purpose of exposing this information is to allow network devices to track connections, but connection tracking in the network is fundamentally flawed since there is no requirement that all packets of a connection go any single network device (i.e. the Internet is packet switched not circuit switched). It is therefore incorrect for a middlebox to assume that it can maintain correct connection state for any connections. This becomes intrusive when the middlebox makes decisions based on imperfect state that affects the connection, for instance when a firewall drops packets for a legitimate established connection but doesn't have state since it was not in the path of the SYN. Thanks, Tom From nobody Sun Jul 31 05:57:14 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0666012D192 for ; Sun, 31 Jul 2016 05:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 vHJkABSm4oiE for ; Sun, 31 Jul 2016 05:57:11 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D4E12D159 for ; Sun, 31 Jul 2016 05:57:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 63932D9315; Sun, 31 Jul 2016 14:57:09 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6jXJ49xA68T9; Sun, 31 Jul 2016 14:57:09 +0200 (MEST) Received: from [192.168.178.33] (p5DEC274B.dip0.t-ipconnect.de [93.236.39.75]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 181A8D930E; Sun, 31 Jul 2016 14:57:09 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Sun, 31 Jul 2016 14:57:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 12:57:14 -0000 Hi Stephen, yes, I believe that the proposed mechanisms are needed (in the first = place to address the ossification problem we see in transport - to = phrase it at a light level) and yes, I believe that the proposed = approaches have the potential to improve but at least doesn=E2=80=99t = degrade the situation in general but also the privacy situation that we = have today in the Internet. If I wouldn=E2=80=99t believe that, I = wouldn=E2=80=99t propose it. The technical basis for this believe (regarding privacy) is that we = propose a mechanism for integrity checking that is stronger than what we = have today in transport and therefore makes mangling as least = detectable. Further, I believe that only a cooperative approach will = enable large-scale encrypting (that includes transport headers) because = otherwise operators may be incentivized to block traffic, and in this = sense standardization of a mechanism for middlebox communication would = draw a much clearer line about what we as a community deem acceptable = and what not, instead of declaring all in-network functions other than = routing as evil. I intentionally used the word =E2=80=9Abelieve=E2=80=98 here several = times because as stated in my previous mail we just have probably very = different starting points. I do think some parts of our discussion = involved technical questions, and I hope I could clarify some points. = However, other parts of the discussion are naturally more vague because = we both don=E2=80=99t know the future. However, in this sense these = =E2=80=9Afirst principles=E2=80=98, as I believe you called them below, = are purely what people believe. But, please note that one of these = =E2=80=9Afirst principles=E2=80=98 is that we in transport see a problem = with the ossification today, and PLUS is foremost a proposal to address = this problem (by enabling encryption). Given this, I don=E2=80=99t = really understand what your comment about the form of the discussion is = below.=20 However as you mentioned the BoF belong, I actually also have a comment = on the form of discussion: this activity is on-going for more than one = year. We mainly worked during this time on addressing security questions = that were raised at the spud BoF. Based on one request on the mailing = before the PLUS BoF we explained how we address privacy concerns and how = we think this makes the current situation at least not worse and = probably better. We did not get only further feedback on mailing list = assuming that our proposal is acceptable. And there was no future = discussion about any privacy and security aspects on the list before the = BoF. I would really appreciate if people could constructively help us to = find a solution to address the ossification problem in transport while = maintain or improving the privacy situation we have today, instead of = just blocking new work. Mirja > Am 30.07.2016 um 14:14 schrieb Stephen Farrell = : >=20 >=20 > Hiya, >=20 > I agree with your conclusion that we seem to have clearly set out > where we disagree without so far changing one another's conclusions. > So I only have one more thing to add for now, which is about the > form of, and not the content of, the discussion. You said: >=20 > On 30/07/16 12:07, Mirja K=C3=BChlewind wrote: >> Enabling large scale encryption that is deployable is the goal of >> PLUS. And this enables two things: increased security and privacy, as >> well as transport evolution. For the first goal we need encryption >> and maintain the status quo (regarding network manageability), while >> for the second part, we envision the development and use of new >> transports that enable new services. Not having a tool to also enable >> some innovation in the network to support these services, archives >> the goal only half way. >=20 > I'm fine with and fully accept the first sentence. >=20 > The rest of that paragraph however seems to me to beg the question, > that is, it assumes that a deployed PLUS-solution will be an overall > good, when it is exactly that that I and others wish to question. I > do think this is an issue in this discussion and was in the BoF - the > proponents, being convinced that the solution is needed, assume that > the solution is needed when answering those who are questioning > whether we'd be better or worse off should PLUS be developed further. >=20 > That's probably natural given folks have been working on SPUD/PLUS > for some time, but it seems to me to hinder discussion with folks like > me who are far from convinced that the envisaged solution is at all > desirable. So my apologies for trying to drag you back to what you > likely consider first principles you probably figured were done with > a couple of years ago, but I think that's actually fair and to be > expected when one has a BoF of this kind. >=20 > Cheers, > S. >=20 >=20 >>=20 >>>>=20 >=20 From nobody Sun Jul 31 07:05:16 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C164612D0DB for ; Sun, 31 Jul 2016 07:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Y4oLzpEsfQWB for ; Sun, 31 Jul 2016 07:05:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A9A12D0C8 for ; Sun, 31 Jul 2016 07:05:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5103ABE33; Sun, 31 Jul 2016 15:05:08 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPr7n8TaQ1zw; Sun, 31 Jul 2016 15:05:06 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EEB87BE50; Sun, 31 Jul 2016 15:05:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469973906; bh=eoaKLcKAV1RStYelRWJPzvS8LSpx4hhRsY9LiuGzjvc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=xHxlyvzma6ExWa/bRIBqbzqdXYJ7zckcTtivOfpVrAAgpLNbGrLYOma+AMcTFEKoB lN1QiQDR2b/M/JaUxQzinuImVCWPo0CnXtklioI1xulzrxWK2G9/ul6gfNJ1rL7dZ7 yHZMv1Wc50Trk+u7ptfuPX+LS2uJiA6kksPqWqNQ= To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> Date: Sun, 31 Jul 2016 15:05:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090007030506080604040603" Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 14:05:13 -0000 This is a cryptographically signed message in MIME format. --------------ms090007030506080604040603 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 31/07/16 13:57, Mirja K=C3=BChlewind wrote: > Hi Stephen, >=20 > yes, I believe that the proposed mechanisms are needed (in the first > place to address the ossification problem we see in transport - to > phrase it at a light level) and yes, I believe that the proposed > approaches have the potential to improve but at least doesn=E2=80=99t d= egrade > the situation in general but also the privacy situation that we have > today in the Internet. If I wouldn=E2=80=99t believe that, I wouldn=E2=80= =99t propose > it. >=20 > The technical basis for this believe (regarding privacy) is that we > propose a mechanism for integrity checking that is stronger than what > we have today in transport and therefore makes mangling as least > detectable. Further, I believe that only a cooperative approach will > enable large-scale encrypting (that includes transport headers) > because otherwise operators may be incentivized to block traffic, and > in this sense standardization of a mechanism for middlebox > communication would draw a much clearer line about what we as a > community deem acceptable and what not, instead of declaring all > in-network functions other than routing as evil. >=20 > I intentionally used the word =E2=80=9Abelieve=E2=80=98 here several ti= mes because as > stated in my previous mail we just have probably very different > starting points. I do think some parts of our discussion involved > technical questions, and I hope I could clarify some points. However, > other parts of the discussion are naturally more vague because we > both don=E2=80=99t know the future. However, in this sense these =E2=80= =9Afirst > principles=E2=80=98, as I believe you called them below, are purely wha= t > people believe. But, please note that one of these =E2=80=9Afirst princ= iples=E2=80=98 > is that we in transport see a problem with the ossification today, > and PLUS is foremost a proposal to address this problem (by enabling > encryption). Given this, I don=E2=80=99t really understand what your co= mment > about the form of the discussion is below. Let me try to clarify a couple of important places where my beliefs and yours don't seem to co-incide: - I'm not sure the ossification issue is as-it-was 3 years ago, given QUIC, and to some extent h2 and TLS1.3, but also due to the much increased deployment of TLS. Given such changes, it is not at all clear to me that a generic approach (like PLUS attempts) is best. - I am unconvinced that "giving up" some privacy in the manner envisaged will lead to an overall privacy benefit. I very much fear that opposite - that any extensible mechanism will give up so much privacy so as to render much higher layer confidentiality moot. What I meant when referring to first principles was being explicit in how we're arguing based our these starting points (or beliefs). My perception of the argument (in this thread and the BoF) is that it is harder because the proponents of PLUS were assuming sharted beliefs/starting points when responding to folks who have very different starting assumptions. So for example, I don't think I've seen any of the PLUS proponents directly provide arguments as to why my concerns/beliefs above are unfounded. (I have seen assertions that they are unfounded but not arguments starting from assumptions with which I'd agree.) And my guess is that the proponents are not doing that because they think it was already done. (If a pointer to the SPUD archive is usable to answer this point, that's entirely fine.) >=20 > However as you mentioned the BoF belong, I actually also have a > comment on the form of discussion: this activity is on-going for more > than one year. We mainly worked during this time on addressing > security questions that were raised at the spud BoF. Based on one > request on the mailing before the PLUS BoF we explained how we > address privacy concerns and how we think this makes the current > situation at least not worse and probably better. We did not get only > further feedback on mailing list assuming that our proposal is > acceptable. And there was no future discussion about any privacy and > security aspects on the list before the BoF. I would really > appreciate if people could constructively help us to find a solution > to address the ossification problem in transport while maintain or > improving the privacy situation we have today, instead of just > blocking new work. Yeah, that's fair. It is of course hard to get input from folks who are worried that the work as envisaged inevitably leads to a bad outcome. (So e.g. I'm not subscribed to the SPUD list and am not sure I'd have time and the energy to be on there constantly trying to drag you back to 1st principles;-) Cheers, S. >=20 > Mirja >=20 >=20 >=20 >> Am 30.07.2016 um 14:14 schrieb Stephen Farrell >> : >>=20 >>=20 >> Hiya, >>=20 >> I agree with your conclusion that we seem to have clearly set out=20 >> where we disagree without so far changing one another's >> conclusions. So I only have one more thing to add for now, which is >> about the form of, and not the content of, the discussion. You >> said: >>=20 >> On 30/07/16 12:07, Mirja K=C3=BChlewind wrote: >>> Enabling large scale encryption that is deployable is the goal >>> of PLUS. And this enables two things: increased security and >>> privacy, as well as transport evolution. For the first goal we >>> need encryption and maintain the status quo (regarding network >>> manageability), while for the second part, we envision the >>> development and use of new transports that enable new services. >>> Not having a tool to also enable some innovation in the network >>> to support these services, archives the goal only half way. >>=20 >> I'm fine with and fully accept the first sentence. >>=20 >> The rest of that paragraph however seems to me to beg the >> question, that is, it assumes that a deployed PLUS-solution will be >> an overall good, when it is exactly that that I and others wish to >> question. I do think this is an issue in this discussion and was in >> the BoF - the proponents, being convinced that the solution is >> needed, assume that the solution is needed when answering those who >> are questioning whether we'd be better or worse off should PLUS be >> developed further. >>=20 >> That's probably natural given folks have been working on SPUD/PLUS=20 >> for some time, but it seems to me to hinder discussion with folks >> like me who are far from convinced that the envisaged solution is >> at all desirable. So my apologies for trying to drag you back to >> what you likely consider first principles you probably figured were >> done with a couple of years ago, but I think that's actually fair >> and to be expected when one has a BoF of this kind. >>=20 >> Cheers, S. >>=20 >>=20 >>>=20 >>>>>=20 >>=20 >=20 > _______________________________________________ Privsec-program > mailing list Privsec-program@iab.org=20 > https://www.iab.org/mailman/listinfo/privsec-program >=20 --------------ms090007030506080604040603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MzEx NDA1MDNaMC8GCSqGSIb3DQEJBDEiBCB7dIt8IRZHfWzhfL6QcdYPKP9asJ82TXsMNqAh4ZXH QTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAKRbON1oLtlVdOay63AgBaLvwZxPn+TMsX9X1ZQ94eKAsvncT2BkcN JLN3Qm+PG5XvlTkJIItEPJRrU8Y/3NqtO/KTQhArO3tPHW2dACmiTtrrLi/5vlCcPvTLTTCM mnvO/ZyiAew+3t1brevEgnPO36WdggLo4UJMYIaYs3cuMEpseER/35W8FUEmGpsC7u3wc/63 czPNXi4Alo/R4JfBsGVegd/WKyqkBXov85K3sDQoH1ps8hhN4hCTBQV4mAUXcZoQkRJ/QYdA DzC+zs+JXqLf0E+fKP9vTqw0q6ay2BdluhmeKYfGrHVVq5G5LgGaVvPXlxiMzP4VcNMJBDYk AAAAAAAA --------------ms090007030506080604040603-- From nobody Sun Jul 31 08:45:53 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A1512D0F8 for ; Sun, 31 Jul 2016 08:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 LMziXWehTpI3 for ; Sun, 31 Jul 2016 08:45:46 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D274712B036 for ; Sun, 31 Jul 2016 08:45:45 -0700 (PDT) Received: from [192.168.1.7] (p4FE312A4.dip0.t-ipconnect.de [79.227.18.164]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id A52A1721E280D; Sun, 31 Jul 2016 17:45:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> Date: Sun, 31 Jul 2016 17:45:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , privsec-program@iab.org, =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 15:45:50 -0000 On 31 Jul 2016, at 16:05, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 31/07/16 13:57, Mirja K=C3=BChlewind wrote: >> Hi Stephen, >>=20 >> yes, I believe that the proposed mechanisms are needed (in the first >> place to address the ossification problem we see in transport - to >> phrase it at a light level) and yes, I believe that the proposed >> approaches have the potential to improve but at least doesn=E2=80=99t = degrade >> the situation in general but also the privacy situation that we have >> today in the Internet. If I wouldn=E2=80=99t believe that, I = wouldn=E2=80=99t propose >> it. >>=20 >> The technical basis for this believe (regarding privacy) is that we >> propose a mechanism for integrity checking that is stronger than what >> we have today in transport and therefore makes mangling as least >> detectable. Further, I believe that only a cooperative approach will >> enable large-scale encrypting (that includes transport headers) >> because otherwise operators may be incentivized to block traffic, and >> in this sense standardization of a mechanism for middlebox >> communication would draw a much clearer line about what we as a >> community deem acceptable and what not, instead of declaring all >> in-network functions other than routing as evil. >>=20 >> I intentionally used the word =E2=80=9Abelieve=E2=80=98 here several = times because as >> stated in my previous mail we just have probably very different >> starting points. I do think some parts of our discussion involved >> technical questions, and I hope I could clarify some points. However, >> other parts of the discussion are naturally more vague because we >> both don=E2=80=99t know the future. However, in this sense these = =E2=80=9Afirst >> principles=E2=80=98, as I believe you called them below, are purely = what >> people believe. But, please note that one of these =E2=80=9Afirst = principles=E2=80=98 >> is that we in transport see a problem with the ossification today, >> and PLUS is foremost a proposal to address this problem (by enabling >> encryption). Given this, I don=E2=80=99t really understand what your = comment >> about the form of the discussion is below. >=20 > Let me try to clarify a couple of important places where my beliefs > and yours don't seem to co-incide: >=20 > - I'm not sure the ossification issue is as-it-was 3 years ago, > given QUIC, and to some extent h2 and TLS1.3, but also due to > the much increased deployment of TLS. Given such changes, it > is not at all clear to me that a generic approach (like PLUS > attempts) is best. Hi Stephen, so do you mean future transport protocols (running over UDP) should define their own protocol specific way of exposing information, similar to the way QUIC does it? That would require constant evolution of middleboxes (NAT, firewalls). Or are you suggesting that future transport protocols should just use the framing of QUIC (for the unencrypted part) and reuse the (hopefully) upcoming QUIC support of middleboxes? Best regards Michael > - I am unconvinced that "giving up" some privacy in the manner > envisaged will lead to an overall privacy benefit. I very much > fear that opposite - that any extensible mechanism will give up > so much privacy so as to render much higher layer confidentiality > moot. >=20 > What I meant when referring to first principles was being explicit > in how we're arguing based our these starting points (or beliefs). >=20 > My perception of the argument (in this thread and the BoF) is that > it is harder because the proponents of PLUS were assuming sharted > beliefs/starting points when responding to folks who have very > different starting assumptions. >=20 > So for example, I don't think I've seen any of the PLUS proponents > directly provide arguments as to why my concerns/beliefs above > are unfounded. (I have seen assertions that they are unfounded but > not arguments starting from assumptions with which I'd agree.) And > my guess is that the proponents are not doing that because they > think it was already done. (If a pointer to the SPUD archive is > usable to answer this point, that's entirely fine.) >=20 >>=20 >> However as you mentioned the BoF belong, I actually also have a >> comment on the form of discussion: this activity is on-going for more >> than one year. We mainly worked during this time on addressing >> security questions that were raised at the spud BoF. Based on one >> request on the mailing before the PLUS BoF we explained how we >> address privacy concerns and how we think this makes the current >> situation at least not worse and probably better. We did not get only >> further feedback on mailing list assuming that our proposal is >> acceptable. And there was no future discussion about any privacy and >> security aspects on the list before the BoF. I would really >> appreciate if people could constructively help us to find a solution >> to address the ossification problem in transport while maintain or >> improving the privacy situation we have today, instead of just >> blocking new work. >=20 > Yeah, that's fair. It is of course hard to get input from folks > who are worried that the work as envisaged inevitably leads to a > bad outcome. (So e.g. I'm not subscribed to the SPUD list and am > not sure I'd have time and the energy to be on there constantly > trying to drag you back to 1st principles;-) >=20 > Cheers, > S. >=20 >>=20 >> Mirja >>=20 >>=20 >>=20 >>> Am 30.07.2016 um 14:14 schrieb Stephen Farrell >>> : >>>=20 >>>=20 >>> Hiya, >>>=20 >>> I agree with your conclusion that we seem to have clearly set out=20 >>> where we disagree without so far changing one another's >>> conclusions. So I only have one more thing to add for now, which is >>> about the form of, and not the content of, the discussion. You >>> said: >>>=20 >>> On 30/07/16 12:07, Mirja K=C3=BChlewind wrote: >>>> Enabling large scale encryption that is deployable is the goal >>>> of PLUS. And this enables two things: increased security and >>>> privacy, as well as transport evolution. For the first goal we >>>> need encryption and maintain the status quo (regarding network >>>> manageability), while for the second part, we envision the >>>> development and use of new transports that enable new services. >>>> Not having a tool to also enable some innovation in the network >>>> to support these services, archives the goal only half way. >>>=20 >>> I'm fine with and fully accept the first sentence. >>>=20 >>> The rest of that paragraph however seems to me to beg the >>> question, that is, it assumes that a deployed PLUS-solution will be >>> an overall good, when it is exactly that that I and others wish to >>> question. I do think this is an issue in this discussion and was in >>> the BoF - the proponents, being convinced that the solution is >>> needed, assume that the solution is needed when answering those who >>> are questioning whether we'd be better or worse off should PLUS be >>> developed further. >>>=20 >>> That's probably natural given folks have been working on SPUD/PLUS=20= >>> for some time, but it seems to me to hinder discussion with folks >>> like me who are far from convinced that the envisaged solution is >>> at all desirable. So my apologies for trying to drag you back to >>> what you likely consider first principles you probably figured were >>> done with a couple of years ago, but I think that's actually fair >>> and to be expected when one has a BoF of this kind. >>>=20 >>> Cheers, S. >>>=20 >>>=20 >>>>=20 >>>>>>=20 >>>=20 >>=20 >> _______________________________________________ Privsec-program >> mailing list Privsec-program@iab.org=20 >> https://www.iab.org/mailman/listinfo/privsec-program >>=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Sun Jul 31 09:03:28 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9465512B046 for ; Sun, 31 Jul 2016 09:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 mK_1K9AJaaoS for ; Sun, 31 Jul 2016 09:03:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86FC12B015 for ; Sun, 31 Jul 2016 09:03:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 66D0FBE56; Sun, 31 Jul 2016 17:03:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rzi2xbe-TaV; Sun, 31 Jul 2016 17:03:19 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C3F3DBE49; Sun, 31 Jul 2016 17:03:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469980999; bh=oyiuf8yCjoCuv+Mi4rwtvLQr9zI2IzYv6Z6rFIV69M8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=IY5HgJsGrZTdERs0MYcKEyEbSkx1ZrRSpTIQX6RO3ZJ1wKDpMOFTB9k5qxAZlS4r6 zS+i3A11Xb2/27GlpUN6SbfA7aM7j70A7qQ2lgUybxB2vO6/+IgH+Txs5ifqUpQGKG U1UwK5q+ojiHfWf4gPrNQGcpbJvMC4QF3Mn6AsYg= To: Michael Tuexen References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> Date: Sun, 31 Jul 2016 17:03:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040504080604090700060903" Archived-At: Cc: Brian Trammell , privsec-program@iab.org, =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 16:03:26 -0000 This is a cryptographically signed message in MIME format. --------------ms040504080604090700060903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 31/07/16 16:45, Michael Tuexen wrote: > On 31 Jul 2016, at 16:05, Stephen Farrell w= rote: >> >> >> Hiya, >> >> On 31/07/16 13:57, Mirja K=C3=BChlewind wrote: >>> Hi Stephen, >>> >>> yes, I believe that the proposed mechanisms are needed (in the first >>> place to address the ossification problem we see in transport - to >>> phrase it at a light level) and yes, I believe that the proposed >>> approaches have the potential to improve but at least doesn=E2=80=99t= degrade >>> the situation in general but also the privacy situation that we have >>> today in the Internet. If I wouldn=E2=80=99t believe that, I wouldn=E2= =80=99t propose >>> it. >>> >>> The technical basis for this believe (regarding privacy) is that we >>> propose a mechanism for integrity checking that is stronger than what= >>> we have today in transport and therefore makes mangling as least >>> detectable. Further, I believe that only a cooperative approach will >>> enable large-scale encrypting (that includes transport headers) >>> because otherwise operators may be incentivized to block traffic, and= >>> in this sense standardization of a mechanism for middlebox >>> communication would draw a much clearer line about what we as a >>> community deem acceptable and what not, instead of declaring all >>> in-network functions other than routing as evil. >>> >>> I intentionally used the word =E2=80=9Abelieve=E2=80=98 here several = times because as >>> stated in my previous mail we just have probably very different >>> starting points. I do think some parts of our discussion involved >>> technical questions, and I hope I could clarify some points. However,= >>> other parts of the discussion are naturally more vague because we >>> both don=E2=80=99t know the future. However, in this sense these =E2=80= =9Afirst >>> principles=E2=80=98, as I believe you called them below, are purely w= hat >>> people believe. But, please note that one of these =E2=80=9Afirst pri= nciples=E2=80=98 >>> is that we in transport see a problem with the ossification today, >>> and PLUS is foremost a proposal to address this problem (by enabling >>> encryption). Given this, I don=E2=80=99t really understand what your = comment >>> about the form of the discussion is below. >> >> Let me try to clarify a couple of important places where my beliefs >> and yours don't seem to co-incide: >> >> - I'm not sure the ossification issue is as-it-was 3 years ago, >> given QUIC, and to some extent h2 and TLS1.3, but also due to >> the much increased deployment of TLS. Given such changes, it >> is not at all clear to me that a generic approach (like PLUS >> attempts) is best. > Hi Stephen, >=20 > so do you mean future transport protocols (running over UDP) should > define their own protocol specific way of exposing information, > similar to the way QUIC does it? > That would require constant evolution of middleboxes (NAT, firewalls). >=20 > Or are you suggesting that future transport protocols should just > use the framing of QUIC (for the unencrypted part) and reuse > the (hopefully) upcoming QUIC support of middleboxes? I didn't mean either. What I meant was that perhaps the analysis that lead to the conclusions about ossification of the transport layer needs to be re-done now, give the increase in use of TLS and given QIUC is now highly likely to be an IETF WG. (That's a similar question to asking if PLUS is OBE, which I think I asked of Brian.) IIUC the IAB w/s that sorta lead to SPUD then PLUS happened before QUIC was mooted as work in the IETF and before many services had switched from port 80 to 443. S. >=20 > Best regards > Michael >> - I am unconvinced that "giving up" some privacy in the manner >> envisaged will lead to an overall privacy benefit. I very much >> fear that opposite - that any extensible mechanism will give up >> so much privacy so as to render much higher layer confidentiality >> moot. >> >> What I meant when referring to first principles was being explicit >> in how we're arguing based our these starting points (or beliefs). >> >> My perception of the argument (in this thread and the BoF) is that >> it is harder because the proponents of PLUS were assuming sharted >> beliefs/starting points when responding to folks who have very >> different starting assumptions. >> >> So for example, I don't think I've seen any of the PLUS proponents >> directly provide arguments as to why my concerns/beliefs above >> are unfounded. (I have seen assertions that they are unfounded but >> not arguments starting from assumptions with which I'd agree.) And >> my guess is that the proponents are not doing that because they >> think it was already done. (If a pointer to the SPUD archive is >> usable to answer this point, that's entirely fine.) >> >>> >>> However as you mentioned the BoF belong, I actually also have a >>> comment on the form of discussion: this activity is on-going for more= >>> than one year. We mainly worked during this time on addressing >>> security questions that were raised at the spud BoF. Based on one >>> request on the mailing before the PLUS BoF we explained how we >>> address privacy concerns and how we think this makes the current >>> situation at least not worse and probably better. We did not get only= >>> further feedback on mailing list assuming that our proposal is >>> acceptable. And there was no future discussion about any privacy and >>> security aspects on the list before the BoF. I would really >>> appreciate if people could constructively help us to find a solution >>> to address the ossification problem in transport while maintain or >>> improving the privacy situation we have today, instead of just >>> blocking new work. >> >> Yeah, that's fair. It is of course hard to get input from folks >> who are worried that the work as envisaged inevitably leads to a >> bad outcome. (So e.g. I'm not subscribed to the SPUD list and am >> not sure I'd have time and the energy to be on there constantly >> trying to drag you back to 1st principles;-) >> >> Cheers, >> S. >> >>> >>> Mirja >>> >>> >>> >>>> Am 30.07.2016 um 14:14 schrieb Stephen Farrell >>>> : >>>> >>>> >>>> Hiya, >>>> >>>> I agree with your conclusion that we seem to have clearly set out=20 >>>> where we disagree without so far changing one another's >>>> conclusions. So I only have one more thing to add for now, which is >>>> about the form of, and not the content of, the discussion. You >>>> said: >>>> >>>> On 30/07/16 12:07, Mirja K=C3=BChlewind wrote: >>>>> Enabling large scale encryption that is deployable is the goal >>>>> of PLUS. And this enables two things: increased security and >>>>> privacy, as well as transport evolution. For the first goal we >>>>> need encryption and maintain the status quo (regarding network >>>>> manageability), while for the second part, we envision the >>>>> development and use of new transports that enable new services. >>>>> Not having a tool to also enable some innovation in the network >>>>> to support these services, archives the goal only half way. >>>> >>>> I'm fine with and fully accept the first sentence. >>>> >>>> The rest of that paragraph however seems to me to beg the >>>> question, that is, it assumes that a deployed PLUS-solution will be >>>> an overall good, when it is exactly that that I and others wish to >>>> question. I do think this is an issue in this discussion and was in >>>> the BoF - the proponents, being convinced that the solution is >>>> needed, assume that the solution is needed when answering those who >>>> are questioning whether we'd be better or worse off should PLUS be >>>> developed further. >>>> >>>> That's probably natural given folks have been working on SPUD/PLUS=20 >>>> for some time, but it seems to me to hinder discussion with folks >>>> like me who are far from convinced that the envisaged solution is >>>> at all desirable. So my apologies for trying to drag you back to >>>> what you likely consider first principles you probably figured were >>>> done with a couple of years ago, but I think that's actually fair >>>> and to be expected when one has a BoF of this kind. >>>> >>>> Cheers, S. >>>> >>>> >>>>> >>>>>>> >>>> >>> >>> _______________________________________________ Privsec-program >>> mailing list Privsec-program@iab.org=20 >>> https://www.iab.org/mailman/listinfo/privsec-program >>> >> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >=20 --------------ms040504080604090700060903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MzEx NjAzMThaMC8GCSqGSIb3DQEJBDEiBCCxmRu06VQbEBCfkZb4/QekagGroCwLiyyE642pqNz9 JjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCjaPQlfhfaV+lh1vuzwKcm4keYnJSHa2BsOYGnXrrs+zZe2cX83esn uFPl6FAwiYNDR6FcICtliauRr57Q9RVze7E+Vc8IzrnCAJUBY7KcEiHcowiHxmGN1FZ32beA BLUUypRY7yt4+JrdCgfEkJpGD+WUixf5FXJ253D5k80b7PyMcbHzTc84JhVATOmgaRgOmDYY j79nfUp3HL00hNXS2Vtrm6OCvEe+pMGGIzJLDAbWZoUpTEJuMs3R1gytRlE55ke85LN6xAL2 ouOfYWBUB965V6yL+Q/mB69GaVZJ3fFhifHHm5SSxdc0hLguCBNfXLwn2Z2RvErrPDlshFKT AAAAAAAA --------------ms040504080604090700060903-- From nobody Sun Jul 31 09:04:33 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4F012B046 for ; Sun, 31 Jul 2016 09:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 FHnd_F4gnY_f for ; Sun, 31 Jul 2016 09:04:31 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E536A12B015 for ; Sun, 31 Jul 2016 09:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2962; q=dns/txt; s=iport; t=1469981071; x=1471190671; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=pL2u4I2iZKOQgO4CiCWvvX0OocXDecQDsz7d+HdKuJQ=; b=kiK3XZNbWyYy6zAZw1wUJF/0uRT6xrS5UIWcXligZi92akppHsoaENmS FeE7t2yC1p5x3csR5Bz4ZIa18kWId6icKRjCnHRmCbrLJ6SfdJLhrKX2/ YmlrFhwtHB9wrWyDZ0CETvWASPLxNwHtwv2fcZhbHhxUfP7GyVHtWFfWs 8=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgBQBYIJ5X/xbLJq1dhEW7WoYdAoFwA?= =?us-ascii?q?QEBAQEBXieEXwEFI1YQC0ICAlcGAQwIAQGILbBRj08BAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEODogiglWHQYJaAQSZM4M6gXCJVYlThWyQJ1SCEhyBTjqJLwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,450,1464652800"; d="asc'?scan'208";a="638653238" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2016 16:04:28 +0000 Received: from [10.61.88.130] (ams3-vpn-dhcp6275.cisco.com [10.61.88.130]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6VG4Sjw024566; Sun, 31 Jul 2016 16:04:28 GMT To: Stephen Farrell , =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> From: Eliot Lear Message-ID: <240cab8d-8e5b-4fa6-c45a-0389a4b499e2@cisco.com> Date: Sun, 31 Jul 2016 18:04:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rKNQhwsOhEDMavwdN3KNUQBWjathCpemL" Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 16:04:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rKNQhwsOhEDMavwdN3KNUQBWjathCpemL Content-Type: multipart/mixed; boundary="6842kNiSSQWDeiNref5h3DC2SaJD4rIML" From: Eliot Lear To: Stephen Farrell , =?UTF-8?Q?Mirja_K=c3=bchlewind?= Cc: Brian Trammell , privsec-program@iab.org, spud Message-ID: <240cab8d-8e5b-4fa6-c45a-0389a4b499e2@cisco.com> Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> In-Reply-To: <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> --6842kNiSSQWDeiNref5h3DC2SaJD4rIML Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 7/31/16 4:05 PM, Stephen Farrell wrote: > - I am unconvinced that "giving up" some privacy in the manner > envisaged will lead to an overall privacy benefit. I very much > fear that opposite - that any extensible mechanism will give up > so much privacy so as to render much higher layer confidentiality > moot. This is the problem with this discussion. You fear giving up privacy.=20 There is no protocol to assuage your fears. Mirja has said that they didn't want to propose a protocol, presumably out of appearing to present a fait accomplit, and round and round we go. I propose the following: Someone show bits, and then let's see if your concerns are borne out or assuaged. This argument is too abstract. Eliot --6842kNiSSQWDeiNref5h3DC2SaJD4rIML-- --rKNQhwsOhEDMavwdN3KNUQBWjathCpemL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXniGLAAoJEIe2a0bZ0nozOZoH/2iwKFENQRAypWl4oUeIEvQg dYQS6T6bliOeLcGM8n7omTjBjP/UDHCys3yJNvcdFEbTOPWycYvkoLeIShFvJSGw 7OTMlKx3rei/0DQUtkz9H1jgZVpN9MGGKu5IO2KhnDHPnpfb5TaiqggAW6lH/v7e zS8Rlvk+2xlnYzRiV3yoqe1LIOr7iv7zrDKHGHDAM01WhbTVFJEmCfRgd2lyKlbo QXYKLPwyRbu1+43W89Jo4grNZRy7urjPS+mZOo+DeDubNml4Nfw5CVJ07n5iFv7G ZWwShvpMCHThUDsHuJI1RDNUqZ02mR4ku5IIv5CUQ4qeEnIR2zgTbHPl7FxLPiw= =jnDl -----END PGP SIGNATURE----- --rKNQhwsOhEDMavwdN3KNUQBWjathCpemL-- From nobody Sun Jul 31 09:13:16 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CA112D1C8 for ; Sun, 31 Jul 2016 09:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 TM5TplValBen for ; Sun, 31 Jul 2016 09:13:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9488112D1D2 for ; Sun, 31 Jul 2016 09:13:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4FF0ABE49; Sun, 31 Jul 2016 17:13:08 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSjM74A6Go2z; Sun, 31 Jul 2016 17:13:07 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 608CBBE56; Sun, 31 Jul 2016 17:13:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469981586; bh=mCkb0HzM/c0tV8LLmg+iMwFDEVhOf3c0FO8QygDTwMQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=z4HXKsZkMyn/PViYrtg8CtUe9QnyDu2HgnE7brYqoYlxRNr/R5qucsIyqAE4nhjXh mTAkbpqoWdwK/AUNpFPtBG++hUPHQ07xRtpT3KwXkj4vhTFqRTib0Xh1ka9oQIu4ni nRkMB+JlGk5rBZyBs71O8Xq9w06ausZVHbedtsD0= To: Eliot Lear , =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <240cab8d-8e5b-4fa6-c45a-0389a4b499e2@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <764437fb-cd83-654e-345a-4d79aaef9e6a@cs.tcd.ie> Date: Sun, 31 Jul 2016 17:13:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <240cab8d-8e5b-4fa6-c45a-0389a4b499e2@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iBQQ5vLktKrPDsN9pePanVn58b08XxsCf" Archived-At: Cc: Brian Trammell , privsec-program@iab.org, spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 16:13:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iBQQ5vLktKrPDsN9pePanVn58b08XxsCf Content-Type: multipart/mixed; boundary="g4O6BOu2G6opoNDJIbiErau5mursfig45" From: Stephen Farrell To: Eliot Lear , =?UTF-8?Q?Mirja_K=c3=bchlewind?= Cc: Brian Trammell , privsec-program@iab.org, spud Message-ID: <764437fb-cd83-654e-345a-4d79aaef9e6a@cs.tcd.ie> Subject: Re: [Privsec-program] [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <240cab8d-8e5b-4fa6-c45a-0389a4b499e2@cisco.com> In-Reply-To: <240cab8d-8e5b-4fa6-c45a-0389a4b499e2@cisco.com> --g4O6BOu2G6opoNDJIbiErau5mursfig45 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 31/07/16 17:04, Eliot Lear wrote: > Hi, >=20 >=20 > On 7/31/16 4:05 PM, Stephen Farrell wrote: >=20 >> - I am unconvinced that "giving up" some privacy in the manner >> envisaged will lead to an overall privacy benefit. I very much >> fear that opposite - that any extensible mechanism will give up >> so much privacy so as to render much higher layer confidentiality >> moot. >=20 > This is the problem with this discussion. You fear giving up privacy. = > There is no protocol to assuage your fears. Mirja has said that they > didn't want to propose a protocol, presumably out of appearing to > present a fait accomplit, and round and round we go. I propose the > following: >=20 > Someone show bits, and then let's see if your concerns are borne out or= > assuaged. This argument is too abstract. Well yes and no. Yes, I can't see how to assuage the fears of those with privacy concerns without at least a straw-man. So the proponent's choice to not provide even that does make the discussion more abstract and less likely to conclude. But no, the proponents of the PLUS BoF suggested a charter that explicitly stated that the solution needed an IANA registry for extensibility and even specified an update rule for that putative registry. I am wholly convinced such a registry with any set of 5226 rules is an error and bad to very bad for privacy. See all the times I've said "over 18" and similar. I don't think I need to know more about the on the wire framing of those codepoints (official or squatted-upon) to reach my conclusion. Whether a protocol without any extensibility or with some other extensibility mechanism would be ok or not is not something about which I've expressed an opinion so far. (Well, at least I've tried to be neutral, but I fully admit that sometimes what I try write as neutral, folks read as opinionated;-) Cheers, S. >=20 > Eliot >=20 >=20 >=20 >=20 > _______________________________________________ > Privsec-program mailing list > Privsec-program@iab.org > https://www.iab.org/mailman/listinfo/privsec-program >=20 --g4O6BOu2G6opoNDJIbiErau5mursfig45-- --iBQQ5vLktKrPDsN9pePanVn58b08XxsCf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXniOSAAoJEC88hzaAX42i5ugIAJInX2Y3fGK3i11mgOadS43C iiaQ8eniv1ndtKUpE3e2gjjZM31OjunEYM4JdBrgN0ZBQn3xq0KXEl9F1MsAe1eF OUpeG2crztAnngtSGNQTm1HNhUocBm4OV7RxQfmm4M/9Ic4iaUyTdlKReNhbA0wY wQ33cUtEhgF7QSvPquuIJ8aDvGuSE0gUfCoX9S51u6rzyVxHhkgt6Vz0KCQdqS80 ZB8pvGVpgx+u11DMoW9M/6H4AP3ERQJGf53Rt5xMTFRKELPMbGs10Z/Or5QZ0851 nMOHe5XEpF9c6QvDOfed7VJ7wF7Ki8unGFWSEU0+V8DsBIgrXKjhMDRhmsHMUqI= =sX2E -----END PGP SIGNATURE----- --iBQQ5vLktKrPDsN9pePanVn58b08XxsCf-- From nobody Sun Jul 31 12:06:43 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B1212D5B4 for ; Sun, 31 Jul 2016 12:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 LyRhrPuwjSHY for ; Sun, 31 Jul 2016 12:06:39 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A58C12D182 for ; Sun, 31 Jul 2016 12:06:39 -0700 (PDT) Received: from [192.168.1.7] (p4FE312A4.dip0.t-ipconnect.de [79.227.18.164]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 9BD22721E280D; Sun, 31 Jul 2016 21:06:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> Date: Sun, 31 Jul 2016 21:06:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , privsec-program@iab.org, =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 19:06:42 -0000 > On 31 Jul 2016, at 18:03, Stephen Farrell = wrote: >=20 >=20 >=20 > On 31/07/16 16:45, Michael Tuexen wrote: >> On 31 Jul 2016, at 16:05, Stephen Farrell = wrote: >>>=20 >>>=20 >>> Hiya, >>>=20 >>> On 31/07/16 13:57, Mirja K=C3=BChlewind wrote: >>>> Hi Stephen, >>>>=20 >>>> yes, I believe that the proposed mechanisms are needed (in the = first >>>> place to address the ossification problem we see in transport - to >>>> phrase it at a light level) and yes, I believe that the proposed >>>> approaches have the potential to improve but at least doesn=E2=80=99t= degrade >>>> the situation in general but also the privacy situation that we = have >>>> today in the Internet. If I wouldn=E2=80=99t believe that, I = wouldn=E2=80=99t propose >>>> it. >>>>=20 >>>> The technical basis for this believe (regarding privacy) is that we >>>> propose a mechanism for integrity checking that is stronger than = what >>>> we have today in transport and therefore makes mangling as least >>>> detectable. Further, I believe that only a cooperative approach = will >>>> enable large-scale encrypting (that includes transport headers) >>>> because otherwise operators may be incentivized to block traffic, = and >>>> in this sense standardization of a mechanism for middlebox >>>> communication would draw a much clearer line about what we as a >>>> community deem acceptable and what not, instead of declaring all >>>> in-network functions other than routing as evil. >>>>=20 >>>> I intentionally used the word =E2=80=9Abelieve=E2=80=98 here = several times because as >>>> stated in my previous mail we just have probably very different >>>> starting points. I do think some parts of our discussion involved >>>> technical questions, and I hope I could clarify some points. = However, >>>> other parts of the discussion are naturally more vague because we >>>> both don=E2=80=99t know the future. However, in this sense these = =E2=80=9Afirst >>>> principles=E2=80=98, as I believe you called them below, are purely = what >>>> people believe. But, please note that one of these =E2=80=9Afirst = principles=E2=80=98 >>>> is that we in transport see a problem with the ossification today, >>>> and PLUS is foremost a proposal to address this problem (by = enabling >>>> encryption). Given this, I don=E2=80=99t really understand what = your comment >>>> about the form of the discussion is below. >>>=20 >>> Let me try to clarify a couple of important places where my beliefs >>> and yours don't seem to co-incide: >>>=20 >>> - I'm not sure the ossification issue is as-it-was 3 years ago, >>> given QUIC, and to some extent h2 and TLS1.3, but also due to >>> the much increased deployment of TLS. Given such changes, it >>> is not at all clear to me that a generic approach (like PLUS >>> attempts) is best. >> Hi Stephen, >>=20 >> so do you mean future transport protocols (running over UDP) should >> define their own protocol specific way of exposing information, >> similar to the way QUIC does it? >> That would require constant evolution of middleboxes (NAT, = firewalls). >>=20 >> Or are you suggesting that future transport protocols should just >> use the framing of QUIC (for the unencrypted part) and reuse >> the (hopefully) upcoming QUIC support of middleboxes? >=20 > I didn't mean either. OK. >=20 > What I meant was that perhaps the analysis that lead to the > conclusions about ossification of the transport layer needs > to be re-done now, give the increase in use of TLS and given > QIUC is now highly likely to be an IETF WG. (That's a similar > question to asking if PLUS is OBE, which I think I asked of > Brian.) What has changed? Building and deploying UDP based transport protocols in combination with crypto has been done earlier. For example in RTMFP by Adobe: https://tools.ietf.org/html/rfc7016 https://tools.ietf.org/html/rfc7425 Other companies did develop their own protocols and did not publish it as an RFC. In the IETF we developed SCTP over UDP and SCTP over DTLS over UDP: https://tools.ietf.org/html/rfc6951 https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-09 All of these activities (including QUIC) focuses on the end points and can/are deployed without specific middlebox support. >=20 > IIUC the IAB w/s that sorta lead to SPUD then PLUS happened > before QUIC was mooted as work in the IETF and before many > services had switched from port 80 to 443. The crucial point is what was brought up in the QUIC BOF: Middlebox vendors (I think it was a Firewall vendor at the mic) explicitly stated that they want to see the QUIC work done in the IETF such that they can build support for QUIC in their products. As far as I understood their argument, it was about knowing a bit regarding QUIC flows (when is it opened, when closed) to deal with them. This might result in QUIC specific support by middleboxes. SPUD/PLUS would allow this for future transports, if middlebox vendors would add support for SPUD/PLUS (which they might or might not do given that there is currently no protocol using it). So do you think that there is no need for middleboxes to support transport protocols? That would be an important point also when looking into the requirements of QUIC. Best regards Michael >=20 > S. >=20 >>=20 >> Best regards >> Michael >>> - I am unconvinced that "giving up" some privacy in the manner >>> envisaged will lead to an overall privacy benefit. I very much >>> fear that opposite - that any extensible mechanism will give up >>> so much privacy so as to render much higher layer confidentiality >>> moot. >>>=20 >>> What I meant when referring to first principles was being explicit >>> in how we're arguing based our these starting points (or beliefs). >>>=20 >>> My perception of the argument (in this thread and the BoF) is that >>> it is harder because the proponents of PLUS were assuming sharted >>> beliefs/starting points when responding to folks who have very >>> different starting assumptions. >>>=20 >>> So for example, I don't think I've seen any of the PLUS proponents >>> directly provide arguments as to why my concerns/beliefs above >>> are unfounded. (I have seen assertions that they are unfounded but >>> not arguments starting from assumptions with which I'd agree.) And >>> my guess is that the proponents are not doing that because they >>> think it was already done. (If a pointer to the SPUD archive is >>> usable to answer this point, that's entirely fine.) >>>=20 >>>>=20 >>>> However as you mentioned the BoF belong, I actually also have a >>>> comment on the form of discussion: this activity is on-going for = more >>>> than one year. We mainly worked during this time on addressing >>>> security questions that were raised at the spud BoF. Based on one >>>> request on the mailing before the PLUS BoF we explained how we >>>> address privacy concerns and how we think this makes the current >>>> situation at least not worse and probably better. We did not get = only >>>> further feedback on mailing list assuming that our proposal is >>>> acceptable. And there was no future discussion about any privacy = and >>>> security aspects on the list before the BoF. I would really >>>> appreciate if people could constructively help us to find a = solution >>>> to address the ossification problem in transport while maintain or >>>> improving the privacy situation we have today, instead of just >>>> blocking new work. >>>=20 >>> Yeah, that's fair. It is of course hard to get input from folks >>> who are worried that the work as envisaged inevitably leads to a >>> bad outcome. (So e.g. I'm not subscribed to the SPUD list and am >>> not sure I'd have time and the energy to be on there constantly >>> trying to drag you back to 1st principles;-) >>>=20 >>> Cheers, >>> S. >>>=20 >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>=20 >>>>> Am 30.07.2016 um 14:14 schrieb Stephen Farrell >>>>> : >>>>>=20 >>>>>=20 >>>>> Hiya, >>>>>=20 >>>>> I agree with your conclusion that we seem to have clearly set out=20= >>>>> where we disagree without so far changing one another's >>>>> conclusions. So I only have one more thing to add for now, which = is >>>>> about the form of, and not the content of, the discussion. You >>>>> said: >>>>>=20 >>>>> On 30/07/16 12:07, Mirja K=C3=BChlewind wrote: >>>>>> Enabling large scale encryption that is deployable is the goal >>>>>> of PLUS. And this enables two things: increased security and >>>>>> privacy, as well as transport evolution. For the first goal we >>>>>> need encryption and maintain the status quo (regarding network >>>>>> manageability), while for the second part, we envision the >>>>>> development and use of new transports that enable new services. >>>>>> Not having a tool to also enable some innovation in the network >>>>>> to support these services, archives the goal only half way. >>>>>=20 >>>>> I'm fine with and fully accept the first sentence. >>>>>=20 >>>>> The rest of that paragraph however seems to me to beg the >>>>> question, that is, it assumes that a deployed PLUS-solution will = be >>>>> an overall good, when it is exactly that that I and others wish to >>>>> question. I do think this is an issue in this discussion and was = in >>>>> the BoF - the proponents, being convinced that the solution is >>>>> needed, assume that the solution is needed when answering those = who >>>>> are questioning whether we'd be better or worse off should PLUS be >>>>> developed further. >>>>>=20 >>>>> That's probably natural given folks have been working on SPUD/PLUS=20= >>>>> for some time, but it seems to me to hinder discussion with folks >>>>> like me who are far from convinced that the envisaged solution is >>>>> at all desirable. So my apologies for trying to drag you back to >>>>> what you likely consider first principles you probably figured = were >>>>> done with a couple of years ago, but I think that's actually fair >>>>> and to be expected when one has a BoF of this kind. >>>>>=20 >>>>> Cheers, S. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ Privsec-program >>>> mailing list Privsec-program@iab.org=20 >>>> https://www.iab.org/mailman/listinfo/privsec-program >>>>=20 >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>=20 >=20 From nobody Sun Jul 31 13:10:20 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6333612D0B9 for ; Sun, 31 Jul 2016 13:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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 jUyyzz9bfgbc for ; Sun, 31 Jul 2016 13:10:18 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0138.outbound.protection.outlook.com [104.47.33.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8B412B020 for ; Sun, 31 Jul 2016 13:10:18 -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=RlyYfAhYpWAO4x8McN+Dffly+xN9/fOGcujogOhv/uw=; b=eUhwlpmbJ2SDkip/sahfWTaf4wflMt+LFi56yO4L/bmgo25JPZFr6LaPqQok2ghi3vCIuOdB9teWSxLGA+EVbRBAqgWyru50g5doa1nYtT5apU546vn3cbyqugW5Y7BJwd3b5yLNzGOjwL8uT99kXOyJAd3uhlBeOAcBY+LptCs= Received: from BN6PR03MB2675.namprd03.prod.outlook.com (10.173.143.150) by BN6PR03MB2674.namprd03.prod.outlook.com (10.173.143.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Sun, 31 Jul 2016 20:10:15 +0000 Received: from BN6PR03MB2675.namprd03.prod.outlook.com ([10.173.143.150]) by BN6PR03MB2675.namprd03.prod.outlook.com ([10.173.143.150]) with mapi id 15.01.0549.022; Sun, 31 Jul 2016 20:10:14 +0000 From: Christian Huitema To: Brian Trammell , spud , "privsec-program@iab.org" Thread-Topic: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks Thread-Index: AQHR6ZVz3wpM8J2u0ky72gV8CNidkqAy82Uw Date: Sun, 31 Jul 2016 20:10:14 +0000 Message-ID: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> In-Reply-To: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [24.16.156.113] x-ms-office365-filtering-correlation-id: 2f2ecbcc-33e2-4df3-d3f5-08d3b97eaf72 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2674; 6:eRmVLRy7HFWMJ61D4DbcBOO340ezNtKiyWFqr30f1K60NutOYMDkiWI3hTHD/DGQoDsCSP1YrY8eaJwwCM3EcgUlHGUnvjqBu00Z/T/DNWOK9U1sBN40WdGkliJjwsvX4fc6gW/UdXqmKovYfHYinFDvrJ1YQJEtw0WnbUy/0ClCtcjPf4B1EC9DBukB7PC9MDoIsrbX7dnNBM+cfs5CitoWDn6+tYMKcQllaQEoSR+hk+Vuu3sYiFKapMJnuer+yYXzkWVJPeAd0rhpCPzZLC87sO8CvvtqitnObgwcoyY4K/UZ4bQJDvcNNZJrWwi/TIaJe4XSPq3pYOg0LhCtbA==; 5:vO0M9AcltnB1R7npnxkLLDPkrBYU/nnTkeZutshG4CtFhyyMdlu59gn7YDiLKPsGXd6TRbtCwyPO2OB91+pql0/b1EViwSH4Mrw6CFdAuaTH2zJaT5OH0hpOBC4tc5RZg4YfHUjYZ5vZTjDPWYqS3g==; 24:LgINKGmyu1quFbWD9lskVnzavXr7xx8FD073vveap1pM1U27JlEjN8CcdBMu3tZ6C8hggbQCnDYa3JJ08+dDV6bSj3wb+ysKQEZcMGAXP+A=; 7:FaEXeFjz3g5H/6CwmiJDWZCgdBxD52wfyRU/sC+sujDajwixifFpeCxat5Q9ptB3G4N9SQ0BsJyEFMWB5EZRifHlr/L0D1ER+MOTvUsyiLAPCQOwfRO8NgVthAFeJeOFVFAfozzoLjsWm+2jb595vqNIQmlT8ON4yCiFZDiRoTf8I/CEeFWg5DvJZFZY4VR2XFgDZYPfSXblD7hNR6fA/eCeOYbiRSXnn+nRw4q0oDPPFbuI2l+WWp72IIDcZx6c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2674; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2674; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2674; x-forefront-prvs: 0020414413 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(24454002)(189002)(101416001)(54356999)(106356001)(33656002)(122556002)(50986999)(76176999)(77096005)(66066001)(3846002)(6116002)(8936002)(19580395003)(102836003)(5002640100001)(2906002)(586003)(81156014)(81166006)(8990500004)(8676002)(106116001)(3660700001)(2501003)(2900100001)(9686002)(76576001)(189998001)(10400500002)(7696003)(3280700002)(7736002)(7846002)(2950100001)(86612001)(74316002)(10290500002)(92566002)(87936001)(99286002)(305945005)(105586002)(10090500001)(5005710100001)(68736007)(15975445007)(107886002)(97736004)(5001770100001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2674; H:BN6PR03MB2675.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2016 20:10:14.7295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2674 Archived-At: Subject: Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 20:10:20 -0000 On Friday, July 29, 2016 5:34 AM, Brian Trammell wrote: >... >... As I said > during my presentation last Thursday, Ted Hardie and I sat down to think > about this at lunch a couple of months ago, and found six ways one could > execute hypercookie injection or coercion today before our pizza showed u= p. >=20 > I sat down a little longer to write these up. I found five more, without = even > considering trivial out-of-band metadata leaks or steganographic side > channels. https://tools.ietf.org/html/draft-trammell-privsec-defeating-tc= pip- > meta-00 is the result. The conclusion: these attacks are trivially easy t= o > execute today by exploiting the gap between valid TCP traffic and what wi= ll be > ignored by TCP-indifferent devices and endpoints, as well as all those ju= icy bits > IPv6 gives you... The original message generated a long thread of comments, but I would like = to look back at Brian's draft. First of all, this is an interesting piece o= f information, and I would like to thank Brian for writing it down. Whether= we believe that additional shim headers are wise or not, we should certain= ly look at current privacy threats against TCP and IP, and as much as possi= ble deploy mitigations. Here is a set of detailed comments: - Section 4.1.2, regarding DHCPv6, ought to quote RFC 7844, Anonymity Profi= les for DHCP Clients, which specifies mitigations for that threat. - Section 4.1.3, Identification using IPv6 network address translation, pro= bably needs a bit more context. The NAT can only identify the user context = if it links that context to a User-ID, which is somewhat hard for shared co= nnections. But we should take this seriously and develop mitigations, e.g. = end-to-end encrypted options that report the address seen by the peer. It w= ould not prevent translation, but it would expose the practice. - Section 4.2.1. Fragment Identification Rewriting. Maybe it is time to sp= ecify in IP that if the "don't fragment" bit is set, the fragment identifie= r MUST be set to all zeroes, and SHOULD be reset to zero on reception. If e= nough end systems and intermediaries do that, this side channel becomes unr= eliable. - Section 4.3. Abusing Transmission Control Protocol Features. All that is= true, but it is also part of the rationales for deploying encrypted transp= orts like QUIC. As far as I can tell, none of these attacks apply to QUIC. = Which is indeed the point made in section 5. The draft mentions the IPv6 flow-ID, but creative intermediaries might also= manipulate the TOS fields, so maybe there should be a subsection describin= g that too. And we could also have recommendations for API designs that exp= ose the received values, so cooperating endpoints could detect alterations. I think the draft should be extended to also cover UDP, and in particular t= he side channel created by the potential gap between IP packet length and U= DP packet length. My personal preference would be to instruct middleboxes a= nd end-systems to simply drop packets in which UDP length and IP length do = not match. -- Christian Huitema From nobody Sun Jul 31 13:13:53 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187A212D0A7 for ; Sun, 31 Jul 2016 13:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Hf_i1OO9c7HM for ; Sun, 31 Jul 2016 13:13:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC8712B027 for ; Sun, 31 Jul 2016 13:13:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 46064BE75; Sun, 31 Jul 2016 21:13:46 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0Se9rj0OXoh; Sun, 31 Jul 2016 21:13:44 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ECC1CBE73; Sun, 31 Jul 2016 21:13:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469996024; bh=0MagIxt7DmHXmYPOR33TWTMItQkop5B7vbBUzkGgSjg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=LmJgowESTTX+EAk10YlYnOGDhqlCIek7wvp5/TqSLQXZxdTuML3LwMQcGZszzAPjP p+GNqZDwUzxp6QFiqxU36QY7/zCeCFV+XaGlEDzfvW91kiaCGMKrcqQzsA0v3hoNwR 1ujMQLzSFCLXOSewVkHcvBCjcWn3EC1m3cIh/25Q= To: Michael Tuexen References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> Date: Sun, 31 Jul 2016 21:13:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090801070609080008090501" Archived-At: Cc: Brian Trammell , privsec-program@iab.org, =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 20:13:51 -0000 This is a cryptographically signed message in MIME format. --------------ms090801070609080008090501 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 31/07/16 20:06, Michael Tuexen wrote: > So do you think that there is no need for > middleboxes to support transport protocols?=20 I have no strong opinions on that. I would be surprised if middleboxes wanted to support PLUS if they think that QUIC is what will be widely deployed. But then I am often surprised;-) Hence my wondering about PLUS being OBE, despite SCTP etc substantially pre-dating QUIC. I do think significant port 443 and QUIC deployment may change the landscape in ways that the definition and implementation of SCTP did not. > That would be > an important point also when looking into the requirements > of QUIC. As I've said a number of times, I think the extensibility as proposed at the PLUS BoF is the major privacy problem. I've also said that I'm so far neutral on a non-extensible way of exposing some transport information to the path (if one exists and is useful, which I also don't claim to know). I would however be opposed if "transport information" is so broadly interpreted as to include identifiers or generic attributes of the endpoints that are not otherwise exposed. And that's before we consider the coercion attack raised at the BoF and (so far) briefly mentioned in Brian's draft. Cheers, S. --------------ms090801070609080008090501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MzEy MDEzNDNaMC8GCSqGSIb3DQEJBDEiBCCiCLnVPiRtTrq02dcA3A+dFoLqtzYcP0W7jli/pM2j IjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB7t7BjAlaDRk/LvrVEXRX5zNH7jGxE8l0HskH5H+00ZnvF8lXTBTOn HR0mLvn9wR8RIeQZLKnZC0EKDotUDQZz8rrPULNoLfM+CnCKWv/Qgiw0MWwg3jDubGmuVxid 8fdMhg5WHVcTJmXES6ON2GtIlIwbgs12r+8rWxCbV7x1nuOOG+sGY3a+okzZZbGrkLn+cxBa aK6+hvFvXNA2KtNVLivKtnoMbc/YWGBBbVE4uypYRikXylqzeL1ZbB4BV4tCXy8Eu5SDmkDr Wj8/KgxdQ2HbaeL/WC4tMG0HZKubC/5W1LU4lICJIbr1xHGJsYBiEHmBeSbcta2tFyiYKtF1 AAAAAAAA --------------ms090801070609080008090501-- From nobody Sun Jul 31 13:22:47 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B2312B020 for ; Sun, 31 Jul 2016 13:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 LAwSWmfDDRzZ for ; Sun, 31 Jul 2016 13:22:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8485812B027 for ; Sun, 31 Jul 2016 13:22:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9C257BE75; Sun, 31 Jul 2016 21:14:48 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCiQW6xkfB4l; Sun, 31 Jul 2016 21:14:47 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E52A2BE73; Sun, 31 Jul 2016 21:14:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469996087; bh=DCMrwBQyoSMvgVyw8XleK842mZTqb2H2xSIytxjrYw0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=K+Vlc/dfDxvdwnLCdFJVrd3C9QRCh7O02CtBE1vBniWEymoiD6t2P1orHIy9skz94 n117hvafimiJ2zZe4dO2iLw7SEBziqRIHV/cTzQoa2blYIhKf2x7ReN1cf1p8VoZYl Bk7/h4/sdhBQbjjDa7A0xGN692fwo7UFSx/zc6BI= To: Christian Huitema , Brian Trammell , spud , "privsec-program@iab.org" References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 31 Jul 2016 21:14:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030508060602020005000408" Archived-At: Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 20:22:42 -0000 This is a cryptographically signed message in MIME format. --------------ms030508060602020005000408 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 31/07/16 21:10, Christian Huitema wrote: > First of all, this is an interesting piece of information, and I > would like to thank Brian for writing it down. Whether we believe > that additional shim headers are wise or not, we should certainly > look at current privacy threats against TCP and IP, and as much as > possible deploy mitigations. In case my verbosity in this thread has obscured it... I do agree with the above. S. --------------ms030508060602020005000408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MzEy MDE0NDZaMC8GCSqGSIb3DQEJBDEiBCDoa7QaCBWu2vnMMkXkKwFBEJvjH3pqh/qbVhKwLndr kDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB3oFiK/bxf6PqdgScOgX4o3muHeOYlxao2aIfyQiN6NsnHO7Ew3yai OQhLtzTUu2QgLSj0YkE14dWsdtKDCufKb3rd/buxGrbfmOIN0UREdJpYvVtZvo4zlIP1iACp MxFEjkZIgjIov4jx/+N4LgOj1YVyHMQbRjO2PAM4hQ1uWJ5b/Fa3hV3ZHulWcKjhkwVd0DPR VVocvYtvIZgWGoncJMUuXbFS0Gj1fyCbnDRp8h+HANKvKdy7qTcCqnnx+70958LbugJ1BkFc 76dEdgIAlGZL8nb1mfXO/JGI91i9jB/B+q3GAaWv1/iGFDTro8ghmpOBzE/mRi/y1vRS7+xU AAAAAAAA --------------ms030508060602020005000408-- From nobody Sun Jul 31 14:12:53 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188A112B069 for ; Sun, 31 Jul 2016 14:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 yWJPilkwruBk for ; Sun, 31 Jul 2016 14:12:50 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3C26F12D0D8 for ; Sun, 31 Jul 2016 14:12:50 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id CA0041A0128; Sun, 31 Jul 2016 23:12:48 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4A9223D6-710D-4C07-8EE2-CB87EB42EDA6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <240cab8d-8e5b-4fa6-c45a-0389a4b499e2@cisco.com> Date: Sun, 31 Jul 2016 23:12:48 +0200 Message-Id: <0AADE895-353A-4860-AA4F-8D8C3E1F5C2D@trammell.ch> References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <240cab8d-8e5b-4fa6-c45a-0389a4b499e2@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spud , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Stephen Farrell Subject: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 21:12:52 -0000 --Apple-Mail=_4A9223D6-710D-4C07-8EE2-CB87EB42EDA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Eliot, all, (dropping privsec-program; we're not talking about hypercookies anymore) > On 31 Jul 2016, at 18:04, Eliot Lear wrote: >=20 > Hi, >=20 >=20 > On 7/31/16 4:05 PM, Stephen Farrell wrote: >=20 >> - I am unconvinced that "giving up" some privacy in the manner >> envisaged will lead to an overall privacy benefit. I very much >> fear that opposite - that any extensible mechanism will give up >> so much privacy so as to render much higher layer confidentiality >> moot. >=20 > This is the problem with this discussion. You fear giving up privacy. > There is no protocol to assuage your fears. Mirja has said that they > didn't want to propose a protocol, presumably out of appearing to > present a fait accomplit, and round and round we go. I propose the > following: >=20 > Someone show bits, and then let's see if your concerns are borne out = or > assuaged. This argument is too abstract. We think we have a reasonable solution to the transport-independent = state exposure problem that doesn't suffer from the issues identified = with simple start/stop signaling. Since this been the core of PLUS since = before its predecessor was called SPUD, we wanted to nail this down = before showing bits. We expect to do this in the next week or so. Cheers, Brian --Apple-Mail=_4A9223D6-710D-4C07-8EE2-CB87EB42EDA6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXnmnQAAoJEIoSt78L6kaj9h8P/17Ffq0yHZ14HiVhROgXpXp7 xs++GYrHIavVsixFol5hQH0kQQYVAcQKAC8cFFVZD49Qf8onpGh2MxtiAxN3m8uh eoL64nN9+onDFsqZhDnkp3mAvR5YjtESonqzyLYPVJUjts/oDgXdLhxfz8X+tgJx Nqi4vlLhJK3gsOS0bCZsU6ixB0BEv7o0809GVHtXGJCvxy60Nrjy2g0WjwgngeQ5 FaEXoeaA9WPY9wsh66nxGovtyEM0bDI3iZBd9Uo+3UIR4CxDvgXIfhjs3n352VYM vN2ZITUqB/KowCSEOjWJ7dpxANn7s0/+7u7IB5nJue7ddazuOvPh3Eey7Pm8GxgY 6gidy2Z6UkaDGhUFwHWp2J37nDiip8YGafazdlI2lBr590QlbrJuA5+6yMBVJJim WjwpDVzpiUU9T6QpzR9lUdrmuaP5nZJkSTbbAATU6FCDhtBgTCmxfAqsqUbyjLQZ gxamOErtgetYufiNHxhwKYnmdeN5xhI3x5u4UM80KdWVqcN5ovMqc17AOcwoAjGK pEpOi5EMXUaPVxX+fzlx9ScToagRnk9OpI3cO9UEJ2p4xbwwip1mDxVQuMaPdWpe nHpnRtBwe6QmT8lEMEVs/1uHbtDNTC7GXDUf0Ug4QpBfwpe//O3i8xUSOPMbcyZq zi2gCdTXqF/QxXIoZ1hh =ZM0S -----END PGP SIGNATURE----- --Apple-Mail=_4A9223D6-710D-4C07-8EE2-CB87EB42EDA6-- From nobody Sun Jul 31 14:22:47 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D059612D0A8 for ; Sun, 31 Jul 2016 14:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 SejHiBQs45A0 for ; Sun, 31 Jul 2016 14:22:44 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073AE12D0D8 for ; Sun, 31 Jul 2016 14:22:44 -0700 (PDT) Received: from [192.168.1.7] (p4FE312A4.dip0.t-ipconnect.de [79.227.18.164]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 4EAC1721E280D; Sun, 31 Jul 2016 23:22:41 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> Date: Sun, 31 Jul 2016 23:22:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <531F6161-E6C6-4D1E-AC3E-DDD4BD72CCAA@lurchi.franken.de> References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , privsec-program@iab.org, =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 21:22:46 -0000 > On 31 Jul 2016, at 22:13, Stephen Farrell = wrote: >=20 >=20 >=20 > On 31/07/16 20:06, Michael Tuexen wrote: >> So do you think that there is no need for >> middleboxes to support transport protocols?=20 >=20 > I have no strong opinions on that. >=20 > I would be surprised if middleboxes wanted to support PLUS > if they think that QUIC is what will be widely deployed. But That might be true and is a new flavour of ossification... Using PLUS would allow multiple transports to be deployed with the same level of middlebox support (whatever that would be). I guess this is the difference. > then I am often surprised;-) >=20 > Hence my wondering about PLUS being OBE, despite SCTP etc > substantially pre-dating QUIC. I do think significant port 443 > and QUIC deployment may change the landscape in ways that the > definition and implementation of SCTP did not. Sure. SCTP (with UDP encapsulation) hasn't been considered as a transport for main stream applications. The point of PLUS is that someone might come up with another transport protocol optimised for something QUIC is not optimised for and they wouldn't have to think about middlebox interaction. Or they can just use the unencrypted QUIC framing as a non-extensible way of PLUS and do their own protocol in the encrypted part... >=20 >> That would be >> an important point also when looking into the requirements >> of QUIC. >=20 > As I've said a number of times, I think the extensibility > as proposed at the PLUS BoF is the major privacy problem. > I've also said that I'm so far neutral on a non-extensible > way of exposing some transport information to the path (if > one exists and is useful, which I also don't claim to know). I see. This is why you are happy with QUIC, but have concerns about PLUS. >=20 > I would however be opposed if "transport information" is so > broadly interpreted as to include identifiers or generic attributes > of the endpoints that are not otherwise exposed. Sure. Best regards Michael >=20 > And that's before we consider the coercion attack raised > at the BoF and (so far) briefly mentioned in Brian's draft. >=20 > Cheers, > S. >=20 >=20 From nobody Sun Jul 31 15:14:04 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A615012B012 for ; Sun, 31 Jul 2016 15:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N07O29ZQAuts for ; Sun, 31 Jul 2016 15:14:00 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 1E25E128B44 for ; Sun, 31 Jul 2016 15:14:00 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id u134so158066944ywg.3 for ; Sun, 31 Jul 2016 15:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1xttxH8EH1H2xdpCV0P23DFzzFFLuXJ3Qfj4ZOXTVes=; b=eaSQjtGxHdJ7qIA/0uQK3FJVyMj3CDfb/DOEILsvjBI0lUAllsYsOR3FCIp9rXAapG pMLqHx58IuClKNxIoKIrlhZDDyKoGdqHgqEuOr/Ife4sjsO5S/rSuhL3QjxWj8yKIyCQ euKbkOnv5Yfey6BaFrBQbwuQhA4sKdDQenvZDwVHTShCEBrrQRfEjx50w7Ox7Ib5HC4n UWhJqsUlb/8Fz1jncQ4BcoZAyPgku5eVeSA5OAHX+xbmDHMdcsT9abeNqgw/X5iSE2AO 4jb07XgFaAO/fijG1oTkNfOPuV+0Ca9sFC8WyFJQ/tyBBILShmdj+igT9U5G4jCy+i35 sL4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1xttxH8EH1H2xdpCV0P23DFzzFFLuXJ3Qfj4ZOXTVes=; b=U5JjqqYhcjmsWMOYeRDaQ6WSo2fWws7pANGxI34gCf6g1/ykgwJMChTM3yskFmo0l8 sgHV55roXSbBiOFrexTS26dOTpi4fZy5o0WnLKZ+5twPw84oqMaHNy5Qc5ZgFichaaun 59hI2+ZuZkxBg5aCDbcvyFEgDnS7vtYkxJaGbhFFiebvS6zNwFcPl1JZZ8ybuj4zICYx 3B0oMSJU6f+hKpwSzJR4Etyw0X9nKwod3jB53+2RwFkF2qE49Xtl/jw3rdRziLVH5Sjp QjDI+HdDj9RS03qGdBbkYLLfugf3KcDyltWhAkNgsWo6EGrVsdyntYLaQug9ur6kYUhh 3Eqw== X-Gm-Message-State: AEkooutNv+nSLsEhH4FAapK+rCxQRYDCltx+3VNRaM7jXEMuwbcwUJVLMnT8lHP8VMvOP59/px+QdKdw4WJMaA== X-Received: by 10.129.73.207 with SMTP id w198mr42783797ywa.64.1470003239105; Sun, 31 Jul 2016 15:13:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.231.198 with HTTP; Sun, 31 Jul 2016 15:13:57 -0700 (PDT) Received: by 10.37.231.198 with HTTP; Sun, 31 Jul 2016 15:13:57 -0700 (PDT) In-Reply-To: <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> From: Spencer Dawkins at IETF Date: Sun, 31 Jul 2016 17:13:57 -0500 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a114dc91ce2c4b40538f5cca0 Archived-At: Cc: Brian Trammell , privsec-program@iab.org, =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud@ietf.org Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 22:14:02 -0000 --001a114dc91ce2c4b40538f5cca0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On one specific point ... On Jul 31, 2016 09:05, "Stephen Farrell" wrote: > > > Hiya, > > On 31/07/16 13:57, Mirja K=C3=BChlewind wrote: > > Hi Stephen, > > > > yes, I believe that the proposed mechanisms are needed (in the first > > place to address the ossification problem we see in transport - to > > phrase it at a light level) and yes, I believe that the proposed > > approaches have the potential to improve but at least doesn=E2=80=99t d= egrade > > the situation in general but also the privacy situation that we have > > today in the Internet. If I wouldn=E2=80=99t believe that, I wouldn=E2= =80=99t propose > > it. > > > > The technical basis for this believe (regarding privacy) is that we > > propose a mechanism for integrity checking that is stronger than what > > we have today in transport and therefore makes mangling as least > > detectable. Further, I believe that only a cooperative approach will > > enable large-scale encrypting (that includes transport headers) > > because otherwise operators may be incentivized to block traffic, and > > in this sense standardization of a mechanism for middlebox > > communication would draw a much clearer line about what we as a > > community deem acceptable and what not, instead of declaring all > > in-network functions other than routing as evil. > > > > I intentionally used the word =E2=80=9Abelieve=E2=80=98 here several ti= mes because as > > stated in my previous mail we just have probably very different > > starting points. I do think some parts of our discussion involved > > technical questions, and I hope I could clarify some points. However, > > other parts of the discussion are naturally more vague because we > > both don=E2=80=99t know the future. However, in this sense these =E2=80= =9Afirst > > principles=E2=80=98, as I believe you called them below, are purely wha= t > > people believe. But, please note that one of these =E2=80=9Afirst princ= iples=E2=80=98 > > is that we in transport see a problem with the ossification today, > > and PLUS is foremost a proposal to address this problem (by enabling > > encryption). Given this, I don=E2=80=99t really understand what your co= mment > > about the form of the discussion is below. > > Let me try to clarify a couple of important places where my beliefs > and yours don't seem to co-incide: > > - I'm not sure the ossification issue is as-it-was 3 years ago, > given QUIC, and to some extent h2 and TLS1.3, but also due to > the much increased deployment of TLS. It seems to me that understanding the current levels and rate of change on deployment of these technologies would be extremely helpful, given the discussions we are having. Spencer > Given such changes, it > is not at all clear to me that a generic approach (like PLUS > attempts) is best. > - I am unconvinced that "giving up" some privacy in the manner > envisaged will lead to an overall privacy benefit. I very much > fear that opposite - that any extensible mechanism will give up > so much privacy so as to render much higher layer confidentiality > moot. > > What I meant when referring to first principles was being explicit > in how we're arguing based our these starting points (or beliefs). > > My perception of the argument (in this thread and the BoF) is that > it is harder because the proponents of PLUS were assuming sharted > beliefs/starting points when responding to folks who have very > different starting assumptions. > > So for example, I don't think I've seen any of the PLUS proponents > directly provide arguments as to why my concerns/beliefs above > are unfounded. (I have seen assertions that they are unfounded but > not arguments starting from assumptions with which I'd agree.) And > my guess is that the proponents are not doing that because they > think it was already done. (If a pointer to the SPUD archive is > usable to answer this point, that's entirely fine.) > > > > > However as you mentioned the BoF belong, I actually also have a > > comment on the form of discussion: this activity is on-going for more > > than one year. We mainly worked during this time on addressing > > security questions that were raised at the spud BoF. Based on one > > request on the mailing before the PLUS BoF we explained how we > > address privacy concerns and how we think this makes the current > > situation at least not worse and probably better. We did not get only > > further feedback on mailing list assuming that our proposal is > > acceptable. And there was no future discussion about any privacy and > > security aspects on the list before the BoF. I would really > > appreciate if people could constructively help us to find a solution > > to address the ossification problem in transport while maintain or > > improving the privacy situation we have today, instead of just > > blocking new work. > > Yeah, that's fair. It is of course hard to get input from folks > who are worried that the work as envisaged inevitably leads to a > bad outcome. (So e.g. I'm not subscribed to the SPUD list and am > not sure I'd have time and the energy to be on there constantly > trying to drag you back to 1st principles;-) > > Cheers, > S. > > > > > Mirja > > > > > > > >> Am 30.07.2016 um 14:14 schrieb Stephen Farrell > >> : > >> > >> > >> Hiya, > >> > >> I agree with your conclusion that we seem to have clearly set out > >> where we disagree without so far changing one another's > >> conclusions. So I only have one more thing to add for now, which is > >> about the form of, and not the content of, the discussion. You > >> said: > >> > >> On 30/07/16 12:07, Mirja K=C3=BChlewind wrote: > >>> Enabling large scale encryption that is deployable is the goal > >>> of PLUS. And this enables two things: increased security and > >>> privacy, as well as transport evolution. For the first goal we > >>> need encryption and maintain the status quo (regarding network > >>> manageability), while for the second part, we envision the > >>> development and use of new transports that enable new services. > >>> Not having a tool to also enable some innovation in the network > >>> to support these services, archives the goal only half way. > >> > >> I'm fine with and fully accept the first sentence. > >> > >> The rest of that paragraph however seems to me to beg the > >> question, that is, it assumes that a deployed PLUS-solution will be > >> an overall good, when it is exactly that that I and others wish to > >> question. I do think this is an issue in this discussion and was in > >> the BoF - the proponents, being convinced that the solution is > >> needed, assume that the solution is needed when answering those who > >> are questioning whether we'd be better or worse off should PLUS be > >> developed further. > >> > >> That's probably natural given folks have been working on SPUD/PLUS > >> for some time, but it seems to me to hinder discussion with folks > >> like me who are far from convinced that the envisaged solution is > >> at all desirable. So my apologies for trying to drag you back to > >> what you likely consider first principles you probably figured were > >> done with a couple of years ago, but I think that's actually fair > >> and to be expected when one has a BoF of this kind. > >> > >> Cheers, S. > >> > >> > >>> > >>>>> > >> > > > > _______________________________________________ Privsec-program > > mailing list Privsec-program@iab.org > > https://www.iab.org/mailman/listinfo/privsec-program > > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --001a114dc91ce2c4b40538f5cca0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On one specific point ...

On Jul 31, 2016 09:05, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> w= rote:
>
>
> Hiya,
>
> On 31/07/16 13:57, Mirja K=C3=BChlewind wrote:
> > Hi Stephen,
> >
> > yes, I believe that the proposed mechanisms are needed (in the fi= rst
> > place to address the ossification problem we see in transport - t= o
> > phrase it at a light level) and yes, I believe that the proposed<= br> > > approaches have the potential to improve but at least doesn=E2=80= =99t degrade
> > the situation in general but also the privacy situation that we h= ave
> > today in the Internet. If I wouldn=E2=80=99t believe that, I woul= dn=E2=80=99t propose
> > it.
> >
> > The technical basis for this believe (regarding privacy) is that = we
> > propose a mechanism for integrity checking that is stronger than = what
> > we have today in transport and therefore makes mangling as least<= br> > > detectable. Further, I believe that only a cooperative approach w= ill
> > enable large-scale encrypting (that includes transport headers) > > because otherwise operators may be incentivized to block traffic,= and
> > in this sense standardization of a mechanism for middlebox
> > communication would draw a much clearer line about what we as a > > community deem acceptable and what not, instead of declaring all<= br> > > in-network functions other than routing as evil.
> >
> > I intentionally used the word =E2=80=9Abelieve=E2=80=98 here seve= ral times because as
> > stated in my previous mail we just have probably very different > > starting points. I do think some parts of our discussion involved=
> > technical questions, and I hope I could clarify some points. Howe= ver,
> > other parts of the discussion are naturally more vague because we=
> > both don=E2=80=99t know the future. However, in this sense these = =E2=80=9Afirst
> > principles=E2=80=98, as I believe you called them below, are pure= ly what
> > people believe. But, please note that one of these =E2=80=9Afirst= principles=E2=80=98
> > is that we in transport see a problem with the ossification today= ,
> > and PLUS is foremost a proposal to address this problem (by enabl= ing
> > encryption). Given this, I don=E2=80=99t really understand what y= our comment
> > about the form of the discussion is below.
>
> Let me try to clarify a couple of important places where my beliefs > and yours don't seem to co-incide:
>
> - I'm not sure the ossification issue is as-it-was 3 years ago, > =C2=A0 given QUIC, and to some extent h2 and TLS1.3, but also due to > =C2=A0 the much increased deployment of TLS.

It seems to me that understanding the current levels and rat= e of change on deployment of these technologies would be extremely helpful,= given the discussions we are having.

Spencer

> Given such changes, it
> =C2=A0 is not at all clear to me that a generic approach (like PLUS > =C2=A0 attempts) is best.
> - I am unconvinced that "giving up" some privacy in the mann= er
> =C2=A0 envisaged will lead to an overall privacy benefit. I very much<= br> > =C2=A0 fear that opposite - that any extensible mechanism will give up=
> =C2=A0 so much privacy so as to render much higher layer confidentiali= ty
> =C2=A0 moot.
>
> What I meant when referring to first principles was being explicit
> in how we're arguing based our these starting points (or beliefs).=
>
> My perception of the argument (in this thread and the BoF) is that
> it is harder because the proponents of PLUS were assuming sharted
> beliefs/starting points when responding to folks who have very
> different starting assumptions.
>
> So for example, I don't think I've seen any of the PLUS propon= ents
> directly provide arguments as to why my concerns/beliefs above
> are unfounded. (I have seen assertions that they are unfounded but
> not arguments starting from assumptions with which I'd agree.) And=
> my guess is that the proponents are not doing that because they
> think it was already done. (If a pointer to the SPUD archive is
> usable to answer this point, that's entirely fine.)
>
> >
> > However as you mentioned the BoF belong, I actually also have a > > comment on the form of discussion: this activity is on-going for = more
> > than one year. We mainly worked during this time on addressing > > security questions that were raised at the spud BoF. Based on one=
> > request on the mailing before the PLUS BoF we explained how we > > address privacy concerns and how we think this makes the current<= br> > > situation at least not worse and probably better. We did not get = only
> > further feedback on mailing list assuming that our proposal is > > acceptable. And there was no future discussion about any privacy = and
> > security aspects on the list before the BoF. I would really
> > appreciate if people could constructively help us to find a solut= ion
> > to address the ossification problem in transport while maintain o= r
> > improving the privacy situation we have today, instead of just > > blocking new work.
>
> Yeah, that's fair. It is of course hard to get input from folks > who are worried that the work as envisaged inevitably leads to a
> bad outcome. (So e.g. I'm not subscribed to the SPUD list and am > not sure I'd have time and the energy to be on there constantly > trying to drag you back to 1st principles;-)
>
> Cheers,
> S.
>
> >
> > Mirja
> >
> >
> >
> >> Am 30.07.2016 um 14:14 schrieb Stephen Farrell
> >> <stephen.farr= ell@cs.tcd.ie>:
> >>
> >>
> >> Hiya,
> >>
> >> I agree with your conclusion that we seem to have clearly set= out
> >> where we disagree without so far changing one another's > >> conclusions. So I only have one more thing to add for now, wh= ich is
> >> about the form of, and not the content of, the discussion. Yo= u
> >> said:
> >>
> >> On 30/07/16 12:07, Mirja K=C3=BChlewind wrote:
> >>> Enabling large scale encryption that is deployable is the= goal
> >>> of PLUS. And this enables two things: increased security = and
> >>> privacy, as well as transport evolution. For the first go= al we
> >>> need encryption and maintain the status quo (regarding ne= twork
> >>> manageability), while for the second part, we envision th= e
> >>> development and use of new transports that enable new ser= vices.
> >>> Not having a tool to also enable some innovation in the n= etwork
> >>> to support these services, archives the goal only half wa= y.
> >>
> >> I'm fine with and fully accept the first sentence.
> >>
> >> The rest of that paragraph however seems to me to beg the
> >> question, that is, it assumes that a deployed PLUS-solution w= ill be
> >> an overall good, when it is exactly that that I and others wi= sh to
> >> question. I do think this is an issue in this discussion and = was in
> >> the BoF - the proponents, being convinced that the solution i= s
> >> needed, assume that the solution is needed when answering tho= se who
> >> are questioning whether we'd be better or worse off shoul= d PLUS be
> >> developed further.
> >>
> >> That's probably natural given folks have been working on = SPUD/PLUS
> >> for some time, but it seems to me to hinder discussion with f= olks
> >> like me who are far from convinced that the envisaged solutio= n is
> >> at all desirable. So my apologies for trying to drag you back= to
> >> what you likely consider first principles you probably figure= d were
> >> done with a couple of years ago, but I think that's actua= lly fair
> >> and to be expected when one has a BoF of this kind.
> >>
> >> Cheers, S.
> >>
> >>
> >>>
> >>>>>
> >>
> >
> > _______________________________________________ Privsec-program > > mailing list Privsec-p= rogram@iab.org
> > = https://www.iab.org/mailman/listinfo/privsec-program
> >
>
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.iet= f.org/mailman/listinfo/spud
>

--001a114dc91ce2c4b40538f5cca0-- From nobody Sun Jul 31 15:49:27 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A8112B059 for ; Sun, 31 Jul 2016 15:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 OVp2vMP1Idci for ; Sun, 31 Jul 2016 15:49:24 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 7F3BE12B03D for ; Sun, 31 Jul 2016 15:49:24 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id u186so231490622ita.0 for ; Sun, 31 Jul 2016 15:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=piv/IceWdZHY+trR9ccb7H2ZfunqIw1CJdrGKJjgW1A=; b=pFoA8r9qJH8TFv9PoNUaLPgw/u2Z99F0iiGZ/u8OrFDju2F/sNrQXUWAVt3NwOQZy1 y2grOuk+cqOYZt4eExC6Xlal30yUnkourPDKXBaZMcnUrZOW6yV4Nwzc6U5rnDhAQpGb NwGZg3Ta4OcRvP5p+VRteLn7FDhAk2/V7tUwFTJAPWKH3TD62zUeTjkkPhtHk/E+FjRs t3mNvFdBS80ag4WIyeiTiGmP8psOj2Ir70NHF6vb4kUw4BC6t+DCVQJIhkmeyEJmvnM2 5SeFER0Jd6OzJOVJYEW6WsEL2S7CyTbyERgZJzyfSJBDozaDtyYN4h2Sw8NrTTgxdnjJ CE2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=piv/IceWdZHY+trR9ccb7H2ZfunqIw1CJdrGKJjgW1A=; b=Yy21qD8Y4LuZ9Wb/QZBNjh7fvr48cbJeNEV83zt8heHR1MBktxaXqPc0BammIx49ex Mqq9fi7ePL2XRH85kz6AnH0b+THo4NfLVns61mE13usUzOfWKoCxotKat4vlblIev9jo 7Qtd8s9DlVYfminquDatuivv0xfVlbQbQvOZdOBlNCKPz+brfZBJyWAD9NC9dAoIWckx 9DTNd+MQD+TfNYqqQgJs/7JPUrvL5qT9tCX7oOP9oMRIFUuw6MHjZYjJvyb2ilvdz17G 8p6EVwxUitqn/iwGPqPe23l1CPzCfD2D++3nzKd0D37QyKqLB/z+l0vBIx3lu5q40aOQ 55rg== X-Gm-Message-State: AEkoouu6cox84KYslwA7q0V50NrhhDW0mJuWR00JwPRf8m3xO3uf8qzAOJqe7AvL0C8bUW70CRjhEUNjhr7jhw== X-Received: by 10.36.51.206 with SMTP id k197mr33628872itk.37.1470005363602; Sun, 31 Jul 2016 15:49:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.130 with HTTP; Sun, 31 Jul 2016 15:49:22 -0700 (PDT) In-Reply-To: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> From: Tom Herbert Date: Sun, 31 Jul 2016 15:49:22 -0700 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Trammell , spud Subject: Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 22:49:27 -0000 On Sun, Jul 31, 2016 at 1:10 PM, Christian Huitema wrote: > On Friday, July 29, 2016 5:34 AM, Brian Trammell wrote: > >>... >>... As I said >> during my presentation last Thursday, Ted Hardie and I sat down to think >> about this at lunch a couple of months ago, and found six ways one could >> execute hypercookie injection or coercion today before our pizza showed = up. >> >> I sat down a little longer to write these up. I found five more, without= even >> considering trivial out-of-band metadata leaks or steganographic side >> channels. https://tools.ietf.org/html/draft-trammell-privsec-defeating-t= cpip- >> meta-00 is the result. The conclusion: these attacks are trivially easy = to >> execute today by exploiting the gap between valid TCP traffic and what w= ill be >> ignored by TCP-indifferent devices and endpoints, as well as all those j= uicy bits >> IPv6 gives you... > > The original message generated a long thread of comments, but I would lik= e to look back at Brian's draft. First of all, this is an interesting piece= of information, and I would like to thank Brian for writing it down. Wheth= er we believe that additional shim headers are wise or not, we should certa= inly look at current privacy threats against TCP and IP, and as much as pos= sible deploy mitigations. > > Here is a set of detailed comments: > > - Section 4.1.2, regarding DHCPv6, ought to quote RFC 7844, Anonymity Pro= files for DHCP Clients, which specifies mitigations for that threat. > > - Section 4.1.3, Identification using IPv6 network address translation, p= robably needs a bit more context. The NAT can only identify the user contex= t if it links that context to a User-ID, which is somewhat hard for shared = connections. But we should take this seriously and develop mitigations, e.g= . end-to-end encrypted options that report the address seen by the peer. It= would not prevent translation, but it would expose the practice. > > - Section 4.2.1. Fragment Identification Rewriting. Maybe it is time to = specify in IP that if the "don't fragment" bit is set, the fragment identif= ier MUST be set to all zeroes, and SHOULD be reset to zero on reception. If= enough end systems and intermediaries do that, this side channel becomes u= nreliable. > > - Section 4.3. Abusing Transmission Control Protocol Features. All that = is true, but it is also part of the rationales for deploying encrypted tran= sports like QUIC. As far as I can tell, none of these attacks apply to QUIC= . Which is indeed the point made in section 5. > > The draft mentions the IPv6 flow-ID, but creative intermediaries might al= so manipulate the TOS fields, so maybe there should be a subsection describ= ing that too. And we could also have recommendations for API designs that e= xpose the received values, so cooperating endpoints could detect alteration= s. > > I think the draft should be extended to also cover UDP, and in particular= the side channel created by the potential gap between IP packet length and= UDP packet length. My personal preference would be to instruct middleboxes= and end-systems to simply drop packets in which UDP length and IP length d= o not match. > Such an ad hoc policy implemented in middleboxes effectively precludes the proposed UDP options (draft-touch-tsvwg-udp-options-03) and provides yet one more example of how protocol ossification kills innovation. Tom From nobody Sun Jul 31 16:33:50 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCA812D0AD for ; Sun, 31 Jul 2016 16:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 dAm1707l4dKL for ; Sun, 31 Jul 2016 16:33:47 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id A161412B01F for ; Sun, 31 Jul 2016 16:33:45 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 3AB801A04CE; Mon, 1 Aug 2016 01:33:44 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_914402AD-4CB3-42C6-A7BB-BB760651854B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> Date: Mon, 1 Aug 2016 01:33:43 +0200 Message-Id: References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Michael Tuexen , =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 23:33:49 -0000 --Apple-Mail=_914402AD-4CB3-42C6-A7BB-BB760651854B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Stephen, A couple of points inline: > On 31 Jul 2016, at 22:13, Stephen Farrell = wrote: >=20 >=20 >=20 > On 31/07/16 20:06, Michael Tuexen wrote: >> So do you think that there is no need for >> middleboxes to support transport protocols? >=20 > I have no strong opinions on that. >=20 > I would be surprised if middleboxes wanted to support PLUS > if they think that QUIC is what will be widely deployed. But > then I am often surprised;-) QUIC is a single transport protocol, designed for a fairly specific kind = of interaction (H2, and things that look a lot like it; "fully-reliable = discrete object transfer" might be a suitable name for this class of = application). Despite the fact that "web" and "internet" (in the lower-case, = AP-style-guide sense) are often used interchangeably, other applications = exist. Interactive video is one of the biggest of these by volume on the = Internet. While it can be and has been wedged into HTTP (largely due to = the ossification PLUS is intended to combat), it is a bad fit. Even the = design of non-interactive video over HTTP implies a good deal of = inefficiency, in part due to that "fully-reliable". If we would like the benefits of transport header integrity to accrue to = these applications as well (and I hope I've made the case that we do), = there are a few things we can do: (1) Design a common wire image for new transports (most of which in the = intermediate term will probably have to slot over UDP, as QUIC does). = This is the PLUS approach. (2) Realize we'll probably only get one more chance to deploy a new = transport in the next two decades, and make QUIC work well for other = points in the application design space. This would come at a cost of = complexity in the design and implementation of QUIC. (3) Don't expand QUIC's design, but wedge these new applications over = QUIC even though it's a terrible fit. This at least has the benefit of = complying with tradition. :) (4) Have other new transports' wire images look like a transport that is = already widely deployed. If QUIC becomes successful, I would expect to = see at least experiments to get other non-QUIC protocols to look like = QUIC on the wire, a la TCP Minion. Note that when discussing QUIC, it is of course important to distinguish = the Google QUIC experiment from the protocol that the QUIC WG (which I = presume will be formed) will standardize. So (3) and (4) might actually = be talking about two subtly different QUICs when considering the = transition to the standard. SPDY/H2 has at least shown that we know how = to make this transition work relatively quickly (or is that speedily? ;) = ) > Hence my wondering about PLUS being OBE, despite SCTP etc > substantially pre-dating QUIC. I do think significant port 443 Nope: HTTPS over tcp/443 does nothing at all for making it possible to = deploy applications that don't wedge nicely atop HTTP, nothing at all = for running those over anything but TCP, and nothing for transport = header integrity. > and QUIC deployment may change the landscape in ways that the > definition and implementation of SCTP did not. QUIC deployment did indeed change the landscape: it added 2 and 3 to the = list above. Both are extremely suboptimal. >> That would be >> an important point also when looking into the requirements >> of QUIC. >=20 > As I've said a number of times, I think the extensibility > as proposed at the PLUS BoF is the major privacy problem. Speaking for myself: I've heard you. I continue to disagree (vehemently) = that zero bits of extensibility is the right amount of extensibility, = simply based on what I know about the history of bad engineering. = However, I will say that my thinking, at least, has gone from unlimited = permissionless definition of signals (the SPUD prototype, which was = expressly experimental) to highly restricted definition of signals (PLUS = as described in the charter) to restricted definition of signals with = severely limited header / codepoint space, to address privacy as well as = overhead concerns. This implies a tradeoff in the ability to fix things = we got wrong later, of course. > I've also said that I'm so far neutral on a non-extensible > way of exposing some transport information to the path (if > one exists and is useful, which I also don't claim to know). There appears to us to exist a useful set of signals that are = transport-agnostic, the minimal set of which we hope to have a full = description of (with bits, yay!!) shortly, as in my message to Eliot. > I would however be opposed if "transport information" is so > broadly interpreted as to include identifiers or generic attributes > of the endpoints that are not otherwise exposed. As would I. I am frankly a little baffled as to who you think is = proposing this interpretation. > And that's before we consider the coercion attack raised > at the BoF and (so far) briefly mentioned in Brian's draft. As noted, I'm convinced the threat posed by coercion attack is very = real, today. I still don't buy the assertion that PLUS expands this = surface. Regards, Brian --Apple-Mail=_914402AD-4CB3-42C6-A7BB-BB760651854B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXnorYAAoJEIoSt78L6kaj9SwP/2ycDm0IsZ8OPwkmWSfGzMoL Hpnqj6Q3112JXQXBrmP2L+3AWSDXLkcr3SU5eF/jgcS+UbOR3pMKy2y4B/idJt+E rNw9Q8RFAwPBBmBTLUqMfkSZbS9xB2bYSvyTn5+wyCnZrZg00E8iVtD9xcBcEpeQ UOGYMgnY1uDJv4xJKICZ3Ou6OnkQ+azumjGuT9UWW3lu8rXnwTWqnGImC3l7oIdp gcw4knSbmhoj1xMx+czUMQj2+gE4O6tDrmHXB2GxxU9wgm9XIO8qTRdeWOxgjgXY SSSV6WfpsMSsjbR68lGRMnjOMWK1p3aYUGEWiREK0FUWxvLe7XdNJvrBcG1f0IYW ppDvYHa1EMqGwHwGjtqH3RIgzs7dtelixkSs2kQqBjR0H4o7PERU1rt7pEVdNOsS /8eo0QecTH5yKtFqR/dEl7llb2x1bFu45C5aujMswkl2Dy5WZ0wSr62cA8YbLZbN 43OrQN7Ot1SBXQABfarC8NRBKgYbHlgx0/u6/z0CUU+RB1BGJJD4AGiJ8wI1XeuS 9xXsM+RpBOg8oRj6FxNqwzL38kMwIismlOsX6Lg+nm8U57GUO+ihFnhbiw94LgvM XUF9cdWhjuFrXtvzMLQdxyCg6cfN8qMwmsoSfdydzGYkxiIy9c1BXnnpgKIaQeQM Lm/XWp5jj13V7uZnaj4a =GTAI -----END PGP SIGNATURE----- --Apple-Mail=_914402AD-4CB3-42C6-A7BB-BB760651854B-- From nobody Sun Jul 31 18:01:34 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD3D12B02A for ; Sun, 31 Jul 2016 18:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 L8Wem3tgI2c0 for ; Sun, 31 Jul 2016 18:01:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7AC128874 for ; Sun, 31 Jul 2016 18:01:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 15DECBE3E; Mon, 1 Aug 2016 02:01:27 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj48LbCw8CX4; Mon, 1 Aug 2016 02:01:24 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3C2EABE25; Mon, 1 Aug 2016 02:01:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1470013284; bh=fSmXt3u7i27dZZWXLiulQFvB/ghmzgVPYOeNjmx8aaQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YPEcSiM/iQMZT6rzPt9zoz5GEzZjdl+O3IhU5AnyM3pbJrYSwY4gvsuppeyEoh7cM /thk0czi/XzrItv2lfxE+MD8CT8ZVC0TtNmQqnfNzwr8x4ejk9m4Bwam+vBuClNmz9 WuorhISJ8kVYeOoPY9FqM3qwrYO2r6s4rO0WJb3k= To: Brian Trammell References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 1 Aug 2016 02:01:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QWoWKCBe0SFaWd78bGSP1VVgKpucn4utE" Archived-At: Cc: Michael Tuexen , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Subject: Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 01:01:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QWoWKCBe0SFaWd78bGSP1VVgKpucn4utE Content-Type: multipart/mixed; boundary="3A1BSh0pVjrfMNvTUsgPIsmBWg4Cn0WNv" From: Stephen Farrell To: Brian Trammell Cc: Michael Tuexen , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Message-ID: Subject: Re: Extensibility considered harmful? was Re: [Privsec-program] [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie> In-Reply-To: --3A1BSh0pVjrfMNvTUsgPIsmBWg4Cn0WNv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/08/16 00:33, Brian Trammell wrote: > hi Stephen, >=20 > A couple of points inline: >=20 >> On 31 Jul 2016, at 22:13, Stephen Farrell >> wrote: >>=20 >>=20 >>=20 >> On 31/07/16 20:06, Michael Tuexen wrote: >>> So do you think that there is no need for middleboxes to support >>> transport protocols? >>=20 >> I have no strong opinions on that. >>=20 >> I would be surprised if middleboxes wanted to support PLUS if they >> think that QUIC is what will be widely deployed. But then I am >> often surprised;-) >=20 > QUIC is a single transport protocol, designed for a fairly specific > kind of interaction (H2, and things that look a lot like it; > "fully-reliable discrete object transfer" might be a suitable name > for this class of application). >=20 > Despite the fact that "web" and "internet" (in the lower-case, > AP-style-guide sense) are often used interchangeably, other > applications exist. Interactive video is one of the biggest of these > by volume on the Internet. While it can be and has been wedged into > HTTP (largely due to the ossification PLUS is intended to combat), it > is a bad fit. Even the design of non-interactive video over HTTP > implies a good deal of inefficiency, in part due to that > "fully-reliable". There are of course many suboptimal ways in which people can get stuff they need to work... to work. My experience is that people are more interested in "working" and not in "optimal." The point here is that the web model is sufficiently close to many many things applications need to be just usable enough. So while I'd love to see evidence that application developers care deeply about transport efficiency/purity, I suspect we might all here agree that such evidence would be surprising. >=20 > If we would like the benefits of transport header integrity to accrue > to these applications as well (and I hope I've made the case that we > do),=20 IMO that case has not been made to the point where I would consider it justifies privacy downsides. IOW, while I am of course in favour of endpoints being able to signal to one another without middlebox interference, I am not at all on side with transport header integrity being counted as a major win in the analysis of PLUS, if that "win" inherently requires a significant privacy cost. (And I am clearly happy to endlessly repeat myself that in this particular case: extensibility =3D=3D privacy unfriendly > there are a few things we can do: >=20 >=20 > (1) Design a common wire image for new transports (most of which in > the intermediate term will probably have to slot over UDP, as QUIC > does). This is the PLUS approach. >=20 > (2) Realize we'll probably only get one more chance to deploy a new > transport in the next two decades, and make QUIC work well for other > points in the application design space. This would come at a cost of > complexity in the design and implementation of QUIC. >=20 > (3) Don't expand QUIC's design, but wedge these new applications over > QUIC even though it's a terrible fit. This at least has the benefit > of complying with tradition. :) >=20 > (4) Have other new transports' wire images look like a transport that > is already widely deployed. If QUIC becomes successful, I would > expect to see at least experiments to get other non-QUIC protocols to > look like QUIC on the wire, a la TCP Minion. >=20 I don't myself back that set of options as the identifiable set of possibly credible options. Minimally, option (0) is omitted, which is to do nothing at all and to let the SPUD/PLUS idea languish as OBE. And options (1)-(4) as presented all seem to assume knowledge of the future - I think at least some options that ack that the future is uncertain would need to be considered too. >=20 > Note that when discussing QUIC, it is of course important to > distinguish the Google QUIC experiment from the protocol that the > QUIC WG (which I presume will be formed) will standardize. So (3) and > (4) might actually be talking about two subtly different QUICs when > considering the transition to the standard. SPDY/H2 has at least > shown that we know how to make this transition work relatively > quickly (or is that speedily? ;) ) Sure. I'd hope/expect a similar dynamic to emerge within the IETF participants working on PLUS. As you say, the h2 experience should be one to learn and benefit from. >> Hence my wondering about PLUS being OBE, despite SCTP etc=20 >> substantially pre-dating QUIC. I do think significant port 443 >=20 > Nope: HTTPS over tcp/443 does nothing at all for making it possible > to deploy applications that don't wedge nicely atop HTTP, nothing at > all for running those over anything but TCP, and nothing for > transport header integrity. I really don't agree about "nothing at all." People are very very inventive in how they can squeeze their new applications into whatever the hell works to get the bits from A to B. (And are also quite willing to redefine the things about which they care to be those that allow them to deploy applications that get stuff from A to B with currently deployed infrastructure.) >=20 >> and QUIC deployment may change the landscape in ways that the=20 >> definition and implementation of SCTP did not. >=20 > QUIC deployment did indeed change the landscape: it added 2 and 3 to > the list above. Both are extremely suboptimal. >=20 >>> That would be an important point also when looking into the >>> requirements of QUIC. >>=20 >> As I've said a number of times, I think the extensibility as >> proposed at the PLUS BoF is the major privacy problem. >=20 > Speaking for myself: I've heard you. Great. I look forward to seeing how we all figure out those trade offs. > I continue to disagree > (vehemently) that zero bits of extensibility is the right amount of > extensibility, simply based on what I know about the history of bad > engineering. However, I will say that my thinking, at least, has gone > from unlimited permissionless definition of signals (the SPUD > prototype, which was expressly experimental) to highly restricted > definition of signals (PLUS as described in the charter) to > restricted definition of signals with severely limited header / > codepoint space, to address privacy as well as overhead concerns. > This implies a tradeoff in the ability to fix things we got wrong > later, of course. Yes. Trade-offs are like that. Noting that in this case, I don't think anyhting bigger than a miniscule space of codepoints can be part of a privacy friendly solution - once there are enough codepoints that the two endpoints in a randomly selected transport connection can unambiguously agree to (ab)use a codepoint as their chosen signal, then the game is over. ISTM, that means even a very very few bits can be very privacy unfriendly. >=20 >> I've also said that I'm so far neutral on a non-extensible way of >> exposing some transport information to the path (if one exists and >> is useful, which I also don't claim to know). >=20 > There appears to us to exist a useful set of signals that are > transport-agnostic, the minimal set of which we hope to have a full > description of (with bits, yay!!) shortly, as in my message to > Eliot. Consider my breath bated:-) >=20 >> I would however be opposed if "transport information" is so broadly >> interpreted as to include identifiers or generic attributes of the >> endpoints that are not otherwise exposed. >=20 > As would I.=20 I'm totally unshocked at that:-) Seriously though, I do fully accept the bone-fides of all of the main disputants here. > I am frankly a little baffled as to who you think is > proposing this interpretation. If we provide enough bits to allow such mappings, then those will be abused. MSISDN enrichment as a popular mechanism tells me that if we provide a way to do even the silliest stuff, then some folks will do just that. (Because it's not silly from their POV.) >=20 >> And that's before we consider the coercion attack raised at the BoF >> and (so far) briefly mentioned in Brian's draft. >=20 > As noted, I'm convinced the threat posed by coercion attack is very > real, today.=20 That's a newish one for me so I need to learn more about it. (Not having been a student of net neutrality:-) > I still don't buy the assertion that PLUS expands this > surface. I think you and I earlier disagreed as to whether or not standardising X-that-was-already-possible does or does not expand the attack surface for threats-due-to-X. I do think a standard has at least that effect. Cheers, S. >=20 > Regards, >=20 > Brian >=20 --3A1BSh0pVjrfMNvTUsgPIsmBWg4Cn0WNv-- --QWoWKCBe0SFaWd78bGSP1VVgKpucn4utE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXnp9jAAoJEC88hzaAX42i3u8H/0+e6G/OLSD7K8/YOjoOlvT9 6uTu+NBwtokyrg88DoafTQNu+kyxZKwdBqOUcBu60Xm19HMoYl3HKBNic2urQ6B1 eRfBUI58p0ns6ioS1I/n5i0cSukrPX9v9baa+o58SXnJiGtZ16IK24d/MWCldTeL WK8vmGo9rJcK/e1fuGaovtwmneMw02nORbQh7X/+/rEfpztuaJv/Fnrzd1/rpQst YdWOrmlikX1xm+622ftiTcbKb2W0HT6GAQLSheC57tCiZrNNb3fWdbnqNe/nGOai yi+pVT9q/hsHC+b+hv0cEER6ysDzGfOzNJ336HSmpQkxLLPt37oZqjmtHSGlZew= =Dw0B -----END PGP SIGNATURE----- --QWoWKCBe0SFaWd78bGSP1VVgKpucn4utE-- From nobody Sun Jul 31 23:34:06 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1070E12D505 for ; Sun, 31 Jul 2016 23:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 EChnVdlgusDR for ; Sun, 31 Jul 2016 23:34:03 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C4912D12D for ; Sun, 31 Jul 2016 23:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2982; q=dns/txt; s=iport; t=1470033243; x=1471242843; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=mGIv1Xov/spb3k4BJXEO98XT8r2ywXMa4PA8Z4qYJJM=; b=Lek1Fqe9ngmlMM1dViajEISbV0rGiEafoJNvWMNv5lI76LsecQnSfkbH pkAZy0nX+jbHyxMIEG9G+CHbur9JyCnlcStv4OGgsyr1SgrUMTrqyRSd9 m3+gjQBYa6L3z4Wjz9pENxFKGfsHfznhEn3OxDIJvpfTAC5ALs38BZVOk c=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbBQB+7J5X/xbLJq1dhEW7YIYdAoFzA?= =?us-ascii?q?QEBAQEBXieEXwEFI1YQCxgqAgJXBgEMCAEBiC2wf49UAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBEQ6IIoJVh0GCWgEEmTODOoFwiVWJU4VskCdUg3w6iQMBAQE?= X-IronPort-AV: E=Sophos;i="5.28,454,1464652800"; d="asc'?scan'208";a="640622166" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2016 06:34:00 +0000 Received: from [10.61.231.198] ([10.61.231.198]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u716Xx0c030462; Mon, 1 Aug 2016 06:34:00 GMT To: Tom Herbert , Stephan Neuhaus References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> From: Eliot Lear Message-ID: Date: Mon, 1 Aug 2016 08:34:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N9dqNSBFhCatUmiXm7fN0GgJ0JDwnQ7Uu" Archived-At: Cc: Brian Trammell , spud , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Stephen Farrell Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 06:34:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N9dqNSBFhCatUmiXm7fN0GgJ0JDwnQ7Uu Content-Type: multipart/mixed; boundary="hmlgLGd7t76LCqE5pbODRXjCWJhrBuLjW" From: Eliot Lear To: Tom Herbert , Stephan Neuhaus Cc: Brian Trammell , Stephen Farrell , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Message-ID: Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> In-Reply-To: --hmlgLGd7t76LCqE5pbODRXjCWJhrBuLjW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/30/16 9:59 PM, Tom Herbert wrote: > > No, it's not. In fact, exposing flow start/stop information is a good > example of something that facilitates intrusiveness by middleboxes at > the transport layer. > > The purpose of exposing this information is to allow network devices > to track connections, but connection tracking in the network is > fundamentally flawed since there is no requirement that all packets of > a connection go any single network device (i.e. the Internet is packet > switched not circuit switched). Except that I will bet you that over 99.999% of connections do, and that this is particularly sufficient for home routers. Eliot --hmlgLGd7t76LCqE5pbODRXjCWJhrBuLjW-- --N9dqNSBFhCatUmiXm7fN0GgJ0JDwnQ7Uu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXnu1YAAoJEIe2a0bZ0nozXrwIAIDeP55Jwy1xRkYbnd+7e4VL iw1jkzxaFwudUYRF0HhX555yPHXbSML6UUlrbgiAJZslxpwZjQV+2c/gVn/75p+S reTzYOfbhDy1aarVwAnU0cJ2iehKLgy9i7QEpHJ25vR+55mxGWdWYdAV1qRrJfmF xn6Ta0+ip1pq2Rw7d6RxSZ6FlRB9PlIx4XTklhVhxSiLKt8P3Ldpu9B/at/Xzbz6 UP/7ZnN6Fj5xuVHwTei4KvlAiwadmIjf2P1X+PBruGEcL5sEP1jwiEzkwMKbi1ug +jcOKfcm/22Z0vc0OmlmI4Q3HpSqITQsZM9hnT8y4qsXdnXG/1iK8ZSd8o323t8= =sxUu -----END PGP SIGNATURE----- --N9dqNSBFhCatUmiXm7fN0GgJ0JDwnQ7Uu--