From nobody Thu May 19 08:04: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 8D2B312D168; Thu, 19 May 2016 08:04:56 -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 WEHS3hNvWK2G; Thu, 19 May 2016 08:04:51 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF1012D142; Thu, 19 May 2016 08:04:51 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 9B0DD1A0B50; Thu, 19 May 2016 17:04:50 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_50E4813F-6322-4AD5-A964-709A1060455A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell Date: Thu, 19 May 2016 17:04:50 +0200 Message-Id: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> References: <4FA9E868-349C-4D67-BD49-E5DDAFB73E1D@trammell.ch> To: spud@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Mirja Kuehlewind \(IETF\)" , tsv-area@ietf.org, Spencer Dawkins at IETF , stackevo-discuss@ietf.org Subject: [Spud] Possible WG-forming follow-on to SPUD 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, 19 May 2016 15:04:56 -0000 --Apple-Mail=_50E4813F-6322-4AD5-A964-709A1060455A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, all, We propose to hold a working-group forming BoF in Berlin as a follow-on = to the SPUD work, to define a common substrate protocol for encrypted = transports based on the requirements derived from experimentation with = the SPUD prototype. First, note that since the acronym "SPUD" refers primarily to the = prototype itself, any follow-on working group should have a different = name. We're using the derived requirements, not starting for the = prototype. The name is a subject for discussion, and suggestions are = welcome. To have something to put in the proposed charter, we'd propose = "Path Layer UDP Substrate" (PLUS) as a starting point. The proposed charter appears below. We're interested in hearing initial = feedback on the proposed charter in preparation for a BoF proposal (the = cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work = to do here within the IETF? Is the scope of the proposed charter = appropriate? Is there energy to do this work? Thanks, cheers, Brian and Mirja Path Layer UDP Substrate (PLUS) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D The PLUS working group=E2=80=99s goal is to enable the deployment of = new, encrypted transport protocols, while providing a transport-independent method to = signal flow semantics under transport and application control. The current Internet protocol stack has no layer for explicit signaling = of flow semantics and characteristics to network elements, nor an = integrated signaling mechanism from network elements to back to endpoints and applications. This layer never evolved within the stack, because = middleboxes and other devices on path could simply inspect and modify headers and = payload of unencrypted traffic at every layer. This implicit use of information = from the transport and application layers is a key origin of the ossification = that makes it hard or impossible to deploy new protocols. In order to support more ubiquitous deployment of encryption, explicit signaling must be added to the stack, and it must be transport protocol independent. 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. Additionally, 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. The PLUS working group will specify a new protocol as a Path Layer User 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 similar semantics to existing protocols (e.g. TCP) = to devices on path (e.g. NATs and firewalls) - allow applications and transport protocols to explicitly provide = limited information to devices on path - allow devices on path to provide feedback and information about the = path to sending endpoints, under sending endpoint control - allow devices on path to provide information about the path to = receiving endpoints, with feedback to the sending endpoint, under = sending endpoint control Note that 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 at the level of = detail that is useful for the network, while encrypting everything else. This = is important to avoid future implicit treatment and the resulting = ossification, as well as to leverage the principle of least exposure to minimize = privacy risks presented by explicit cooperation. Given that the primary goal of PLUS is to enable the deployment of = arbitrary, fully encrypted transport protocols, 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 = 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 these use cases and requirements. 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 other working groups = that could or should 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. TLS) which could be used for encryption of transport protocols running over PLUS. --Apple-Mail=_50E4813F-6322-4AD5-A964-709A1060455A 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 iQIcBAEBCgAGBQJXPdYSAAoJEIoSt78L6kajjhcP/0Hh3hRfnbmQPUGEG2hu8S8A l6a4eX5tHSd9X1aZIJ+ba/h9957/UBS1Ez6o/TGQ9r/zfxaEoXpltCp0ViAEwF+H ZhPA2dao9rxyBHbNXEAYN+baHi9Tfb2O0qGeDmH88pM/fe3CzxMVwsACU6pDJH0w U4DDBggsv+it+sWGovqLMMXu9elPmfumI6tynmXn16EmSl40o9OED6yTQhNKcLUN Mkqn+NqS5alky1pf4n9zeHYP7qnaBEsYCSU5bLfGia7V5ArGmulEW1oHdQGedove H83hzdDpmaCES4j+uLJ97uVAgkfyaYh4bIlTqo5cmGlG1OAILw2Iujb+PvJ8slra 7sJJfXizZxWbUvhAiI3Qw9BsR8thmZe+qg2ruNVaXQrCUCVMj9zssMDsg6TiH7Ar r0lubRLmRjYzPW3a0MhBN86m6C9HuGSjdfabj4ujGpb1j4VKqjU0H4MZMrococno cC3EP75Gek8W5GtMw4dB6J35gPgCNuLdas0qEjjRfAnWY4X3K/vDQmkJOZk8DtZh AS7u0bCMDW3WdTusAyeetjFDRRmoeUAdLhN4tGJwO2LFu7jMr+drG15lCoK6zSXR a1CppykfprKOdmTcZHcIJ2Ko6jyMQ8ZZPvHXEE6FayFYvX3KLOW5VTyjX1E5DFwq mYFeVRtXj8fREMwYBXsT =+/MS -----END PGP SIGNATURE----- --Apple-Mail=_50E4813F-6322-4AD5-A964-709A1060455A-- From nobody Thu May 19 10:12: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 F2C3A12D109 for ; Thu, 19 May 2016 10:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Ci0hloP59y70 for ; Thu, 19 May 2016 10:12:42 -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 8781B12D5BF for ; Thu, 19 May 2016 10:12:41 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id AEA0D71198D9E; Thu, 19 May 2016 17:12:36 +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 u4JHCdOf015826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2016 17:12:39 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 u4JHCRcL031439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 May 2016 19:12:38 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 19 May 2016 19:12:04 +0200 From: "Scharf, Michael (Nokia - DE)" To: Brian Trammell Thread-Topic: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF Thread-Index: AQHRseA50Ukv47cg8kyAjhwTgJjj85/AelIw Date: Thu, 19 May 2016 17:12:03 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> In-Reply-To: <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 19 May 2016 17:12:45 -0000 RG9lcyB0aGUgc2VudGVuY2UgLi4uDQoNCiAgVGhlIGN1cnJlbnQgSW50ZXJuZXQgcHJvdG9jb2wg c3RhY2sgaGFzIG5vIGxheWVyIGZvciBleHBsaWNpdCBzaWduYWxpbmcgb2YgZmxvdyBzZW1hbnRp Y3MgYW5kIGNoYXJhY3RlcmlzdGljcyB0byBuZXR3b3JrIGVsZW1lbnRzIC4uLg0KIA0KYWN0dWFs bHkgd2FudHMgdG8gc2F5IHNvbWV0aGluZyBsaWtlDQoNCiAgVGhlIGN1cnJlbnQgSW50ZXJuZXQg cHJvdG9jb2wgc3RhY2sgaGFzIG5vIGxheWVyIGZvciBleHBsaWNpdCAqaW4tYmFuZCogc2lnbmFs aW5nIG9mIGZsb3cgc2VtYW50aWNzIGFuZCBjaGFyYWN0ZXJpc3RpY3MgLi4uID8NCg0KSSBtYXkg YmUgd3JvbmcsIGJ1dCB0aGVyZSBpcyBubyBzaG9ydGFnZSBvZiBJRVRGIGFuZCBub24tSUVURiBw cm90b2NvbHMgdGhhdCBjYW4gc2lnbmFsIGZsb3cgc2VtYW50aWNzIGFuZCBjaGFyYWN0ZXJpc3Rp Y3Mgb3V0LW9mLWJhbmQsIGVpdGhlciBwYXRoLWNvdXBsZWQgb3IgcGF0aC1kZWNvdXBsZWQsIGUu Zy4sIGluIHRoZSBjb250cm9sIG9yIG1hbmFnZW1lbnQgcGxhbmUuIEFzIGEgcmVzdWx0LCB0aGVy ZSBhcmUgcHJvdG9jb2wgImxheWVycyIgZm9yIHRoYXQgc2lnbmFsaW5nLCBidXQgdGhleSBhcmUg bm90IGluLWJhbmQuIFRoZXJlIG1heSBhbHNvIGJlIG90aGVyIHdheXMgdG8gZml4IHRoaXMgcHJv YmxlbSAoZS5nLiwgYnkgYWRkaW5nICJlbmQtdG8tZW5kIiBvciAiaW50ZXItZG9tYWluIiBpbnN0 ZWFkIG9mICJpbi1iYW5kIikuDQoNCk1pY2hhZWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogU3RhY2tldm8tZGlzY3VzcyBbbWFpbHRvOnN0YWNrZXZvLWRpc2N1c3MtYm91 bmNlc0BpYWIub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gVHJhbW1lbGwNClNlbnQ6IFRodXJzZGF5 LCBNYXkgMTksIDIwMTYgNTowNyBQTQ0KVG86IHN0YWNrZXZvLWRpc2N1c3NAaWFiLm9yZw0KU3Vi amVjdDogW1N0YWNrZXZvLWRpc2N1c3NdIEZ3ZDogUG9zc2libGUgV0ctZm9ybWluZyBmb2xsb3ct b24gdG8gU1BVRCBCb0YNCg0KR3JlZXRpbmdzLCBhbGwsDQoNCkZvcndhcmRpbmcgdGhpcyB0byB0 aGUgY29ycmVjdCBhZGRyZXNzIGZvciB0aGlzIG1haWxpbmcgbGlzdCAob29wcykuIFBsZWFzZSBk aXNjdXNzIGF0IHNwdWRAaWV0Zi5vcmcuDQoNClRoYW5rcywgY2hlZXJzLA0KDQpCcmlhbg0KDQo+ IEJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KPiANCj4gRnJvbTogQnJpYW4gVHJhbW1lbGwgPGll dGZAdHJhbW1lbGwuY2g+DQo+IFN1YmplY3Q6IFBvc3NpYmxlIFdHLWZvcm1pbmcgZm9sbG93LW9u IHRvIFNQVUQgQm9GDQo+IERhdGU6IDE5IE1heSAyMDE2IGF0IDE3OjA0OjUwIEdNVCsyDQo+IFRv OiBzcHVkQGlldGYub3JnDQo+IENjOiBzdGFja2V2by1kaXNjdXNzQGlldGYub3JnLCB0c3YtYXJl YUBpZXRmLm9yZywgIk1pcmphIEt1ZWhsZXdpbmQgDQo+IChJRVRGKSIgPGlldGZAa3VlaGxld2lu ZC5uZXQ+LCBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiANCj4gPHNwZW5jZXJkYXdraW5zLmlldGZA Z21haWwuY29tPg0KPiANCj4gR3JlZXRpbmdzLCBhbGwsDQo+IA0KPiBXZSBwcm9wb3NlIHRvIGhv bGQgYSB3b3JraW5nLWdyb3VwIGZvcm1pbmcgQm9GIGluIEJlcmxpbiBhcyBhIGZvbGxvdy1vbiB0 byB0aGUgU1BVRCB3b3JrLCB0byBkZWZpbmUgYSBjb21tb24gc3Vic3RyYXRlIHByb3RvY29sIGZv ciBlbmNyeXB0ZWQgdHJhbnNwb3J0cyBiYXNlZCBvbiB0aGUgcmVxdWlyZW1lbnRzIGRlcml2ZWQg ZnJvbSBleHBlcmltZW50YXRpb24gd2l0aCB0aGUgU1BVRCBwcm90b3R5cGUuDQo+IA0KPiBGaXJz dCwgbm90ZSB0aGF0IHNpbmNlIHRoZSBhY3JvbnltICJTUFVEIiByZWZlcnMgcHJpbWFyaWx5IHRv IHRoZSBwcm90b3R5cGUgaXRzZWxmLCBhbnkgZm9sbG93LW9uIHdvcmtpbmcgZ3JvdXAgc2hvdWxk IGhhdmUgYSBkaWZmZXJlbnQgbmFtZS4gV2UncmUgdXNpbmcgdGhlIGRlcml2ZWQgcmVxdWlyZW1l bnRzLCBub3Qgc3RhcnRpbmcgZm9yIHRoZSBwcm90b3R5cGUuIFRoZSBuYW1lIGlzIGEgc3ViamVj dCBmb3IgZGlzY3Vzc2lvbiwgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLiBUbyBoYXZlIHNv bWV0aGluZyB0byBwdXQgaW4gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIsIHdlJ2QgcHJvcG9zZSAiUGF0 aCBMYXllciBVRFAgU3Vic3RyYXRlIiAoUExVUykgYXMgYSBzdGFydGluZyBwb2ludC4NCj4gDQo+ IFRoZSBwcm9wb3NlZCBjaGFydGVyIGFwcGVhcnMgYmVsb3cuIFdlJ3JlIGludGVyZXN0ZWQgaW4g aGVhcmluZyBpbml0aWFsIGZlZWRiYWNrIG9uIHRoZSBwcm9wb3NlZCBjaGFydGVyIGluIHByZXBh cmF0aW9uIGZvciBhIEJvRiBwcm9wb3NhbCAodGhlIGN1dG9mZiBkYXRlIGlzIHR3byB3ZWVrcyBm cm9tIHRvbW9ycm93LCBvbiBGcmlkYXkgMyBKdW5lKS4gSXMgdGhlcmUgd29yayB0byBkbyBoZXJl IHdpdGhpbiB0aGUgSUVURj8gSXMgdGhlIHNjb3BlIG9mIHRoZSBwcm9wb3NlZCBjaGFydGVyIGFw cHJvcHJpYXRlPyBJcyB0aGVyZSBlbmVyZ3kgdG8gZG8gdGhpcyB3b3JrPw0KPiANCj4gVGhhbmtz LCBjaGVlcnMsDQo+IA0KPiBCcmlhbiBhbmQgTWlyamENCj4gDQo+IA0KPiBQYXRoIExheWVyIFVE UCBTdWJzdHJhdGUgKFBMVVMpDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4g DQo+IFRoZSBQTFVTIHdvcmtpbmcgZ3JvdXDigJlzIGdvYWwgaXMgdG8gZW5hYmxlIHRoZSBkZXBs b3ltZW50IG9mIG5ldywgDQo+IGVuY3J5cHRlZCB0cmFuc3BvcnQgcHJvdG9jb2xzLCB3aGlsZSBw cm92aWRpbmcgYSB0cmFuc3BvcnQtaW5kZXBlbmRlbnQgDQo+IG1ldGhvZCB0byBzaWduYWwgZmxv dyBzZW1hbnRpY3MgdW5kZXIgdHJhbnNwb3J0IGFuZCBhcHBsaWNhdGlvbiBjb250cm9sLg0KPiAN Cj4gVGhlIGN1cnJlbnQgSW50ZXJuZXQgcHJvdG9jb2wgc3RhY2sgaGFzIG5vIGxheWVyIGZvciBl eHBsaWNpdCANCj4gc2lnbmFsaW5nIG9mIGZsb3cgc2VtYW50aWNzIGFuZCBjaGFyYWN0ZXJpc3Rp Y3MgdG8gbmV0d29yayBlbGVtZW50cywgDQo+IG5vciBhbiBpbnRlZ3JhdGVkIHNpZ25hbGluZyBt ZWNoYW5pc20gZnJvbSBuZXR3b3JrIGVsZW1lbnRzIHRvIGJhY2sgdG8gDQo+IGVuZHBvaW50cyBh bmQgYXBwbGljYXRpb25zLiBUaGlzIGxheWVyIG5ldmVyIGV2b2x2ZWQgd2l0aGluIHRoZSBzdGFj aywgDQo+IGJlY2F1c2UgbWlkZGxlYm94ZXMgYW5kIG90aGVyIGRldmljZXMgb24gcGF0aCBjb3Vs ZCBzaW1wbHkgaW5zcGVjdCBhbmQgDQo+IG1vZGlmeSBoZWFkZXJzIGFuZCBwYXlsb2FkIG9mIHVu ZW5jcnlwdGVkIHRyYWZmaWMgYXQgZXZlcnkgbGF5ZXIuIFRoaXMgDQo+IGltcGxpY2l0IHVzZSBv ZiBpbmZvcm1hdGlvbiBmcm9tIHRoZSB0cmFuc3BvcnQgYW5kIGFwcGxpY2F0aW9uIGxheWVycyAN Cj4gaXMgYSBrZXkgb3JpZ2luIG9mIHRoZSBvc3NpZmljYXRpb24gdGhhdCBtYWtlcyBpdCBoYXJk IG9yIGltcG9zc2libGUgdG8gZGVwbG95IG5ldyBwcm90b2NvbHMuDQo+IA0KPiBJbiBvcmRlciB0 byBzdXBwb3J0IG1vcmUgdWJpcXVpdG91cyBkZXBsb3ltZW50IG9mIGVuY3J5cHRpb24sIGV4cGxp Y2l0IA0KPiBzaWduYWxpbmcgbXVzdCBiZSBhZGRlZCB0byB0aGUgc3RhY2ssIGFuZCBpdCBtdXN0 IGJlIHRyYW5zcG9ydCANCj4gcHJvdG9jb2wgaW5kZXBlbmRlbnQuIFdoaWxlIElQIHdvdWxkIHNl ZW0gdG8gYmUgdGhlIG5hdHVyYWwgaG9tZSBmb3IgDQo+IHRoaXMgZmFjaWxpdHksIGJvdGggSVB2 NCBhbmQgSVB2NiBvcHRpb25zIGFuZCBleHRlbnNpb25zIGhhdmUgDQo+IGRlcGxveW1lbnQgcHJv YmxlbXMgb24gdGhlaXIgb3duLCB3aGljaCBtYWtlcyBpdCBoYXJkIHRvIGluY2x1ZGUgYW55IA0K PiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGluIHRoZXNlIHByb3RvY29scy4gIEFkZGl0aW9uYWxs eSwgYSBmZWVkYmFjayANCj4gY2hhbm5lbCB0aGF0IHByb3ZpZGVzIGluZm9ybWF0aW9uIGZyb20g b24tcGF0aCBkZXZpY2VzIGJhY2sgdG8gDQo+IGVuZHBvaW50cyBhbmQgYXBwbGljYXRpb25zLCBl LmcuIGZvciBlcnJvciBoYW5kbGluZywgaXMgZXNzZW50aWFsIGZvciANCj4gdGhlIGRlcGxveW1l bnQgYW5kIHN1Y2Nlc3Mgb2YgYW4gZXhwbGljaXQgY29vcGVyYXRpb24gYXBwcm9hY2guDQo+IA0K PiBUaGUgUExVUyB3b3JraW5nIGdyb3VwIHdpbGwgc3BlY2lmeSBhIG5ldyBwcm90b2NvbCBhcyBh IFBhdGggTGF5ZXIgDQo+IFVzZXIgU3Vic3RyYXRlIChQTFVTKSwgdG8gc3VwcG9ydCBleHBlcmlt ZW50YWwgZGVwbG95bWVudCBvZiBleHBsaWNpdCANCj4gY29vcGVyYXRpb24gYmV0d2VlbiBlbmRw b2ludHMgYW5kIGRldmljZXMgb24gcGF0aCwgd2l0aCB0aGUgZm9sbG93aW5nIGdvYWxzOg0KPiAN Cj4gLSBlbmFibGUgdWJpcXVpdG91cyBkZXBsb3ltZW50IG9mIGVuY3J5cHRlZCBoaWdoZXIgbGF5 ZXIgcHJvdG9jb2xzIGJ5IA0KPiBwcm92aWRpbmcgZXhwb3N1cmUgb2Ygc2ltaWxhciBzZW1hbnRp Y3MgdG8gZXhpc3RpbmcgcHJvdG9jb2xzIChlLmcuIA0KPiBUQ1ApIHRvIGRldmljZXMgb24gcGF0 aCAoZS5nLiBOQVRzIGFuZCBmaXJld2FsbHMpDQo+IA0KPiAtIGFsbG93IGFwcGxpY2F0aW9ucyBh bmQgdHJhbnNwb3J0IHByb3RvY29scyB0byBleHBsaWNpdGx5IHByb3ZpZGUgDQo+IGxpbWl0ZWQg aW5mb3JtYXRpb24gdG8gZGV2aWNlcyBvbiBwYXRoDQo+IA0KPiAtIGFsbG93IGRldmljZXMgb24g cGF0aCB0byBwcm92aWRlIGZlZWRiYWNrIGFuZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgDQo+IHBh dGggdG8gc2VuZGluZyBlbmRwb2ludHMsIHVuZGVyIHNlbmRpbmcgZW5kcG9pbnQgY29udHJvbA0K PiANCj4gLSBhbGxvdyBkZXZpY2VzIG9uIHBhdGggdG8gcHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgcGF0aCB0byANCj4gcmVjZWl2aW5nIGVuZHBvaW50cywgd2l0aCBmZWVkYmFjayB0byB0 aGUgc2VuZGluZyBlbmRwb2ludCwgdW5kZXIgDQo+IHNlbmRpbmcgZW5kcG9pbnQgY29udHJvbA0K PiANCj4gTm90ZSB0aGF0IHRoaXMgYXBwcm9hY2ggZXhwbGljaXRseSBnaXZlcyB0aGUgY29udHJv bCBvZiBpbmZvcm1hdGlvbiANCj4gZXhwb3N1cmUgYmFjayB0aGUgYXBwbGljYXRpb24gYW5kL29y IHRyYW5zcG9ydCBsYXllciBwcm90b2NvbCBvbiB0aGUgDQo+IGVuZCBob3N0LiBJdCBpcyB0aGUg Z29hbCBvZiBQTFVTIHRvIG1pbmltaXplIHRoZSBpbmZvcm1hdGlvbiBleHBvc2VkIA0KPiBhdCB0 aGUgbGV2ZWwgb2YgZGV0YWlsIHRoYXQgaXMgdXNlZnVsIGZvciB0aGUgbmV0d29yaywgd2hpbGUg DQo+IGVuY3J5cHRpbmcgZXZlcnl0aGluZyBlbHNlLiBUaGlzIGlzIGltcG9ydGFudCB0byBhdm9p ZCBmdXR1cmUgaW1wbGljaXQgDQo+IHRyZWF0bWVudCBhbmQgdGhlIHJlc3VsdGluZyBvc3NpZmlj YXRpb24sIGFzIHdlbGwgYXMgdG8gbGV2ZXJhZ2UgdGhlIA0KPiBwcmluY2lwbGUgb2YgbGVhc3Qg ZXhwb3N1cmUgdG8gbWluaW1pemUgcHJpdmFjeSByaXNrcyBwcmVzZW50ZWQgYnkgZXhwbGljaXQg Y29vcGVyYXRpb24uDQo+IA0KPiBHaXZlbiB0aGF0IHRoZSBwcmltYXJ5IGdvYWwgb2YgUExVUyBp cyB0byBlbmFibGUgdGhlIGRlcGxveW1lbnQgb2YgDQo+IGFyYml0cmFyeSwgZnVsbHkgZW5jcnlw dGVkIHRyYW5zcG9ydCBwcm90b2NvbHMsIHdlIGFzc3VtZSB0aGF0IHRoZSANCj4gaGlnaGVyIGxh eWVyIHByb3RvY29sIGNhbiBwcm92aWRlIGFuIGVuY3J5cHRpb24gY29udGV4dCB0aGF0IGNhbiBi ZSANCj4gdXNlZCBieSBQTFVTIHRvIHByb3ZpZGUgYXV0aGVudGljYXRpb24sIGludGVncml0eSwg YW5kIGVuY3J5cHRpb24gDQo+IHdoZXJlIG5lZWRlZC4gVGhlIHByaW1hcnkgdGhyZWF0IG1vZGVs IHRvIGRlZmVuZCBhZ2FpbnN0IHdpbGwgYmUgDQo+IG1vZGlmaWNhdGlvbiBvciBkZWxldGlvbiBv ZiBleHBvc2VkIGluZm9ybWF0aW9uIGJ5IG1pZGRsZWJveGVzIGFuZCANCj4gb3RoZXIgZGV2aWNl cyBvbiBwYXRoLCBieSBhbGxvd2luZyBhIHJlbW90ZSBlbmRwb2ludCB0byBkZXRlY3QgbW9kaWZp Y2F0aW9ucy4NCj4gDQo+IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgc3RhcnQgd2l0aCBhbiBpbml0 aWFsIHNldCBvZiB1c2UgY2FzZXMgKHNlZQ0KPiBkcmFmdC1rdWVobGV3aW5kLXNwdWQtdXNlLWNh c2VzKSBhbmQgcmVxdWlyZW1lbnRzIChzZWUgDQo+IGRyYWZ0LXRyYW1tZWxsLXNwdWQtcmVxKSwg dGFrZW4gZnJvbSBleHBlcmllbmNlIHdpdGggdGhlIFN1YnN0cmF0ZSBQcm90b2NvbCBmb3IgVXNl ciBEYXRhZ3JhbXMgcHJvdG90eXBlLg0KPiBUaGUgd29ya2luZyBncm91cCdzIG1haW4gb3V0cHV0 IHdpbGwgYmUgYW4gZXhwZXJpbWVudGFsIHByb3RvY29sIA0KPiBzcGVjaWZpY2F0aW9uLCB0b2dl dGhlciB3aXRoIGFuIGluaXRpYWwgcmVnaXN0cnkgb2YgdHlwZXMgb2YgDQo+IGluZm9ybWF0aW9u IHRoYXQgY2FuIGJlIGV4cG9zZWQgdXNpbmcgUExVUywgY2xlYXJseSBhbGlnbmVkIHRvIHRoZXNl IA0KPiB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cy4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBj bG9zZSBpZiBpdCBpcyBub3QgDQo+IGFibGUgdG8gY29tZSB0byBjb25zZW5zdXMgb24gYSBwcm90 b2NvbCBkZXNpZ24gdG8gbWVldCB0aGVzZSByZXF1aXJlbWVudHMuDQo+IA0KPiBUaGUgd29ya2lu ZyBncm91cCB3aWxsIGFkZGl0aW9uYWxseSBhaW0gdG8gaWRlbnRpZnkgb3RoZXIgd29ya2luZyAN Cj4gZ3JvdXBzIHRoYXQgY291bGQgb3Igc2hvdWxkIGFkZHJlc3MgcGFydHMgb2YgdGhlc2UgcmVx dWlyZW1lbnRzIHdpdGhpbiANCj4gZXhpc3RpbmcgcHJvdG9jb2xzLCBlLmcuIGJ5IHNwZWNpZnlp bmcgbmV3IHByb3RvY29sIGV4dGVuc2lvbnMgb3IgYXMgDQo+IGlucHV0IGZvciBvbi1nb2luZyBz dGFuZGFyZGl6YXRpb24gd29yay4gSXQgd2lsbCBhaW0gdG8gd29yayB3aXRoIA0KPiB3b3JraW5n IGdyb3VwcyBkZWZpbmluZyBlbmNyeXB0aW9uIHByb3RvY29scyAoZS5nLiBUTFMpIHdoaWNoIGNv dWxkIGJlIA0KPiB1c2VkIGZvciBlbmNyeXB0aW9uIG9mIHRyYW5zcG9ydCBwcm90b2NvbHMgcnVu bmluZyBvdmVyIFBMVVMuDQo+IA0KDQo= From nobody Thu May 19 10:50: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 0FAA412DB57 for ; Thu, 19 May 2016 10:50: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, 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 hRVXDPIgZpjV for ; Thu, 19 May 2016 10:50:22 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 A098312DB5B for ; Thu, 19 May 2016 10:50:22 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id 190so116992788iow.1 for ; Thu, 19 May 2016 10:50:22 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=7FC9mLJDgwjt6b5wHB3HidZnhqS9gSN2Te/DAcIi8Is=; b=fUQ7zdBA6d7fKIY0QUJI/QjBSCxBT3iQEmYGjiYIZChTNdZXt9ACf2vIlQLhnLg6zM gQttIIAhRk5bYLL6bFupEcbeDNhD9QRxgU6MqZZbgvDVVe1R/tkRi3KfimO5ycKA4PpQ E1Agi56UbhOoHqcHF0uJBFyIbAeNGkcvD61+gh0RL+GBVr0Y/eLsUqhIIW3/sQHszfYU E1uAS8s1npFATm+kVqR2jX3nkLAiCozqlfAyprcb95zU9DQ2ER6tR9GJ0o2y5SS+ScuX GrkPt9SBAaUsh6h1/YxC6eCqNJfGouJHIFYvuktso87AuyRLAw0ZjO0KO8M/UV19AJAl d2aw== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=7FC9mLJDgwjt6b5wHB3HidZnhqS9gSN2Te/DAcIi8Is=; b=ZvaD85A5YeJnZ1zyknYUv4rr2QjPyW5dkdTfBLYts8uKznZmTs4zE49W+9hEazZ0Nh rW7KFqaGj8N6xOnBysuD+MjHyhosjNjFmibQSZw/ZgKgOk+JgQfolx1yI+Pl7C0F2MSr b1+uNrpU4KCBRzXwDQa+J2MS26J0vA1g8nZbzi2aG8nVFQQJJiZ8PDUIlluPwywEQM3u cU60LjWLOMi8hR2uVF+pyXQ7obfGd/KspcZ3XUclZfI6BSNa7fQ8p6SqKxHTl8x3UaLD 51cnyr0cH3gWxYNSAc+XjHWAv/+1khvRbZ9n2iWOfrJlykZ+w5WnSlN+fPO5zYfe7kDz 5QcA== X-Gm-Message-State: AOPr4FVYoA+dxreppZPW5kEbTEXGwzHP9ObvKll0I56ds48jG9Jqtq7Aus5h/JY7YwJiKTUqUV3n+nMS0EfYBw== MIME-Version: 1.0 X-Received: by 10.36.46.76 with SMTP id i73mr4230106ita.91.1463680221740; Thu, 19 May 2016 10:50:21 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 19 May 2016 10:50:21 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Thu, 19 May 2016 10:50:21 -0700 Message-ID: From: Tom Herbert To: "Scharf, Michael (Nokia - DE)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Trammell , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 19 May 2016 17:50:25 -0000 On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) wrote: > Does the sentence ... > > The current Internet protocol stack has no layer for explicit signaling= of flow semantics and characteristics to network elements ... > > actually wants to say something like > > The current Internet protocol stack has no layer for explicit *in-band*= signaling of flow semantics and characteristics ... ? > > I may be wrong, but there is no shortage of IETF and non-IETF protocols t= hat can signal flow semantics and characteristics out-of-band, either path-= coupled or path-decoupled, e.g., in the control or management plane. As a r= esult, there are protocol "layers" for that signaling, but they are not in-= band. There may also be other ways to fix this problem (e.g., by adding "en= d-to-end" or "inter-domain" instead of "in-band"). > Not to mention that TOS and diff-serv are in-band signaling mechanisms to the network, ECN is explicitly signaling from the network. Given that they've been around for many years but have never been widely deployed on the Internet makes me wonder if any in-band signaling mechanism will ever catch on. The use of out of band signaling should be considered, especially considered that in many cases like NAT and firewall the network elements that need signaling are likely in local networks of one side of the connection. I have a similar concern about the statement that IP options/EH and extension headers are being left off the table as part of a solution. The fact that neither have these caught on in the Internet and that tells me two things 1) No IP option is needed for the Internet to operate and be successful which makes me wonder if signaling between network and hosts is even required 2) If the extensibility mechanisms of IP are chronically not deployable, I wonder why any alternative that does not yet exist but intends to solve the same problem would be any more deployable. Tom > Michael > > > -----Original Message----- > From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On Behal= f Of Brian Trammell > Sent: Thursday, May 19, 2016 5:07 PM > To: stackevo-discuss@iab.org > Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD Bo= F > > Greetings, all, > > Forwarding this to the correct address for this mailing list (oops). Plea= se discuss at spud@ietf.org. > > Thanks, cheers, > > Brian > >> Begin forwarded message: >> >> From: Brian Trammell >> Subject: Possible WG-forming follow-on to SPUD BoF >> Date: 19 May 2016 at 17:04:50 GMT+2 >> To: spud@ietf.org >> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >> (IETF)" , Spencer Dawkins at IETF >> >> >> Greetings, all, >> >> We propose to hold a working-group forming BoF in Berlin as a follow-on = to the SPUD work, to define a common substrate protocol for encrypted trans= ports based on the requirements derived from experimentation with the SPUD = prototype. >> >> First, note that since the acronym "SPUD" refers primarily to the protot= ype itself, any follow-on working group should have a different name. We're= using the derived requirements, not starting for the prototype. The name i= s a subject for discussion, and suggestions are welcome. To have something = to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (PL= US) as a starting point. >> >> The proposed charter appears below. We're interested in hearing initial = feedback on the proposed charter in preparation for a BoF proposal (the cut= off date is two weeks from tomorrow, on Friday 3 June). Is there work to do= here within the IETF? Is the scope of the proposed charter appropriate? Is= there energy to do this work? >> >> Thanks, cheers, >> >> Brian and Mirja >> >> >> Path Layer UDP Substrate (PLUS) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> >> The PLUS working group=E2=80=99s goal is to enable the deployment of new= , >> encrypted transport protocols, while providing a transport-independent >> method to signal flow semantics under transport and application control. >> >> The current Internet protocol stack has no layer for explicit >> signaling of flow semantics and characteristics to network elements, >> nor an integrated signaling mechanism from network elements to back to >> endpoints and applications. This layer never evolved within the stack, >> because middleboxes and other devices on path could simply inspect and >> modify headers and payload of unencrypted traffic at every layer. This >> implicit use of information from the transport and application layers >> is a key origin of the ossification that makes it hard or impossible to = deploy new protocols. >> >> In order to support more ubiquitous deployment of encryption, explicit >> signaling must be added to the stack, and it must be transport >> protocol independent. 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. Additionally, 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. >> >> The PLUS working group will specify a new protocol as a Path Layer >> User Substrate (PLUS), to support experimental deployment of explicit >> cooperation between endpoints and devices on path, with the following go= als: >> >> - enable ubiquitous deployment of encrypted higher layer protocols by >> providing exposure of similar semantics to existing protocols (e.g. >> TCP) to devices on path (e.g. NATs and firewalls) >> >> - allow applications and transport protocols to explicitly provide >> limited information to devices on path >> >> - allow devices on path to provide feedback and information about the >> path to sending endpoints, under sending endpoint control >> >> - allow devices on path to provide information about the path to >> receiving endpoints, with feedback to the sending endpoint, under >> sending endpoint control >> >> Note that 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 >> at the level of detail that is useful for the network, while >> encrypting everything else. This is important to avoid future implicit >> treatment and the resulting ossification, as well as to leverage the >> principle of least exposure to minimize privacy risks presented by expli= cit cooperation. >> >> Given that the primary goal of PLUS is to enable the deployment of >> arbitrary, fully encrypted transport protocols, 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 modificat= ions. >> >> 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 Proto= col for User Datagrams 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 these >> use cases and requirements. The working group will close if it is not >> able to come to consensus on a protocol design to meet these requirement= s. >> >> The working group will additionally aim to identify other working >> groups that could or should 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. TLS) which could be >> used for encryption of transport protocols running over PLUS. >> > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Thu May 19 11:19: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 081B812DBCD for ; Thu, 19 May 2016 11:18:54 -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 5FXNgtlE9eKC for ; Thu, 19 May 2016 11:18:35 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 4122F12D637 for ; Thu, 19 May 2016 11:17:10 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id 190so117961517iow.1 for ; Thu, 19 May 2016 11:17: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:date:message-id:subject:from:to; bh=EmN7is+7T3zsnXbwkWyL/GNmxSDGj+7rpFhm+wBDTIM=; b=ch04uXvpjH06sT199w0L3BrcWPn9BuFta/tqCWJsd+UW00cvL9uSNdvmsKCyXXRlGK VtnLqAuHlxDhnhohyfnF+9X7P41pqQzfxdJ4SFQbf4mc+c2u2820SMEdIKMagNbGwMGk OOKh3UqSuQB2gjyViQfIOzh/dWVdCSASfws6Pj4O9mnXgMmdw4gCjH6DAaXwCLsFqRSd KWMmZhWM6mNOvMo7QpjInXlgs0Sy9UBYoMI0iSLV0Vx1ajQx6AURRkNrOFK2+dj5oBKX Zi79128Ejz7rV8ER+Sba2pdUK+o39CdqAakCcXUGmrvvMU43LZeaqpFEVZ62easz0z3J LMQw== 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:date :message-id:subject:from:to; bh=EmN7is+7T3zsnXbwkWyL/GNmxSDGj+7rpFhm+wBDTIM=; b=QnPVAk4fRNOBQA0KehRKLpTIIfYqm2HjnRCwZs5iXuA7rTrheGclyAYdIsFmIPqrk6 0foAUmvJKZEPHq9uE/aheYDV3dtrDMoTghYVNjp77ZvUQRPjEv7ZHnySIE32aqk9Ex0R ZjloDXBHdRKiLhKVh7nxNGY76U9k70FLkjA71tf+BPmJUcNllYJEZtCQIs7jNKkBNrz6 ReaupuIetRjinLqod2AUljSyRumG+B+0PdjKLQbDzcXuZQKtSvuYxcF9GZnXjJSifnlH vHpT61wphZhpMd7147eu2VNhlzrkA94E7oUzhVY9aXWcxu5WlprzVP2wPAHiQvDL+vao cSLQ== X-Gm-Message-State: AOPr4FUY2lzKSgNcjMpqe+mpoIWDxuElFa0Ooi+a8kBKPSs60OaIkK6n0Xn65GgnzcpPQnXt8SwX+0sanqxV0Q== MIME-Version: 1.0 X-Received: by 10.36.33.131 with SMTP id e125mr4452008ita.37.1463681829520; Thu, 19 May 2016 11:17:09 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 19 May 2016 11:17:09 -0700 (PDT) In-Reply-To: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 11:17:09 -0700 Message-ID: From: Tom Herbert To: spud Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 18:18:54 -0000 X-List-Received-Date: Thu, 19 May 2016 18:18:54 -0000 Hello, We are working on a method to encapsulate transport protocols over UDP. This has two goals that are intended to address transport protocol ossification in the Internet: 1) Allow applications to run their own transport layer stack (i.e.from userspace). This eliminates dependencies on the OS (e.g. solves a major dependency issue for Facebook on clients). 2) Make transport layer headers (all of L4) invisible to the network so that they can't do intrusive actions at L4. This will be enforced with DTLS in use. Any comments or suggestions are welcome. Thanks, Tom ---------- Forwarded message ---------- From: Date: Thu, May 19, 2016 at 10:57 AM Subject: New Version Notification for draft-herbert-transports-over-udp-00.txt To: Tom Herbert A new version of I-D, draft-herbert-transports-over-udp-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-transports-over-udp Revision: 00 Title: Transport layer protocols over UDP Document date: 2016-05-19 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-herbert-transports-over-udp-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-transports-over-udp/ Htmlized: https://tools.ietf.org/html/draft-herbert-transports-over-udp-00 Abstract: This specification defines a mechanism to encapsulate layer four 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. 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 May 19 11:29: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 D1FC912D5F8 for ; Thu, 19 May 2016 11:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 UJ5m5BtPGy9x for ; Thu, 19 May 2016 11:29:50 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85D112DBB6 for ; Thu, 19 May 2016 11:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11228; q=dns/txt; s=iport; t=1463682436; x=1464892036; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=09HgWdeLsR+4yAx8O4doJhE1psdQpPqolu2CD6fdHA4=; b=To7L7pq39sqouc3BeR7Fj2ydsqimNH4E6EelGxNH4ztVXpMvTqLoiWFt qTKd+krHdHlIp2Hs8jcIIA0UnVZNzyklR7fQVsjHHHrl/CCQpLUNW8EUq 6JPDq3j54ZYfPquAqsZfGKScdBJp3l6UU5LgOM7SKwNdSiibYoKO9mdDl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgAIBT5X/4cNJK1UCoM3Vn6uJ4tqA?= =?us-ascii?q?Q2BdRcLhW8CgTo4FAEBAQEBAQFlJ4RCAQEBAwEBAQE3NAsFBwQLEQMBAQEBCR4?= =?us-ascii?q?HDwUNBh8JDhMbh3oDDwgOvzANhCgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYlvg?= =?us-ascii?q?QOCQ4FMCASFfQWNZHSJJzKIeIMvgW8KgWmET4hih2GHaB4BAUKEDRwyhkiBPgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.26,335,1459814400"; d="scan'208";a="109857915" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 May 2016 18:27:02 +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 u4JIR2Bx006719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2016 18:27:02 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 u4JIR1nK030684; Thu, 19 May 2016 11:27:01 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4JIR13U030683; Thu, 19 May 2016 11:27:01 -0700 Date: Thu, 19 May 2016 11:27:01 -0700 From: Toerless Eckert To: Tom Herbert Message-ID: <20160519182701.GL12994@cisco.com> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> 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: Brian Trammell , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 19 May 2016 18:29:56 -0000 Tom, Michael I am reading your positions and i am confused: DSCP is very successfull in enterprise networks. SPUD does not have to be successfull "on the Internet". To me it would already be a great success if it would help to improve controlled network services (like enterprise or 4G/5G networks). And their transit traffic across the Internet (without changing anything on the Internet itself). AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if we often think about them as per-flow and ould maybe like them to be restrict to per-flow. At least i don't know any normative reference that defines them to be per-flow. Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis that all those mechanisms fail to provide an easily deplopyale framework in the face of middleboxes. Aka: their presence and mostly non-success should be an argument FOR working on spud. Not against it. If a NAT/FW does support any flow signaling, its most likely inband. Every NAT/firwall supports flow recognition via the explicit signaling of flow-based transport protoocols like TCP. They do try to do the same for UDP and because that has no explicit flow signaling, thats where the problem starts. NAT/FW do deep packet inspection which has all these problems we know. SPUD sets out to solve/reduce these NAT/FW issues. Non-support of anything like IP options is IMHO primarily driven by the absence of unform cross-OS/Dev-language APIs for them. Yes. It may suck architecturally by designing protocol stacks based on reality like: applications will only be able to use UDP and TCP, so lets do new work on top of them, but to me the most important goal is to find the best deployable solution to a problem. Not the architecturally cleanest one. If you give me research money to work outside of reality i will happily take it though and represent a different perspective. Please, i do not want to dismiss your opposition, i just don't understand how the arguments you make are working out. Maybe you can explain to me where i am going wrong in my interpretations above. Cheers Toerless On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: > On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) > wrote: > > Does the sentence ... > > > > The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements ... > > > > actually wants to say something like > > > > The current Internet protocol stack has no layer for explicit *in-band* signaling of flow semantics and characteristics ... ? > > > > I may be wrong, but there is no shortage of IETF and non-IETF protocols that can signal flow semantics and characteristics out-of-band, either path-coupled or path-decoupled, e.g., in the control or management plane. As a result, there are protocol "layers" for that signaling, but they are not in-band. There may also be other ways to fix this problem (e.g., by adding "end-to-end" or "inter-domain" instead of "in-band"). > > > Not to mention that TOS and diff-serv are in-band signaling mechanisms > to the network, ECN is explicitly signaling from the network. Given > that they've been around for many years but have never been widely > deployed on the Internet makes me wonder if any in-band signaling > mechanism will ever catch on. The use of out of band signaling should > be considered, especially considered that in many cases like NAT and > firewall the network elements that need signaling are likely in local > networks of one side of the connection. > > I have a similar concern about the statement that IP options/EH and > extension headers are being left off the table as part of a solution. > The fact that neither have these caught on in the Internet and that > tells me two things 1) No IP option is needed for the Internet to > operate and be successful which makes me wonder if signaling between > network and hosts is even required 2) If the extensibility mechanisms > of IP are chronically not deployable, I wonder why any alternative > that does not yet exist but intends to solve the same problem would be > any more deployable. > > Tom > > > Michael > > > > > > -----Original Message----- > > From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On Behalf Of Brian Trammell > > Sent: Thursday, May 19, 2016 5:07 PM > > To: stackevo-discuss@iab.org > > Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF > > > > Greetings, all, > > > > Forwarding this to the correct address for this mailing list (oops). Please discuss at spud@ietf.org. > > > > Thanks, cheers, > > > > Brian > > > >> Begin forwarded message: > >> > >> From: Brian Trammell > >> Subject: Possible WG-forming follow-on to SPUD BoF > >> Date: 19 May 2016 at 17:04:50 GMT+2 > >> To: spud@ietf.org > >> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind > >> (IETF)" , Spencer Dawkins at IETF > >> > >> > >> Greetings, all, > >> > >> We propose to hold a working-group forming BoF in Berlin as a follow-on to the SPUD work, to define a common substrate protocol for encrypted transports based on the requirements derived from experimentation with the SPUD prototype. > >> > >> First, note that since the acronym "SPUD" refers primarily to the prototype itself, any follow-on working group should have a different name. We're using the derived requirements, not starting for the prototype. The name is a subject for discussion, and suggestions are welcome. To have something to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (PLUS) as a starting point. > >> > >> The proposed charter appears below. We're interested in hearing initial feedback on the proposed charter in preparation for a BoF proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work to do here within the IETF? Is the scope of the proposed charter appropriate? Is there energy to do this work? > >> > >> Thanks, cheers, > >> > >> Brian and Mirja > >> > >> > >> Path Layer UDP Substrate (PLUS) > >> =============================== > >> > >> The PLUS working group???s goal is to enable the deployment of new, > >> encrypted transport protocols, while providing a transport-independent > >> method to signal flow semantics under transport and application control. > >> > >> The current Internet protocol stack has no layer for explicit > >> signaling of flow semantics and characteristics to network elements, > >> nor an integrated signaling mechanism from network elements to back to > >> endpoints and applications. This layer never evolved within the stack, > >> because middleboxes and other devices on path could simply inspect and > >> modify headers and payload of unencrypted traffic at every layer. This > >> implicit use of information from the transport and application layers > >> is a key origin of the ossification that makes it hard or impossible to deploy new protocols. > >> > >> In order to support more ubiquitous deployment of encryption, explicit > >> signaling must be added to the stack, and it must be transport > >> protocol independent. 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. Additionally, 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. > >> > >> The PLUS working group will specify a new protocol as a Path Layer > >> User 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 similar semantics to existing protocols (e.g. > >> TCP) to devices on path (e.g. NATs and firewalls) > >> > >> - allow applications and transport protocols to explicitly provide > >> limited information to devices on path > >> > >> - allow devices on path to provide feedback and information about the > >> path to sending endpoints, under sending endpoint control > >> > >> - allow devices on path to provide information about the path to > >> receiving endpoints, with feedback to the sending endpoint, under > >> sending endpoint control > >> > >> Note that 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 > >> at the level of detail that is useful for the network, while > >> encrypting everything else. This is important to avoid future implicit > >> treatment and the resulting ossification, as well as to leverage the > >> principle of least exposure to minimize privacy risks presented by explicit cooperation. > >> > >> Given that the primary goal of PLUS is to enable the deployment of > >> arbitrary, fully encrypted transport protocols, 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 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 these > >> use cases and requirements. 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 other working > >> groups that could or should 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. TLS) which could be > >> used for encryption of transport protocols running over 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 -- --- Toerless Eckert, eckert@cisco.com From nobody Thu May 19 11:56:46 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 554F912DB9C for ; Thu, 19 May 2016 11:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Kt6FAZbzF6Lt for ; Thu, 19 May 2016 11:56:40 -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 4865B12D61E for ; Thu, 19 May 2016 11:56:40 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id DC1773EA3858E; Thu, 19 May 2016 18:56:34 +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 u4JIuZ4C017149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2016 18:56:36 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 u4JIuXj1009268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 May 2016 20:56:34 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 19 May 2016 20:56:34 +0200 From: "Scharf, Michael (Nokia - DE)" To: Toerless Eckert , Tom Herbert Thread-Topic: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF Thread-Index: AQHRseA50Ukv47cg8kyAjhwTgJjj85/AelIw///uOYCAAAo/gIAAIkLg Date: Thu, 19 May 2016 18:56:34 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> In-Reply-To: <20160519182701.GL12994@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US 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: Cc: Brian Trammell , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 19 May 2016 18:56:44 -0000 My comment is *only* that the sentence "The current Internet protocol stack= has no layer for explicit signaling of flow semantics and characteristics = to network elements" needs to be improved, in my personal point of view. =20 For instance, for NAT/FW control, there are many existing out-of-band proto= cols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, etc., not t= o mention all the SDN protocols, which are typically all flow-based. They a= re all out-of-band but e.g. NSIS would have been end-to-end. The intention = and deployment model of these protocols may be very different to what SPUD = aims for, and none of them is deployed end-to-end in the Internet. But I th= ink this sentence has to be slightly more specific how to differentiate e.g= . from control plane solutions. Michael -----Original Message----- From: Toerless Eckert [mailto:eckert@cisco.com]=20 Sent: Thursday, May 19, 2016 8:27 PM To: Tom Herbert Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on t= o SPUD BoF Tom, Michael I am reading your positions and i am confused: DSCP is very successfull in enterprise networks. SPUD does not have to be s= uccessfull "on the Internet". To me it would already be a great success if = it would help to improve controlled network services (like enterprise or 4G= /5G networks). And their transit traffic across the Internet (without chang= ing anything on the Internet itself). AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if we= often think about them as per-flow and ould maybe like them to be restrict= to per-flow. At least i don't know any normative reference that defines th= em to be per-flow. Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis t= hat all those mechanisms fail to provide an easily deplopyale framework in = the face of middleboxes. Aka: their presence and mostly non-success should = be an argument FOR working on spud. Not against it. If a NAT/FW does support any flow signaling, its most likely inband. Every = NAT/firwall supports flow recognition via the explicit signaling of flow-ba= sed transport protoocols like TCP. They do try to do the same for UDP and b= ecause that has no explicit flow signaling, thats where the problem starts.= NAT/FW do deep packet inspection which has all these problems we know. SPU= D sets out to solve/reduce these NAT/FW issues. Non-support of anything like IP options is IMHO primarily driven by the abs= ence of unform cross-OS/Dev-language APIs for them. Yes. It may suck archit= ecturally by designing protocol stacks based on reality like: applications = will only be able to use UDP and TCP, so lets do new work on top of them, b= ut to me the most important goal is to find the best deployable solution to= a problem. Not the architecturally cleanest one. If you give me research m= oney to work outside of reality i will happily take it though and represent= a different perspective. Please, i do not want to dismiss your opposition, i just don't understand h= ow the arguments you make are working out. Maybe you can explain to me wher= e i am going wrong in my interpretations above. Cheers Toerless On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: > On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE)=20 > wrote: > > Does the sentence ... > > > > The current Internet protocol stack has no layer for explicit signali= ng of flow semantics and characteristics to network elements ... > > > > actually wants to say something like > > > > The current Internet protocol stack has no layer for explicit *in-ban= d* signaling of flow semantics and characteristics ... ? > > > > I may be wrong, but there is no shortage of IETF and non-IETF protocols= that can signal flow semantics and characteristics out-of-band, either pat= h-coupled or path-decoupled, e.g., in the control or management plane. As a= result, there are protocol "layers" for that signaling, but they are not i= n-band. There may also be other ways to fix this problem (e.g., by adding "= end-to-end" or "inter-domain" instead of "in-band"). > > > Not to mention that TOS and diff-serv are in-band signaling mechanisms=20 > to the network, ECN is explicitly signaling from the network. Given=20 > that they've been around for many years but have never been widely=20 > deployed on the Internet makes me wonder if any in-band signaling=20 > mechanism will ever catch on. The use of out of band signaling should=20 > be considered, especially considered that in many cases like NAT and=20 > firewall the network elements that need signaling are likely in local=20 > networks of one side of the connection. >=20 > I have a similar concern about the statement that IP options/EH and=20 > extension headers are being left off the table as part of a solution. > The fact that neither have these caught on in the Internet and that=20 > tells me two things 1) No IP option is needed for the Internet to=20 > operate and be successful which makes me wonder if signaling between=20 > network and hosts is even required 2) If the extensibility mechanisms=20 > of IP are chronically not deployable, I wonder why any alternative=20 > that does not yet exist but intends to solve the same problem would be=20 > any more deployable. >=20 > Tom >=20 > > Michael > > > > > > -----Original Message----- > > From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On=20 > > Behalf Of Brian Trammell > > Sent: Thursday, May 19, 2016 5:07 PM > > To: stackevo-discuss@iab.org > > Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to=20 > > SPUD BoF > > > > Greetings, all, > > > > Forwarding this to the correct address for this mailing list (oops). Pl= ease discuss at spud@ietf.org. > > > > Thanks, cheers, > > > > Brian > > > >> Begin forwarded message: > >> > >> From: Brian Trammell > >> Subject: Possible WG-forming follow-on to SPUD BoF > >> Date: 19 May 2016 at 17:04:50 GMT+2 > >> To: spud@ietf.org > >> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind=20 > >> (IETF)" , Spencer Dawkins at IETF=20 > >> > >> > >> Greetings, all, > >> > >> We propose to hold a working-group forming BoF in Berlin as a follow-o= n to the SPUD work, to define a common substrate protocol for encrypted tra= nsports based on the requirements derived from experimentation with the SPU= D prototype. > >> > >> First, note that since the acronym "SPUD" refers primarily to the prot= otype itself, any follow-on working group should have a different name. We'= re using the derived requirements, not starting for the prototype. The name= is a subject for discussion, and suggestions are welcome. To have somethin= g to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (= PLUS) as a starting point. > >> > >> The proposed charter appears below. We're interested in hearing initia= l feedback on the proposed charter in preparation for a BoF proposal (the c= utoff date is two weeks from tomorrow, on Friday 3 June). Is there work to = do here within the IETF? Is the scope of the proposed charter appropriate? = Is there energy to do this work? > >> > >> Thanks, cheers, > >> > >> Brian and Mirja > >> > >> > >> Path Layer UDP Substrate (PLUS) > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > >> > >> The PLUS working group???s goal is to enable the deployment of new,=20 > >> encrypted transport protocols, while providing a=20 > >> transport-independent method to signal flow semantics under transport = and application control. > >> > >> The current Internet protocol stack has no layer for explicit=20 > >> signaling of flow semantics and characteristics to network=20 > >> elements, nor an integrated signaling mechanism from network=20 > >> elements to back to endpoints and applications. This layer never=20 > >> evolved within the stack, because middleboxes and other devices on=20 > >> path could simply inspect and modify headers and payload of=20 > >> unencrypted traffic at every layer. This implicit use of=20 > >> information from the transport and application layers is a key origin = of the ossification that makes it hard or impossible to deploy new protocol= s. > >> > >> In order to support more ubiquitous deployment of encryption,=20 > >> explicit signaling must be added to the stack, and it must be=20 > >> transport protocol independent. While IP would seem to be the=20 > >> natural home for this facility, both IPv4 and IPv6 options and=20 > >> extensions have deployment problems on their own, which makes it=20 > >> hard to include any additional information in these protocols. =20 > >> Additionally, a feedback channel that provides information from=20 > >> on-path devices back to endpoints and applications, e.g. for error=20 > >> handling, is essential for the deployment and success of an explicit c= ooperation approach. > >> > >> The PLUS working group will specify a new protocol as a Path Layer=20 > >> User Substrate (PLUS), to support experimental deployment of=20 > >> explicit cooperation between endpoints and devices on path, with the f= ollowing goals: > >> > >> - enable ubiquitous deployment of encrypted higher layer protocols=20 > >> by providing exposure of similar semantics to existing protocols (e.g. > >> TCP) to devices on path (e.g. NATs and firewalls) > >> > >> - allow applications and transport protocols to explicitly provide=20 > >> limited information to devices on path > >> > >> - allow devices on path to provide feedback and information about=20 > >> the path to sending endpoints, under sending endpoint control > >> > >> - allow devices on path to provide information about the path to=20 > >> receiving endpoints, with feedback to the sending endpoint, under=20 > >> sending endpoint control > >> > >> Note that this approach explicitly gives the control of information=20 > >> exposure back the application and/or transport layer protocol on=20 > >> the end host. It is the goal of PLUS to minimize the information=20 > >> exposed at the level of detail that is useful for the network,=20 > >> while encrypting everything else. This is important to avoid future=20 > >> implicit treatment and the resulting ossification, as well as to=20 > >> leverage the principle of least exposure to minimize privacy risks pre= sented by explicit cooperation. > >> > >> Given that the primary goal of PLUS is to enable the deployment of=20 > >> arbitrary, fully encrypted transport protocols, we assume that the=20 > >> higher layer protocol can provide an encryption context that can be=20 > >> used by PLUS to provide authentication, integrity, and encryption=20 > >> where needed. The primary threat model to defend against will be=20 > >> modification or deletion of exposed information by middleboxes and=20 > >> other devices on path, by allowing a remote endpoint to detect modific= ations. > >> > >> The working group will start with an initial set of use cases (see > >> draft-kuehlewind-spud-use-cases) and requirements (see=20 > >> draft-trammell-spud-req), taken from experience with the Substrate Pro= tocol for User Datagrams prototype. > >> The working group's main output will be an experimental protocol=20 > >> specification, together with an initial registry of types of=20 > >> information that can be exposed using PLUS, clearly aligned to=20 > >> these use cases and requirements. The working group will close if=20 > >> it is not able to come to consensus on a protocol design to meet these= requirements. > >> > >> The working group will additionally aim to identify other working=20 > >> groups that could or should address parts of these requirements=20 > >> within existing protocols, e.g. by specifying new protocol=20 > >> extensions or as input for on-going standardization work. It will=20 > >> aim to work with working groups defining encryption protocols (e.g.=20 > >> TLS) which could be used for encryption of transport protocols running= over PLUS. > >> > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Thu May 19 11:59: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 A8C8612DB2A for ; Thu, 19 May 2016 11:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 xQo8p4-BqmJB for ; Thu, 19 May 2016 11:59:45 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D7012DBB7 for ; Thu, 19 May 2016 11:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4149; q=dns/txt; s=iport; t=1463684384; x=1464893984; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=mmFzA3S5yvSl5Xc/4Z+Mnq3yZwuWf+GKv8zwt+0Yk3E=; b=TQeGJNfhYxguhG29leyC1yMkqMebH8KJrAX2uPkgJn2voQ3E3XMz3KlO w77OlrnqBuVyn7Ft5+Gqs55c0r3YDroZaNDVyxL2zuOKYbaGV1qj/5qoo iyyJvUlz4JuAlQhQsZRypfSCNk+86KhTyljWqVlgyAAEqW7h1V8sPgemP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgD4Cz5X/5NdJa1egzdWfrI1h1wBD?= =?us-ascii?q?YF1Fw2FbQKBOjgUAQEBAQEBAWUnhEIBAQEEAQEBNzQJAhALEQMBAgEJJQ8FEyg?= =?us-ascii?q?OExmIFg7DaAEBAQEBAQEBAQEBAQEBAQEBAQEBARyJb4EDihgFhkCBQ4VhdIlZh?= =?us-ascii?q?RhoiBYKgWlOhAGIYo9JHgEBQoIGHBaBVRwyAYgFAQEB?= X-IronPort-AV: E=Sophos;i="5.26,335,1459814400"; d="scan'208";a="104034350" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 May 2016 18:59:43 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u4JIxheC015325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2016 18:59:43 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 u4JIxhXb030965; Thu, 19 May 2016 11:59:43 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4JIxha1030964; Thu, 19 May 2016 11:59:43 -0700 Date: Thu, 19 May 2016 11:59:43 -0700 From: Toerless Eckert To: Tom Herbert Message-ID: <20160519185943.GM12994@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> 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: spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 18:59:48 -0000 Whats the likely use-case for this ? Many transports already have a UDP binding, some like RTP ONLY work across UDP. Even if there is no pre-existing UDP or better yet dTLS encap, why would someone with transport X choose this scheme over a home-grown one using UDP/dTLS ? This should be written out with explicit examples to motivate this draft better. I haven't spent enough time to understand it all in detail, but the mobility aspect is of course quite important and necessarily complex. It would be great to write down a section comparing how you're trying to solve it with your session identifiver vs. how MT-TCP solves it. I can't see how you provide good mobility and therefore IP address independency without adding new signaling packets. I am also concerned about creating a new session identifier to replace transport addresses because that impacts applications building eg: a TCP connection and whose APIs might need to change. But as said: Mostly FUD and not enough detailled understanding of your drafts bits & pieces here. Wrt to your claim that its useful to protect the L4 headers: I would like to see text that explicitly writes out what specific elements are protected by this scheme with or without dTLS and how this reduces which attack vectors. For example, yes: you may not be able to see TCP session setup/teardown messages and may therefore make life more miserable for middleboxes, even those trying to do a good thing, but dTLS session signaling would likely more than compensate for that. Wrt to protect every single last bit of a transport layer header from middleboxes, let me bring this up in another thread. Cheers toerless On Thu, May 19, 2016 at 11:17:09AM -0700, Tom Herbert wrote: > Hello, > > We are working on a method to encapsulate transport protocols over > UDP. This has two goals that are intended to address transport > protocol ossification in the Internet: > > 1) Allow applications to run their own transport layer stack (i.e.from > userspace). This eliminates dependencies on the OS (e.g. solves a > major dependency issue for Facebook on clients). > 2) Make transport layer headers (all of L4) invisible to the network > so that they can't do intrusive actions at L4. This will be enforced > with DTLS in use. > > Any comments or suggestions are welcome. > > Thanks, > Tom > > > ---------- Forwarded message ---------- > From: > Date: Thu, May 19, 2016 at 10:57 AM > Subject: New Version Notification for draft-herbert-transports-over-udp-00.txt > To: Tom Herbert > > > > A new version of I-D, draft-herbert-transports-over-udp-00.txt > has been successfully submitted by Tom Herbert and posted to the > IETF repository. > > Name: draft-herbert-transports-over-udp > Revision: 00 > Title: Transport layer protocols over UDP > Document date: 2016-05-19 > Group: Individual Submission > Pages: 20 > URL: > https://www.ietf.org/internet-drafts/draft-herbert-transports-over-udp-00.txt > Status: > https://datatracker.ietf.org/doc/draft-herbert-transports-over-udp/ > Htmlized: https://tools.ietf.org/html/draft-herbert-transports-over-udp-00 > > > Abstract: > This specification defines a mechanism to encapsulate layer four > 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. > > > > > 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 -- --- Toerless Eckert, eckert@cisco.com From nobody Thu May 19 12:16: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 A23B312D620 for ; Thu, 19 May 2016 12:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 dTTa6mqngUh9 for ; Thu, 19 May 2016 12:16:24 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5354612D194 for ; Thu, 19 May 2016 12:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1609; q=dns/txt; s=iport; t=1463685384; x=1464894984; h=date:from:to:subject:message-id:mime-version; bh=OsxjvrJA9RcVsfJyosFosRQ9JaT6oGDQM4BmCvgRaQg=; b=OHJ2wZ8cK6oxl4y2XulFCF1F6P8EUFmRPVdntcG48JCLbHSZQihVbjwl eQujqXAedgGRgs6AR6NlNjxUqkiUtCdMGlwS3fLdYYId09nB95PiKGNOF S4JKo+nYdxKEoRZa7BgTQyaxhdef10yjeK2BzasSStJv8ADJAtyjnUKtp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BPBwC+ED5X/4ENJK1egzdWfgG4AYQSI?= =?us-ascii?q?ocrOxEBAQEBAQEBZSeERAQ7OkE0BUkuiAwIDqIZoUsBAQgBAQEBAQEhlQoFjli?= =?us-ascii?q?JWYYAiBYKgjeMYQKPSTYshA0cMgGIBQEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,335,1459814400"; d="scan'208";a="275464532" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 May 2016 19:16:23 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u4JJGNl8029800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 May 2016 19:16:23 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 u4JJGM2V031205 for ; Thu, 19 May 2016 12:16:22 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4JJGMex031204 for spud@ietf.org; Thu, 19 May 2016 12:16:22 -0700 Date: Thu, 19 May 2016 12:16:22 -0700 From: Toerless Eckert To: spud Message-ID: <20160519191622.GN12994@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: [Spud] SPUD: good reading 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, 19 May 2016 19:16:25 -0000 http://queue.acm.org/detail.cfm?id=2904894 >> The IT and networking communities overlooked a wise saying from >> soldiers and police officers: "Make sure the other side has an >> easier way out than destroying you." This IMHO exactly what we should fix with SPUD. Aka: At this stage it does not help me at all to further encrypt last bits of end-to-end traffic like eg: transport header bits (for the mayority of cases). We've long passed the point where operators with security requirements have gone away from simple network inspection to even more convoluted application layer proxies that will continue to negate all the benefits we've tried to do with end-to-end encryption. And we're still fighting here forever about defining a layer where we can controll and standardize information that must reasonably be seen by middleboxes. How much do you think the IETF can influence the limits of what application-layer proxy middleboxes can do on perpass and worse ? How much more could we be in control if we'd take this operator requirement on and define solutions ourselves. Eg: Have it be in a separate layer easily differentiable from actual user-data that needs to be privacy protected ? You want you hide flow-control messaging exchangees from middleboxes to make bandwidth management even more difficult ?? Why ?? You really think that helps you unless you want to run attacks against resource sharing ? Just an example. If we (IETF) are not doing something like SPUD, we're just becoming another big player in the global security theater. Cheers Toerless From nobody Thu May 19 12:17: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 54C6012D620 for ; Thu, 19 May 2016 12:17: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 byxXhAdGi9gx for ; Thu, 19 May 2016 12:17:31 -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 8C53212D633 for ; Thu, 19 May 2016 12:17:31 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id t40so27901019ioi.0 for ; Thu, 19 May 2016 12:17: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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=Izkfo9QGMQWtj5MTdKDHnrzEECXziKMaIOO/t1MjKvY=; b=jKCCVO3l9Nfulau5W65yaZ5Vb22C6YteJE+KPIZhID1L8DQeNCUxZKODnM41SE9P0R q0ohgSDofg35obSP/xKKT2bISAZIM6wlOoaYLLyXFFOk8oRcKadcOMzNTWGW6hyKDpMP BufwNL+slq5UmJbfEmMnnbfH2aPPL3VRgM75uH9MB9pauIeY4tIdwf8rdApsxzJqYbER X02yvUApvEJC6CXuCoIVHfJBsgaUjxk2tKigXhgdxCg6giW/am2T+co0L0YbwoDxDaQA C3Viwx8psfFPBqch/B9nuX0SuSbnSFJZfH0J6OkoWj4RCQMooPQx6n2eSAJi13XT0PDo ZZJg== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=Izkfo9QGMQWtj5MTdKDHnrzEECXziKMaIOO/t1MjKvY=; b=HIp3puk2c1V+wmpXCoZctMhR4DFDV9vGRbahJykyxp+XaMeOeevTjHgk7jiu+uCcj0 i4GvYib1jfpFDmHA+QyM2rlq1T3a3zIMp4NCTDSnb0dw4PDoEfXQeVcHwMJ0+vJOGa0a 6/dN5OfYSg+uQeH39kzFQ0EmAk4CTX25rwUA1nx24F/GTAc8XupBZKxfL17TAnNQzC22 +mvQcV3xPEc+noaL3B1I6ZF6CCmkKa1xr21qhmeWhdzmbBPo96wGCG6/9DtWFKUhCsjN Nc+0koqZYOPn/UrSLU24x7L1HiJmsd3/Aj5dZvCpDSvOYJTAeAEZ2XEJjErbhoa3+3ub eRaA== X-Gm-Message-State: AOPr4FUOSogWKzPiTUIBVQBSHyC3H5u4V1I9QNkrChPubHa4hF6epsUmsoFbZ/Kmui8hzlfAptvzbeW4ncJulA== MIME-Version: 1.0 X-Received: by 10.36.46.76 with SMTP id i73mr4562489ita.91.1463685450826; Thu, 19 May 2016 12:17:30 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 19 May 2016 12:17:30 -0700 (PDT) In-Reply-To: <20160519182701.GL12994@cisco.com> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> Date: Thu, 19 May 2016 12:17:30 -0700 Message-ID: From: Tom Herbert To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Trammell , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 19 May 2016 19:17:34 -0000 On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert wrote: > Tom, Michael > > I am reading your positions and i am confused: > > DSCP is very successfull in enterprise networks. SPUD does not have to > be successfull "on the Internet". To me it would already be a great succe= ss if it would > help to improve controlled network services (like enterprise or 4G/5G net= works). And > their transit traffic across the Internet (without changing anything on t= he Internet > itself). > Yes, that is my point about localizing the problem. A client device should know what network it's on an be able to signal to that network to get the services it wants. A server on the other side of the planet that the node is talking to really shouldn't be concerned with this and not required to implement some complex protocol to accommodate it. > AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if = we often think about > them as per-flow and ould maybe like them to be restrict to per-flow. At = least i don't know > any normative reference that defines them to be per-flow. > > Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis= that all those > mechanisms fail to provide an easily deplopyale framework in the face of = middleboxes. Aka: their > presence and mostly non-success should be an argument FOR working on spud= . Not against it. > > If a NAT/FW does support any flow signaling, its most likely inband. Ever= y NAT/firwall > supports flow recognition via the explicit signaling of flow-based transp= ort protoocols > like TCP. They do try to do the same for UDP and because that has no expl= icit flow signaling, > thats where the problem starts. NAT/FW do deep packet inspection which ha= s all these problems > we know. SPUD sets out to solve/reduce these NAT/FW issues. > There seems to be a lot of UDP going through NAT/FW today without any sort of in-band signaling, and protocols like QUIC are already seeing deployment without that (according to their slide deck "About half of Google to Chrome"). Considering that there is no deployment of a SPUD aware firewall and we can't want to wait for every device on the Internet to upgrade, SPUD will have to work with NAT/FW as is or we couldn't consider it. TBH I'm really having a hard time seeing that any extra signaling is required in the Internet other than what is in the IP header, at best it seems like an optimization for certain networks or configurations. > Non-support of anything like IP options is IMHO primarily driven by the a= bsence of > unform cross-OS/Dev-language APIs for them. Yes. It may suck architectura= lly by designing > protocol stacks based on reality like: applications will only be able to = use UDP and TCP, > so lets do new work on top of them, but to me the most important goal is = to find the best > deployable solution to a problem. Not the architecturally cleanest one. I= f you give me > research money to work outside of reality i will happily take it though a= nd represent a > different perspective. > There has been a lot of discussion about this in v6ops, many networks are simply dropping packets with extension headers. Please look at draft-ietf-v6ops-ipv6-ehs-in-real-world-02 and draft-gont-v6ops-ipv6-ehs-packet-drops-03. Because of this and the fact that there hasn't been any interesting options defined worth sending to date means that we (speaking for applications) have no use to send them (btw all the major OSes support options AFAIK). If some interesting options did come about, then we would probably apply a happy eyeballs approach to deploy. With something like SPUD (basically anything not simple TCP/IPv4) we are always faced with the same problem that some networks on the Internet may arbitrarily drop or otherwise restrict packets (we know for instance that some network operators choose to severely rate limit all UDP because of DOS concerns). So even if we do manage to start deploying transport protocols over UDP we are going have TCP as a fallback for indefinite future, i.e. more happy eyeballs. Tom > Please, i do not want to dismiss your opposition, i just don't understand= how the > arguments you make are working out. Maybe you can explain to me where i a= m going wrong > in my interpretations above. > > Cheers > Toerless > > On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >> wrote: >> > Does the sentence ... >> > >> > The current Internet protocol stack has no layer for explicit signal= ing of flow semantics and characteristics to network elements ... >> > >> > actually wants to say something like >> > >> > The current Internet protocol stack has no layer for explicit *in-ba= nd* signaling of flow semantics and characteristics ... ? >> > >> > I may be wrong, but there is no shortage of IETF and non-IETF protocol= s that can signal flow semantics and characteristics out-of-band, either pa= th-coupled or path-decoupled, e.g., in the control or management plane. As = a result, there are protocol "layers" for that signaling, but they are not = in-band. There may also be other ways to fix this problem (e.g., by adding = "end-to-end" or "inter-domain" instead of "in-band"). >> > >> Not to mention that TOS and diff-serv are in-band signaling mechanisms >> to the network, ECN is explicitly signaling from the network. Given >> that they've been around for many years but have never been widely >> deployed on the Internet makes me wonder if any in-band signaling >> mechanism will ever catch on. The use of out of band signaling should >> be considered, especially considered that in many cases like NAT and >> firewall the network elements that need signaling are likely in local >> networks of one side of the connection. >> >> I have a similar concern about the statement that IP options/EH and >> extension headers are being left off the table as part of a solution. >> The fact that neither have these caught on in the Internet and that >> tells me two things 1) No IP option is needed for the Internet to >> operate and be successful which makes me wonder if signaling between >> network and hosts is even required 2) If the extensibility mechanisms >> of IP are chronically not deployable, I wonder why any alternative >> that does not yet exist but intends to solve the same problem would be >> any more deployable. >> >> Tom >> >> > Michael >> > >> > >> > -----Original Message----- >> > From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On Be= half Of Brian Trammell >> > Sent: Thursday, May 19, 2016 5:07 PM >> > To: stackevo-discuss@iab.org >> > Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD= BoF >> > >> > Greetings, all, >> > >> > Forwarding this to the correct address for this mailing list (oops). P= lease discuss at spud@ietf.org. >> > >> > Thanks, cheers, >> > >> > Brian >> > >> >> Begin forwarded message: >> >> >> >> From: Brian Trammell >> >> Subject: Possible WG-forming follow-on to SPUD BoF >> >> Date: 19 May 2016 at 17:04:50 GMT+2 >> >> To: spud@ietf.org >> >> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >> >> (IETF)" , Spencer Dawkins at IETF >> >> >> >> >> >> Greetings, all, >> >> >> >> We propose to hold a working-group forming BoF in Berlin as a follow-= on to the SPUD work, to define a common substrate protocol for encrypted tr= ansports based on the requirements derived from experimentation with the SP= UD prototype. >> >> >> >> First, note that since the acronym "SPUD" refers primarily to the pro= totype itself, any follow-on working group should have a different name. We= 're using the derived requirements, not starting for the prototype. The nam= e is a subject for discussion, and suggestions are welcome. To have somethi= ng to put in the proposed charter, we'd propose "Path Layer UDP Substrate" = (PLUS) as a starting point. >> >> >> >> The proposed charter appears below. We're interested in hearing initi= al feedback on the proposed charter in preparation for a BoF proposal (the = cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work to= do here within the IETF? Is the scope of the proposed charter appropriate?= Is there energy to do this work? >> >> >> >> Thanks, cheers, >> >> >> >> Brian and Mirja >> >> >> >> >> >> Path Layer UDP Substrate (PLUS) >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> The PLUS working group???s goal is to enable the deployment of new, >> >> encrypted transport protocols, while providing a transport-independen= t >> >> method to signal flow semantics under transport and application contr= ol. >> >> >> >> The current Internet protocol stack has no layer for explicit >> >> signaling of flow semantics and characteristics to network elements, >> >> nor an integrated signaling mechanism from network elements to back t= o >> >> endpoints and applications. This layer never evolved within the stack= , >> >> because middleboxes and other devices on path could simply inspect an= d >> >> modify headers and payload of unencrypted traffic at every layer. Thi= s >> >> implicit use of information from the transport and application layers >> >> is a key origin of the ossification that makes it hard or impossible = to deploy new protocols. >> >> >> >> In order to support more ubiquitous deployment of encryption, explici= t >> >> signaling must be added to the stack, and it must be transport >> >> protocol independent. 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. Additionally, 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. >> >> >> >> The PLUS working group will specify a new protocol as a Path Layer >> >> User 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 similar semantics to existing protocols (e.g. >> >> TCP) to devices on path (e.g. NATs and firewalls) >> >> >> >> - allow applications and transport protocols to explicitly provide >> >> limited information to devices on path >> >> >> >> - allow devices on path to provide feedback and information about the >> >> path to sending endpoints, under sending endpoint control >> >> >> >> - allow devices on path to provide information about the path to >> >> receiving endpoints, with feedback to the sending endpoint, under >> >> sending endpoint control >> >> >> >> Note that 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 >> >> at the level of detail that is useful for the network, while >> >> encrypting everything else. This is important to avoid future implici= t >> >> treatment and the resulting ossification, as well as to leverage the >> >> principle of least exposure to minimize privacy risks presented by ex= plicit cooperation. >> >> >> >> Given that the primary goal of PLUS is to enable the deployment of >> >> arbitrary, fully encrypted transport protocols, 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 modifi= cations. >> >> >> >> 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 Pr= otocol for User Datagrams 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 these >> >> use cases and requirements. The working group will close if it is not >> >> able to come to consensus on a protocol design to meet these requirem= ents. >> >> >> >> The working group will additionally aim to identify other working >> >> groups that could or should address parts of these requirements withi= n >> >> 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. TLS) which could b= e >> >> used for encryption of transport protocols running over 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 > > -- > --- > Toerless Eckert, eckert@cisco.com From nobody Thu May 19 12:39: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 1F4EA12DBF7 for ; Thu, 19 May 2016 12:39:14 -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 1unrNpsp58IH for ; Thu, 19 May 2016 12:39:12 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 3422412D67F for ; Thu, 19 May 2016 12:39:12 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id p64so29424440ioi.2 for ; Thu, 19 May 2016 12:39:12 -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:date:message-id:subject:from:to :cc; bh=BkIVCkaD0bH1xjeGBMfum2qbSSqGmttwp6B6/Ms1tSU=; b=ehMZyWWu+NkVtqrjIQSSK8tYLFARhL8StDcVywPpUN5DL/hQ+oHmGcwQftJqh1yYxD XEKEgfao9NRL6bMKigbqkJRhADcMnU6oCMPacLY5/ZPrewr6jyE4zTYuoJv0yh3GHyZh vHiep4s4OBc1oFNvxn0IRV5nbz8ODIBILLtokZVCUzfsCH7U4smTnnDguwkGEi26CbG0 GPlBsQYT8hZNC2BmIfziQGKiVz4a7aMxsImyOHBMcWBUzD48YyfHYLEhTreRi5vTGEb3 s6ecRxQ5Z6E7+CCWkIieM0xDzHfF+WDnImkYozTPPt/7BI3+HOg7albPCPc8i3Ho6s7s iMVw== 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:date :message-id:subject:from:to:cc; bh=BkIVCkaD0bH1xjeGBMfum2qbSSqGmttwp6B6/Ms1tSU=; b=bynfq74ufsZy4ODT33nCPd09MmRcY3xjLomP7pvEzRb3WFhCXKXlHABLgQuzBHgmmS YdYzSRfxaCXtmw2pw8TnViZVqgk3iX5aznyb8QdxPQC8SS2g7KbFR4janPq9vbvYMIJR 16esMbw0q22JLc5FlHtRhSQsE/TNBMD+SGZE3AsPDW9DV494gR5f5JH8IbRnp/psO5Zg b59INuTckOcgpu399BkyEmde0r12M9RIMZogDwJ0FnAGTp8SiePfdWOm5OXs0TFvt2Rk zKUckVjJwAontIkpin9BCcUUHfxuuis2W58HSFIJlB36XQwO7jO7Ga2VJ9IFTUiHnlY/ AKRw== X-Gm-Message-State: AOPr4FUpIdRaNm0iTqel6/BayeHskbVe8Oajo9/L5MWIVcJmZY9HFIut7Bo9sfxmGePkGNXQ+VopDU//ANnklg== MIME-Version: 1.0 X-Received: by 10.36.96.14 with SMTP id i14mr4597873itc.91.1463686751389; Thu, 19 May 2016 12:39:11 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 19 May 2016 12:39:11 -0700 (PDT) In-Reply-To: <20160519185943.GM12994@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> Date: Thu, 19 May 2016 12:39:11 -0700 Message-ID: From: Tom Herbert To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 19:39:14 -0000 On Thu, May 19, 2016 at 11:59 AM, Toerless Eckert wrote: > Whats the likely use-case for this ? Many transports already have a UDP binding, > some like RTP ONLY work across UDP. Even if there is no pre-existing UDP or better > yet dTLS encap, why would someone with transport X choose this scheme over a home-grown one > using UDP/dTLS ? This should be written out with explicit examples to motivate this draft > better. > The current use case we are developing is TCP over UDP. Our deployment scenario is that we want to embed a TCP stack in the client application (Facebook app in this instance), and will update out server stacks appropriately. With the transport stack under our control we can now modify it quickly and not depend on underlying OS to leak out features. An example feature that we'd like to have is TCP Fast Open (TFO). TFO was developed nearly five years ago, but we still cannot effectively use this because Android hasn't supported it. Once we control both the client and server stacks and don't need to worry to affects in the network of changing the transport protocol, implementing new features like TFO in a timely manner becomes feasible. > I haven't spent enough time to understand it all in detail, but the mobility aspect is > of course quite important and necessarily complex. It would be great to write down a > section comparing how you're trying to solve it with your session identifiver vs. how > MT-TCP solves it. I can't see how you provide good mobility and therefore IP address > independency without adding new signaling packets. I am also concerned about creating a > new session identifier to replace transport addresses because that impacts applications > building eg: a TCP connection and whose APIs might need to change. But as said: Mostly > FUD and not enough detailled understanding of your drafts bits & pieces here. > > Wrt to your claim that its useful to protect the L4 headers: I would like to see text > that explicitly writes out what specific elements are protected by this scheme with or > without dTLS and how this reduces which attack vectors. For example, yes: you may not > be able to see TCP session setup/teardown messages and may therefore make life more > miserable for middleboxes, even those trying to do a good thing, but dTLS session > signaling would likely more than compensate for that. > We want to hide the full TCP header from middle boxes. While for the most part middlebox inspection of L4 headers may be innocuous or even beneficial, there are several known cases of middleboxes maliciously mucking with headers. Some middleboxes have dropped TCP options they don't like, so called TCP optimizers rewrite recv window or drop data. There are also injection attacks in TCP streams that can mess up TLS. Another problem is that middleboxes are not guaranteed to have complete flow state. A stateful FW for instance requires that all packets for the flow got through the same device, this reeks havoc with multihoming or mobility. Hiding flow state from such devices nullifies the ad hoc requirement that all packets of a flow must follow the same path. Tom > Wrt to protect every single last bit of a transport layer header from middleboxes, let me bring > this up in another thread. > > Cheers > toerless > > On Thu, May 19, 2016 at 11:17:09AM -0700, Tom Herbert wrote: >> Hello, >> >> We are working on a method to encapsulate transport protocols over >> UDP. This has two goals that are intended to address transport >> protocol ossification in the Internet: >> >> 1) Allow applications to run their own transport layer stack (i.e.from >> userspace). This eliminates dependencies on the OS (e.g. solves a >> major dependency issue for Facebook on clients). >> 2) Make transport layer headers (all of L4) invisible to the network >> so that they can't do intrusive actions at L4. This will be enforced >> with DTLS in use. >> >> Any comments or suggestions are welcome. >> >> Thanks, >> Tom >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Thu, May 19, 2016 at 10:57 AM >> Subject: New Version Notification for draft-herbert-transports-over-udp-00.txt >> To: Tom Herbert >> >> >> >> A new version of I-D, draft-herbert-transports-over-udp-00.txt >> has been successfully submitted by Tom Herbert and posted to the >> IETF repository. >> >> Name: draft-herbert-transports-over-udp >> Revision: 00 >> Title: Transport layer protocols over UDP >> Document date: 2016-05-19 >> Group: Individual Submission >> Pages: 20 >> URL: >> https://www.ietf.org/internet-drafts/draft-herbert-transports-over-udp-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-herbert-transports-over-udp/ >> Htmlized: https://tools.ietf.org/html/draft-herbert-transports-over-udp-00 >> >> >> Abstract: >> This specification defines a mechanism to encapsulate layer four >> 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. >> >> >> >> >> 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 > > -- > --- > Toerless Eckert, eckert@cisco.com From nobody Thu May 19 13:21: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 B3F1F12D64C for ; Thu, 19 May 2016 13:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.948 X-Spam-Level: X-Spam-Status: No, score=-15.948 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.426, 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 N_88LB5bMVnN for ; Thu, 19 May 2016 13:21:41 -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 E113912B078 for ; Thu, 19 May 2016 13:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6659; q=dns/txt; s=iport; t=1463689300; x=1464898900; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=xRLUixlyV4WT2RNUkKWxYK8txrTv1IbwMrGwgVGBuic=; b=U9CUufIof16oVvhl4m5yVrze4CTC0ZoE6WRIcuHz9T1MeCoNARop8VIL 2OJOf3vgD0R4695R/kAsyHGNp1o1aP3JgWPHuv0BJ/ZjmbLngblYrcJIJ pqng2HBU15AXAmMdo7r/IK3hY3YdDBsExW4IBnB8ljpLx+CRoZpvKKIMJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQAJHz5X/xbLJq1ehA1+sjWHXAENg?= =?us-ascii?q?XUXDYVtAoFnFAEBAQEBAQFlJ4RCAQEBAwEBAQE3NAkCBQsLEQMBAgEJJQ8FEyg?= =?us-ascii?q?OExuIDAgOw1MBAQEBAQEBAQEBAQEBAQEBAQEBAQEciW+BA4QphW8FhkCBQ4Vhd?= =?us-ascii?q?IRdhHyFGGiIFgqBaU6EAYhihjGJGB4BAUKCOIFVHDIBiAUBAQE?= X-IronPort-AV: E=Sophos;i="5.26,335,1459814400"; d="scan'208";a="677265977" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 May 2016 20:21:37 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4JKLZtE006319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2016 20:21:37 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 u4JKLZ1O031896; Thu, 19 May 2016 13:21:35 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4JKLYrD031895; Thu, 19 May 2016 13:21:34 -0700 Date: Thu, 19 May 2016 13:21:34 -0700 From: Toerless Eckert To: Tom Herbert Message-ID: <20160519202134.GP12994@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> 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: spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 20:21:44 -0000 On Thu, May 19, 2016 at 12:39:11PM -0700, Tom Herbert wrote: > The current use case we are developing is TCP over UDP. Our deployment > scenario is that we want to embed a TCP stack in the client > application (Facebook app in this instance), and will update out > server stacks appropriately. With the transport stack under our > control we can now modify it quickly and not depend on underlying OS > to leak out features. An example feature that we'd like to have is TCP > Fast Open (TFO). TFO was developed nearly five years ago, but we still > cannot effectively use this because Android hasn't supported it. > Once we control both the client and server stacks and don't need to > worry to affects in the network of changing the transport protocol, > implementing new features like TFO in a timely manner becomes > feasible. Thanks. If where to translate this into text i'd like to see it would say: Operating System Transport Protocol Stacks are not agile enough with latest improvements in Transport protocols, especially extensions to widely used ones like TCP (example TFO). Various experiements where and are being done to implement transport layer protocols over UDP to allow them to be implemented in application layer code. A standard encapsulation would allow interoperability between different implementations and allow to not having to reinvent the encap across different transport protocols. > We want to hide the full TCP header from middle boxes. While for the > most part middlebox inspection of L4 headers may be innocuous or even > beneficial, there are several known cases of middleboxes maliciously > mucking with headers. Some middleboxes have dropped TCP options they > don't like, so called TCP optimizers rewrite recv window or drop data. > There are also injection attacks in TCP streams that can mess up TLS. > Another problem is that middleboxes are not guaranteed to have > complete flow state. A stateful FW for instance requires that all > packets for the flow got through the same device, this reeks havoc > with multihoming or mobility. Hiding flow state from such devices > nullifies the ad hoc requirement that all packets of a flow must > follow the same path. Unless all this is in some reference to your doc i've overlooked, this would all be good text to ad and better motivate the work. That would still not persuade me that your approach is the best one to address these issues though ;-): TLS should not be attackable this way. Isn't this fixed in 1.3 ? You don't want to be a baby sitter for TLS. TLS has to be a standalone babysitter. That why we hired it ;-) The other cases are just examples of bad middleboxes. So let's say TCP optimizers. If you hide everything from them you also negate their good effects. Like localizing retransmissions on lousy paths. Of course, they will suck in specific scenarios because don't support them. The solution for this IMHO only be more complex. The way i'd do it is a) definitely transport over UDP so we can let apps instead OS libs do the work b) have the option to hide or NOT-hide the transport layer in the encap. c) do happy-eyeball to figure out what works best. Start with exposing transport headers. That should give you flow-control improved performance. Change to hiding it when you see that something is not working well. Btw: a well configured middlebox should give traffic that it can not figure out only the lowest bandwidth class anyhow. The nicer you play with the middlebox, the nier it should play with your traffic ;-)) Cheers Toerless > Tom > > > > Wrt to protect every single last bit of a transport layer header from middleboxes, let me bring > > this up in another thread. > > > > Cheers > > toerless > > > > On Thu, May 19, 2016 at 11:17:09AM -0700, Tom Herbert wrote: > >> Hello, > >> > >> We are working on a method to encapsulate transport protocols over > >> UDP. This has two goals that are intended to address transport > >> protocol ossification in the Internet: > >> > >> 1) Allow applications to run their own transport layer stack (i.e.from > >> userspace). This eliminates dependencies on the OS (e.g. solves a > >> major dependency issue for Facebook on clients). > >> 2) Make transport layer headers (all of L4) invisible to the network > >> so that they can't do intrusive actions at L4. This will be enforced > >> with DTLS in use. > >> > >> Any comments or suggestions are welcome. > >> > >> Thanks, > >> Tom > >> > >> > >> ---------- Forwarded message ---------- > >> From: > >> Date: Thu, May 19, 2016 at 10:57 AM > >> Subject: New Version Notification for draft-herbert-transports-over-udp-00.txt > >> To: Tom Herbert > >> > >> > >> > >> A new version of I-D, draft-herbert-transports-over-udp-00.txt > >> has been successfully submitted by Tom Herbert and posted to the > >> IETF repository. > >> > >> Name: draft-herbert-transports-over-udp > >> Revision: 00 > >> Title: Transport layer protocols over UDP > >> Document date: 2016-05-19 > >> Group: Individual Submission > >> Pages: 20 > >> URL: > >> https://www.ietf.org/internet-drafts/draft-herbert-transports-over-udp-00.txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-herbert-transports-over-udp/ > >> Htmlized: https://tools.ietf.org/html/draft-herbert-transports-over-udp-00 > >> > >> > >> Abstract: > >> This specification defines a mechanism to encapsulate layer four > >> 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. > >> > >> > >> > >> > >> 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 > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Thu May 19 13:57:15 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 5847512B017 for ; Thu, 19 May 2016 13:57:14 -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 RNI6lvUIy8v1 for ; Thu, 19 May 2016 13:57:12 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12827128B44 for ; Thu, 19 May 2016 13:57:12 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id 190so123402922iow.1 for ; Thu, 19 May 2016 13:57:12 -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:date:message-id:subject:from:to :cc; bh=f5Gs5U3aI/AbN2jyO4mQBxFBlS1jjtORzikofOKoDuA=; b=t26hLoi1+BcTP9pWi9YekWLNEphTCOT1epanpU8Ur7H20GilNd9S8EXp9FFddRVgJN TIRqX89sizaYBv+N7dhtkYE3+b0Jfij10v4AiEE6pXipJWAl4wrwzVx7jvRZ5YZwbQOx RnBjFclbN/e+/TgyPyX4+bXDGY8jdVrOISZMpw0T6LV5hLu7KAOdlr+k/uZ4/6TKAEe+ w6eV44B6/QU5duWKLSwD6MVsCYFRjXmm4qZQF0djKzI0o5rnTXF2C1+Bb/MTp4Sl4Ta3 yq7rx4N1oNNlS23tvBXFaKrmr7mrfjPDmhQforKkrSJXxJwqo3Ec08wsBVry6ukLsw4m 5mBQ== 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:date :message-id:subject:from:to:cc; bh=f5Gs5U3aI/AbN2jyO4mQBxFBlS1jjtORzikofOKoDuA=; b=hY3AUHMpMwvT0cdg18XLdp7snVYxu2DGi/KviT50p7Dpu6rwPrpgcezvGP7PXQUtvG DtQF9mpyw5iZHbm7S6TLhu6N5rk6DduZvyUhKe/A0mO1oreWYK6yFEH7eFPNBJlZ0Pj3 JNxETvvSoEjnI/x9Gt+ri/iATfil9RZRo4X8acqs/e5Bu3mihiVhLvgGLYH1fM7wHdZC 9Kqod4zN21CezySzh3R+HsWOwNhtIqHeSGLRQVV+ejoJDh4B3661LkbopCZtQymRf3Jn AQGd5GaaG6SugKdoDI/DCmgjO0f7qyKnT9pmCz5dWzqekN6xhqvtjC7oPV3Tpd9mgHXu mQDw== X-Gm-Message-State: AOPr4FVCLg69hPUELI2CrPkJqGV/JGi2cI+Yb/jihJ7+WxlB4yTYCsyJGp+iWbQAVIyCCBGSV/UPCVogb/ZzFA== MIME-Version: 1.0 X-Received: by 10.107.142.18 with SMTP id q18mr11423588iod.84.1463691431326; Thu, 19 May 2016 13:57:11 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 19 May 2016 13:57:10 -0700 (PDT) In-Reply-To: <20160519202134.GP12994@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <20160519202134.GP12994@cisco.com> Date: Thu, 19 May 2016 13:57:10 -0700 Message-ID: From: Tom Herbert To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 20:57:14 -0000 On Thu, May 19, 2016 at 1:21 PM, Toerless Eckert wrote: > On Thu, May 19, 2016 at 12:39:11PM -0700, Tom Herbert wrote: >> The current use case we are developing is TCP over UDP. Our deployment >> scenario is that we want to embed a TCP stack in the client >> application (Facebook app in this instance), and will update out >> server stacks appropriately. With the transport stack under our >> control we can now modify it quickly and not depend on underlying OS >> to leak out features. An example feature that we'd like to have is TCP >> Fast Open (TFO). TFO was developed nearly five years ago, but we still >> cannot effectively use this because Android hasn't supported it. >> Once we control both the client and server stacks and don't need to >> worry to affects in the network of changing the transport protocol, >> implementing new features like TFO in a timely manner becomes >> feasible. > > Thanks. > > If where to translate this into text i'd like to see it would say: > Operating System Transport Protocol Stacks are not agile enough with latest improvements > in Transport protocols, especially extensions to widely used ones like TCP (example TFO). > Various experiements where and are being done to implement transport layer protocols > over UDP to allow them to be implemented in application layer code. A standard > encapsulation would allow interoperability between different implementations and > allow to not having to reinvent the encap across different transport protocols. > Yes, also the part about interactions of middleboxes with new transport layer features is probably equally important as the client OS issue. >> We want to hide the full TCP header from middle boxes. While for the >> most part middlebox inspection of L4 headers may be innocuous or even >> beneficial, there are several known cases of middleboxes maliciously >> mucking with headers. Some middleboxes have dropped TCP options they >> don't like, so called TCP optimizers rewrite recv window or drop data. >> There are also injection attacks in TCP streams that can mess up TLS. >> Another problem is that middleboxes are not guaranteed to have >> complete flow state. A stateful FW for instance requires that all >> packets for the flow got through the same device, this reeks havoc >> with multihoming or mobility. Hiding flow state from such devices >> nullifies the ad hoc requirement that all packets of a flow must >> follow the same path. > > Unless all this is in some reference to your doc i've overlooked, this would all be > good text to ad and better motivate the work. That would still not persuade me that > your approach is the best one to address these issues though ;-): > Thanks, I'll add that. > TLS should not be attackable this way. Isn't this fixed in 1.3 ? You don't want > to be a baby sitter for TLS. TLS has to be a standalone babysitter. That why we > hired it ;-) > If an attacker successfully injects a packet into the TCP stream (by predicting seq #s for instance) couldn't that mess up TLS? > The other cases are just examples of bad middleboxes. So let's say TCP optimizers. > If you hide everything from them you also negate their good effects. Like > localizing retransmissions on lousy paths. Of course, they will suck in specific > scenarios because don't support them. The solution for this IMHO only be more > complex. The way i'd do it is > a) definitely transport over UDP so we can let apps instead OS libs do the work > b) have the option to hide or NOT-hide the transport layer in the encap. > c) do happy-eyeball to figure out what works best. Start with exposing transport > headers. That should give you flow-control improved performance. Change > to hiding it when you see that something is not working well. > > Btw: a well configured middlebox should give traffic that it can not figure out > only the lowest bandwidth class anyhow. The nicer you play with the middlebox, the > nier it should play with your traffic ;-)) > Right, the way we're dealing with seems to be a textbook application of the robustness principle. Tom > Cheers > Toerless > >> Tom >> >> >> > Wrt to protect every single last bit of a transport layer header from middleboxes, let me bring >> > this up in another thread. >> > >> > Cheers >> > toerless >> > >> > On Thu, May 19, 2016 at 11:17:09AM -0700, Tom Herbert wrote: >> >> Hello, >> >> >> >> We are working on a method to encapsulate transport protocols over >> >> UDP. This has two goals that are intended to address transport >> >> protocol ossification in the Internet: >> >> >> >> 1) Allow applications to run their own transport layer stack (i.e.from >> >> userspace). This eliminates dependencies on the OS (e.g. solves a >> >> major dependency issue for Facebook on clients). >> >> 2) Make transport layer headers (all of L4) invisible to the network >> >> so that they can't do intrusive actions at L4. This will be enforced >> >> with DTLS in use. >> >> >> >> Any comments or suggestions are welcome. >> >> >> >> Thanks, >> >> Tom >> >> >> >> >> >> ---------- Forwarded message ---------- >> >> From: >> >> Date: Thu, May 19, 2016 at 10:57 AM >> >> Subject: New Version Notification for draft-herbert-transports-over-udp-00.txt >> >> To: Tom Herbert >> >> >> >> >> >> >> >> A new version of I-D, draft-herbert-transports-over-udp-00.txt >> >> has been successfully submitted by Tom Herbert and posted to the >> >> IETF repository. >> >> >> >> Name: draft-herbert-transports-over-udp >> >> Revision: 00 >> >> Title: Transport layer protocols over UDP >> >> Document date: 2016-05-19 >> >> Group: Individual Submission >> >> Pages: 20 >> >> URL: >> >> https://www.ietf.org/internet-drafts/draft-herbert-transports-over-udp-00.txt >> >> Status: >> >> https://datatracker.ietf.org/doc/draft-herbert-transports-over-udp/ >> >> Htmlized: https://tools.ietf.org/html/draft-herbert-transports-over-udp-00 >> >> >> >> >> >> Abstract: >> >> This specification defines a mechanism to encapsulate layer four >> >> 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. >> >> >> >> >> >> >> >> >> >> 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 >> > >> > -- >> > --- >> > Toerless Eckert, eckert@cisco.com >> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud > > -- > --- > Toerless Eckert, eckert@cisco.com From nobody Thu May 19 14:06: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 080A1128B44 for ; Thu, 19 May 2016 14:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.927 X-Spam-Level: X-Spam-Status: No, score=-15.927 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, RP_MATCHES_RCVD=-1.426, 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 WZPSF1brcYiU for ; Thu, 19 May 2016 14:06:47 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C35B12D644 for ; Thu, 19 May 2016 14:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4296; q=dns/txt; s=iport; t=1463692006; x=1464901606; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=El3ZW5Ic2SiB1R4pCqwp/dJJOBUEsNSei3Rg/0U0KwE=; b=jtPZ5l84syuqcKVNuenqfssu5Ay+OnAQqme7yGHnVK5OPW80jtl8HZ5m WPSdTFiygIEqE5Hn1/K/5L6HBwZeqEhG0c5MEgCEIJWkYUHSR06bzsWXD 9Q1Iv0kd6C0TSq6oKNzH3hQKKsLW2KCqOuNnzlEvQRkYjEYvGoAy/CEur w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBAAaKj5X/xjFo0hehA1+sjWJXxcNh?= =?us-ascii?q?W0CgXsBAQEBAQFmJ4RCAQEBAwEBAQE3NAkCEAsRAwECAQklDwUTKA4TiCcIDsM?= =?us-ascii?q?4AQEBAQEBAQEBAQEBAQEBAQEBAQEBHIpyihgFhkCBQ4VhdIlZhRhoiBYKgWlOh?= =?us-ascii?q?AGIYo9JYoI4gVUcMgGIBQEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,335,1459814400"; d="scan'208";a="60169178" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 May 2016 21:06:42 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4JL6dFr003825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2016 21:06:42 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 u4JL6d3R032330; Thu, 19 May 2016 14:06:39 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4JL6dcd032329; Thu, 19 May 2016 14:06:39 -0700 Date: Thu, 19 May 2016 14:06:39 -0700 From: Toerless Eckert To: Tom Herbert Message-ID: <20160519210639.GQ12994@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <20160519202134.GP12994@cisco.com> 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: spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 21:06:49 -0000 On Thu, May 19, 2016 at 01:57:10PM -0700, Tom Herbert wrote: > > TLS should not be attackable this way. Isn't this fixed in 1.3 ? You don't want > > to be a baby sitter for TLS. TLS has to be a standalone babysitter. That why we > > hired it ;-) > > > If an attacker successfully injects a packet into the TCP stream (by > predicting seq #s for instance) couldn't that mess up TLS? Define "mess up". And yes, maybe. But the more interesting question is if there is no such attack (inject faked packets to make connction unworkable) againt dTLS. Cheers Toerless > > Btw: a well configured middlebox should give traffic that it can not figure out > > only the lowest bandwidth class anyhow. The nicer you play with the middlebox, the > > nier it should play with your traffic ;-)) > > > Right, the way we're dealing with seems to be a textbook application > of the robustness principle. > > Tom > > > Cheers > > Toerless > > > >> Tom > >> > >> > >> > Wrt to protect every single last bit of a transport layer header from middleboxes, let me bring > >> > this up in another thread. > >> > > >> > Cheers > >> > toerless > >> > > >> > On Thu, May 19, 2016 at 11:17:09AM -0700, Tom Herbert wrote: > >> >> Hello, > >> >> > >> >> We are working on a method to encapsulate transport protocols over > >> >> UDP. This has two goals that are intended to address transport > >> >> protocol ossification in the Internet: > >> >> > >> >> 1) Allow applications to run their own transport layer stack (i.e.from > >> >> userspace). This eliminates dependencies on the OS (e.g. solves a > >> >> major dependency issue for Facebook on clients). > >> >> 2) Make transport layer headers (all of L4) invisible to the network > >> >> so that they can't do intrusive actions at L4. This will be enforced > >> >> with DTLS in use. > >> >> > >> >> Any comments or suggestions are welcome. > >> >> > >> >> Thanks, > >> >> Tom > >> >> > >> >> > >> >> ---------- Forwarded message ---------- > >> >> From: > >> >> Date: Thu, May 19, 2016 at 10:57 AM > >> >> Subject: New Version Notification for draft-herbert-transports-over-udp-00.txt > >> >> To: Tom Herbert > >> >> > >> >> > >> >> > >> >> A new version of I-D, draft-herbert-transports-over-udp-00.txt > >> >> has been successfully submitted by Tom Herbert and posted to the > >> >> IETF repository. > >> >> > >> >> Name: draft-herbert-transports-over-udp > >> >> Revision: 00 > >> >> Title: Transport layer protocols over UDP > >> >> Document date: 2016-05-19 > >> >> Group: Individual Submission > >> >> Pages: 20 > >> >> URL: > >> >> https://www.ietf.org/internet-drafts/draft-herbert-transports-over-udp-00.txt > >> >> Status: > >> >> https://datatracker.ietf.org/doc/draft-herbert-transports-over-udp/ > >> >> Htmlized: https://tools.ietf.org/html/draft-herbert-transports-over-udp-00 > >> >> > >> >> > >> >> Abstract: > >> >> This specification defines a mechanism to encapsulate layer four > >> >> 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. > >> >> > >> >> > >> >> > >> >> > >> >> 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 > >> > > >> > -- > >> > --- > >> > Toerless Eckert, eckert@cisco.com > >> > >> _______________________________________________ > >> Spud mailing list > >> Spud@ietf.org > >> https://www.ietf.org/mailman/listinfo/spud > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com -- --- Toerless Eckert, eckert@cisco.com From nobody Thu May 19 14:36:46 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 4020E12D692 for ; Thu, 19 May 2016 14:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 qh5Aj6xPOlr6 for ; Thu, 19 May 2016 14:36:44 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 6A1F112D690 for ; Thu, 19 May 2016 14:36:44 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4JLaYHi018845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 May 2016 14:36:34 -0700 (PDT) To: Tom Herbert , Toerless Eckert References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> From: Joe Touch Message-ID: <573E31E1.807@isi.edu> Date: Thu, 19 May 2016 14:36:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; 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-MailScanner-ID: u4JLaYHi018845 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 21:36:45 -0000 There are many ways to support user-land transport protocols (raw IP, tun/tap devices, etc.) and some good reasons not to (lack of coordination with kernel-based transports). IMO, adding a layer of encapsulation (and all that entails, including the need for PLPMTUD, other ICMP signal relaying between layers, etc.) is a very inefficient and complex way to overcome an implementation convenience issue. Joe On 5/19/2016 12:39 PM, Tom Herbert wrote: > The current use case we are developing is TCP over UDP. Our deployment > scenario is that we want to embed a TCP stack in the client > application (Facebook app in this instance), and will update out > server stacks appropriately. With the transport stack under our > control we can now modify it quickly and not depend on underlying OS > to leak out features. An example feature that we'd like to have is TCP > Fast Open (TFO). TFO was developed nearly five years ago, but we still > cannot effectively use this because Android hasn't supported it. > Once we control both the client and server stacks and don't need to > worry to affects in the network of changing the transport protocol, > implementing new features like TFO in a timely manner becomes > feasible. From nobody Thu May 19 14:59: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 6772A12D116 for ; Thu, 19 May 2016 14:59: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 DjJhXf5zjjG5 for ; Thu, 19 May 2016 14:59:32 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 AA79212D0A5 for ; Thu, 19 May 2016 14:59:32 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id b78so8347296ioj.3 for ; Thu, 19 May 2016 14:59: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:date:message-id:subject:from:to :cc; bh=Iufr0P5y3rMai+2c5A/+y7V1kf2BVJm7KSIe0e9NApo=; b=hQKyQz2G8RqDbBc5l75hEvIWWnjCHChHZlTeB+J0y2E1edEwajr7salzKlCqOZ7GhY ypX3EgL5p8styzgP9+W6b0npkLuHflcwdpN1cPHlsHWQuTZiW1MXO05cZV/Sb24VeBTy GMs8lm7PAf8ObLZ4VA/1PxpOLwUBz5Fds3zWBgE2iWuBn7MmD/bW25iu3D19a4sXRfZr RcOMNm4zIDU2Sdvbvi3W+7nx1m+91mWhNRydkNLiNRrz3SRSVQg9CX2EW7QHQiuKOI2+ tdzE8D656OwRAbZ+HS/thO/3gSrEfIuS5TcYDjvdq7WDiUXVuo40NQZywmE5E/3YIglu AnTQ== 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:date :message-id:subject:from:to:cc; bh=Iufr0P5y3rMai+2c5A/+y7V1kf2BVJm7KSIe0e9NApo=; b=ebc7apsPP0nR8Bx2qiN7zBIVLw9IbTEO0xv3YyMWMq4cPV3wkjA3UfWDXfU4SVJkMl YjkZKurv0wx+W/0IYz4uahWEqkRwqj34Sm6EM/iSpzTySzkauy3rDXL/VvSRQBpdZ9FQ DmQbEnmk86k8Q/SBmp90heT0/Xkzf1ZmFhij4vH0VhV6xrB6X/WG8hUiyEiT0iEn1pLB /9wd2qs8uATsG1v9qrj5WNVKMFM/jSZ0+mjLZyllIiWV7Ho+j2x7HQi4BUv5XAeYiS73 O2skg1QXXD2zlixqMyuox0kSxsq+lZiLi3d/bHHlhv2x1uCh0rTSYtCW/aAXXzZcsFWK mgeg== X-Gm-Message-State: AOPr4FW1N167p1ywsQdJ++/lO/QkrseAsheB1qgz4nY8ofnbpKPkysMiGqu6McHc/xb4gn6qFtaZEuj5ZVVYpw== MIME-Version: 1.0 X-Received: by 10.36.46.76 with SMTP id i73mr32251ita.91.1463695171767; Thu, 19 May 2016 14:59:31 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 19 May 2016 14:59:31 -0700 (PDT) In-Reply-To: <573E31E1.807@isi.edu> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> Date: Thu, 19 May 2016 14:59:31 -0700 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Toerless Eckert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 21:59:34 -0000 On Thu, May 19, 2016 at 2:36 PM, Joe Touch wrote: > There are many ways to support user-land transport protocols (raw IP, > tun/tap devices, etc.) and some good reasons not to (lack of > coordination with kernel-based transports). > Raw IP and tun/tap require privileged access and as you mention requires coordination with kernel stack (if nothing else we need to deal with allocations in TCP tuple namespace). We have support for neither of those available in the application environment we need to run in. > IMO, adding a layer of encapsulation (and all that entails, including > the need for PLPMTUD, other ICMP signal relaying between layers, etc.) > is a very inefficient and complex way to overcome an implementation > convenience issue. > As far as the kernel is concerned this is just another UDP application so PMTU discovery and ICMP should work normally as long as the ICMP messages are sent pertaining to the UDP packet. It is true that if we run a TCP stack in userspace we lose quite a bit of efficiency compared to a stack running in kernel that is well integrated with lower layers, routing, NIC offloads, etc. (at my last count Linux TCP stack interacted with other layers and other parts of the kernel at about fifty different points). This is why I believe we want an asymmetric implementation. For our Internet clients we want to run the TCP stack as part of the application to achieve OS independence (from Android, iOS, etc.); on the server side where scalability is the primary issue I will use a modified kernel stack that implements TOU. Tom > Joe > > On 5/19/2016 12:39 PM, Tom Herbert wrote: >> The current use case we are developing is TCP over UDP. Our deployment >> scenario is that we want to embed a TCP stack in the client >> application (Facebook app in this instance), and will update out >> server stacks appropriately. With the transport stack under our >> control we can now modify it quickly and not depend on underlying OS >> to leak out features. An example feature that we'd like to have is TCP >> Fast Open (TFO). TFO was developed nearly five years ago, but we still >> cannot effectively use this because Android hasn't supported it. >> Once we control both the client and server stacks and don't need to >> worry to affects in the network of changing the transport protocol, >> implementing new features like TFO in a timely manner becomes >> feasible. > From nobody Thu May 19 15:11: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 17F4212D140 for ; Thu, 19 May 2016 15:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 rQdr_nDqLNfM for ; Thu, 19 May 2016 15:11:04 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69DD12D0DA for ; Thu, 19 May 2016 15:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2235; q=dns/txt; s=iport; t=1463695864; x=1464905464; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Uboh6IVEuYx75KCOGbVvx7/4Zs6M61CU669Av9Cn7IM=; b=Go4PveZb5Hl+OEgIe8rnvpkgrFuijZRolqtf0x8EiB9XIsL3I+sShJiK aU+OoN/1TkpdEjmqYSgQB7Wcfy4PhKJV7PVUFgJyv0mhWmDJR4VbePUui kNyCFvexPiaL7qgVLeKYbFB6lrl3JQgMs/T9sz/D5HDXN6xQUHqjZzsAE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAgDZOD5X/4QNJK1eDoMpgVS6EQENg?= =?us-ascii?q?XWGEQKBLzgUAQEBAQEBAWUnhEIBAQEDATo9AgULCxgJJQ8FSROIJwjDVwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARyKcoQphW8FhkCHIwF0iVmFGIh+CoFpjTGGMYkYH?= =?us-ascii?q?gEBQoI4elscMogGAQEB?= X-IronPort-AV: E=Sophos;i="5.26,336,1459814400"; d="scan'208";a="275759221" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 May 2016 22:11:03 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4JMB32m030751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2016 22:11: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 u4JMB3g4000436; Thu, 19 May 2016 15:11:03 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4JMB2wc000435; Thu, 19 May 2016 15:11:02 -0700 Date: Thu, 19 May 2016 15:11:02 -0700 From: Toerless Eckert To: Joe Touch Message-ID: <20160519221102.GS12994@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573E31E1.807@isi.edu> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 22:11:06 -0000 On Thu, May 19, 2016 at 02:36:33PM -0700, Joe Touch wrote: > There are many ways to support user-land transport protocols (raw IP, > tun/tap devices, etc.) All options not available to non-privileged user processes across the board of OSs and programming language libraries (C,C++,python,java,javascript). > and some good reasons not to (lack of coordination with kernel-based transports). And example why i'd care for coordination with kernel based transports ? > IMO, adding a layer of encapsulation (and all that entails, including > the need for PLPMTUD, Just use IPv6 and < 1280 packets. IN my book, Jumbo packets should be the last dinosaurs on their way out. > other ICMP signal relaying between layers, etc.) Example ? > is a very inefficient and complex way to overcome an implementation > convenience issue. Do you think you can come with metrics for "inefficient and complex" that everybody agrees to ? Eg: The overhead of going from IPv4 to IPv6 addresses is higher than the UDP encap. Does that make IPv6 "very very inefficient" ? Also: your convenience issue is my market innovation/agility/ossification and adoption issue. How do we build agreeable metrics around those criteria ? Name calling is easy. Quantification is not. Cheers Toerless If we where > > Joe > > On 5/19/2016 12:39 PM, Tom Herbert wrote: > > The current use case we are developing is TCP over UDP. Our deployment > > scenario is that we want to embed a TCP stack in the client > > application (Facebook app in this instance), and will update out > > server stacks appropriately. With the transport stack under our > > control we can now modify it quickly and not depend on underlying OS > > to leak out features. An example feature that we'd like to have is TCP > > Fast Open (TFO). TFO was developed nearly five years ago, but we still > > cannot effectively use this because Android hasn't supported it. > > Once we control both the client and server stacks and don't need to > > worry to affects in the network of changing the transport protocol, > > implementing new features like TFO in a timely manner becomes > > feasible. -- --- Toerless Eckert, eckert@cisco.com From nobody Thu May 19 15:21: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 E0C6412D140 for ; Thu, 19 May 2016 15:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 DbsWNeSIG8lM for ; Thu, 19 May 2016 15:21:49 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 B0FC012D0DA for ; Thu, 19 May 2016 15:21:49 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4JMLIrw025524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 May 2016 15:21:19 -0700 (PDT) To: Toerless Eckert References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> From: Joe Touch Message-ID: <573E3C5E.2090300@isi.edu> Date: Thu, 19 May 2016 15:21:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160519221102.GS12994@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u4JMLIrw025524 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 22:21:51 -0000 On 5/19/2016 3:11 PM, Toerless Eckert wrote: > On Thu, May 19, 2016 at 02:36:33PM -0700, Joe Touch wrote: >> There are many ways to support user-land transport protocols (raw IP, >> tun/tap devices, etc.) > All options not available to non-privileged user processes across the board > of OSs and programming language libraries (C,C++,python,java,javascript). There's a reason for that; a protocol hack is not a good rationale for an end-run around the legitimate desire for security in these systems. >> and some good reasons not to (lack of coordination with kernel-based transports). > And example why i'd care for coordination with kernel based transports ? At some point, when the version of TCP you want is in the kernel, you'll want to transition. That begs the question of demuxing incoming services, and whether the kernel peeks into the packet to send them to the right place (which might be at a different port inside the kernel). >> IMO, adding a layer of encapsulation (and all that entails, including >> the need for PLPMTUD, > Just use IPv6 and < 1280 packets. IN my book, Jumbo packets should be the last dinosaurs > on their way out. You can't expect support for these new TCP variants, but you expect ubiquitous support for IPv6? >> other ICMP signal relaying between layers, etc.) > Example ? see draft-ietf-intarea-tunnels, section 4.5 >> is a very inefficient and complex way to overcome an implementation >> convenience issue. > Do you think you can come with metrics for "inefficient and complex" that everybody > agrees to ? Eg: The overhead of going from IPv4 to IPv6 addresses is higher than > the UDP encap. Does that make IPv6 "very very inefficient" ? I'm confused now; above you assumed IPv6. Now you're comparing UDP/IPv4 vs. IPv6? > Also: your convenience issue is my market innovation/agility/ossification and adoption issue. > How do we build agreeable metrics around those criteria ? Your ossification is my stability. Let's say you migrate to using this encapsulation. What happens later when you want to transition to a more native version? How do you coordinate whether to use the encapsulated version or not? or will you now require the kernel to do the extra UDP encapsulation? I'm not in favor of creating a mess for the future for a little short-term benefit. Effort would be better spent getting the desired features into these OS transport implementations. Joe From nobody Thu May 19 15:22: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 BD21912D0DA for ; Thu, 19 May 2016 15:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 ifTkHVyfgsad for ; Thu, 19 May 2016 15:22:43 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 EB8EE12D1B7 for ; Thu, 19 May 2016 15:22:42 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4JMMOQ2025616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 May 2016 15:22:24 -0700 (PDT) To: Tom Herbert References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> From: Joe Touch Message-ID: <573E3C9F.202@isi.edu> Date: Thu, 19 May 2016 15:22:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u4JMMOQ2025616 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Toerless Eckert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 22:22:45 -0000 Your intent is to thus reinvent the Internet over UDP, solely to get around the fact that you don't have permission to do so otherwise? Again, a very poor justification for this level of complexity. I don't consider RFCs useful when they address only temporary concerns. Joe On 5/19/2016 2:59 PM, Tom Herbert wrote: > On Thu, May 19, 2016 at 2:36 PM, Joe Touch wrote: >> There are many ways to support user-land transport protocols (raw IP, >> tun/tap devices, etc.) and some good reasons not to (lack of >> coordination with kernel-based transports). >> > Raw IP and tun/tap require privileged access and as you mention > requires coordination with kernel stack (if nothing else we need to > deal with allocations in TCP tuple namespace). We have support for > neither of those available in the application environment we need to > run in. > >> IMO, adding a layer of encapsulation (and all that entails, including >> the need for PLPMTUD, other ICMP signal relaying between layers, etc.) >> is a very inefficient and complex way to overcome an implementation >> convenience issue. >> > As far as the kernel is concerned this is just another UDP application > so PMTU discovery and ICMP should work normally as long as the ICMP > messages are sent pertaining to the UDP packet. > > It is true that if we run a TCP stack in userspace we lose quite a bit > of efficiency compared to a stack running in kernel that is well > integrated with lower layers, routing, NIC offloads, etc. (at my last > count Linux TCP stack interacted with other layers and other parts of > the kernel at about fifty different points). This is why I believe we > want an asymmetric implementation. For our Internet clients we want to > run the TCP stack as part of the application to achieve OS > independence (from Android, iOS, etc.); on the server side where > scalability is the primary issue I will use a modified kernel stack > that implements TOU. > > Tom > >> Joe >> >> On 5/19/2016 12:39 PM, Tom Herbert wrote: >>> The current use case we are developing is TCP over UDP. Our deployment >>> scenario is that we want to embed a TCP stack in the client >>> application (Facebook app in this instance), and will update out >>> server stacks appropriately. With the transport stack under our >>> control we can now modify it quickly and not depend on underlying OS >>> to leak out features. An example feature that we'd like to have is TCP >>> Fast Open (TFO). TFO was developed nearly five years ago, but we still >>> cannot effectively use this because Android hasn't supported it. >>> Once we control both the client and server stacks and don't need to >>> worry to affects in the network of changing the transport protocol, >>> implementing new features like TFO in a timely manner becomes >>> feasible. From nobody Thu May 19 15:31: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 E695112D0DA for ; Thu, 19 May 2016 15:31: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 rxLYniyEb8gY for ; Thu, 19 May 2016 15:31:01 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001: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 65DC512D1B7 for ; Thu, 19 May 2016 15:31:01 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id p64so34592226ioi.2 for ; Thu, 19 May 2016 15:31:01 -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:date:message-id:subject:from:to :cc; bh=+6qaZpjmOSsEhiBf+W/k6ssybW47dFUY/mWt02JigpY=; b=GTteZ0L5/Z7PUPDx0d3oITXoUhAwMVY16+GlcGTczn8iKgUsq01DL35pbN1IjQvXSF NSUldfKXNULrv3slGcU1YiXtvZyi3EzXUamrr9TOSSWoiWhKc2Z/WfBy42xy8KkSoOsO gULJmVBL1hoOTpbHkTMQPD/StMsVxSjj44QmJ57ECTzUbruAZ6ZR0p0OJXCeOdhM2z47 0nuqenoXHHYza8xfCsES/yWAISwQLz8RwpSrIvHPfLsJ6g5ty7H+gcQQgOtzvL4exVnT yGdsFKOBn0Klq7G2LlmKrR0Gg9HcrflYepOLhNFvBsaJNbIWqE2VJ4HfAxGrjxiUrUXo UOIg== 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:date :message-id:subject:from:to:cc; bh=+6qaZpjmOSsEhiBf+W/k6ssybW47dFUY/mWt02JigpY=; b=hnENlXTHpFEt2UquRSCdtFYOGfgsJ7JTHxn5oOVd975LzeLdUU73IZ/y619ZSreqjH CjoJB3gODMbur7S5x8YQCxy5RoYfyUxlGpG1c9pTKCGJtbvozE3FMM31VLKCTGTLeZPy 5T8d+z82AXFyzRrmBHMWeExNhKhDi4FpKfiuto1RpY6lj9dxDNZ5RfBpfZImCV6Z9Pj7 cIkhLprRw0gKI5Pyq79GsRXcEpObsHLLIpfo0Usu6sAk4BURxHLI+Tv+8C4F+zmLMk1S 4mnb6ZNIwGljIoKY2ZbKr/wOjabDeSql2p26uFIUGqEJhTAFxHw5LMy1MBk9Ahc6vCV1 CN6A== X-Gm-Message-State: AOPr4FXmvN1MizZoFdjAFKn+Nk01zWo3HfEtg6H1Gkp0Z8FjegPtWjyuioQInACK1i1HkAdXTz0Zq1yHLBuYMQ== MIME-Version: 1.0 X-Received: by 10.107.142.18 with SMTP id q18mr274585iod.84.1463697060567; Thu, 19 May 2016 15:31:00 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 19 May 2016 15:31:00 -0700 (PDT) In-Reply-To: <573E3C9F.202@isi.edu> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> Date: Thu, 19 May 2016 15:31:00 -0700 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Toerless Eckert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 22:31:04 -0000 On Thu, May 19, 2016 at 3:22 PM, Joe Touch wrote: > Your intent is to thus reinvent the Internet over UDP, solely to get > around the fact that you don't have permission to do so otherwise? > A somewhat coarse way of phrasing it, but otherwise correct. Running over UDP seems to be the best solution to defeating protocol ossification in the Internet-- RFC7663, SPUD, QUIC, and others attest to that. > Again, a very poor justification for this level of complexity. I don't > consider RFCs useful when they address only temporary concerns. > Unfortunately, protocol ossification does not seem to be a temporary issue. Tom > Joe > > On 5/19/2016 2:59 PM, Tom Herbert wrote: >> On Thu, May 19, 2016 at 2:36 PM, Joe Touch wrote: >>> There are many ways to support user-land transport protocols (raw IP, >>> tun/tap devices, etc.) and some good reasons not to (lack of >>> coordination with kernel-based transports). >>> >> Raw IP and tun/tap require privileged access and as you mention >> requires coordination with kernel stack (if nothing else we need to >> deal with allocations in TCP tuple namespace). We have support for >> neither of those available in the application environment we need to >> run in. >> >>> IMO, adding a layer of encapsulation (and all that entails, including >>> the need for PLPMTUD, other ICMP signal relaying between layers, etc.) >>> is a very inefficient and complex way to overcome an implementation >>> convenience issue. >>> >> As far as the kernel is concerned this is just another UDP application >> so PMTU discovery and ICMP should work normally as long as the ICMP >> messages are sent pertaining to the UDP packet. >> >> It is true that if we run a TCP stack in userspace we lose quite a bit >> of efficiency compared to a stack running in kernel that is well >> integrated with lower layers, routing, NIC offloads, etc. (at my last >> count Linux TCP stack interacted with other layers and other parts of >> the kernel at about fifty different points). This is why I believe we >> want an asymmetric implementation. For our Internet clients we want to >> run the TCP stack as part of the application to achieve OS >> independence (from Android, iOS, etc.); on the server side where >> scalability is the primary issue I will use a modified kernel stack >> that implements TOU. >> >> Tom >> >>> Joe >>> >>> On 5/19/2016 12:39 PM, Tom Herbert wrote: >>>> The current use case we are developing is TCP over UDP. Our deployment >>>> scenario is that we want to embed a TCP stack in the client >>>> application (Facebook app in this instance), and will update out >>>> server stacks appropriately. With the transport stack under our >>>> control we can now modify it quickly and not depend on underlying OS >>>> to leak out features. An example feature that we'd like to have is TCP >>>> Fast Open (TFO). TFO was developed nearly five years ago, but we still >>>> cannot effectively use this because Android hasn't supported it. >>>> Once we control both the client and server stacks and don't need to >>>> worry to affects in the network of changing the transport protocol, >>>> implementing new features like TFO in a timely manner becomes >>>> feasible. > From nobody Thu May 19 15:32: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 E6B9A12D5F4 for ; Thu, 19 May 2016 15:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 k_95Fybk5SeH for ; Thu, 19 May 2016 15:32:12 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 AE63312D5D2 for ; Thu, 19 May 2016 15:32:12 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id x19so152489376oix.2 for ; Thu, 19 May 2016 15:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=iOGg4TiDFG1z6Ox/OoeQJJTTF4RulQUIJSELSKLPV2A=; b=Tl4gFT+taK6qJ0Rgodf8/EaopsR+r4Xwfym99gtCMjgNU/wYhsed6Yt5UjZy9l6dRM 3q14cn6hAR/n4zhBj71BhlhyL7MplkQO6R0e6rU3m9KfNxmn6irwdEC1Z9NZB15gOeTK SLFdJX6AJLKIijVYYLBYRlnLVvntivBM1QzesrHvTbdGcBK7wYqTbP39Bh1xJQEgnoV+ QEBgsM532+YJ9RlIv0UhKptF2stsWrPyKTzGeWho6VNF3HmdCKTXzoREGQno7fTXuiba Vo5e5JjYsPdQqvodfmUNFqBjwmxFiXgnd9H5Qg+pOrYuDegXNOAX76aE4DNlB8NIMYcH 1pgQ== 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:date :message-id:subject:from:to:cc; bh=iOGg4TiDFG1z6Ox/OoeQJJTTF4RulQUIJSELSKLPV2A=; b=RD0jbcicmha5KQNTj23vBGXUtU9f9IICsan2H/13LVMsk7WP2Rh5SOOA8tFkw06kOq Sa8ECVRLEnSogXnLCO0SJZUUPH2yDM+pp+oDyOIVt0QUGOj+K2tICdU3tJYvgbI/sDM3 1IdjREPaeyQLit6RgyKH0+Y+lytDwm4bv+Gb6bj8UNly7LDNshQzxk4cuz9k3HHqyRA/ JH/HdGz9SIsYtyAGFZhrKWa1SeMXpPN/Vwprw9ynubsZIr2wc7SRVhKXpyBHZzfzQl4A vaOLPpZT+Dou7k42D76va4udZpcPK4CsZpMcAFycACEw+UZCcrdGQS7shMklVvmjWA2p rleQ== X-Gm-Message-State: AOPr4FWiUe/Msqu/40p2oQ+qOw1QpnBffRAPOgHWHPf/QJqNBEN6xzQR5rKmTDwCu5xxEpJHiOkwpHC4kCaemA== MIME-Version: 1.0 X-Received: by 10.202.219.196 with SMTP id s187mr33422oig.167.1463697132064; Thu, 19 May 2016 15:32:12 -0700 (PDT) Received: by 10.157.42.69 with HTTP; Thu, 19 May 2016 15:32:11 -0700 (PDT) In-Reply-To: <573E3C9F.202@isi.edu> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> Date: Thu, 19 May 2016 15:32:11 -0700 Message-ID: From: Ca By To: Joe Touch Content-Type: multipart/alternative; boundary=001a113d22d49d98d70533398b42 Archived-At: Cc: Tom Herbert , Toerless Eckert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 22:32:15 -0000 --001a113d22d49d98d70533398b42 Content-Type: text/plain; charset=UTF-8 On Thursday, May 19, 2016, Joe Touch wrote: > Your intent is to thus reinvent the Internet over UDP, solely to get > around the fact that you don't have permission to do so otherwise? > > Again, a very poor justification for this level of complexity. I don't > consider RFCs useful when they address only temporary concerns. > > Joe > > +1 for joe. This and similarly quic are creating an arms race. These things wont stop, and the next step is your local middle box provider requiring users to install their mitm cert :( We already saw this this "http trusted proxies" > On 5/19/2016 2:59 PM, Tom Herbert wrote: > > On Thu, May 19, 2016 at 2:36 PM, Joe Touch > > wrote: > >> There are many ways to support user-land transport protocols (raw IP, > >> tun/tap devices, etc.) and some good reasons not to (lack of > >> coordination with kernel-based transports). > >> > > Raw IP and tun/tap require privileged access and as you mention > > requires coordination with kernel stack (if nothing else we need to > > deal with allocations in TCP tuple namespace). We have support for > > neither of those available in the application environment we need to > > run in. > > > >> IMO, adding a layer of encapsulation (and all that entails, including > >> the need for PLPMTUD, other ICMP signal relaying between layers, etc.) > >> is a very inefficient and complex way to overcome an implementation > >> convenience issue. > >> > > As far as the kernel is concerned this is just another UDP application > > so PMTU discovery and ICMP should work normally as long as the ICMP > > messages are sent pertaining to the UDP packet. > > > > It is true that if we run a TCP stack in userspace we lose quite a bit > > of efficiency compared to a stack running in kernel that is well > > integrated with lower layers, routing, NIC offloads, etc. (at my last > > count Linux TCP stack interacted with other layers and other parts of > > the kernel at about fifty different points). This is why I believe we > > want an asymmetric implementation. For our Internet clients we want to > > run the TCP stack as part of the application to achieve OS > > independence (from Android, iOS, etc.); on the server side where > > scalability is the primary issue I will use a modified kernel stack > > that implements TOU. > > > > Tom > > > >> Joe > >> > >> On 5/19/2016 12:39 PM, Tom Herbert wrote: > >>> The current use case we are developing is TCP over UDP. Our deployment > >>> scenario is that we want to embed a TCP stack in the client > >>> application (Facebook app in this instance), and will update out > >>> server stacks appropriately. With the transport stack under our > >>> control we can now modify it quickly and not depend on underlying OS > >>> to leak out features. An example feature that we'd like to have is TCP > >>> Fast Open (TFO). TFO was developed nearly five years ago, but we still > >>> cannot effectively use this because Android hasn't supported it. > >>> Once we control both the client and server stacks and don't need to > >>> worry to affects in the network of changing the transport protocol, > >>> implementing new features like TFO in a timely manner becomes > >>> feasible. > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --001a113d22d49d98d70533398b42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, May 19, 2016, Joe Touch <touch@isi.edu> wrote:
Your = intent is to thus reinvent the Internet over UDP, solely to get
around the fact that you don't have permission to do so otherwise?

Again, a very poor justification for this level of complexity. I don't<= br> consider RFCs useful when they address only temporary concerns.

Joe


+1 for joe.=C2=A0

=
This and similarly quic are creating an arms race.=C2=A0
These things wont stop, and the next step is your local middle = box provider requiring users to install their mitm cert :(

We already saw this this "http trusted proxies"
=C2=A0
On 5/19/2016 2:59 PM, Tom Herbert wrote:
> On Thu, May 19, 2016 at 2:36 PM, Joe Touch <touch@isi.= edu> wrote:
>> There are many ways to support user-land transport protocols (raw = IP,
>> tun/tap devices, etc.) and some good reasons not to (lack of
>> coordination with kernel-based transports).
>>
> Raw IP and tun/tap require privileged access and as you mention
> requires coordination with kernel stack (if nothing else we need to > deal with allocations in TCP tuple namespace). We have support for
> neither of those available in the application environment we need to > run in.
>
>> IMO, adding a layer of encapsulation (and all that entails, includ= ing
>> the need for PLPMTUD, other ICMP signal relaying between layers, e= tc.)
>> is a very inefficient and complex way to overcome an implementatio= n
>> convenience issue.
>>
> As far as the kernel is concerned this is just another UDP application=
> so PMTU discovery and ICMP should work normally as long as the ICMP > messages are sent pertaining to the UDP packet.
>
> It is true that if we run a TCP stack in userspace we lose quite a bit=
> of efficiency compared to a stack running in kernel that is well
> integrated with lower layers, routing, NIC offloads, etc. (at my last<= br> > count Linux TCP stack interacted with other layers and other parts of<= br> > the kernel at about fifty different points). This is why I believe we<= br> > want an asymmetric implementation. For our Internet clients we want to=
> run the TCP stack as part of the application to achieve OS
> independence (from Android, iOS, etc.); on the server side where
> scalability is the primary issue I will use a modified kernel stack > that implements TOU.
>
> Tom
>
>> Joe
>>
>> On 5/19/2016 12:39 PM, Tom Herbert wrote:
>>> The current use case we are developing is TCP over UDP. Our de= ployment
>>> scenario is that we want to embed a TCP stack in the client >>> application (Facebook app in this instance), and will update o= ut
>>> server stacks appropriately. With the transport stack under ou= r
>>> control we can now modify it quickly and not depend on underly= ing OS
>>> to leak out features. An example feature that we'd like to= have is TCP
>>> Fast Open (TFO). TFO was developed nearly five years ago, but = we still
>>> cannot effectively use this because Android hasn't support= ed it.
>>> Once we control both the client and server stacks and don'= t need to
>>> worry to affects in the network of changing the transport prot= ocol,
>>> implementing new features like TFO in a timely manner becomes<= br> >>> feasible.

_______________________________________________
Spud mailing list
Spud@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/spud
--001a113d22d49d98d70533398b42-- From nobody Thu May 19 15:43: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 26DAB12D1A7 for ; Thu, 19 May 2016 15:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 U50e3GB3csQt for ; Thu, 19 May 2016 15:43:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CD812D0DA for ; Thu, 19 May 2016 15:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4317; q=dns/txt; s=iport; t=1463697814; x=1464907414; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=QwXJjw3oeBik0zu1U54ntwtIXjZJdNp81upkFs9592E=; b=OaUX0FlMUaLI0SdWahUjB8faPpi5NWBb5y82oL6kZFu4Dx/FMgXVRbl3 nWgC5L49rrx0UdznNcyiy3E3OVz6d71gZWODNkj0OAHRG4wNxlWmVOOaw H+JGgKNr6zIaY4uhkfPuJu2IE3ixaRHn9Gxq1BIU2gJOUbnQmMnmFSEuo 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgBbQD5X/4QNJK1egzdWfroRAQ2Bd?= =?us-ascii?q?RcLhW8CgTA4FAEBAQEBAQFlJ4RCAQEBAwEBAQE3NAkCEAsOCgklDwUTNhOIJwg?= =?us-ascii?q?Ow14BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYpyhCmFbwWGQIcjdYlZhRiIfgqBa?= =?us-ascii?q?Y0xhjGJGB4BAUKCOIFVHDKGSCSBGgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,336,1459814400"; d="scan'208";a="106373268" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 May 2016 22:43:33 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4JMhWIQ020117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2016 22:43:33 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 u4JMhWrt000731; Thu, 19 May 2016 15:43:32 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4JMhWt8000730; Thu, 19 May 2016 15:43:32 -0700 Date: Thu, 19 May 2016 15:43:32 -0700 From: Toerless Eckert To: Ca By Message-ID: <20160519224332.GU12994@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> 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: Tom Herbert , spud , Joe Touch Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 22:43:36 -0000 On Thu, May 19, 2016 at 03:32:11PM -0700, Ca By wrote: > On Thursday, May 19, 2016, Joe Touch wrote: > > > Your intent is to thus reinvent the Internet over UDP, solely to get > > around the fact that you don't have permission to do so otherwise? > > > > Again, a very poor justification for this level of complexity. I don't > > consider RFCs useful when they address only temporary concerns. > > > > Joe > > > > > +1 for joe. > > This and similarly quic are creating an arms race. > > These things wont stop, and the next step is your local middle box provider > requiring users to install their mitm cert :( > > We already saw this this "http trusted proxies" *Sob* First of all, there will not be an arms race on one front: We will escape ossification of the transport stack implementations because OS vendors MUST keep UDP sockets available to apps. So we can long term continue to plan to use the for app based transport stack. Btw: The alternative that app vendors are going to guarantee they have a predictasble transprt stack is to build their apps into VMs so they have control over the kernel. That a lot more complex in my book. Secondly: SPUD is exactly the proposal to avoid having the need for these "http trusted proxies" Toerless > > On 5/19/2016 2:59 PM, Tom Herbert wrote: > > > On Thu, May 19, 2016 at 2:36 PM, Joe Touch > > > wrote: > > >> There are many ways to support user-land transport protocols (raw IP, > > >> tun/tap devices, etc.) and some good reasons not to (lack of > > >> coordination with kernel-based transports). > > >> > > > Raw IP and tun/tap require privileged access and as you mention > > > requires coordination with kernel stack (if nothing else we need to > > > deal with allocations in TCP tuple namespace). We have support for > > > neither of those available in the application environment we need to > > > run in. > > > > > >> IMO, adding a layer of encapsulation (and all that entails, including > > >> the need for PLPMTUD, other ICMP signal relaying between layers, etc.) > > >> is a very inefficient and complex way to overcome an implementation > > >> convenience issue. > > >> > > > As far as the kernel is concerned this is just another UDP application > > > so PMTU discovery and ICMP should work normally as long as the ICMP > > > messages are sent pertaining to the UDP packet. > > > > > > It is true that if we run a TCP stack in userspace we lose quite a bit > > > of efficiency compared to a stack running in kernel that is well > > > integrated with lower layers, routing, NIC offloads, etc. (at my last > > > count Linux TCP stack interacted with other layers and other parts of > > > the kernel at about fifty different points). This is why I believe we > > > want an asymmetric implementation. For our Internet clients we want to > > > run the TCP stack as part of the application to achieve OS > > > independence (from Android, iOS, etc.); on the server side where > > > scalability is the primary issue I will use a modified kernel stack > > > that implements TOU. > > > > > > Tom > > > > > >> Joe > > >> > > >> On 5/19/2016 12:39 PM, Tom Herbert wrote: > > >>> The current use case we are developing is TCP over UDP. Our deployment > > >>> scenario is that we want to embed a TCP stack in the client > > >>> application (Facebook app in this instance), and will update out > > >>> server stacks appropriately. With the transport stack under our > > >>> control we can now modify it quickly and not depend on underlying OS > > >>> to leak out features. An example feature that we'd like to have is TCP > > >>> Fast Open (TFO). TFO was developed nearly five years ago, but we still > > >>> cannot effectively use this because Android hasn't supported it. > > >>> Once we control both the client and server stacks and don't need to > > >>> worry to affects in the network of changing the transport protocol, > > >>> implementing new features like TFO in a timely manner becomes > > >>> feasible. > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud > > -- --- Toerless Eckert, eckert@cisco.com From nobody Thu May 19 15:53: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 96E4912D0F1 for ; Thu, 19 May 2016 15:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 E21d7UmfMAis for ; Thu, 19 May 2016 15:52:57 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2364E12D0BE for ; Thu, 19 May 2016 15:52:56 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id x19so153122196oix.2 for ; Thu, 19 May 2016 15:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=E548oiEc1ZvyNaTutcgio75fxNdbL/z8m7jybZY+SMg=; b=ZNp+lOkkfM6Gfqa9c5UTOUWK87UKmLSk2M34vpw+LOatmt4BjynDn1E4d75A9sHxwS 9FkQO5ziHMhcEs8R0ZlLD2uzZ9MfmqiXmtLk6qWxdbcc+gFcy7os8vKMitQqGaoTreDL m7LOwV4OAlLe0D1dTqzwUhrENHb2nal0Agvl+9rWx4f8E933KiVKH7nP+5jG4qqOroA7 YWNXd1A1eqQuCaxDXPDsAqzL6FoDETYZhJIQoaHYhHgKnwUqJy57J/iP0pHBm7g/Ein2 dfilffqv8PwlNcii/IWRwzohWnq2hU/CWo4915IfvD3Y8lpPonIc4Ybsj9JITg0BoRSO RQDg== 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:date :message-id:subject:from:to:cc; bh=E548oiEc1ZvyNaTutcgio75fxNdbL/z8m7jybZY+SMg=; b=N5WM2pKt4ckoKUW76+Fn1EyiaU0/8RSg6s529jTohxX/MQMnzOf6VN59u7jSN5l6A+ raSsgNZqyBF+Bd3JCfZztXymefKKeIyjW++Lg20EaXkckkUt36DI3Q+lve3P6K4sKFDt MOJDBx2iw4DEQ1WpK/V7AbC3xJMVOPfTfZ+gj7KewMdLKSkuQicq/tagf/wo5GYh8q5r rKrKixGtAigeHR+5GwjIw2UIQAOaWBK0TrA+3UJoRx2o3LpSafIbnwi3feUIg1D6bg6u LSQkdSxXqg6IBEc9tSy7RJGHC9jbYuldl4CycqjwNVR6qJi0XGpZOT9uheFM8RRrU1DZ w1vQ== X-Gm-Message-State: AOPr4FXzyoLBQ4ZDu9mHSJrARZbwGTjafk2YafEfLmiKLL4ThEeuZilZ9ItT6Zmh8Hp9fZ3l5SHLdSm8sUiYRw== MIME-Version: 1.0 X-Received: by 10.157.9.100 with SMTP id 91mr9171818otp.142.1463698376284; Thu, 19 May 2016 15:52:56 -0700 (PDT) Received: by 10.157.42.69 with HTTP; Thu, 19 May 2016 15:52:56 -0700 (PDT) In-Reply-To: <20160519224332.GU12994@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519224332.GU12994@cisco.com> Date: Thu, 19 May 2016 15:52:56 -0700 Message-ID: From: Ca By To: Toerless Eckert Content-Type: multipart/alternative; boundary=94eb2c04f3fcc6e243053339d5cc Archived-At: Cc: Tom Herbert , spud , Joe Touch Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 22:52:59 -0000 --94eb2c04f3fcc6e243053339d5cc Content-Type: text/plain; charset=UTF-8 On Thursday, May 19, 2016, Toerless Eckert wrote: > On Thu, May 19, 2016 at 03:32:11PM -0700, Ca By wrote: > > On Thursday, May 19, 2016, Joe Touch > > wrote: > > > > > Your intent is to thus reinvent the Internet over UDP, solely to get > > > around the fact that you don't have permission to do so otherwise? > > > > > > Again, a very poor justification for this level of complexity. I don't > > > consider RFCs useful when they address only temporary concerns. > > > > > > Joe > > > > > > > > +1 for joe. > > > > This and similarly quic are creating an arms race. > > > > These things wont stop, and the next step is your local middle box > provider > > requiring users to install their mitm cert :( > > > > We already saw this this "http trusted proxies" > > *Sob* > > I hear you. > First of all, there will not be an arms race on one front: We will escape > ossification of the transport stack implementations because OS vendors MUST > keep UDP sockets available to apps. So we can long term continue to plan to > use the for app based transport stack. Btw: The alternative that app > vendors > are going to guarantee they have a predictasble transprt stack is to build > their > apps into VMs so they have control over the kernel. That a lot more complex > in my book. > > 1. The IETF recommends using existing transport. Translation, the IETF says dont do this with udp https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-13#section-3 2. Udp is and will be blocked in many cases, so you are just forcing the evil telcos to plug another hole UDP is already blocked in many context, your app must always fall back to work in these common scenarios ... So blocking udp is just a downgrade attack. > Secondly: SPUD is exactly the proposal to avoid having the need for these > "http trusted proxies" > > Again, udp will be blocked if used in this way. I wish not to have an arms race, but playing out the moves on the chess board .... Toerless > > > > On 5/19/2016 2:59 PM, Tom Herbert wrote: > > > > On Thu, May 19, 2016 at 2:36 PM, Joe Touch > > > > wrote: > > > >> There are many ways to support user-land transport protocols (raw > IP, > > > >> tun/tap devices, etc.) and some good reasons not to (lack of > > > >> coordination with kernel-based transports). > > > >> > > > > Raw IP and tun/tap require privileged access and as you mention > > > > requires coordination with kernel stack (if nothing else we need to > > > > deal with allocations in TCP tuple namespace). We have support for > > > > neither of those available in the application environment we need to > > > > run in. > > > > > > > >> IMO, adding a layer of encapsulation (and all that entails, > including > > > >> the need for PLPMTUD, other ICMP signal relaying between layers, > etc.) > > > >> is a very inefficient and complex way to overcome an implementation > > > >> convenience issue. > > > >> > > > > As far as the kernel is concerned this is just another UDP > application > > > > so PMTU discovery and ICMP should work normally as long as the ICMP > > > > messages are sent pertaining to the UDP packet. > > > > > > > > It is true that if we run a TCP stack in userspace we lose quite a > bit > > > > of efficiency compared to a stack running in kernel that is well > > > > integrated with lower layers, routing, NIC offloads, etc. (at my last > > > > count Linux TCP stack interacted with other layers and other parts of > > > > the kernel at about fifty different points). This is why I believe we > > > > want an asymmetric implementation. For our Internet clients we want > to > > > > run the TCP stack as part of the application to achieve OS > > > > independence (from Android, iOS, etc.); on the server side where > > > > scalability is the primary issue I will use a modified kernel stack > > > > that implements TOU. > > > > > > > > Tom > > > > > > > >> Joe > > > >> > > > >> On 5/19/2016 12:39 PM, Tom Herbert wrote: > > > >>> The current use case we are developing is TCP over UDP. Our > deployment > > > >>> scenario is that we want to embed a TCP stack in the client > > > >>> application (Facebook app in this instance), and will update out > > > >>> server stacks appropriately. With the transport stack under our > > > >>> control we can now modify it quickly and not depend on underlying > OS > > > >>> to leak out features. An example feature that we'd like to have is > TCP > > > >>> Fast Open (TFO). TFO was developed nearly five years ago, but we > still > > > >>> cannot effectively use this because Android hasn't supported it. > > > >>> Once we control both the client and server stacks and don't need to > > > >>> worry to affects in the network of changing the transport protocol, > > > >>> implementing new features like TFO in a timely manner becomes > > > >>> feasible. > > > > > > _______________________________________________ > > > Spud mailing list > > > Spud@ietf.org > > > https://www.ietf.org/mailman/listinfo/spud > > > > > -- > --- > Toerless Eckert, eckert@cisco.com > --94eb2c04f3fcc6e243053339d5cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, May 19, 2016, Toerless Eckert <eckert@cisco.com> wrote:
On Thu, May 19, 2016 at 03:32:11PM -0700, Ca By wrote:
> On Thursday, May 19, 2016, Joe Touch <touch@isi.edu> wrote:
>
> > Your intent is to thus reinvent the Internet over UDP, solely to = get
> > around the fact that you don't have permission to do so other= wise?
> >
> > Again, a very poor justification for this level of complexity. I = don't
> > consider RFCs useful when they address only temporary concerns. > >
> > Joe
> >
> >
> +1 for joe.
>
> This and similarly quic are creating an arms race.
>
> These things wont stop, and the next step is your local middle box pro= vider
> requiring users to install their mitm cert :(
>
> We already saw this this "http trusted proxies"

*Sob*


=C2=A0
First of all, there will not be an arms race on one front: We will escape ossification of the transport stack implementations because OS vendors MUST=
keep UDP sockets available to apps. So we can long term continue to plan to=
use the for app based transport stack. Btw: The alternative that app vendor= s
are going to guarantee they have a predictasble transprt stack is to build = their
apps into VMs so they have control over the kernel. That a lot more complex=
in my book.


1. The IETF recommends using existing = transport. Translation, the IETF says dont do this with udp

2.=C2=A0 Udp is and will be blocked in many cas= es, so you are just forcing the evil telcos to plug another hole
=
UDP is already blocked in many context, your app must always= fall back to work in these common scenarios=C2=A0... So blocking udp is ju= st a downgrade attack.=C2=A0
=C2=A0
Secondly: SPUD is exactly the proposal to avoid having the need for these "http trusted proxies"


Again, udp will be blocked=C2=A0if use= d in this way.=C2=A0

I wish not to have an arms ra= ce, but playing out the moves on the chess board ....

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Toerless

> > On 5/19/2016 2:59 PM, Tom Herbert wrote:
> > > On Thu, May 19, 2016 at 2:36 PM, Joe Touch <= touch@isi.edu <javascript:;>>
> > wrote:
> > >> There are many ways to support user-land transport proto= cols (raw IP,
> > >> tun/tap devices, etc.) and some good reasons not to (lac= k of
> > >> coordination with kernel-based transports).
> > >>
> > > Raw IP and tun/tap require privileged access and as you ment= ion
> > > requires coordination with kernel stack (if nothing else we = need to
> > > deal with allocations in TCP tuple namespace). We have suppo= rt for
> > > neither of those available in the application environment we= need to
> > > run in.
> > >
> > >> IMO, adding a layer of encapsulation (and all that entai= ls, including
> > >> the need for PLPMTUD, other ICMP signal relaying between= layers, etc.)
> > >> is a very inefficient and complex way to overcome an imp= lementation
> > >> convenience issue.
> > >>
> > > As far as the kernel is concerned this is just another UDP a= pplication
> > > so PMTU discovery and ICMP should work normally as long as t= he ICMP
> > > messages are sent pertaining to the UDP packet.
> > >
> > > It is true that if we run a TCP stack in userspace we lose q= uite a bit
> > > of efficiency compared to a stack running in kernel that is = well
> > > integrated with lower layers, routing, NIC offloads, etc. (a= t my last
> > > count Linux TCP stack interacted with other layers and other= parts of
> > > the kernel at about fifty different points). This is why I b= elieve we
> > > want an asymmetric implementation. For our Internet clients = we want to
> > > run the TCP stack as part of the application to achieve OS > > > independence (from Android, iOS, etc.); on the server side w= here
> > > scalability is the primary issue I will use a modified kerne= l stack
> > > that implements TOU.
> > >
> > > Tom
> > >
> > >> Joe
> > >>
> > >> On 5/19/2016 12:39 PM, Tom Herbert wrote:
> > >>> The current use case we are developing is TCP over U= DP. Our deployment
> > >>> scenario is that we want to embed a TCP stack in the= client
> > >>> application (Facebook app in this instance), and wil= l update out
> > >>> server stacks appropriately. With the transport stac= k under our
> > >>> control we can now modify it quickly and not depend = on underlying OS
> > >>> to leak out features. An example feature that we'= ;d like to have is TCP
> > >>> Fast Open (TFO). TFO was developed nearly five years= ago, but we still
> > >>> cannot effectively use this because Android hasn'= ;t supported it.
> > >>> Once we control both the client and server stacks an= d don't need to
> > >>> worry to affects in the network of changing the tran= sport protocol,
> > >>> implementing new features like TFO in a timely manne= r becomes
> > >>> feasible.
> >
> > _______________________________________________
> > Spud mailing list
> > Spud@ietf.org <javascript:;>
> > https://www.ietf.org/mailman/listinfo/spud
> >

--
---
Toerless Eckert, eckert@cisco.com
--94eb2c04f3fcc6e243053339d5cc-- From nobody Thu May 19 15:56: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 0368212D0F1 for ; Thu, 19 May 2016 15:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 iNkhOGD76-SG for ; Thu, 19 May 2016 15:56:10 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 01FE212B05C for ; Thu, 19 May 2016 15:56:09 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u4JMtmi8016032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 May 2016 15:55:49 -0700 (PDT) To: Toerless Eckert , Ca By References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519224332.GU12994@cisco.com> From: Joe Touch Message-ID: <573E4474.6000202@isi.edu> Date: Thu, 19 May 2016 15:55:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160519224332.GU12994@cisco.com> 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: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 22:56:11 -0000 On the point of an arms race: On 5/19/2016 3:43 PM, Toerless Eckert wrote: > *Sob* > > First of all, there will not be an arms race on one front: We will escape > ossification of the transport stack implementations because OS vendors MUST > keep UDP sockets available to apps. But they can and may end up blocking access to whatever port is assigned to this service, exactly because it's an end-run around OS protections (i.e., anyone can then run a System port service inside UDP on a User port number). And it'll end up impacting things like ECMP, requiring router vendors to peek even further inside packets to find the "real" transport. --- In the end, this has been tried before. The most notable example is Active Nets, which was created to overcome the problem with deploying multicast and IPv6. Yet our "ossified" kernels now have multicast and IPv6 but not Active Nets. It was the rationale for the GENI testbed and so-called "clean slate" approaches. Which have yet to yield anything operational. Can we please learn from the past? Joe From nobody Thu May 19 16:03: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 1105112D0C6 for ; Thu, 19 May 2016 16:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 jrJuwBfEOiHv for ; Thu, 19 May 2016 16:03:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 26AD712D0BE for ; Thu, 19 May 2016 16:03:37 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u4JN3Jvl016727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 May 2016 16:03:20 -0700 (PDT) To: Toerless Eckert References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> From: Joe Touch Message-ID: <573E4636.70001@isi.edu> Date: Thu, 19 May 2016 16:03:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160519225859.GV12994@cisco.com> 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: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 23:03:38 -0000 On 5/19/2016 3:58 PM, Toerless Eckert wrote: > On Thu, May 19, 2016 at 03:22:23PM -0700, Joe Touch wrote: >> Your intent is to thus reinvent the Internet over UDP, solely to get >> around the fact that you don't have permission to do so otherwise? > Its not about reinventing the Internet over UDP, its just about providing > an amendment to the Internet architecture that defines a better demarkation > between OS-land and application-land. The Internet architecture has no knowledge of that distinction. At best, it had the knowledge of privileged vs non-privileged in the assignment of transport port numbers, but that assumption has been depcrated. > There is no reason whatsoever why > anything more than transport layer demultiplexing must be in the kernel, > and there are a lot of good reasons to have per-application differences in > any of the more advanced transport layer functions. > > Expecting the superset of state-of-the art transport layer functions to ALL > exist in ALL OS kernels of internet hosts is just a ridiculous architecture > proposition. And there is nothing in the Internet architecture that constrains any of this. Your issue is with the OS, not the Internet. Please don't *#*!-up the Internet to fix an OS implementation issue. Joe From nobody Thu May 19 16:05: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 687AD12D0BE for ; Thu, 19 May 2016 16:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 ia2W6JETx7nX for ; Thu, 19 May 2016 16:05:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C71612B05C for ; Thu, 19 May 2016 15:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4235; q=dns/txt; s=iport; t=1463698741; x=1464908341; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=4wqFhIUEwZhU6SxTEiYpLkJq7KJFXBg9LjDt/dMDs7k=; b=AXcnaTpbfA8O3g9I5vorxViav5B60bfVxSU7dFAb0wxsGJ4w2soYUfoW xs+HqYZrEls+cs3cWCSQW+Ja1fUIjSE3+6Zw9SbMPzQWPrvXfXFKy1rjs wUtH7SGptmf9obg3iZ4Hs/XuoHk6fCCfQ+ep2r/EpYpcyxlVcjc9tNhKj k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAgBZRD5X/5ldJa1eDoMpgVS6FQENg?= =?us-ascii?q?XWGEQKBMDgUAQEBAQEBAWUnhEIBAQEDATo9AgULCxIGCSUPBTUUExuIDAjDagE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARyKcoQphW8FhkCHIwF0iVmFGIh+CoFphE+IY?= =?us-ascii?q?oYxiRgeAQFCgjh6WxwyhkgkgRoBAQE?= X-IronPort-AV: E=Sophos;i="5.26,336,1459814400"; d="scan'208";a="106230980" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 May 2016 22:59:00 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4JMwx1B031865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2016 22:59:00 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 u4JMwxob001195; Thu, 19 May 2016 15:58:59 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4JMwxOu001194; Thu, 19 May 2016 15:58:59 -0700 Date: Thu, 19 May 2016 15:58:59 -0700 From: Toerless Eckert To: Joe Touch Message-ID: <20160519225859.GV12994@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573E3C9F.202@isi.edu> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 23:05:28 -0000 On Thu, May 19, 2016 at 03:22:23PM -0700, Joe Touch wrote: > Your intent is to thus reinvent the Internet over UDP, solely to get > around the fact that you don't have permission to do so otherwise? Its not about reinventing the Internet over UDP, its just about providing an amendment to the Internet architecture that defines a better demarkation between OS-land and application-land. There is no reason whatsoever why anything more than transport layer demultiplexing must be in the kernel, and there are a lot of good reasons to have per-application differences in any of the more advanced transport layer functions. Expecting the superset of state-of-the art transport layer functions to ALL exist in ALL OS kernels of internet hosts is just a ridiculous architecture proposition. UDP is the only solution to empower apps to have the advanced transport layer functions they want, running on the OSs they need to. This is architecturally the cleanest solution. There is no simpler or better option, because UDP really is only that: a transport layer demultipler in the kernel. Slavery was a mistake in 1789, not thinking about userland agility for transport functions was a mistake in the original internet architecture. We need an amendment that fixes this. > Again, a very poor justification for this level of complexity. I don't > consider RFCs useful when they address only temporary concerns. Again: please define the metrics for you name calling ("level of complexity"). Cheers Toerless > > Joe > > On 5/19/2016 2:59 PM, Tom Herbert wrote: > > On Thu, May 19, 2016 at 2:36 PM, Joe Touch wrote: > >> There are many ways to support user-land transport protocols (raw IP, > >> tun/tap devices, etc.) and some good reasons not to (lack of > >> coordination with kernel-based transports). > >> > > Raw IP and tun/tap require privileged access and as you mention > > requires coordination with kernel stack (if nothing else we need to > > deal with allocations in TCP tuple namespace). We have support for > > neither of those available in the application environment we need to > > run in. > > > >> IMO, adding a layer of encapsulation (and all that entails, including > >> the need for PLPMTUD, other ICMP signal relaying between layers, etc.) > >> is a very inefficient and complex way to overcome an implementation > >> convenience issue. > >> > > As far as the kernel is concerned this is just another UDP application > > so PMTU discovery and ICMP should work normally as long as the ICMP > > messages are sent pertaining to the UDP packet. > > > > It is true that if we run a TCP stack in userspace we lose quite a bit > > of efficiency compared to a stack running in kernel that is well > > integrated with lower layers, routing, NIC offloads, etc. (at my last > > count Linux TCP stack interacted with other layers and other parts of > > the kernel at about fifty different points). This is why I believe we > > want an asymmetric implementation. For our Internet clients we want to > > run the TCP stack as part of the application to achieve OS > > independence (from Android, iOS, etc.); on the server side where > > scalability is the primary issue I will use a modified kernel stack > > that implements TOU. > > > > Tom > > > >> Joe > >> > >> On 5/19/2016 12:39 PM, Tom Herbert wrote: > >>> The current use case we are developing is TCP over UDP. Our deployment > >>> scenario is that we want to embed a TCP stack in the client > >>> application (Facebook app in this instance), and will update out > >>> server stacks appropriately. With the transport stack under our > >>> control we can now modify it quickly and not depend on underlying OS > >>> to leak out features. An example feature that we'd like to have is TCP > >>> Fast Open (TFO). TFO was developed nearly five years ago, but we still > >>> cannot effectively use this because Android hasn't supported it. > >>> Once we control both the client and server stacks and don't need to > >>> worry to affects in the network of changing the transport protocol, > >>> implementing new features like TFO in a timely manner becomes > >>> feasible. From nobody Thu May 19 16:23: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 3492C12D177 for ; Thu, 19 May 2016 16:23:20 -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 avgQKgQK4RWU for ; Thu, 19 May 2016 16:23:15 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 C1AD512B05C for ; Thu, 19 May 2016 16:23:15 -0700 (PDT) Received: by mail-ig0-x232.google.com with SMTP id bi2so126217209igb.0 for ; Thu, 19 May 2016 16:23:15 -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:date:message-id:subject:from:to :cc; bh=6IHoSPlJAzDCHy/db6r1eSnc322ib1/e6ef9SWcEnis=; b=z6uCKS34ENgtfpISBH6KUyJ9Ai0Ctub7/DlzebLTfHTLAfSyyGa5F89UIO95lzOUve QUzuE+Iuq9TspJuS0TOaOew4vDEq8Mi44REilApltVaATwR7XeaVsMtionvX5tJAMh41 2s30BYxvwPpFBMgBZP+E87WJEUAX03eMsBZrWGmoKRIjvV17MC8Ys7FagoSvbpbbEDZ+ SIRrjh9oIhdG+HKcicq1vWzc9IFTLZ6qzLobDKLGR/ZxfLUvF0iJQchCO1juMQFkhF2H DHbH7eaxohGniW6V8rqw8qi9xLsbJoXDWKDFe+dtLkApdtvyRKX0Ay5aup9nypkHDf+p 32Og== 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:date :message-id:subject:from:to:cc; bh=6IHoSPlJAzDCHy/db6r1eSnc322ib1/e6ef9SWcEnis=; b=kq2rcreLqVLZ95PIZlQ3X7fWkwmI9HjVEJFt0zwh9RDcJxF7Suhyzwf9yOzSQVuKU+ uCqGTazfmx1RiJ5IJ6EPZZ0LevOCtbVz5+dwWMRVMdd+A0GoLraUcK7fHFc6uHIk6jDX CXqEkLGbOlee382UMESJRSdrpeg68d0R118SwbPvuz/0XDhr65Bty2GxDojuPtWCIk5j 4HiZIrE2vgEv3P8azAr40U8bX1LJkNAFpO2H6NMIiXWTGWFR1DoDY+yXCUnPSKyTkjDC jFwVBrSPd4JZXvdfAR13MlbqPpa4xc04C2LKpmz8baouWG0Ujh0EwrtuZ1hTJTArVjQp zGsg== X-Gm-Message-State: AOPr4FXTYtBLGmiUgug+VHgiHHGpA8iMXvrqq0AnUiS1pYZ7I61EhkJaWKMrx2qCyJcHgjwH3yxZmLkDgB94ug== MIME-Version: 1.0 X-Received: by 10.50.13.106 with SMTP id g10mr292277igc.65.1463700195100; Thu, 19 May 2016 16:23:15 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 19 May 2016 16:23:14 -0700 (PDT) In-Reply-To: <573E4636.70001@isi.edu> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> Date: Thu, 19 May 2016 16:23:14 -0700 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Toerless Eckert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 23:23:21 -0000 On Thu, May 19, 2016 at 4:03 PM, Joe Touch wrote: > > > On 5/19/2016 3:58 PM, Toerless Eckert wrote: >> On Thu, May 19, 2016 at 03:22:23PM -0700, Joe Touch wrote: >>> Your intent is to thus reinvent the Internet over UDP, solely to get >>> around the fact that you don't have permission to do so otherwise? >> Its not about reinventing the Internet over UDP, its just about providing >> an amendment to the Internet architecture that defines a better demarkation >> between OS-land and application-land. > > The Internet architecture has no knowledge of that distinction. > > At best, it had the knowledge of privileged vs non-privileged in the > assignment of transport port numbers, but that assumption has been > depcrated. > >> There is no reason whatsoever why >> anything more than transport layer demultiplexing must be in the kernel, >> and there are a lot of good reasons to have per-application differences in >> any of the more advanced transport layer functions. >> >> Expecting the superset of state-of-the art transport layer functions to ALL >> exist in ALL OS kernels of internet hosts is just a ridiculous architecture >> proposition. > And there is nothing in the Internet architecture that constrains any of > this. > > Your issue is with the OS, not the Internet. > But there is the issue issue with Internet. Middleboxes will drop packets they don't like for arbitrary reasons. RFC2460 clearly states that intermediate devices should not inspect EH and yet they do and often drop these packets. As I pointed out we've seen middleboxes that drop TCP packets that contain options unknown to it, ones that drop SYN packets that contain data (problem with deploying TFO), middleboxes that take it upon themselves to rewrite parts of the TCP header as they see fit. Heck, before we were using TLS we had middleboxes parsing TCP payloads and doing strange things to it like inserting their own ads into http (see accord BOF). The common theme here is that these middlebox activities are not done per any standard, there is no security or accountability, and we have no way to distinguish malicious versus beneficial interaction; but we (application providers) have to worry about all of this since it is reality. Middlebox invasiveness at layer 4 runs contrary to the end-to-end model and is a primary source of protocol ossification. Either we need to wait for middelboxes to stop being invasive or we need to eliminate the opportunity to be invasive. I don't see that waiting the for the problem to be fixed for us is productive, hence we will pursue the latter. Tom > Please don't *#*!-up the Internet to fix an OS implementation issue. > > Joe > From nobody Thu May 19 16:30: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 1475712D0F5 for ; Thu, 19 May 2016 16:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 vmNVWo82Z3r2 for ; Thu, 19 May 2016 16:30:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 1755012B05C for ; Thu, 19 May 2016 16:30:43 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u4JNUItx021325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 May 2016 16:30:19 -0700 (PDT) To: Tom Herbert References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> From: Joe Touch Message-ID: <573E4C8A.9080902@isi.edu> Date: Thu, 19 May 2016 16:30:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; 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: Toerless Eckert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 23:30:44 -0000 On 5/19/2016 4:23 PM, Tom Herbert wrote: > ... >> And there is nothing in the Internet architecture that constrains any of >> this. >> >> Your issue is with the OS, not the Internet. >> > But there is the issue issue with Internet. Middleboxes will drop > packets they don't like for arbitrary reasons. RFC2460 clearly states > that intermediate devices should not inspect EH and yet they do and > often drop these packets. As I pointed out we've seen middleboxes that > drop TCP packets that contain options unknown to it, ones that drop > SYN packets that contain data (problem with deploying TFO), > middleboxes that take it upon themselves to rewrite parts of the TCP > header as they see fit. Heck, before we were using TLS we had > middleboxes parsing TCP payloads and doing strange things to it like > inserting their own ads into http (see accord BOF). Now your issue is with the ISOC for not enforcing compliance, or at least requiring validation before using terms like "supports Internet protocols and standards". However, like problems with OS implementation, these issues cannot be corrected with technology. All you will accomplish is to "move the goalposts" and escalate the problems you're already experiencing. Joe From nobody Thu May 19 16:32: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 CC10012D11F for ; Thu, 19 May 2016 16:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 Hfu0Z4IEYIio for ; Thu, 19 May 2016 16:32:29 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284D012D0F5 for ; Thu, 19 May 2016 16:32:29 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id x201so154441258oif.3 for ; Thu, 19 May 2016 16:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=15T7rsphO+yGZh4ENkO5Qjo6Xf2MoShVzcL7BIXuW8U=; b=sAyFucjf5d2SRknIPNqRlK1xuyq5x8JrUVK/oBF4YK7SxwZ0OtVBuZ7/Env5tcjsHB fzMdKDLRx+H0EsWzhwW3ARxPANhgQVe58T7pN+aLNqhCJNa2g1pl00JqoAa9/xK25pAp BLqSQKiMYm+pIehATPeeUgn3HMJ1PaTCbWUgOzL5pzfHRfC2DorMMozIEmarLT/3ro4E QjVUVPyJZ2xQmQOMw3WDoOROFnzUO57q3Cn53kbubwtf0eZJ7RJ4OCt2lUIW8ICnN3rM kE8eCFXfJud/ietiZwIUnNLEW2rTzAj8J3773Y9ekTmS4zZe8DW17Z50j4LnQxWp5XD5 s27Q== 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:date :message-id:subject:from:to:cc; bh=15T7rsphO+yGZh4ENkO5Qjo6Xf2MoShVzcL7BIXuW8U=; b=GdlI1SIjK5iFWqnNNfovC+R+8IsehWk5R2WHJ2D84Vb/YITE8djdT2L6CTjwRMGFLP cyaa53aimrxNjhKmDHDvjh5BGNrTqRT+BACC/fybUYJ1SdKm/z49l6v+yYCvAoMkCdF1 RRL+o2EvZmtki94GK/UwBNqkkJgG/asMVIKOf96fig078XB0jne0BxZM9XGYmOgf69wD zC7VF5e4f2mPc6u2LEVz5SbKCaeZpLn5tC4eanFsdlZiXNz2gsf7d9FRkDIbStl0k21G QHYj/H7Uu3RZGcuJBpfjEl1+wKnau8hGQ3HSt/vfH5MVNMQHblv/OAvzptvUuKpOWTch dOPw== X-Gm-Message-State: AOPr4FV6p5GFviZGFWsy6ExVvaP+4oNqbkztmWfiq0Deq1yBZ72lPYhSbbLZy8G2eaKvYBU2Rve6SXB245RRUw== MIME-Version: 1.0 X-Received: by 10.157.42.107 with SMTP id t98mr2442ota.146.1463700748490; Thu, 19 May 2016 16:32:28 -0700 (PDT) Received: by 10.157.42.69 with HTTP; Thu, 19 May 2016 16:32:28 -0700 (PDT) In-Reply-To: References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> Date: Thu, 19 May 2016 16:32:28 -0700 Message-ID: From: Ca By To: Tom Herbert Content-Type: multipart/alternative; boundary=001a113d001a2c035705333a636d Archived-At: Cc: Toerless Eckert , spud , Joe Touch Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 23:32:32 -0000 --001a113d001a2c035705333a636d Content-Type: text/plain; charset=UTF-8 On Thursday, May 19, 2016, Tom Herbert wrote: > On Thu, May 19, 2016 at 4:03 PM, Joe Touch > > wrote: > > > > > > On 5/19/2016 3:58 PM, Toerless Eckert wrote: > >> On Thu, May 19, 2016 at 03:22:23PM -0700, Joe Touch wrote: > >>> Your intent is to thus reinvent the Internet over UDP, solely to get > >>> around the fact that you don't have permission to do so otherwise? > >> Its not about reinventing the Internet over UDP, its just about > providing > >> an amendment to the Internet architecture that defines a better > demarkation > >> between OS-land and application-land. > > > > The Internet architecture has no knowledge of that distinction. > > > > At best, it had the knowledge of privileged vs non-privileged in the > > assignment of transport port numbers, but that assumption has been > > depcrated. > > > >> There is no reason whatsoever why > >> anything more than transport layer demultiplexing must be in the kernel, > >> and there are a lot of good reasons to have per-application differences > in > >> any of the more advanced transport layer functions. > >> > >> Expecting the superset of state-of-the art transport layer functions to > ALL > >> exist in ALL OS kernels of internet hosts is just a ridiculous > architecture > >> proposition. > > And there is nothing in the Internet architecture that constrains any of > > this. > > > > Your issue is with the OS, not the Internet. > > > But there is the issue issue with Internet. Middleboxes will drop > packets they don't like for arbitrary reasons. RFC2460 clearly states > that intermediate devices should not inspect EH and yet they do and > often drop these packets. As I pointed out we've seen middleboxes that > drop TCP packets that contain options unknown to it, ones that drop > SYN packets that contain data (problem with deploying TFO), > middleboxes that take it upon themselves to rewrite parts of the TCP > header as they see fit. Heck, before we were using TLS we had > middleboxes parsing TCP payloads and doing strange things to it like > inserting their own ads into http (see accord BOF). > > The common theme here is that these middlebox activities are not done > per any standard, there is no security or accountability, and we have > no way to distinguish malicious versus beneficial interaction; but we > (application providers) have to worry about all of this since it is > reality. Middlebox invasiveness at layer 4 runs contrary to the > end-to-end model and is a primary source of protocol ossification. > Either we need to wait for middelboxes to stop being invasive or we > need to eliminate the opportunity to be invasive. I don't see that > waiting the for the problem to be fixed for us is productive, hence we > will pursue the latter. > > Tom > > I am sympathetic to your argument. But please answer this 1) if the middleboxes block xyz today, why will they not block your udp innovations ? 2) udp is blocked in many places, so thinga like quic fall back to tcp. 3) given 1 and 2, is your innovation suceptable to a bid-down attack that makes the effort useless ? My view is that middle boxes dont scale and are going away. TCP / TLS / H2 along with decreased latencies in LTE make the escalating cost of middle boxes not smart. My view is based on one real network that had L4 middle boxes for 5+ years and removed them with growing LTE penetration that made scale a problem and benefits marginal. Ymmv > Please don't *#*!-up the Internet to fix an OS implementation issue. > > > > Joe > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --001a113d001a2c035705333a636d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, May 19, 2016, Tom Herbert <tom@herbertland.com> wrote:
On Thu, May 19, 2016 at 4:03 PM, Joe Touch <touch@= isi.edu> wrote:
>
>
> On 5/19/2016 3:58 PM, Toerless Eckert wrote:
>> On Thu, May 19, 2016 at 03:22:23PM -0700, Joe Touch wrote:
>>> Your intent is to thus reinvent the Internet over UDP, solely = to get
>>> around the fact that you don't have permission to do so ot= herwise?
>> Its not about reinventing the Internet over UDP, its just about pr= oviding
>> an amendment to the Internet architecture that defines a better de= markation
>> between OS-land and application-land.
>
> The Internet architecture has no knowledge of that distinction.
>
> At best, it had the knowledge of privileged vs non-privileged in the > assignment of transport port numbers, but that assumption has been
> depcrated.
>
>>=C2=A0 There is no reason whatsoever why
>> anything more than transport layer demultiplexing must be in the k= ernel,
>> and there are a lot of good reasons to have per-application differ= ences in
>> any of the more advanced transport layer functions.
>>
>> Expecting the superset of state-of-the art transport layer functio= ns to ALL
>> exist in ALL OS kernels of internet hosts is just a ridiculous arc= hitecture
>> proposition.
> And there is nothing in the Internet architecture that constrains any = of
> this.
>
> Your issue is with the OS, not the Internet.
>
But there is the issue issue with Internet. Middleboxes will drop
packets they don't like for arbitrary reasons. RFC2460 clearly states that intermediate devices should not inspect EH and yet they do and
often drop these packets. As I pointed out we've seen middleboxes that<= br> drop TCP packets that contain options unknown to it, ones that drop
SYN packets that contain data (problem with deploying TFO),
middleboxes that take it upon themselves to rewrite parts of the TCP
header as they see fit. Heck, before we were using TLS we had
middleboxes parsing TCP payloads and doing strange things to it like
inserting their own ads into http (see accord BOF).

The common theme here is that these middlebox activities are not done
per any standard, there is no security or accountability, and we have
no way to distinguish malicious versus beneficial interaction; but we
(application providers) have to worry about all of this since it is
reality. Middlebox invasiveness at layer 4 runs contrary to the
end-to-end model and is a primary source of protocol ossification.
Either we need to wait for middelboxes to stop being invasive or we
need to eliminate the opportunity to be invasive. I don't see that
waiting the for the problem to be fixed for us is productive, hence we
will pursue the latter.

Tom


I am sympathetic to your argument. But= please answer this

1) if the middleboxes block xy= z today, why will they not block your udp innovations ?

2) udp is blocked in many places, so thinga like quic fall=C2=A0back = to tcp.=C2=A0

3) given 1 and 2, =C2=A0is your inno= vation suceptable to a bid-down attack that makes the effort useless ?=C2= =A0

My view is that middle boxes dont scale and ar= e going away. TCP / TLS / H2 along with decreased=C2=A0=C2=A0latencies in L= TE make=C2=A0=C2=A0the escalating cost of middle boxes not smart.=C2=A0

My view is based on one real=C2=A0network that had L4= =C2=A0middle boxes for 5+ years=C2=A0and removed them with growing LTE pene= tration that made scale a problem and benefits marginal.=C2=A0
Ymmv


> Please don't *#*!-up the Internet to fix an OS implementation issu= e.
>
> Joe
>

_______________________________________________
Spud mailing list
Spud@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/spud
--001a113d001a2c035705333a636d-- From nobody Thu May 19 16:38: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 6023012D177 for ; Thu, 19 May 2016 16:38:56 -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 BxKjAUhLDlGp for ; Thu, 19 May 2016 16:38:55 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 1F20D12D13F for ; Thu, 19 May 2016 16:38:54 -0700 (PDT) Received: by mail-ig0-x232.google.com with SMTP id bi2so126400640igb.0 for ; Thu, 19 May 2016 16:38:54 -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:date:message-id:subject:from:to :cc; bh=fa7cNsIKTpyvxduwXCbLChqf2dhFjf42TlX4sKM0ldg=; b=r6B3V2vhX5Yuw6g5GWebOjytStqHtMgWAtHHvbPa/rfU+eNMU+DaIxCWHP/ohD/+yY QrFCYB6m/6uaW82Asi8HNigX9CzB7ys22HcOLvZaoFFrJ4tXj5iQFJQMv4wizkyN7qS5 mkSxZCZLhS8Np/d+qzh7QvJs9jxnL8gXjfwddm3KBuidjpGwks03rLW6uws4bfEA9KeM xgo/A0emT555k9mxchTwOWXzcG9WAFGFPuxIo/MtmU8TiNVPV1QJJUDK7Jm3q2FgoCRw 6UD8U/aFiBbHLEZ/nCLERU27jZ7GhzqqByWgFrdihW+IJgMi5lbMXIo2W2tEuSRrmGgB iqpw== 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:date :message-id:subject:from:to:cc; bh=fa7cNsIKTpyvxduwXCbLChqf2dhFjf42TlX4sKM0ldg=; b=dFRSb6UPQs3moW1RhrBFdA4ltujdQ5EXhVyctNfrFC338a3f75TogWEaZIGjyyZiXT +r24JIQskPp16ZcKd2hSUEQDSdNluAHltv+nsIixgYdPtcqYTm3Z5HLycq7cuZYh9txP oKR5bDs/fqaGrqV3bZO22YAXUpUb888fgI65mgrQRqAnB/oERjcFis+3lpsMV4GjJoCS SgUWfOVP+0SNeUKZiXPzfd4+mV0TWbaf2safhTCVezFJsC5MoWDKU7n/YGJGqtYgfzkE j6UD39tCPaNjv8i52NunMEXxrNYHUIqmAKIKasCXsDfYdpbg0iKCfsobe2K4v/CQ4Rx2 xX6g== X-Gm-Message-State: AOPr4FV8Tfnx8XUCUgfM9YQEDFIE/e4zJb5xIdvVre20unyetjtnbhjJLUnll05ZLROxUGUjRPrlnBWwZQtAYQ== MIME-Version: 1.0 X-Received: by 10.50.111.15 with SMTP id ie15mr351849igb.94.1463701134283; Thu, 19 May 2016 16:38:54 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 19 May 2016 16:38:54 -0700 (PDT) In-Reply-To: <573E4C8A.9080902@isi.edu> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> <573E4C8A.9080902@isi.edu> Date: Thu, 19 May 2016 16:38:54 -0700 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Toerless Eckert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 23:38:56 -0000 On Thu, May 19, 2016 at 4:30 PM, Joe Touch wrote: > > > On 5/19/2016 4:23 PM, Tom Herbert wrote: >> ... >>> And there is nothing in the Internet architecture that constrains any of >>> this. >>> >>> Your issue is with the OS, not the Internet. >>> >> But there is the issue issue with Internet. Middleboxes will drop >> packets they don't like for arbitrary reasons. RFC2460 clearly states >> that intermediate devices should not inspect EH and yet they do and >> often drop these packets. As I pointed out we've seen middleboxes that >> drop TCP packets that contain options unknown to it, ones that drop >> SYN packets that contain data (problem with deploying TFO), >> middleboxes that take it upon themselves to rewrite parts of the TCP >> header as they see fit. Heck, before we were using TLS we had >> middleboxes parsing TCP payloads and doing strange things to it like >> inserting their own ads into http (see accord BOF). > > Now your issue is with the ISOC for not enforcing compliance, or at > least requiring validation before using terms like "supports Internet > protocols and standards". > > However, like problems with OS implementation, these issues cannot be > corrected with technology. All you will accomplish is to "move the > goalposts" and escalate the problems you're already experiencing. > I disagree. Applying TLS to all of TCP on the Internet has halted middlebox invasiveness beyond layer 4 and is a clear security win for our users (much to the chagrin of some network operators who were parsing payload for legitimate reason, but we will work to adapt their needs to the encrypted world). I don't see why moving the obfuscation point to include transport headers won't have the same effect. If the network can't see it, it can't ossify it. Tom > Joe From nobody Thu May 19 16:48:40 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 C904912D1A7 for ; Thu, 19 May 2016 16:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 blaYrxGKAVyt for ; Thu, 19 May 2016 16:48:38 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC9B12D177 for ; Thu, 19 May 2016 16:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=292; q=dns/txt; s=iport; t=1463701717; x=1464911317; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=hdn00ZccIEqM9unEYb8b3NPIrNNCJ+5r8Md3FhQrJiQ=; b=AU7//5QOJU75++YTKixAK77JlIgSd38MkR8rrb2nUk/Otbvy6n/A4qeN 7vJEik00QDb2rHI/EYgNUTUZdEc8MJSsgqkb4R6VI8xIdnMeodJhrb+mb WoQdA8eOXNRjRZW9fk6reVcRhxRGDTZgLdGi/nTOIS1M35hMZ3jBu1HS4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAgASUD5X/5xdJa1eDoMpu2kBDYF1h?= =?us-ascii?q?hECgTA4FAEBAQEBAQFlJ4RCAQEBAwE6PQIFCwsYCSUPBUmIOgjDfgEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBARyKcodqgi4BBI5YiVmOFgqBUwEVhE+IYo9JHgEBQoI4e?= =?us-ascii?q?lsciDgBAQE?= X-IronPort-AV: E=Sophos;i="5.26,336,1459814400"; d="scan'208";a="275548444" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 May 2016 23:48:37 +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 u4JNmaQI000610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2016 23:48:37 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 u4JNmamS002622; Thu, 19 May 2016 16:48:36 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4JNmabi002621; Thu, 19 May 2016 16:48:36 -0700 Date: Thu, 19 May 2016 16:48:36 -0700 From: Toerless Eckert To: Joe Touch Message-ID: <20160519234836.GA2511@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573E4636.70001@isi.edu> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 23:48:39 -0000 On Thu, May 19, 2016 at 04:03:18PM -0700, Joe Touch wrote: > Your issue is with the OS, not the Internet. Definitely, thats one issue. > Please don't *#*!-up the Internet to fix an OS implementation issue. Still haven't made the point why this is *#*!-up the Internet. Toerless From nobody Thu May 19 16:50: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 67D3F12D1CF for ; Thu, 19 May 2016 16:50:21 -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 d0wz-GQv7wbb for ; Thu, 19 May 2016 16:50:19 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 8EBA212D1BC for ; Thu, 19 May 2016 16:50:19 -0700 (PDT) Received: by mail-ig0-x233.google.com with SMTP id l10so1213364igk.0 for ; Thu, 19 May 2016 16:50:19 -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:date:message-id:subject:from:to :cc; bh=0OuyBSyyrSADVUfixDEVoXYdw5bGmg+oLBykgWzrScs=; b=n/Zate4RHUMAEEDXXiy//JRsgVJSTYJbG0RW9ZMpXXr3KL+/bgYRfBNV++C62cKCRI VEgI8hfJBT44DKJ/nixvjkTM9yKeKuiJ0I8LYyDWh236mAqIC+jmXJ5fLYT1xBwzPzPY iheStUGuf6Llk5xmHIc209BTV43nQoa7jVCka+czDkP1PhxXAJQk5crtnDhrfKawWnLY TWMdNO8foEr3aIk/YH33ajylzjGHFekq90cy4H12C71TEO9cUG4pJto4c7QV1x7RoQB3 3lp2Ip4UNCHYKxLsaNjWyTwk4FOoktV46cfVvryKGbM4c0FrWM8MpzQb0dY/Oe/JMKzf nzAg== 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:date :message-id:subject:from:to:cc; bh=0OuyBSyyrSADVUfixDEVoXYdw5bGmg+oLBykgWzrScs=; b=SfGKilTO6cr2BWrWlxHswY/gdvcC3810iGHEfrkBd+k+JuF3RXWolh6Sun4mRiwoPm vBqNNfQB69CBcOqenWAGfhhNWPqIzXJ7JWaQTftzzLH4JvYipKxd2JtsmiA/HbAduHOj f7x5aHzd4IylMqrzH8GIDnVLX5OQvCX5GVGEKoyrAF9ukWeeErbSnVRuWVvu8lrux0yw 4Pj5IzsQyFoIZsBLfNBoMMba3Z0rjTyzp8FhZL3sAf2/wwQsYR5I6f7Ps1y2yt9kaN3i 0h8G65Q/x+tXx+TRr55SFzYuat139efWUDXSJgYt1ZnHLDUln8I1kIET+0vO5DMk+zZ/ ouOw== X-Gm-Message-State: AOPr4FXvmGn8Tch7Az4UVRAIWi7DNqOskjBsKiaHTs/8hpkftPaWqa21MueJi5FHfkgUbW885Zb2RXVMnjVKQg== MIME-Version: 1.0 X-Received: by 10.50.111.15 with SMTP id ie15mr380637igb.94.1463701818781; Thu, 19 May 2016 16:50:18 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 19 May 2016 16:50:18 -0700 (PDT) In-Reply-To: References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> Date: Thu, 19 May 2016 16:50:18 -0700 Message-ID: From: Tom Herbert To: Ca By Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Toerless Eckert , spud , Joe Touch Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 23:50:21 -0000 On Thu, May 19, 2016 at 4:32 PM, Ca By wrote: > > > On Thursday, May 19, 2016, Tom Herbert wrote: >> >> On Thu, May 19, 2016 at 4:03 PM, Joe Touch wrote: >> > >> > >> > On 5/19/2016 3:58 PM, Toerless Eckert wrote: >> >> On Thu, May 19, 2016 at 03:22:23PM -0700, Joe Touch wrote: >> >>> Your intent is to thus reinvent the Internet over UDP, solely to get >> >>> around the fact that you don't have permission to do so otherwise? >> >> Its not about reinventing the Internet over UDP, its just about >> >> providing >> >> an amendment to the Internet architecture that defines a better >> >> demarkation >> >> between OS-land and application-land. >> > >> > The Internet architecture has no knowledge of that distinction. >> > >> > At best, it had the knowledge of privileged vs non-privileged in the >> > assignment of transport port numbers, but that assumption has been >> > depcrated. >> > >> >> There is no reason whatsoever why >> >> anything more than transport layer demultiplexing must be in the >> >> kernel, >> >> and there are a lot of good reasons to have per-application differences >> >> in >> >> any of the more advanced transport layer functions. >> >> >> >> Expecting the superset of state-of-the art transport layer functions to >> >> ALL >> >> exist in ALL OS kernels of internet hosts is just a ridiculous >> >> architecture >> >> proposition. >> > And there is nothing in the Internet architecture that constrains any of >> > this. >> > >> > Your issue is with the OS, not the Internet. >> > >> But there is the issue issue with Internet. Middleboxes will drop >> packets they don't like for arbitrary reasons. RFC2460 clearly states >> that intermediate devices should not inspect EH and yet they do and >> often drop these packets. As I pointed out we've seen middleboxes that >> drop TCP packets that contain options unknown to it, ones that drop >> SYN packets that contain data (problem with deploying TFO), >> middleboxes that take it upon themselves to rewrite parts of the TCP >> header as they see fit. Heck, before we were using TLS we had >> middleboxes parsing TCP payloads and doing strange things to it like >> inserting their own ads into http (see accord BOF). >> >> The common theme here is that these middlebox activities are not done >> per any standard, there is no security or accountability, and we have >> no way to distinguish malicious versus beneficial interaction; but we >> (application providers) have to worry about all of this since it is >> reality. Middlebox invasiveness at layer 4 runs contrary to the >> end-to-end model and is a primary source of protocol ossification. >> Either we need to wait for middelboxes to stop being invasive or we >> need to eliminate the opportunity to be invasive. I don't see that >> waiting the for the problem to be fixed for us is productive, hence we >> will pursue the latter. >> >> Tom >> > > I am sympathetic to your argument. But please answer this > > 1) if the middleboxes block xyz today, why will they not block your udp > innovations ? > They can choose to arbitrarily block UDP if they want (again that is not standard, but we can't stop them). The assumed rationale is that all UDP is generally a DOS problem, however presuming we using well known ports for transport protocols that are properly congestion controlled and not source of reflection attacks, those specific ports can be allowed as safely as packets with IP protocol number 6 are. > 2) udp is blocked in many places, so thinga like quic fall back to tcp. > Yes, that is a given. Anything new we deploy on the Internet, be it IPv6, SCTP, UDP, TFO, extension headers will necessitate fallback to least common denominator like simple TCP/IP. > 3) given 1 and 2, is your innovation suceptable to a bid-down attack that > makes the effort useless ? > I think that depends on how pervasive UDP drop are. The data presented in BA and QUIC deployment data seems to indicate that UDP is mostly deployable on the Internet right now. Tom > My view is that middle boxes dont scale and are going away. TCP / TLS / H2 > along with decreased latencies in LTE make the escalating cost of middle > boxes not smart. > > My view is based on one real network that had L4 middle boxes for 5+ years > and removed them with growing LTE penetration that made scale a problem and > benefits marginal. > > Ymmv > > >> > Please don't *#*!-up the Internet to fix an OS implementation issue. >> > >> > Joe >> > >> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud From nobody Thu May 19 16:55: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 7F88712D177 for ; Thu, 19 May 2016 16:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 ZDVFyt_w7q-V for ; Thu, 19 May 2016 16:55:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B98E12B04E for ; Thu, 19 May 2016 16:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=635; q=dns/txt; s=iport; t=1463702150; x=1464911750; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=D4KRglfY/lp/ysKtuBoRueJ0RbEuAHITogdCQaZtnTk=; b=fU/ZaOLtGJi9r2ulxA07Rb80dYH85qtC4ivbrvtXsjCcfiL/xBytrHOA qkH9vJp3o4pCDPFlZLOP15fIeru3cGuEgT55K/2W42x8UtfYcBYB35k73 6Zr8gcKxA8/LhSt/0Kih6Zmgv3zBDTcq9XFqVMznGb2VFK5G6kwetPlWJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNBQDyUT5X/4YNJK1egze7d4F1hhECg?= =?us-ascii?q?TA5EwEBAQEBAQFlJ4RDAQEEOj0CEAsYCSUPBUmIQsN9AQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBHIpyh2qCLgEEjliJWY4WCoFTjUePSSICPoI4gVUciDgBAQE?= X-IronPort-AV: E=Sophos;i="5.26,336,1459814400"; d="scan'208";a="106230474" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 May 2016 23:55:49 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4JNtmeV012370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2016 23:55:49 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 u4JNtmrf002781; Thu, 19 May 2016 16:55:48 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4JNtm4W002777; Thu, 19 May 2016 16:55:48 -0700 Date: Thu, 19 May 2016 16:55:48 -0700 From: Toerless Eckert To: Tom Herbert Message-ID: <20160519235548.GB2511@cisco.com> References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> 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: Ca By , spud , Joe Touch Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 23:55:51 -0000 On Thu, May 19, 2016 at 04:50:18PM -0700, Tom Herbert wrote: > I think that depends on how pervasive UDP drop are. The data presented > in BA and QUIC deployment data seems to indicate that UDP is mostly > deployable on the Internet right now. Btw: If your goal is to only get foo over UDP without SPUD then i think this would be the main disagrement i'd have. But i still think any work that leads to more business relevant UDP traffic over non-well known ports will have middlebox operators wake up to the problem, having to let UDP through, and tht ultimatelly will increate ask for SPUD. ;-)) Cheers Yoerless From nobody Thu May 19 16:56: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 08E7212D177 for ; Thu, 19 May 2016 16:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 HKv0nPpLOOSq for ; Thu, 19 May 2016 16:56:35 -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 21B8312B04E for ; Thu, 19 May 2016 16:56:35 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u4JNtvRc017108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 May 2016 16:55:57 -0700 (PDT) To: Toerless Eckert References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> <20160519234836.GA2511@cisco.com> From: Joe Touch Message-ID: <573E528C.3080303@isi.edu> Date: Thu, 19 May 2016 16:55:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160519234836.GA2511@cisco.com> 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: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 19 May 2016 23:56:36 -0000 On 5/19/2016 4:48 PM, Toerless Eckert wrote: >> Please don't *#*!-up the Internet to fix an OS implementation issue. > Still haven't made the point why this is *#*!-up the Internet. I did - in summary: you're adding a new protocol that we don't otherwise need, can't seamlessly transition to kernel-based transports without requiring the additional encapsulation overhead, and only end up making DPI look one more header in. Joe From nobody Thu May 19 17:13: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 95C4512D533 for ; Thu, 19 May 2016 17:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 Tzgt80Kg8k3z for ; Thu, 19 May 2016 17:13:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1509312D531 for ; Thu, 19 May 2016 17:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4514; q=dns/txt; s=iport; t=1463703205; x=1464912805; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ezKe2dyGOT7gwnjXqVaq2tEp5ZIGfmHk0DCrFfUHPVM=; b=gBX6zB8ZAY26yMGn7MOXdMO6q4xDxB5KqOSecT9+5alwY6FanYvYRA+n sPkpaj57nZgB64gA1v2uqf/x8suOskXMJSI0tlFqokoeUge5/tMVM27UM yMVuzIHrWfx0KcdKvfH/TM2em+yTHT+ACQ2LUN/t022/FlCl4i2VbRZm9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAgBxVT5X/5tdJa1eDoMpgVS6GQENg?= =?us-ascii?q?XWCX4MyAoEwOBQBAQEBAQEBZSeEQgEBAQMBOj0CBQsLGAklDwVJE4gnCMN1AQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBHIlvgQOEMoM4gi4FjliJW44WCoFpjTKGMYkYH?= =?us-ascii?q?gEBQoIGHBZ6WxwyhkqBPAEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,336,1459814400"; d="scan'208";a="106393369" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 May 2016 00:13:24 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4K0DNKB012438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2016 00:13:24 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 u4K0DN8i003404; Thu, 19 May 2016 17:13:23 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4K0DNj8003403; Thu, 19 May 2016 17:13:23 -0700 Date: Thu, 19 May 2016 17:13:23 -0700 From: Toerless Eckert To: Joe Touch Message-ID: <20160520001323.GC2511@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573E3C5E.2090300@isi.edu> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 00:13:26 -0000 On Thu, May 19, 2016 at 03:21:18PM -0700, Joe Touch wrote: > At some point, when the version of TCP you want is in the kernel, you'll > want to transition. That begs the question of demuxing incoming > services, and whether the kernel peeks into the packet to send them to > the right place (which might be at a different port inside the kernel). Nah. Thats where i started off from as well. But then think about you having this wonderful application that started out with a cool & better TCP stack. Maybe the kernel catches up some time to do exactly what you want. But it could equally evolve into soment which may be better but not really for your application - at least not without improving/changing your app. If i want to deploy one binary of an app and let it run stable, kernel changes are the worst thing that can happen to me. Having my transport stack in my app is a godsend to decouple me from this. Why do apps want containers ? To decouple them from the variability of userland. And arguably most userland evolution is good. But it creates incompatibilityes and ongoing app-update work. Wasted effort for many apps. Same argument can be made about transport stack in the app. > >> IMO, adding a layer of encapsulation (and all that entails, including > >> the need for PLPMTUD, > > Just use IPv6 and < 1280 packets. IN my book, Jumbo packets should be the last dinosaurs > > on their way out. > > You can't expect support for these new TCP variants, but you expect ubiquitous support for IPv6? pretty much, yes. But i am right now just representing a strategic interest. the quicker yo want to get things running the more hacks you may need. > >> other ICMP signal relaying between layers, etc.) > > Example ? > > see draft-ietf-intarea-tunnels, section 4.5 Nice. Yeah. ICMP is a challenge. Doesn't make the strategy wrong though. > >> is a very inefficient and complex way to overcome an implementation > >> convenience issue. > > Do you think you can come with metrics for "inefficient and complex" that everybody > > agrees to ? Eg: The overhead of going from IPv4 to IPv6 addresses is higher than > > the UDP encap. Does that make IPv6 "very very inefficient" ? > > I'm confused now; above you assumed IPv6. Now you're comparing UDP/IPv4 > vs. IPv6? No, i am saying that a loss in packet efficiency (sizze of header) did not stop us to do IPv6, it shouldn't stop us to run transport over UDP. If we do transport UDP purely with encap this creates more overhead. Ultimately, i wish we would only crearte new transports natively on UDP eg: without duplicating anything UDP already does. > > Also: your convenience issue is my market innovation/agility/ossification and adoption issue. > > How do we build agreeable metrics around those criteria ? > > Your ossification is my stability. Let's say you migrate to using this > encapsulation. What happens later when you want to transition to a more > native version? How do you coordinate whether to use the encapsulated > version or not? or will you now require the kernel to do the extra UDP > encapsulation? Your stability is my stability as explained above. So i am all for that. The ossification comes i want to avoid is to share a single transport stack version forced onto me by some crazy OS-vendor roadmaps across 30 applications i am running on my host, and they all have different transport requirements. Once threy have their own transport stack bound to them i am home free. My new cool app will have the new cool transport improvements, while my legacy "do not touch me" app will not feel any negative impact from me upgrading my OS once a year because my vendor forces me to. > I'm not in favor of creating a mess for the future for a little > short-term benefit. Effort would be better spent getting the desired > features into these OS transport implementations. This is really a matter of lifecycle management of software.a And you do NOT want to get all "desired" features into OS implementations. Just think about an important app you wrote depending on some transport stack feature that later was found to be not such a good idea, but the app itself is still business critical. And not developed any further. What do you do ? Put it in a VM, right ? If it would have just started with it's own transport stack library, you'd get away much easier. Cheers Toerless > > Joe -- --- Toerless Eckert, eckert@cisco.com From nobody Thu May 19 17:20: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 03B8912D531 for ; Thu, 19 May 2016 17:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 pcEWerUNFXUu for ; Thu, 19 May 2016 17:20:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048B812D1DD for ; Thu, 19 May 2016 17:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1087; q=dns/txt; s=iport; t=1463703615; x=1464913215; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=7zj0iSpCTU6asaQUIvzo1X8r0SXi4qvs5BhGFOu6JtY=; b=X/tsN0bxzN03AAr36KKv+dzI5a9wVtpz+5/rj4nVl07PWXEimciLCeAI IbpC2rb5iggnKFa78flBh941RX/L3EDGSkUGEqjmdIdxHJUHuFJVI+xf0 IbtBzyHwuhgo+K59+x9DWczjQZAhGr/lVaYwkqOJbHOzqpSo/Ugt/XF9K M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAgDlVz5X/5FdJa1eDoMpu20BDYF1h?= =?us-ascii?q?hECgTI4FAEBAQEBAQFlJ4RDAQEEOj0CEAsYCSUPBUmIQsN7AQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBHIpyh2qCLgEEjliJW44WCoFphE+IY49JHgEBQoIGHBZ6WxyIO?= =?us-ascii?q?AEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,336,1459814400"; d="scan'208";a="104468704" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 May 2016 00:20:15 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u4K0KEoY011870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2016 00:20:15 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 u4K0KEh6003611; Thu, 19 May 2016 17:20:14 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4K0KENq003610; Thu, 19 May 2016 17:20:14 -0700 Date: Thu, 19 May 2016 17:20:14 -0700 From: Toerless Eckert To: Joe Touch Message-ID: <20160520002014.GD2511@cisco.com> References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> <20160519234836.GA2511@cisco.com> <573E528C.3080303@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573E528C.3080303@isi.edu> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 00:20:17 -0000 On Thu, May 19, 2016 at 04:55:56PM -0700, Joe Touch wrote: > On 5/19/2016 4:48 PM, Toerless Eckert wrote: > >> Please don't *#*!-up the Internet to fix an OS implementation issue. > > Still haven't made the point why this is *#*!-up the Internet. > I did - in summary: you're adding a new protocol that we don't otherwise > need, can't seamlessly transition to kernel-based transports without > requiring the additional encapsulation overhead, and only end up making > DPI look one more header in. - Ideally, you would just design optimized new transports that use UDP as demux layer. Think about it. Just try to imagine you'd be doing TCP with IP proto UDP... how much more overhead would you need to add ? - IMHO there are only minute benefits of in-kernel transport protocol. I'd be happy to have them die out. OS vendors can happily implement TCP wih UDP ports as a library. That immediately makes it part of my docker container and gives me predictable behavior when i distribute my container. - No deeper look with DPI needed. Cheers Toerless From nobody Thu May 19 18:06: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 EEAA312D1E0 for ; Thu, 19 May 2016 18:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 Z5IEAukTQaNe for ; Thu, 19 May 2016 18:06:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 A6CE812D1CB for ; Thu, 19 May 2016 18:06:40 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u4K16Cfw006345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 May 2016 18:06:12 -0700 (PDT) To: Toerless Eckert References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> From: Joe Touch Message-ID: <573E6303.8030701@isi.edu> Date: Thu, 19 May 2016 18:06:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160520001323.GC2511@cisco.com> 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: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 01:06:42 -0000 On 5/19/2016 5:13 PM, Toerless Eckert wrote: > On Thu, May 19, 2016 at 03:21:18PM -0700, Joe Touch wrote: >> At some point, when the version of TCP you want is in the kernel, you'll >> want to transition. That begs the question of demuxing incoming >> services, and whether the kernel peeks into the packet to send them to >> the right place (which might be at a different port inside the kernel). > Nah. Thats where i started off from as well. But then think about you having > this wonderful application that started out with a cool & better TCP stack. > Maybe the kernel catches up some time to do exactly what you want. But it > could equally evolve into soment which may be better but not really for > your application - at least not without improving/changing your app. > > If i want to deploy one binary of an app and let it run stable, kernel changes > are the worst thing that can happen to me. Having my transport stack in my > app is a godsend to decouple me from this. I don't disagree with the potential benefits. I disagree with using UDP encapsulation to achieve an end-run around the OS exerting control. > Why do apps want containers ? To decouple them from the variability of userland. Hmm. So containers are good, but doing a full hypervisor with an (encapsulated) OS isn't as good? See the analogy? You're arguing for user access to rawIP. > ... >> I'm confused now; above you assumed IPv6. Now you're comparing UDP/IPv4 >> vs. IPv6? > No, i am saying that a loss in packet efficiency (sizze of header) did not > stop us to do IPv6, it shouldn't stop us to run transport over UDP. I wasn't arguing solely on the basis of the additional bytes. It's the additional protocol layer that is expensive. ... >> I'm not in favor of creating a mess for the future for a little >> short-term benefit. Effort would be better spent getting the desired >> features into these OS transport implementations. > This is really a matter of lifecycle management of software. And you do NOT > want to get all "desired" features into OS implementations. OK, so put differently, I don't want to create a mess in the Internet to fix an OS problem. The OS problem is lack of access to raw IP. If you had that, you wouldn't need any of this. That's a simple direct target. A lot simpler than untangling the mess that this reinvention will cause. Joe From nobody Thu May 19 18:09: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 BA52712D1E0 for ; Thu, 19 May 2016 18:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 DLTNmQrN_DNv for ; Thu, 19 May 2016 18:09:10 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 B404612D1CB for ; Thu, 19 May 2016 18:09:10 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u4K18ZoJ006536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 May 2016 18:08:37 -0700 (PDT) To: Toerless Eckert References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> <20160519234836.GA2511@cisco.com> <573E528C.3080303@isi.edu> <20160520002014.GD2511@cisco.com> From: Joe Touch Message-ID: <573E6393.4090701@isi.edu> Date: Thu, 19 May 2016 18:08:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160520002014.GD2511@cisco.com> 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: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 01:09:11 -0000 On 5/19/2016 5:20 PM, Toerless Eckert wrote: > On Thu, May 19, 2016 at 04:55:56PM -0700, Joe Touch wrote: >> On 5/19/2016 4:48 PM, Toerless Eckert wrote: >>>> Please don't *#*!-up the Internet to fix an OS implementation issue. >>> Still haven't made the point why this is *#*!-up the Internet. >> I did - in summary: you're adding a new protocol that we don't otherwise >> need, can't seamlessly transition to kernel-based transports without >> requiring the additional encapsulation overhead, and only end up making >> DPI look one more header in. > - Ideally, you would just design optimized new transports that use > UDP as demux layer. Think about it. That's why I said you were reinventing the Internet at the UDP layer. If you expect the end game is that we keep UDP as an additional demuxing layer, I think this is not just a bad idea, it's a VERY bad idea. > - IMHO there are only minute benefits of in-kernel transport protocol. I'd be happy > to have them die out. OS vendors can happily implement TCP wih UDP ports as > a library. Some do. I recall that there were ways to update old versions of Windows with new transport stacks (Trumpet, I think?). > That immediately makes it part of my docker container and gives > me predictable behavior when i distribute my container. > - No deeper look with DPI needed. I agree. So go fix that, IMO, and leave the Internet alone. Joe From nobody Thu May 19 18:24: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 313EB12B054 for ; Thu, 19 May 2016 18:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 5j5jMWw2LJI0 for ; Thu, 19 May 2016 18:24:32 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CCF12B039 for ; Thu, 19 May 2016 18:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2523; q=dns/txt; s=iport; t=1463707472; x=1464917072; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=KUQoGi2Wh7xxikcTHuTKauggrRGFPOMg35NrzCJvSJg=; b=OBvQYS01bRXNfZ2577gH73r0lhMozN8/7U4SH4W/jAGWEihKMXNMfTBd L2nXddVmKWiHVZtqXs+fUVv5NERsVpa8SV1jVlataQyzW8fhvzKZdfymK MHq608IODbbeQqNmCNsrNJGrdNie2hdFGH3oOzzQoa4E3/Je/zj/Mt+Bi g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAgBTZj5X/5ldJa1eDoMpVn66GQENg?= =?us-ascii?q?XUXC4VvAoEyOBQBAQEBAQEBZSeEQgEBAQMBAQEBNzQJAgULCxgJJQ8FEzYTiCc?= =?us-ascii?q?IDsQkAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWKcodqgi4FjliJW44WCo8bj0keA?= =?us-ascii?q?QFCggMDHBZ6WxwyiAYBAQE?= X-IronPort-AV: E=Sophos;i="5.26,336,1459814400"; d="scan'208";a="104494686" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 May 2016 01:24:31 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4K1OVPA025093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2016 01:24:31 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 u4K1OVV2005540; Thu, 19 May 2016 18:24:31 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4K1OVKM005539; Thu, 19 May 2016 18:24:31 -0700 Date: Thu, 19 May 2016 18:24:31 -0700 From: Toerless Eckert To: Joe Touch Message-ID: <20160520012431.GF2511@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573E6303.8030701@isi.edu> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 01:24:34 -0000 On Thu, May 19, 2016 at 06:06:11PM -0700, Joe Touch wrote: > I don't disagree with the potential benefits. I disagree with using UDP > encapsulation to achieve an end-run around the OS exerting control. Don't think of it as UDP. Think of it as creating multiple layers inside the current transport layer. The lowest layer is demultiplexing. Architecturally very clean. > > Why do apps want containers ? To decouple them from the variability of userland. > Hmm. So containers are good, but doing a full hypervisor with an > (encapsulated) OS isn't as good? > Well. one logical reason why is the demultiplexing: Everything below it is naturally shared, everything above it IMHO naturally not. That makes it realistically harder to virtualilze IP. But yes, we've been thinking about doing that. In IPv6 it's easy, we'd have enough address space per-app. And there are nice examples for this even if some of them are mostly driven by runarounds on arch limits (port number space). > See the analogy? You're arguing for user access to rawIP. No, not really. But i am also not a fan for architectural and pragmatic reasons to use IP extensions. I The why is longer, but lets just say that without them, i see no use-case requirements to virtualize the IP layer in a host. > >> I'm confused now; above you assumed IPv6. Now you're comparing UDP/IPv4 > >> vs. IPv6? > > No, i am saying that a loss in packet efficiency (sizze of header) did not > > stop us to do IPv6, it shouldn't stop us to run transport over UDP. > I wasn't arguing solely on the basis of the additional bytes. It's the > additional protocol layer that is expensive. Well, if we stick to architectural vision, there is no additional protocol layer. Just strict sublayering with explicit interfaes between. And reuse one well working demux layer - UDP. > OK, so put differently, I don't want to create a mess in the Internet to > fix an OS problem. The OS problem is lack of access to raw IP. If you > had that, you wouldn't need any of this. Well, i told you why i think it's not a mess but good. > That's a simple direct target. A lot simpler than untangling the mess > that this reinvention will cause. No, not really, because we can't agree on criteria to quantify 'mess'. Cheers Toerless > > Joe > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Thu May 19 18:26: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 74E3412D10F for ; Thu, 19 May 2016 18:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 LPoPQhrbVZuc for ; Thu, 19 May 2016 18:26:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877CB12D0DF for ; Thu, 19 May 2016 18:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1256; q=dns/txt; s=iport; t=1463707608; x=1464917208; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=qqzElqGUcCRxYPFm2/yrLIBvvULSCFU18GbWgOBYj2I=; b=dq4CbH4MytPk8rkTduTyw4kHPveL/BL4hBR9+fikV6EsFlNyT8so29xm NeD9QHkNZ8gzDGPcLfR/cvqR96wGtUTpRvYyxd2J6xYRpoastIjAnCNkk u4heS8dvVKXljC0FHxK0xajXPzkHVCrBkrCo09QF3YX+ij5o7vfUYHFuf U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAgB9Zz5X/4kNJK1eDoMpgVS6GQENg?= =?us-ascii?q?XWGEQKBMjgUAQEBAQEBAWUnhEIBAQEDATo9AhALEgYJJQ8FNRQTG4gMCMQ0AQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBHIpyihgBBI5YiVuOFgqBaY0yhjGJGB4BAUKCB?= =?us-ascii?q?hwWelscMogGAQEB?= X-IronPort-AV: E=Sophos;i="5.26,336,1459814400"; d="scan'208";a="104495008" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 May 2016 01:26:25 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4K1QOtV014265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2016 01:26:25 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 u4K1QOLQ005602; Thu, 19 May 2016 18:26:24 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4K1QONV005601; Thu, 19 May 2016 18:26:24 -0700 Date: Thu, 19 May 2016 18:26:24 -0700 From: Toerless Eckert To: Joe Touch Message-ID: <20160520012624.GG2511@cisco.com> References: <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> <20160519234836.GA2511@cisco.com> <573E528C.3080303@isi.edu> <20160520002014.GD2511@cisco.com> <573E6393.4090701@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573E6393.4090701@isi.edu> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 01:26:50 -0000 On Thu, May 19, 2016 at 06:08:35PM -0700, Joe Touch wrote: > > - Ideally, you would just design optimized new transports that use > > UDP as demux layer. Think about it. > > That's why I said you were reinventing the Internet at the UDP layer. > If you expect the end game is that we keep UDP as an additional demuxing > layer, I think this is not just a bad idea, it's a VERY bad idea. Why ? > > - IMHO there are only minute benefits of in-kernel transport protocol. I'd be happy > > to have them die out. OS vendors can happily implement TCP wih UDP ports as > > a library. > > Some do. I recall that there were ways to update old versions of Windows > with new transport stacks (Trumpet, I think?). Sure, but i want to have a network architecture whose API standards allow all OSs to do this. The solutions you're talking about have OS specific APIs. ANd i want UDP as the cross-OS demux layer. Cheers Toerless > > That immediately makes it part of my docker container and gives > > me predictable behavior when i distribute my container. > > - No deeper look with DPI needed. > > I agree. So go fix that, IMO, and leave the Internet alone. > > Joe -- --- Toerless Eckert, eckert@cisco.com From nobody Thu May 19 19:30: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 2699F12D53A for ; Thu, 19 May 2016 19:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 qDSdWgQy3U2X for ; Thu, 19 May 2016 19:30:02 -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 5D88412D537 for ; Thu, 19 May 2016 19:30:02 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.176) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 19 May 2016 22:30:00 -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.0181.006; Thu, 19 May 2016 22:29:59 -0400 From: Dave Dolson To: Tom Herbert , Toerless Eckert Thread-Topic: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF Thread-Index: AdGyP4CFJ2cvNkb2DUuyKJNQQWe2WQ== Date: Fri, 20 May 2016 02:29:58 +0000 Message-ID: <20160520022957.5697621.53774.85449@sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-ID: <094E08E075F8D345A87D79CCCA563326@sandvine.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Brian Trammell , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 02:30:05 -0000 UGxlYXNlIGFsc28gdGhpbmsgYWJvdXQgaG93IGEgbmV0d29yayBvcGVyYXRvciBjYW4gbW9uaXRv ciBob3cgd2VsbCB0aGluZ3MgYXJlIHdvcmtpbmcsIGFuZCBob3cgRERvUyB0cmFmZmljIG1heSBi ZSBkaXNjcmltaW5hdGVkIGZyb20gbm9uLWF0dGFjayB0cmFmZmljLg0KVG9kYXksDQotIFRDUCBw YWNrZXQgbG9zcyBjYW4gYmUgbWVhc3VyZWQgYnkgb2JzZXJ2aW5nIHNlcXVlbmNlIG51bWJlcnMN Ci0gcm91bmQtdHJpcCB0aW1lcyBjYW4gYmUgbWVhc3VyZWQg4oCOZnJvbSBUQ1Agc2VxdWVuY2Uv YWNrIG51bWJlcnMNCi0gbm9uLWF0dGFjayB0cmFmZmljIHByb3Blcmx5IGNvbXBsZXRlcyBjb25u ZWN0aW9ucywgd2hlcmVhcyBhdHRhY2sgdHJhZmZpYyBvZnRlbiBkb2VzIG5vdA0KLSBzb21lIGZh aXItcXVldWluZyBhcHByb2FjaGVzIGFwcGx5IGZhaXJuZXNzIGJ5IFRDUCBjb25uZWN0aW9uc+KA jg0KLSBFQ01QIGFuZCBsb2FkLWJhbGFuY2VycyB0cnkgdG8gbWFrZSBpbmRpdmlkdWFsIHNlc3Np b25zIGZvbGxvdyBhIHNpbmdsZSBwYXRoDQoNCklmIHBhY2tldHMgYmVjb21lIGNvbXBsZXRlbHkg b3BhcXVlLCBJIHRoaW5rIOKAjmluIGdlbmVyYWwgdGhlIGludGVybmV0IHdvdWxkIG9wZXJhdGUg bGVzcyB3ZWxsLg0KSXQgd291bGQgYmUgZ29vZCBmb3IgU1BVRCBhbmQgUVVJQyDigI50byBwcm92 aWRlIGVub3VnaCBpbmZvcm1hdGlvbiBmb3IgbW9uaXRvcmluZyBkZXZpY2VzIHRvIG1lYXN1cmUg cHJvZ3Jlc3MsIGhhbmRzaGFrZXMsIHJvdW5kLXRyaXAgdGltZXMsIGFzIGNhbiBiZSBkb25lIHdp dGggVENQIGNhcnJ5aW5nIFRDUC4NCg0KLURhdmUNCuKAjg0KDQrCoCBPcmlnaW5hbCBNZXNzYWdl IMKgDQpGcm9tOiBUb20gSGVyYmVydA0KU2VudDogVGh1cnNkYXksIE1heSAxOSwgMjAxNiAzOjE3 IFBNDQpUbzogVG9lcmxlc3MgRWNrZXJ0DQpDYzogQnJpYW4gVHJhbW1lbGw7IFNjaGFyZiwgTWlj aGFlbCAoTm9raWEgLSBERSk7IHNwdWRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbU3B1ZF0gW1N0 YWNrZXZvLWRpc2N1c3NdIEZ3ZDogUG9zc2libGUgV0ctZm9ybWluZyBmb2xsb3ctb24gdG8gU1BV RCBCb0YNCg0KT24gVGh1LCBNYXkgMTksIDIwMTYgYXQgMTE6MjcgQU0sIFRvZXJsZXNzIEVja2Vy dCA8ZWNrZXJ0QGNpc2NvLmNvbT4gd3JvdGU6DQo+IFRvbSwgTWljaGFlbA0KPg0KPiBJIGFtIHJl YWRpbmcgeW91ciBwb3NpdGlvbnMgYW5kIGkgYW0gY29uZnVzZWQ6DQo+DQo+IERTQ1AgaXMgdmVy eSBzdWNjZXNzZnVsbCBpbiBlbnRlcnByaXNlIG5ldHdvcmtzLiBTUFVEIGRvZXMgbm90IGhhdmUg dG8NCj4gYmUgc3VjY2Vzc2Z1bGwgIm9uIHRoZSBJbnRlcm5ldCIuIFRvIG1lIGl0IHdvdWxkIGFs cmVhZHkgYmUgYSBncmVhdCBzdWNjZXNzIGlmIGl0IHdvdWxkDQo+IGhlbHAgdG8gaW1wcm92ZSBj b250cm9sbGVkIG5ldHdvcmsgc2VydmljZXMgKGxpa2UgZW50ZXJwcmlzZSBvciA0Ry81RyBuZXR3 b3JrcykuIEFuZA0KPiB0aGVpciB0cmFuc2l0IHRyYWZmaWMgYWNyb3NzIHRoZSBJbnRlcm5ldCAo d2l0aG91dCBjaGFuZ2luZyBhbnl0aGluZyBvbiB0aGUgSW50ZXJuZXQNCj4gaXRzZWxmKS4NCj4N ClllcywgdGhhdCBpcyBteSBwb2ludCBhYm91dCBsb2NhbGl6aW5nIHRoZSBwcm9ibGVtLiBBIGNs aWVudCBkZXZpY2UNCnNob3VsZCBrbm93IHdoYXQgbmV0d29yayBpdCdzIG9uIGFuIGJlIGFibGUg dG8gc2lnbmFsIHRvIHRoYXQgbmV0d29yaw0KdG8gZ2V0IHRoZSBzZXJ2aWNlcyBpdCB3YW50cy4g QSBzZXJ2ZXIgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHBsYW5ldA0KdGhhdCB0aGUgbm9kZSBp cyB0YWxraW5nIHRvIHJlYWxseSBzaG91bGRuJ3QgYmUgY29uY2VybmVkIHdpdGggdGhpcw0KYW5k IG5vdCByZXF1aXJlZCB0byBpbXBsZW1lbnQgc29tZSBjb21wbGV4IHByb3RvY29sIHRvIGFjY29t bW9kYXRlIGl0Lg0KDQo+IEFGQUlLLCBUT1MvRFNDUC9FQ04gYXJlIG5vdCBwZXItZmxvdywgYnV0 IHBlci1wYWNrZXQgbWVjaGFuaXNtcy4gRXZlbiBpZiB3ZSBvZnRlbiB0aGluayBhYm91dA0KPiB0 aGVtIGFzIHBlci1mbG93IGFuZCBvdWxkIG1heWJlIGxpa2UgdGhlbSB0byBiZSByZXN0cmljdCB0 byBwZXItZmxvdy4gQXQgbGVhc3QgaSBkb24ndCBrbm93DQo+IGFueSBub3JtYXRpdmUgcmVmZXJl bmNlIHRoYXQgZGVmaW5lcyB0aGVtIHRvIGJlIHBlci1mbG93Lg0KPg0KPiBXcnQgdG8gb3V0LW9m LWJhbmQvb3V0LW9mLXBhdGg6IFRoZSB3aG9sZSByZWFzb24gZm9yIFNQVUQgaXMgdGhlIGFuYWx5 c2lzIHRoYXQgYWxsIHRob3NlDQo+IG1lY2hhbmlzbXMgZmFpbCB0byBwcm92aWRlIGFuIGVhc2ls eSBkZXBsb3B5YWxlIGZyYW1ld29yayBpbiB0aGUgZmFjZSBvZiBtaWRkbGVib3hlcy4gQWthOiB0 aGVpcg0KPiBwcmVzZW5jZSBhbmQgbW9zdGx5IG5vbi1zdWNjZXNzIHNob3VsZCBiZSBhbiBhcmd1 bWVudCBGT1Igd29ya2luZyBvbiBzcHVkLiBOb3QgYWdhaW5zdCBpdC4NCj4NCj4gSWYgYSBOQVQv RlcgZG9lcyBzdXBwb3J0IGFueSBmbG93IHNpZ25hbGluZywgaXRzIG1vc3QgbGlrZWx5IGluYmFu ZC4gRXZlcnkgTkFUL2ZpcndhbGwNCj4gc3VwcG9ydHMgZmxvdyByZWNvZ25pdGlvbiB2aWEgdGhl IGV4cGxpY2l0IHNpZ25hbGluZyBvZiBmbG93LWJhc2VkIHRyYW5zcG9ydCBwcm90b29jb2xzDQo+ IGxpa2UgVENQLiBUaGV5IGRvIHRyeSB0byBkbyB0aGUgc2FtZSBmb3IgVURQIGFuZCBiZWNhdXNl IHRoYXQgaGFzIG5vIGV4cGxpY2l0IGZsb3cgc2lnbmFsaW5nLA0KPiB0aGF0cyB3aGVyZSB0aGUg cHJvYmxlbSBzdGFydHMuIE5BVC9GVyBkbyBkZWVwIHBhY2tldCBpbnNwZWN0aW9uIHdoaWNoIGhh cyBhbGwgdGhlc2UgcHJvYmxlbXMNCj4gd2Uga25vdy4gU1BVRCBzZXRzIG91dCB0byBzb2x2ZS9y ZWR1Y2UgdGhlc2UgTkFUL0ZXIGlzc3Vlcy4NCj4NClRoZXJlIHNlZW1zIHRvIGJlIGEgbG90IG9m IFVEUCBnb2luZyB0aHJvdWdoIE5BVC9GVyB0b2RheSB3aXRob3V0IGFueQ0Kc29ydCBvZiBpbi1i YW5kIHNpZ25hbGluZywgYW5kIHByb3RvY29scyBsaWtlIFFVSUMgYXJlIGFscmVhZHkgc2VlaW5n DQpkZXBsb3ltZW50IHdpdGhvdXQgdGhhdCAoYWNjb3JkaW5nIHRvIHRoZWlyIHNsaWRlIGRlY2sg IkFib3V0IGhhbGYgb2YNCkdvb2dsZSB0byBDaHJvbWUiKS4gQ29uc2lkZXJpbmcgdGhhdCB0aGVy ZSBpcyBubyBkZXBsb3ltZW50IG9mIGEgU1BVRA0KYXdhcmUgZmlyZXdhbGwgYW5kIHdlIGNhbid0 IHdhbnQgdG8gd2FpdCBmb3IgZXZlcnkgZGV2aWNlIG9uIHRoZQ0KSW50ZXJuZXQgdG8gdXBncmFk ZSwgU1BVRCB3aWxsIGhhdmUgdG8gd29yayB3aXRoIE5BVC9GVyBhcyBpcyBvciB3ZQ0KY291bGRu J3QgY29uc2lkZXIgaXQuIFRCSCBJJ20gcmVhbGx5IGhhdmluZyBhIGhhcmQgdGltZSBzZWVpbmcg dGhhdA0KYW55IGV4dHJhIHNpZ25hbGluZyBpcyByZXF1aXJlZCBpbiB0aGUgSW50ZXJuZXQgb3Ro ZXIgdGhhbiB3aGF0IGlzIGluDQp0aGUgSVAgaGVhZGVyLCBhdCBiZXN0IGl0IHNlZW1zIGxpa2Ug YW4gb3B0aW1pemF0aW9uIGZvciBjZXJ0YWluDQpuZXR3b3JrcyBvciBjb25maWd1cmF0aW9ucy4N Cg0KPiBOb24tc3VwcG9ydCBvZiBhbnl0aGluZyBsaWtlIElQIG9wdGlvbnMgaXMgSU1ITyBwcmlt YXJpbHkgZHJpdmVuIGJ5IHRoZSBhYnNlbmNlIG9mDQo+IHVuZm9ybSBjcm9zcy1PUy9EZXYtbGFu Z3VhZ2UgQVBJcyBmb3IgdGhlbS4gWWVzLiBJdCBtYXkgc3VjayBhcmNoaXRlY3R1cmFsbHkgYnkg ZGVzaWduaW5nDQo+IHByb3RvY29sIHN0YWNrcyBiYXNlZCBvbiByZWFsaXR5IGxpa2U6IGFwcGxp Y2F0aW9ucyB3aWxsIG9ubHkgYmUgYWJsZSB0byB1c2UgVURQIGFuZCBUQ1AsDQo+IHNvIGxldHMg ZG8gbmV3IHdvcmsgb24gdG9wIG9mIHRoZW0sIGJ1dCB0byBtZSB0aGUgbW9zdCBpbXBvcnRhbnQg Z29hbCBpcyB0byBmaW5kIHRoZSBiZXN0DQo+IGRlcGxveWFibGUgc29sdXRpb24gdG8gYSBwcm9i bGVtLiBOb3QgdGhlIGFyY2hpdGVjdHVyYWxseSBjbGVhbmVzdCBvbmUuIElmIHlvdSBnaXZlIG1l DQo+IHJlc2VhcmNoIG1vbmV5IHRvIHdvcmsgb3V0c2lkZSBvZiByZWFsaXR5IGkgd2lsbCBoYXBw aWx5IHRha2UgaXQgdGhvdWdoIGFuZCByZXByZXNlbnQgYQ0KPiBkaWZmZXJlbnQgcGVyc3BlY3Rp dmUuDQo+DQoNClRoZXJlIGhhcyBiZWVuIGEgbG90IG9mIGRpc2N1c3Npb24gYWJvdXQgdGhpcyBp biB2Nm9wcywgbWFueSBuZXR3b3Jrcw0KYXJlIHNpbXBseSBkcm9wcGluZyBwYWNrZXRzIHdpdGgg ZXh0ZW5zaW9uIGhlYWRlcnMuIFBsZWFzZSBsb29rIGF0DQpkcmFmdC1pZXRmLXY2b3BzLWlwdjYt ZWhzLWluLXJlYWwtd29ybGQtMDIgYW5kDQpkcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tl dC1kcm9wcy0wMy4gQmVjYXVzZSBvZiB0aGlzIGFuZCB0aGUNCmZhY3QgdGhhdCB0aGVyZSBoYXNu J3QgYmVlbiBhbnkgaW50ZXJlc3Rpbmcgb3B0aW9ucyBkZWZpbmVkIHdvcnRoDQpzZW5kaW5nIHRv IGRhdGUgbWVhbnMgdGhhdCB3ZSAoc3BlYWtpbmcgZm9yIGFwcGxpY2F0aW9ucykgaGF2ZSBubyB1 c2UNCnRvIHNlbmQgdGhlbSAoYnR3IGFsbCB0aGUgbWFqb3IgT1NlcyBzdXBwb3J0IG9wdGlvbnMg QUZBSUspLiBJZiBzb21lDQppbnRlcmVzdGluZyBvcHRpb25zIGRpZCBjb21lIGFib3V0LCB0aGVu IHdlIHdvdWxkIHByb2JhYmx5IGFwcGx5IGENCmhhcHB5IGV5ZWJhbGxzIGFwcHJvYWNoIHRvIGRl cGxveS4NCg0KV2l0aCBzb21ldGhpbmcgbGlrZSBTUFVEIChiYXNpY2FsbHkgYW55dGhpbmcgbm90 IHNpbXBsZSBUQ1AvSVB2NCkgd2UNCmFyZSBhbHdheXMgZmFjZWQgd2l0aCB0aGUgc2FtZSBwcm9i bGVtIHRoYXQgc29tZSBuZXR3b3JrcyBvbiB0aGUNCkludGVybmV0IG1heSBhcmJpdHJhcmlseSBk cm9wIG9yIG90aGVyd2lzZSByZXN0cmljdCBwYWNrZXRzICh3ZSBrbm93DQpmb3IgaW5zdGFuY2Ug dGhhdCBzb21lIG5ldHdvcmsgb3BlcmF0b3JzIGNob29zZSB0byBzZXZlcmVseSByYXRlIGxpbWl0 DQphbGwgVURQIGJlY2F1c2Ugb2YgRE9TIGNvbmNlcm5zKS4gU28gZXZlbiBpZiB3ZSBkbyBtYW5h Z2UgdG8gc3RhcnQNCmRlcGxveWluZyB0cmFuc3BvcnQgcHJvdG9jb2xzIG92ZXIgVURQIHdlIGFy ZSBnb2luZyBoYXZlIFRDUCBhcyBhDQpmYWxsYmFjayBmb3IgaW5kZWZpbml0ZSBmdXR1cmUsIGku ZS4gbW9yZSBoYXBweSBleWViYWxscy4NCg0KVG9tDQoNCj4gUGxlYXNlLCBpIGRvIG5vdCB3YW50 IHRvIGRpc21pc3MgeW91ciBvcHBvc2l0aW9uLCBpIGp1c3QgZG9uJ3QgdW5kZXJzdGFuZCBob3cg dGhlDQo+IGFyZ3VtZW50cyB5b3UgbWFrZSBhcmUgd29ya2luZyBvdXQuIE1heWJlIHlvdSBjYW4g ZXhwbGFpbiB0byBtZSB3aGVyZSBpIGFtIGdvaW5nIHdyb25nDQo+IGluIG15IGludGVycHJldGF0 aW9ucyBhYm92ZS4NCj4NCj4gQ2hlZXJzDQo+IFRvZXJsZXNzDQo+DQo+IE9uIFRodSwgTWF5IDE5 LCAyMDE2IGF0IDEwOjUwOjIxQU0gLTA3MDAsIFRvbSBIZXJiZXJ0IHdyb3RlOg0KPj4gT24gVGh1 LCBNYXkgMTksIDIwMTYgYXQgMTA6MTIgQU0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkN Cj4+IDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+IHdyb3RlOg0KPj4gPiBEb2VzIHRoZSBzZW50 ZW5jZSAuLi4NCj4+ID4NCj4+ID4gVGhlIGN1cnJlbnQgSW50ZXJuZXQgcHJvdG9jb2wgc3RhY2sg aGFzIG5vIGxheWVyIGZvciBleHBsaWNpdCBzaWduYWxpbmcgb2YgZmxvdyBzZW1hbnRpY3MgYW5k IGNoYXJhY3RlcmlzdGljcyB0byBuZXR3b3JrIGVsZW1lbnRzIC4uLg0KPj4gPg0KPj4gPiBhY3R1 YWxseSB3YW50cyB0byBzYXkgc29tZXRoaW5nIGxpa2UNCj4+ID4NCj4+ID4gVGhlIGN1cnJlbnQg SW50ZXJuZXQgcHJvdG9jb2wgc3RhY2sgaGFzIG5vIGxheWVyIGZvciBleHBsaWNpdCAqaW4tYmFu ZCogc2lnbmFsaW5nIG9mIGZsb3cgc2VtYW50aWNzIGFuZCBjaGFyYWN0ZXJpc3RpY3MgLi4uID8N Cj4+ID4NCj4+ID4gSSBtYXkgYmUgd3JvbmcsIGJ1dCB0aGVyZSBpcyBubyBzaG9ydGFnZSBvZiBJ RVRGIGFuZCBub24tSUVURiBwcm90b2NvbHMgdGhhdCBjYW4gc2lnbmFsIGZsb3cgc2VtYW50aWNz IGFuZCBjaGFyYWN0ZXJpc3RpY3Mgb3V0LW9mLWJhbmQsIGVpdGhlciBwYXRoLWNvdXBsZWQgb3Ig cGF0aC1kZWNvdXBsZWQsIGUuZy4sIGluIHRoZSBjb250cm9sIG9yIG1hbmFnZW1lbnQgcGxhbmUu IEFzIGEgcmVzdWx0LCB0aGVyZSBhcmUgcHJvdG9jb2wgImxheWVycyIgZm9yIHRoYXQgc2lnbmFs aW5nLCBidXQgdGhleSBhcmUgbm90IGluLWJhbmQuIFRoZXJlIG1heSBhbHNvIGJlIG90aGVyIHdh eXMgdG8gZml4IHRoaXMgcHJvYmxlbSAoZS5nLiwgYnkgYWRkaW5nICJlbmQtdG8tZW5kIiBvciAi aW50ZXItZG9tYWluIiBpbnN0ZWFkIG9mICJpbi1iYW5kIikuDQo+PiA+DQo+PiBOb3QgdG8gbWVu dGlvbiB0aGF0IFRPUyBhbmQgZGlmZi1zZXJ2IGFyZSBpbi1iYW5kIHNpZ25hbGluZyBtZWNoYW5p c21zDQo+PiB0byB0aGUgbmV0d29yaywgRUNOIGlzIGV4cGxpY2l0bHkgc2lnbmFsaW5nIGZyb20g dGhlIG5ldHdvcmsuIEdpdmVuDQo+PiB0aGF0IHRoZXkndmUgYmVlbiBhcm91bmQgZm9yIG1hbnkg eWVhcnMgYnV0IGhhdmUgbmV2ZXIgYmVlbiB3aWRlbHkNCj4+IGRlcGxveWVkIG9uIHRoZSBJbnRl cm5ldCBtYWtlcyBtZSB3b25kZXIgaWYgYW55IGluLWJhbmQgc2lnbmFsaW5nDQo+PiBtZWNoYW5p c20gd2lsbCBldmVyIGNhdGNoIG9uLiBUaGUgdXNlIG9mIG91dCBvZiBiYW5kIHNpZ25hbGluZyBz aG91bGQNCj4+IGJlIGNvbnNpZGVyZWQsIGVzcGVjaWFsbHkgY29uc2lkZXJlZCB0aGF0IGluIG1h bnkgY2FzZXMgbGlrZSBOQVQgYW5kDQo+PiBmaXJld2FsbCB0aGUgbmV0d29yayBlbGVtZW50cyB0 aGF0IG5lZWQgc2lnbmFsaW5nIGFyZSBsaWtlbHkgaW4gbG9jYWwNCj4+IG5ldHdvcmtzIG9mIG9u ZSBzaWRlIG9mIHRoZSBjb25uZWN0aW9uLg0KPj4NCj4+IEkgaGF2ZSBhIHNpbWlsYXIgY29uY2Vy biBhYm91dCB0aGUgc3RhdGVtZW50IHRoYXQgSVAgb3B0aW9ucy9FSCBhbmQNCj4+IGV4dGVuc2lv biBoZWFkZXJzIGFyZSBiZWluZyBsZWZ0IG9mZiB0aGUgdGFibGUgYXMgcGFydCBvZiBhIHNvbHV0 aW9uLg0KPj4gVGhlIGZhY3QgdGhhdCBuZWl0aGVyIGhhdmUgdGhlc2UgY2F1Z2h0IG9uIGluIHRo ZSBJbnRlcm5ldCBhbmQgdGhhdA0KPj4gdGVsbHMgbWUgdHdvIHRoaW5ncyAxKSBObyBJUCBvcHRp b24gaXMgbmVlZGVkIGZvciB0aGUgSW50ZXJuZXQgdG8NCj4+IG9wZXJhdGUgYW5kIGJlIHN1Y2Nl c3NmdWwgd2hpY2ggbWFrZXMgbWUgd29uZGVyIGlmIHNpZ25hbGluZyBiZXR3ZWVuDQo+PiBuZXR3 b3JrIGFuZCBob3N0cyBpcyBldmVuIHJlcXVpcmVkIDIpIElmIHRoZSBleHRlbnNpYmlsaXR5IG1l Y2hhbmlzbXMNCj4+IG9mIElQIGFyZSBjaHJvbmljYWxseSBub3QgZGVwbG95YWJsZSwgSSB3b25k ZXIgd2h5IGFueSBhbHRlcm5hdGl2ZQ0KPj4gdGhhdCBkb2VzIG5vdCB5ZXQgZXhpc3QgYnV0IGlu dGVuZHMgdG8gc29sdmUgdGhlIHNhbWUgcHJvYmxlbSB3b3VsZCBiZQ0KPj4gYW55IG1vcmUgZGVw bG95YWJsZS4NCj4+DQo+PiBUb20NCj4+DQo+PiA+IE1pY2hhZWwNCj4+ID4NCj4+ID4NCj4+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4gRnJvbTogU3RhY2tldm8tZGlzY3VzcyBb bWFpbHRvOnN0YWNrZXZvLWRpc2N1c3MtYm91bmNlc0BpYWIub3JnXSBPbiBCZWhhbGYgT2YgQnJp YW4gVHJhbW1lbGwNCj4+ID4gU2VudDogVGh1cnNkYXksIE1heSAxOSwgMjAxNiA1OjA3IFBNDQo+ PiA+IFRvOiBzdGFja2V2by1kaXNjdXNzQGlhYi5vcmcNCj4+ID4gU3ViamVjdDogW1N0YWNrZXZv LWRpc2N1c3NdIEZ3ZDogUG9zc2libGUgV0ctZm9ybWluZyBmb2xsb3ctb24gdG8gU1BVRCBCb0YN Cj4+ID4NCj4+ID4gR3JlZXRpbmdzLCBhbGwsDQo+PiA+DQo+PiA+IEZvcndhcmRpbmcgdGhpcyB0 byB0aGUgY29ycmVjdCBhZGRyZXNzIGZvciB0aGlzIG1haWxpbmcgbGlzdCAob29wcykuIFBsZWFz ZSBkaXNjdXNzIGF0IHNwdWRAaWV0Zi5vcmcuDQo+PiA+DQo+PiA+IFRoYW5rcywgY2hlZXJzLA0K Pj4gPg0KPj4gPiBCcmlhbg0KPj4gPg0KPj4gPj4gQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQo+ PiA+Pg0KPj4gPj4gRnJvbTogQnJpYW4gVHJhbW1lbGwgPGlldGZAdHJhbW1lbGwuY2g+DQo+PiA+ PiBTdWJqZWN0OiBQb3NzaWJsZSBXRy1mb3JtaW5nIGZvbGxvdy1vbiB0byBTUFVEIEJvRg0KPj4g Pj4gRGF0ZTogMTkgTWF5IDIwMTYgYXQgMTc6MDQ6NTAgR01UKzINCj4+ID4+IFRvOiBzcHVkQGll dGYub3JnDQo+PiA+PiBDYzogc3RhY2tldm8tZGlzY3Vzc0BpZXRmLm9yZywgdHN2LWFyZWFAaWV0 Zi5vcmcsICJNaXJqYSBLdWVobGV3aW5kDQo+PiA+PiAoSUVURikiIDxpZXRmQGt1ZWhsZXdpbmQu bmV0PiwgU3BlbmNlciBEYXdraW5zIGF0IElFVEYNCj4+ID4+IDxzcGVuY2VyZGF3a2lucy5pZXRm QGdtYWlsLmNvbT4NCj4+ID4+DQo+PiA+PiBHcmVldGluZ3MsIGFsbCwNCj4+ID4+DQo+PiA+PiBX ZSBwcm9wb3NlIHRvIGhvbGQgYSB3b3JraW5nLWdyb3VwIGZvcm1pbmcgQm9GIGluIEJlcmxpbiBh cyBhIGZvbGxvdy1vbiB0byB0aGUgU1BVRCB3b3JrLCB0byBkZWZpbmUgYSBjb21tb24gc3Vic3Ry YXRlIHByb3RvY29sIGZvciBlbmNyeXB0ZWQgdHJhbnNwb3J0cyBiYXNlZCBvbiB0aGUgcmVxdWly ZW1lbnRzIGRlcml2ZWQgZnJvbSBleHBlcmltZW50YXRpb24gd2l0aCB0aGUgU1BVRCBwcm90b3R5 cGUuDQo+PiA+Pg0KPj4gPj4gRmlyc3QsIG5vdGUgdGhhdCBzaW5jZSB0aGUgYWNyb255bSAiU1BV RCIgcmVmZXJzIHByaW1hcmlseSB0byB0aGUgcHJvdG90eXBlIGl0c2VsZiwgYW55IGZvbGxvdy1v biB3b3JraW5nIGdyb3VwIHNob3VsZCBoYXZlIGEgZGlmZmVyZW50IG5hbWUuIFdlJ3JlIHVzaW5n IHRoZSBkZXJpdmVkIHJlcXVpcmVtZW50cywgbm90IHN0YXJ0aW5nIGZvciB0aGUgcHJvdG90eXBl LiBUaGUgbmFtZSBpcyBhIHN1YmplY3QgZm9yIGRpc2N1c3Npb24sIGFuZCBzdWdnZXN0aW9ucyBh cmUgd2VsY29tZS4gVG8gaGF2ZSBzb21ldGhpbmcgdG8gcHV0IGluIHRoZSBwcm9wb3NlZCBjaGFy dGVyLCB3ZSdkIHByb3Bvc2UgIlBhdGggTGF5ZXIgVURQIFN1YnN0cmF0ZSIgKFBMVVMpIGFzIGEg c3RhcnRpbmcgcG9pbnQuDQo+PiA+Pg0KPj4gPj4gVGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYXBwZWFy cyBiZWxvdy4gV2UncmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIGluaXRpYWwgZmVlZGJhY2sgb24g dGhlIHByb3Bvc2VkIGNoYXJ0ZXIgaW4gcHJlcGFyYXRpb24gZm9yIGEgQm9GIHByb3Bvc2FsICh0 aGUgY3V0b2ZmIGRhdGUgaXMgdHdvIHdlZWtzIGZyb20gdG9tb3Jyb3csIG9uIEZyaWRheSAzIEp1 bmUpLiBJcyB0aGVyZSB3b3JrIHRvIGRvIGhlcmUgd2l0aGluIHRoZSBJRVRGPyBJcyB0aGUgc2Nv cGUgb2YgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYXBwcm9wcmlhdGU/IElzIHRoZXJlIGVuZXJneSB0 byBkbyB0aGlzIHdvcms/DQo+PiA+Pg0KPj4gPj4gVGhhbmtzLCBjaGVlcnMsDQo+PiA+Pg0KPj4g Pj4gQnJpYW4gYW5kIE1pcmphDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IFBhdGggTGF5ZXIgVURQIFN1 YnN0cmF0ZSAoUExVUykNCj4+ID4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4+ ID4+DQo+PiA+PiBUaGUgUExVUyB3b3JraW5nIGdyb3VwPz8/cyBnb2FsIGlzIHRvIGVuYWJsZSB0 aGUgZGVwbG95bWVudCBvZiBuZXcsDQo+PiA+PiBlbmNyeXB0ZWQgdHJhbnNwb3J0IHByb3RvY29s cywgd2hpbGUgcHJvdmlkaW5nIGEgdHJhbnNwb3J0LWluZGVwZW5kZW50DQo+PiA+PiBtZXRob2Qg dG8gc2lnbmFsIGZsb3cgc2VtYW50aWNzIHVuZGVyIHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24g Y29udHJvbC4NCj4+ID4+DQo+PiA+PiBUaGUgY3VycmVudCBJbnRlcm5ldCBwcm90b2NvbCBzdGFj ayBoYXMgbm8gbGF5ZXIgZm9yIGV4cGxpY2l0DQo+PiA+PiBzaWduYWxpbmcgb2YgZmxvdyBzZW1h bnRpY3MgYW5kIGNoYXJhY3RlcmlzdGljcyB0byBuZXR3b3JrIGVsZW1lbnRzLA0KPj4gPj4gbm9y IGFuIGludGVncmF0ZWQgc2lnbmFsaW5nIG1lY2hhbmlzbSBmcm9tIG5ldHdvcmsgZWxlbWVudHMg dG8gYmFjayB0bw0KPj4gPj4gZW5kcG9pbnRzIGFuZCBhcHBsaWNhdGlvbnMuIFRoaXMgbGF5ZXIg bmV2ZXIgZXZvbHZlZCB3aXRoaW4gdGhlIHN0YWNrLA0KPj4gPj4gYmVjYXVzZSBtaWRkbGVib3hl cyBhbmQgb3RoZXIgZGV2aWNlcyBvbiBwYXRoIGNvdWxkIHNpbXBseSBpbnNwZWN0IGFuZA0KPj4g Pj4gbW9kaWZ5IGhlYWRlcnMgYW5kIHBheWxvYWQgb2YgdW5lbmNyeXB0ZWQgdHJhZmZpYyBhdCBl dmVyeSBsYXllci4gVGhpcw0KPj4gPj4gaW1wbGljaXQgdXNlIG9mIGluZm9ybWF0aW9uIGZyb20g dGhlIHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24gbGF5ZXJzDQo+PiA+PiBpcyBhIGtleSBvcmln aW4gb2YgdGhlIG9zc2lmaWNhdGlvbiB0aGF0IG1ha2VzIGl0IGhhcmQgb3IgaW1wb3NzaWJsZSB0 byBkZXBsb3kgbmV3IHByb3RvY29scy4NCj4+ID4+DQo+PiA+PiBJbiBvcmRlciB0byBzdXBwb3J0 IG1vcmUgdWJpcXVpdG91cyBkZXBsb3ltZW50IG9mIGVuY3J5cHRpb24sIGV4cGxpY2l0DQo+PiA+ PiBzaWduYWxpbmcgbXVzdCBiZSBhZGRlZCB0byB0aGUgc3RhY2ssIGFuZCBpdCBtdXN0IGJlIHRy YW5zcG9ydA0KPj4gPj4gcHJvdG9jb2wgaW5kZXBlbmRlbnQuIFdoaWxlIElQIHdvdWxkIHNlZW0g dG8gYmUgdGhlIG5hdHVyYWwgaG9tZSBmb3INCj4+ID4+IHRoaXMgZmFjaWxpdHksIGJvdGggSVB2 NCBhbmQgSVB2NiBvcHRpb25zIGFuZCBleHRlbnNpb25zIGhhdmUNCj4+ID4+IGRlcGxveW1lbnQg cHJvYmxlbXMgb24gdGhlaXIgb3duLCB3aGljaCBtYWtlcyBpdCBoYXJkIHRvIGluY2x1ZGUgYW55 DQo+PiA+PiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGluIHRoZXNlIHByb3RvY29scy4gQWRkaXRp b25hbGx5LCBhIGZlZWRiYWNrDQo+PiA+PiBjaGFubmVsIHRoYXQgcHJvdmlkZXMgaW5mb3JtYXRp b24gZnJvbSBvbi1wYXRoIGRldmljZXMgYmFjayB0bw0KPj4gPj4gZW5kcG9pbnRzIGFuZCBhcHBs aWNhdGlvbnMsIGUuZy4gZm9yIGVycm9yIGhhbmRsaW5nLCBpcyBlc3NlbnRpYWwgZm9yDQo+PiA+ PiB0aGUgZGVwbG95bWVudCBhbmQgc3VjY2VzcyBvZiBhbiBleHBsaWNpdCBjb29wZXJhdGlvbiBh cHByb2FjaC4NCj4+ID4+DQo+PiA+PiBUaGUgUExVUyB3b3JraW5nIGdyb3VwIHdpbGwgc3BlY2lm eSBhIG5ldyBwcm90b2NvbCBhcyBhIFBhdGggTGF5ZXINCj4+ID4+IFVzZXIgU3Vic3RyYXRlIChQ TFVTKSwgdG8gc3VwcG9ydCBleHBlcmltZW50YWwgZGVwbG95bWVudCBvZiBleHBsaWNpdA0KPj4g Pj4gY29vcGVyYXRpb24gYmV0d2VlbiBlbmRwb2ludHMgYW5kIGRldmljZXMgb24gcGF0aCwgd2l0 aCB0aGUgZm9sbG93aW5nIGdvYWxzOg0KPj4gPj4NCj4+ID4+IC0gZW5hYmxlIHViaXF1aXRvdXMg ZGVwbG95bWVudCBvZiBlbmNyeXB0ZWQgaGlnaGVyIGxheWVyIHByb3RvY29scyBieQ0KPj4gPj4g cHJvdmlkaW5nIGV4cG9zdXJlIG9mIHNpbWlsYXIgc2VtYW50aWNzIHRvIGV4aXN0aW5nIHByb3Rv Y29scyAoZS5nLg0KPj4gPj4gVENQKSB0byBkZXZpY2VzIG9uIHBhdGggKGUuZy4gTkFUcyBhbmQg ZmlyZXdhbGxzKQ0KPj4gPj4NCj4+ID4+IC0gYWxsb3cgYXBwbGljYXRpb25zIGFuZCB0cmFuc3Bv cnQgcHJvdG9jb2xzIHRvIGV4cGxpY2l0bHkgcHJvdmlkZQ0KPj4gPj4gbGltaXRlZCBpbmZvcm1h dGlvbiB0byBkZXZpY2VzIG9uIHBhdGgNCj4+ID4+DQo+PiA+PiAtIGFsbG93IGRldmljZXMgb24g cGF0aCB0byBwcm92aWRlIGZlZWRiYWNrIGFuZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUNCj4+ID4+ IHBhdGggdG8gc2VuZGluZyBlbmRwb2ludHMsIHVuZGVyIHNlbmRpbmcgZW5kcG9pbnQgY29udHJv bA0KPj4gPj4NCj4+ID4+IC0gYWxsb3cgZGV2aWNlcyBvbiBwYXRoIHRvIHByb3ZpZGUgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIHBhdGggdG8NCj4+ID4+IHJlY2VpdmluZyBlbmRwb2ludHMsIHdpdGgg ZmVlZGJhY2sgdG8gdGhlIHNlbmRpbmcgZW5kcG9pbnQsIHVuZGVyDQo+PiA+PiBzZW5kaW5nIGVu ZHBvaW50IGNvbnRyb2wNCj4+ID4+DQo+PiA+PiBOb3RlIHRoYXQgdGhpcyBhcHByb2FjaCBleHBs aWNpdGx5IGdpdmVzIHRoZSBjb250cm9sIG9mIGluZm9ybWF0aW9uDQo+PiA+PiBleHBvc3VyZSBi YWNrIHRoZSBhcHBsaWNhdGlvbiBhbmQvb3IgdHJhbnNwb3J0IGxheWVyIHByb3RvY29sIG9uIHRo ZQ0KPj4gPj4gZW5kIGhvc3QuIEl0IGlzIHRoZSBnb2FsIG9mIFBMVVMgdG8gbWluaW1pemUgdGhl IGluZm9ybWF0aW9uIGV4cG9zZWQNCj4+ID4+IGF0IHRoZSBsZXZlbCBvZiBkZXRhaWwgdGhhdCBp cyB1c2VmdWwgZm9yIHRoZSBuZXR3b3JrLCB3aGlsZQ0KPj4gPj4gZW5jcnlwdGluZyBldmVyeXRo aW5nIGVsc2UuIFRoaXMgaXMgaW1wb3J0YW50IHRvIGF2b2lkIGZ1dHVyZSBpbXBsaWNpdA0KPj4g Pj4gdHJlYXRtZW50IGFuZCB0aGUgcmVzdWx0aW5nIG9zc2lmaWNhdGlvbiwgYXMgd2VsbCBhcyB0 byBsZXZlcmFnZSB0aGUNCj4+ID4+IHByaW5jaXBsZSBvZiBsZWFzdCBleHBvc3VyZSB0byBtaW5p bWl6ZSBwcml2YWN5IHJpc2tzIHByZXNlbnRlZCBieSBleHBsaWNpdCBjb29wZXJhdGlvbi4NCj4+ ID4+DQo+PiA+PiBHaXZlbiB0aGF0IHRoZSBwcmltYXJ5IGdvYWwgb2YgUExVUyBpcyB0byBlbmFi bGUgdGhlIGRlcGxveW1lbnQgb2YNCj4+ID4+IGFyYml0cmFyeSwgZnVsbHkgZW5jcnlwdGVkIHRy YW5zcG9ydCBwcm90b2NvbHMsIHdlIGFzc3VtZSB0aGF0IHRoZQ0KPj4gPj4gaGlnaGVyIGxheWVy IHByb3RvY29sIGNhbiBwcm92aWRlIGFuIGVuY3J5cHRpb24gY29udGV4dCB0aGF0IGNhbiBiZQ0K Pj4gPj4gdXNlZCBieSBQTFVTIHRvIHByb3ZpZGUgYXV0aGVudGljYXRpb24sIGludGVncml0eSwg YW5kIGVuY3J5cHRpb24NCj4+ID4+IHdoZXJlIG5lZWRlZC4gVGhlIHByaW1hcnkgdGhyZWF0IG1v ZGVsIHRvIGRlZmVuZCBhZ2FpbnN0IHdpbGwgYmUNCj4+ID4+IG1vZGlmaWNhdGlvbiBvciBkZWxl dGlvbiBvZiBleHBvc2VkIGluZm9ybWF0aW9uIGJ5IG1pZGRsZWJveGVzIGFuZA0KPj4gPj4gb3Ro ZXIgZGV2aWNlcyBvbiBwYXRoLCBieSBhbGxvd2luZyBhIHJlbW90ZSBlbmRwb2ludCB0byBkZXRl Y3QgbW9kaWZpY2F0aW9ucy4NCj4+ID4+DQo+PiA+PiBUaGUgd29ya2luZyBncm91cCB3aWxsIHN0 YXJ0IHdpdGggYW4gaW5pdGlhbCBzZXQgb2YgdXNlIGNhc2VzIChzZWUNCj4+ID4+IGRyYWZ0LWt1 ZWhsZXdpbmQtc3B1ZC11c2UtY2FzZXMpIGFuZCByZXF1aXJlbWVudHMgKHNlZQ0KPj4gPj4gZHJh ZnQtdHJhbW1lbGwtc3B1ZC1yZXEpLCB0YWtlbiBmcm9tIGV4cGVyaWVuY2Ugd2l0aCB0aGUgU3Vi c3RyYXRlIFByb3RvY29sIGZvciBVc2VyIERhdGFncmFtcyBwcm90b3R5cGUuDQo+PiA+PiBUaGUg d29ya2luZyBncm91cCdzIG1haW4gb3V0cHV0IHdpbGwgYmUgYW4gZXhwZXJpbWVudGFsIHByb3Rv Y29sDQo+PiA+PiBzcGVjaWZpY2F0aW9uLCB0b2dldGhlciB3aXRoIGFuIGluaXRpYWwgcmVnaXN0 cnkgb2YgdHlwZXMgb2YNCj4+ID4+IGluZm9ybWF0aW9uIHRoYXQgY2FuIGJlIGV4cG9zZWQgdXNp bmcgUExVUywgY2xlYXJseSBhbGlnbmVkIHRvIHRoZXNlDQo+PiA+PiB1c2UgY2FzZXMgYW5kIHJl cXVpcmVtZW50cy4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBjbG9zZSBpZiBpdCBpcyBub3QNCj4+ ID4+IGFibGUgdG8gY29tZSB0byBjb25zZW5zdXMgb24gYSBwcm90b2NvbCBkZXNpZ24gdG8gbWVl dCB0aGVzZSByZXF1aXJlbWVudHMuDQo+PiA+Pg0KPj4gPj4gVGhlIHdvcmtpbmcgZ3JvdXAgd2ls bCBhZGRpdGlvbmFsbHkgYWltIHRvIGlkZW50aWZ5IG90aGVyIHdvcmtpbmcNCj4+ID4+IGdyb3Vw cyB0aGF0IGNvdWxkIG9yIHNob3VsZCBhZGRyZXNzIHBhcnRzIG9mIHRoZXNlIHJlcXVpcmVtZW50 cyB3aXRoaW4NCj4+ID4+IGV4aXN0aW5nIHByb3RvY29scywgZS5nLiBieSBzcGVjaWZ5aW5nIG5l dyBwcm90b2NvbCBleHRlbnNpb25zIG9yIGFzDQo+PiA+PiBpbnB1dCBmb3Igb24tZ29pbmcgc3Rh bmRhcmRpemF0aW9uIHdvcmsuIEl0IHdpbGwgYWltIHRvIHdvcmsgd2l0aA0KPj4gPj4gd29ya2lu ZyBncm91cHMgZGVmaW5pbmcgZW5jcnlwdGlvbiBwcm90b2NvbHMgKGUuZy4gVExTKSB3aGljaCBj b3VsZCBiZQ0KPj4gPj4gdXNlZCBmb3IgZW5jcnlwdGlvbiBvZiB0cmFuc3BvcnQgcHJvdG9jb2xz IHJ1bm5pbmcgb3ZlciBQTFVTLg0KPj4gPj4NCj4+ID4NCj4+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4gU3B1ZCBtYWlsaW5nIGxpc3QNCj4+ ID4gU3B1ZEBpZXRmLm9yZw0KPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwdWQNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gU3B1ZCBtYWlsaW5nIGxpc3QNCj4+IFNwdWRAaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3B1ZA0KPg0KPiAtLQ0KPiAtLS0NCj4g VG9lcmxlc3MgRWNrZXJ0LCBlY2tlcnRAY2lzY28uY29tDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTcHVkIG1haWxpbmcgbGlzdA0KU3B1ZEBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkDQo= From nobody Thu May 19 19:40: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 1B55E12D537 for ; Thu, 19 May 2016 19:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 r4TDfxITqG49 for ; Thu, 19 May 2016 19:40:27 -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 1D7E212D1D7 for ; Thu, 19 May 2016 19:31:19 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Thu, 19 May 2016 22:31:17 -0400 From: Dave Dolson To: Tom Herbert , Toerless Eckert Thread-Topic: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF Thread-Index: AdGyP4CFJ2cvNkb2DUuyKJNQQWe2WQAAC9Ow Date: Fri, 20 May 2016 02:31:17 +0000 Message-ID: <20160520023116.5697621.93269.85452@sandvine.com> References: <20160520022957.5697621.53774.85449@sandvine.com> In-Reply-To: <20160520022957.5697621.53774.85449@sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Brian Trammell , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 02:40:29 -0000 Er, make that "TCP carrying TLS" in the last sentence. Original Message From: Dave Dolson Sent: Thursday, May 19, 2016 10:30 PM To: Tom Herbert; Toerless Eckert Cc: Brian Trammell; Scharf, Michael (Nokia - DE); spud@ietf.org Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on t= o SPUD BoF Please also think about how a network operator can monitor how well things = are working, and how DDoS traffic may be discriminated from non-attack traf= fic. Today, - TCP packet loss can be measured by observing sequence numbers - round-trip times can be measured =FDfrom TCP sequence/ack numbers - non-attack traffic properly completes connections, whereas attack traffic= often does not - some fair-queuing approaches apply fairness by TCP connections=FD - ECMP and load-balancers try to make individual sessions follow a single p= ath If packets become completely opaque, I think =FDin general the internet wou= ld operate less well. It would be good for SPUD and QUIC =FDto provide enough information for mon= itoring devices to measure progress, handshakes, round-trip times, as can b= e done with TCP carrying TCP. -Dave =FD Original Message From: Tom Herbert Sent: Thursday, May 19, 2016 3:17 PM To: Toerless Eckert Cc: Brian Trammell; Scharf, Michael (Nokia - DE); spud@ietf.org Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on t= o SPUD BoF On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert wrote: > Tom, Michael > > I am reading your positions and i am confused: > > DSCP is very successfull in enterprise networks. SPUD does not have to > be successfull "on the Internet". To me it would already be a great succe= ss if it would > help to improve controlled network services (like enterprise or 4G/5G net= works). And > their transit traffic across the Internet (without changing anything on t= he Internet > itself). > Yes, that is my point about localizing the problem. A client device should know what network it's on an be able to signal to that network to get the services it wants. A server on the other side of the planet that the node is talking to really shouldn't be concerned with this and not required to implement some complex protocol to accommodate it. > AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if = we often think about > them as per-flow and ould maybe like them to be restrict to per-flow. At = least i don't know > any normative reference that defines them to be per-flow. > > Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis= that all those > mechanisms fail to provide an easily deplopyale framework in the face of = middleboxes. Aka: their > presence and mostly non-success should be an argument FOR working on spud= . Not against it. > > If a NAT/FW does support any flow signaling, its most likely inband. Ever= y NAT/firwall > supports flow recognition via the explicit signaling of flow-based transp= ort protoocols > like TCP. They do try to do the same for UDP and because that has no expl= icit flow signaling, > thats where the problem starts. NAT/FW do deep packet inspection which ha= s all these problems > we know. SPUD sets out to solve/reduce these NAT/FW issues. > There seems to be a lot of UDP going through NAT/FW today without any sort of in-band signaling, and protocols like QUIC are already seeing deployment without that (according to their slide deck "About half of Google to Chrome"). Considering that there is no deployment of a SPUD aware firewall and we can't want to wait for every device on the Internet to upgrade, SPUD will have to work with NAT/FW as is or we couldn't consider it. TBH I'm really having a hard time seeing that any extra signaling is required in the Internet other than what is in the IP header, at best it seems like an optimization for certain networks or configurations. > Non-support of anything like IP options is IMHO primarily driven by the a= bsence of > unform cross-OS/Dev-language APIs for them. Yes. It may suck architectura= lly by designing > protocol stacks based on reality like: applications will only be able to = use UDP and TCP, > so lets do new work on top of them, but to me the most important goal is = to find the best > deployable solution to a problem. Not the architecturally cleanest one. I= f you give me > research money to work outside of reality i will happily take it though a= nd represent a > different perspective. > There has been a lot of discussion about this in v6ops, many networks are simply dropping packets with extension headers. Please look at draft-ietf-v6ops-ipv6-ehs-in-real-world-02 and draft-gont-v6ops-ipv6-ehs-packet-drops-03. Because of this and the fact that there hasn't been any interesting options defined worth sending to date means that we (speaking for applications) have no use to send them (btw all the major OSes support options AFAIK). If some interesting options did come about, then we would probably apply a happy eyeballs approach to deploy. With something like SPUD (basically anything not simple TCP/IPv4) we are always faced with the same problem that some networks on the Internet may arbitrarily drop or otherwise restrict packets (we know for instance that some network operators choose to severely rate limit all UDP because of DOS concerns). So even if we do manage to start deploying transport protocols over UDP we are going have TCP as a fallback for indefinite future, i.e. more happy eyeballs. Tom > Please, i do not want to dismiss your opposition, i just don't understand= how the > arguments you make are working out. Maybe you can explain to me where i a= m going wrong > in my interpretations above. > > Cheers > Toerless > > On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >> wrote: >> > Does the sentence ... >> > >> > The current Internet protocol stack has no layer for explicit signalin= g of flow semantics and characteristics to network elements ... >> > >> > actually wants to say something like >> > >> > The current Internet protocol stack has no layer for explicit *in-band= * signaling of flow semantics and characteristics ... ? >> > >> > I may be wrong, but there is no shortage of IETF and non-IETF protocol= s that can signal flow semantics and characteristics out-of-band, either pa= th-coupled or path-decoupled, e.g., in the control or management plane. As = a result, there are protocol "layers" for that signaling, but they are not = in-band. There may also be other ways to fix this problem (e.g., by adding = "end-to-end" or "inter-domain" instead of "in-band"). >> > >> Not to mention that TOS and diff-serv are in-band signaling mechanisms >> to the network, ECN is explicitly signaling from the network. Given >> that they've been around for many years but have never been widely >> deployed on the Internet makes me wonder if any in-band signaling >> mechanism will ever catch on. The use of out of band signaling should >> be considered, especially considered that in many cases like NAT and >> firewall the network elements that need signaling are likely in local >> networks of one side of the connection. >> >> I have a similar concern about the statement that IP options/EH and >> extension headers are being left off the table as part of a solution. >> The fact that neither have these caught on in the Internet and that >> tells me two things 1) No IP option is needed for the Internet to >> operate and be successful which makes me wonder if signaling between >> network and hosts is even required 2) If the extensibility mechanisms >> of IP are chronically not deployable, I wonder why any alternative >> that does not yet exist but intends to solve the same problem would be >> any more deployable. >> >> Tom >> >> > Michael >> > >> > >> > -----Original Message----- >> > From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On Be= half Of Brian Trammell >> > Sent: Thursday, May 19, 2016 5:07 PM >> > To: stackevo-discuss@iab.org >> > Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD= BoF >> > >> > Greetings, all, >> > >> > Forwarding this to the correct address for this mailing list (oops). P= lease discuss at spud@ietf.org. >> > >> > Thanks, cheers, >> > >> > Brian >> > >> >> Begin forwarded message: >> >> >> >> From: Brian Trammell >> >> Subject: Possible WG-forming follow-on to SPUD BoF >> >> Date: 19 May 2016 at 17:04:50 GMT+2 >> >> To: spud@ietf.org >> >> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >> >> (IETF)" , Spencer Dawkins at IETF >> >> >> >> >> >> Greetings, all, >> >> >> >> We propose to hold a working-group forming BoF in Berlin as a follow-= on to the SPUD work, to define a common substrate protocol for encrypted tr= ansports based on the requirements derived from experimentation with the SP= UD prototype. >> >> >> >> First, note that since the acronym "SPUD" refers primarily to the pro= totype itself, any follow-on working group should have a different name. We= 're using the derived requirements, not starting for the prototype. The nam= e is a subject for discussion, and suggestions are welcome. To have somethi= ng to put in the proposed charter, we'd propose "Path Layer UDP Substrate" = (PLUS) as a starting point. >> >> >> >> The proposed charter appears below. We're interested in hearing initi= al feedback on the proposed charter in preparation for a BoF proposal (the = cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work to= do here within the IETF? Is the scope of the proposed charter appropriate?= Is there energy to do this work? >> >> >> >> Thanks, cheers, >> >> >> >> Brian and Mirja >> >> >> >> >> >> Path Layer UDP Substrate (PLUS) >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> The PLUS working group???s goal is to enable the deployment of new, >> >> encrypted transport protocols, while providing a transport-independen= t >> >> method to signal flow semantics under transport and application contr= ol. >> >> >> >> The current Internet protocol stack has no layer for explicit >> >> signaling of flow semantics and characteristics to network elements, >> >> nor an integrated signaling mechanism from network elements to back t= o >> >> endpoints and applications. This layer never evolved within the stack= , >> >> because middleboxes and other devices on path could simply inspect an= d >> >> modify headers and payload of unencrypted traffic at every layer. Thi= s >> >> implicit use of information from the transport and application layers >> >> is a key origin of the ossification that makes it hard or impossible = to deploy new protocols. >> >> >> >> In order to support more ubiquitous deployment of encryption, explici= t >> >> signaling must be added to the stack, and it must be transport >> >> protocol independent. 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. Additionally, 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. >> >> >> >> The PLUS working group will specify a new protocol as a Path Layer >> >> User 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 similar semantics to existing protocols (e.g. >> >> TCP) to devices on path (e.g. NATs and firewalls) >> >> >> >> - allow applications and transport protocols to explicitly provide >> >> limited information to devices on path >> >> >> >> - allow devices on path to provide feedback and information about the >> >> path to sending endpoints, under sending endpoint control >> >> >> >> - allow devices on path to provide information about the path to >> >> receiving endpoints, with feedback to the sending endpoint, under >> >> sending endpoint control >> >> >> >> Note that 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 >> >> at the level of detail that is useful for the network, while >> >> encrypting everything else. This is important to avoid future implici= t >> >> treatment and the resulting ossification, as well as to leverage the >> >> principle of least exposure to minimize privacy risks presented by ex= plicit cooperation. >> >> >> >> Given that the primary goal of PLUS is to enable the deployment of >> >> arbitrary, fully encrypted transport protocols, 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 modifi= cations. >> >> >> >> 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 Pr= otocol for User Datagrams 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 these >> >> use cases and requirements. The working group will close if it is not >> >> able to come to consensus on a protocol design to meet these requirem= ents. >> >> >> >> The working group will additionally aim to identify other working >> >> groups that could or should address parts of these requirements withi= n >> >> 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. TLS) which could b= e >> >> used for encryption of transport protocols running over 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 > > -- > --- > Toerless Eckert, eckert@cisco.com _______________________________________________ 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 Thu May 19 19:42: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 52E4712D545 for ; Thu, 19 May 2016 19:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 AvaOgpO9f7vG for ; Thu, 19 May 2016 19:42:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C2E12D537 for ; Thu, 19 May 2016 19:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16487; q=dns/txt; s=iport; t=1463712160; x=1464921760; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=TaQc5vzZOYzAslelneHyaT0Wt20B3ElYqawwme7oXT4=; b=WA4bn9z5fmRdnVjzqTNu1cNSe+diJ2SkEf8/rFPgNLFLFsY7cpGb0HW3 BDUGvFz9ecX2WGG/S0ZsLK3UAykUVYE+60SAlyzndEww3QpkT31xjEUso Pm8pazW3DMZyDkwPdBrxSD2cB6d9sLWc7GcrtcmfMXjU4s4xGjIzGSTgd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAgDXeD5X/4oNJK1UCoM3Vn6uKotvA?= =?us-ascii?q?Q2BdRcLhW8CgTU4FAEBAQEBAQFlJ4RCAQEBBAEBAS8BMgkLDAQLDgMDAQEBAQk?= =?us-ascii?q?eBw8FDQYfCQ4TG4d6AxcOv2UNhDABAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYlvg?= =?us-ascii?q?QOCQ4FMCAQBDRaFWgWNZHSJKDOIeIMvgW8KgWmET4hjh2GHaB4BAUKCBhyBaxw?= =?us-ascii?q?yhkgBBhmBHgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,337,1459814400"; d="scan'208";a="106263769" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 May 2016 02:42:38 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4K2gcrZ025946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2016 02:42:38 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 u4K2gbn5007716; Thu, 19 May 2016 19:42:37 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4K2gbbp007715; Thu, 19 May 2016 19:42:37 -0700 Date: Thu, 19 May 2016 19:42:37 -0700 From: Toerless Eckert To: Dave Dolson Message-ID: <20160520024237.GI2511@cisco.com> References: <20160520022957.5697621.53774.85449@sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160520022957.5697621.53774.85449@sandvine.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" , Brian Trammell Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 02:42:43 -0000 +1 a) The ECMP/fair-queueing issues should be resolved if SPUD as i hope it will simply maps UDP/SPUD ports 1:1 to the transport protocols inside of it. No aggregation. b) SPUD is meant to add connection setup/close signaling even if the original protocol did not have it. And having a single con setup/teardown signaling to network elements would allow new transport protocols to come up with whatever they want without having to bother with network devices not understanding them. c) Wrt to measurements: I don't think you can measure RTT from sequence/ack. I do like the idea of measuring loss, but if i want to enable agility of transport protocol designs then its a bad idea to rely on headers that are transport specific. In the same way as SPUD would have common setup/teardown signaling, it could have an optional measurement header. Make it kinda RTP-lite to allow east quality measurements. Sequence-number and timestamp (timestamps are great for delay/jitter measurements). On Fri, May 20, 2016 at 02:29:58AM +0000, Dave Dolson wrote: > Please also think about how a network operator can monitor how well things are working, and how DDoS traffic may be discriminated from non-attack traffic. > Today, > - TCP packet loss can be measured by observing sequence numbers > - round-trip times can be measured ???from TCP sequence/ack numbers > - non-attack traffic properly completes connections, whereas attack traffic often does not > - some fair-queuing approaches apply fairness by TCP connections??? > - ECMP and load-balancers try to make individual sessions follow a single path > > If packets become completely opaque, I think ???in general the internet would operate less well. > It would be good for SPUD and QUIC ???to provide enough information for monitoring devices to measure progress, handshakes, round-trip times, as can be done with TCP carrying TCP. > > -Dave > ??? > >   Original Message   > From: Tom Herbert > Sent: Thursday, May 19, 2016 3:17 PM > To: Toerless Eckert > Cc: Brian Trammell; Scharf, Michael (Nokia - DE); spud@ietf.org > Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF > > On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert wrote: > > Tom, Michael > > > > I am reading your positions and i am confused: > > > > DSCP is very successfull in enterprise networks. SPUD does not have to > > be successfull "on the Internet". To me it would already be a great success if it would > > help to improve controlled network services (like enterprise or 4G/5G networks). And > > their transit traffic across the Internet (without changing anything on the Internet > > itself). > > > Yes, that is my point about localizing the problem. A client device > should know what network it's on an be able to signal to that network > to get the services it wants. A server on the other side of the planet > that the node is talking to really shouldn't be concerned with this > and not required to implement some complex protocol to accommodate it. > > > AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if we often think about > > them as per-flow and ould maybe like them to be restrict to per-flow. At least i don't know > > any normative reference that defines them to be per-flow. > > > > Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis that all those > > mechanisms fail to provide an easily deplopyale framework in the face of middleboxes. Aka: their > > presence and mostly non-success should be an argument FOR working on spud. Not against it. > > > > If a NAT/FW does support any flow signaling, its most likely inband. Every NAT/firwall > > supports flow recognition via the explicit signaling of flow-based transport protoocols > > like TCP. They do try to do the same for UDP and because that has no explicit flow signaling, > > thats where the problem starts. NAT/FW do deep packet inspection which has all these problems > > we know. SPUD sets out to solve/reduce these NAT/FW issues. > > > There seems to be a lot of UDP going through NAT/FW today without any > sort of in-band signaling, and protocols like QUIC are already seeing > deployment without that (according to their slide deck "About half of > Google to Chrome"). Considering that there is no deployment of a SPUD > aware firewall and we can't want to wait for every device on the > Internet to upgrade, SPUD will have to work with NAT/FW as is or we > couldn't consider it. TBH I'm really having a hard time seeing that > any extra signaling is required in the Internet other than what is in > the IP header, at best it seems like an optimization for certain > networks or configurations. > > > Non-support of anything like IP options is IMHO primarily driven by the absence of > > unform cross-OS/Dev-language APIs for them. Yes. It may suck architecturally by designing > > protocol stacks based on reality like: applications will only be able to use UDP and TCP, > > so lets do new work on top of them, but to me the most important goal is to find the best > > deployable solution to a problem. Not the architecturally cleanest one. If you give me > > research money to work outside of reality i will happily take it though and represent a > > different perspective. > > > > There has been a lot of discussion about this in v6ops, many networks > are simply dropping packets with extension headers. Please look at > draft-ietf-v6ops-ipv6-ehs-in-real-world-02 and > draft-gont-v6ops-ipv6-ehs-packet-drops-03. Because of this and the > fact that there hasn't been any interesting options defined worth > sending to date means that we (speaking for applications) have no use > to send them (btw all the major OSes support options AFAIK). If some > interesting options did come about, then we would probably apply a > happy eyeballs approach to deploy. > > With something like SPUD (basically anything not simple TCP/IPv4) we > are always faced with the same problem that some networks on the > Internet may arbitrarily drop or otherwise restrict packets (we know > for instance that some network operators choose to severely rate limit > all UDP because of DOS concerns). So even if we do manage to start > deploying transport protocols over UDP we are going have TCP as a > fallback for indefinite future, i.e. more happy eyeballs. > > Tom > > > Please, i do not want to dismiss your opposition, i just don't understand how the > > arguments you make are working out. Maybe you can explain to me where i am going wrong > > in my interpretations above. > > > > Cheers > > Toerless > > > > On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: > >> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) > >> wrote: > >> > Does the sentence ... > >> > > >> > The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements ... > >> > > >> > actually wants to say something like > >> > > >> > The current Internet protocol stack has no layer for explicit *in-band* signaling of flow semantics and characteristics ... ? > >> > > >> > I may be wrong, but there is no shortage of IETF and non-IETF protocols that can signal flow semantics and characteristics out-of-band, either path-coupled or path-decoupled, e.g., in the control or management plane. As a result, there are protocol "layers" for that signaling, but they are not in-band. There may also be other ways to fix this problem (e.g., by adding "end-to-end" or "inter-domain" instead of "in-band"). > >> > > >> Not to mention that TOS and diff-serv are in-band signaling mechanisms > >> to the network, ECN is explicitly signaling from the network. Given > >> that they've been around for many years but have never been widely > >> deployed on the Internet makes me wonder if any in-band signaling > >> mechanism will ever catch on. The use of out of band signaling should > >> be considered, especially considered that in many cases like NAT and > >> firewall the network elements that need signaling are likely in local > >> networks of one side of the connection. > >> > >> I have a similar concern about the statement that IP options/EH and > >> extension headers are being left off the table as part of a solution. > >> The fact that neither have these caught on in the Internet and that > >> tells me two things 1) No IP option is needed for the Internet to > >> operate and be successful which makes me wonder if signaling between > >> network and hosts is even required 2) If the extensibility mechanisms > >> of IP are chronically not deployable, I wonder why any alternative > >> that does not yet exist but intends to solve the same problem would be > >> any more deployable. > >> > >> Tom > >> > >> > Michael > >> > > >> > > >> > -----Original Message----- > >> > From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On Behalf Of Brian Trammell > >> > Sent: Thursday, May 19, 2016 5:07 PM > >> > To: stackevo-discuss@iab.org > >> > Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF > >> > > >> > Greetings, all, > >> > > >> > Forwarding this to the correct address for this mailing list (oops). Please discuss at spud@ietf.org. > >> > > >> > Thanks, cheers, > >> > > >> > Brian > >> > > >> >> Begin forwarded message: > >> >> > >> >> From: Brian Trammell > >> >> Subject: Possible WG-forming follow-on to SPUD BoF > >> >> Date: 19 May 2016 at 17:04:50 GMT+2 > >> >> To: spud@ietf.org > >> >> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind > >> >> (IETF)" , Spencer Dawkins at IETF > >> >> > >> >> > >> >> Greetings, all, > >> >> > >> >> We propose to hold a working-group forming BoF in Berlin as a follow-on to the SPUD work, to define a common substrate protocol for encrypted transports based on the requirements derived from experimentation with the SPUD prototype. > >> >> > >> >> First, note that since the acronym "SPUD" refers primarily to the prototype itself, any follow-on working group should have a different name. We're using the derived requirements, not starting for the prototype. The name is a subject for discussion, and suggestions are welcome. To have something to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (PLUS) as a starting point. > >> >> > >> >> The proposed charter appears below. We're interested in hearing initial feedback on the proposed charter in preparation for a BoF proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work to do here within the IETF? Is the scope of the proposed charter appropriate? Is there energy to do this work? > >> >> > >> >> Thanks, cheers, > >> >> > >> >> Brian and Mirja > >> >> > >> >> > >> >> Path Layer UDP Substrate (PLUS) > >> >> =============================== > >> >> > >> >> The PLUS working group???s goal is to enable the deployment of new, > >> >> encrypted transport protocols, while providing a transport-independent > >> >> method to signal flow semantics under transport and application control. > >> >> > >> >> The current Internet protocol stack has no layer for explicit > >> >> signaling of flow semantics and characteristics to network elements, > >> >> nor an integrated signaling mechanism from network elements to back to > >> >> endpoints and applications. This layer never evolved within the stack, > >> >> because middleboxes and other devices on path could simply inspect and > >> >> modify headers and payload of unencrypted traffic at every layer. This > >> >> implicit use of information from the transport and application layers > >> >> is a key origin of the ossification that makes it hard or impossible to deploy new protocols. > >> >> > >> >> In order to support more ubiquitous deployment of encryption, explicit > >> >> signaling must be added to the stack, and it must be transport > >> >> protocol independent. 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. Additionally, 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. > >> >> > >> >> The PLUS working group will specify a new protocol as a Path Layer > >> >> User 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 similar semantics to existing protocols (e.g. > >> >> TCP) to devices on path (e.g. NATs and firewalls) > >> >> > >> >> - allow applications and transport protocols to explicitly provide > >> >> limited information to devices on path > >> >> > >> >> - allow devices on path to provide feedback and information about the > >> >> path to sending endpoints, under sending endpoint control > >> >> > >> >> - allow devices on path to provide information about the path to > >> >> receiving endpoints, with feedback to the sending endpoint, under > >> >> sending endpoint control > >> >> > >> >> Note that 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 > >> >> at the level of detail that is useful for the network, while > >> >> encrypting everything else. This is important to avoid future implicit > >> >> treatment and the resulting ossification, as well as to leverage the > >> >> principle of least exposure to minimize privacy risks presented by explicit cooperation. > >> >> > >> >> Given that the primary goal of PLUS is to enable the deployment of > >> >> arbitrary, fully encrypted transport protocols, 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 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 these > >> >> use cases and requirements. 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 other working > >> >> groups that could or should 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. TLS) which could be > >> >> used for encryption of transport protocols running over 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 > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Fri May 20 00:33: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 6283512D6D2 for ; Fri, 20 May 2016 00:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 mwPJiA6g9d0A for ; Fri, 20 May 2016 00:33:16 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 43C8512D6CD for ; Fri, 20 May 2016 00:33:15 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b3evp-0003tp-3v; Fri, 20 May 2016 09:33:13 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b3evo-0005NX-MY; Fri, 20 May 2016 09:33:13 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Fri, 20 May 2016 09:33:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> To: Tom Herbert X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 14 msgs/h 8 sum rcpts/h 19 sum msgs/h 11 total rcpts 41899 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.646, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0D5E468319F3A10B16AF65D0D4DCC7290B28B5B3 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 8 total 10067 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Ca By , Joe Touch , Toerless Eckert , spud Subject: Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 07:33:18 -0000 BRAAAAAAA TOOOOOOOOOOOOOTTT TOOOOOOOOOOT BRRRAAAAA TOOOOOOOOOOOTT = !!!!! This was the ugly sound of me blowing my own horn. I just have to do = this, I can't resist: >> 2) udp is blocked in many places, so thinga like quic fall back to = tcp. >>=20 > Yes, that is a given. Anything new we deploy on the Internet, be it > IPv6, SCTP, UDP, TFO, extension headers will necessitate fallback to > least common denominator like simple TCP/IP. ....... this is so true, and this is happening so little for transports = because applications are tied to the protocol (or at least can't use = features of protocols other than TCP or UDP, even with higher-level = APIs), and this is why the TAPS WG is so important. TAPS needs more activity I think... Cheers, Michael From nobody Fri May 20 01:46: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 7B88612D0B1 for ; Fri, 20 May 2016 01:46:16 -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 n-S-LWU5B_vH for ; Fri, 20 May 2016 01:46:14 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id D971612D0B0 for ; Fri, 20 May 2016 01:46:13 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 308C91A03C3; Fri, 20 May 2016 10:46:11 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6E180729-66C2-4EB0-9456-F5A3DE61001C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 20 May 2016 10:46:10 +0200 Message-Id: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Nokia - DE)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 08:46:16 -0000 --Apple-Mail=_6E180729-66C2-4EB0-9456-F5A3DE61001C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Michael, > On 19 May 2016, at 19:12, Scharf, Michael (Nokia - DE) = wrote: >=20 > Does the sentence ... >=20 > The current Internet protocol stack has no layer for explicit = signaling of flow semantics and characteristics to network elements ... >=20 > actually wants to say something like >=20 > The current Internet protocol stack has no layer for explicit = *in-band* signaling of flow semantics and characteristics ... ? Yes. One could make the argument that DSCP is an in-band signaling = mechanism at the network layer, but as designed really does work at the = network layer (i.e., it is explicitly applied per hop). > I may be wrong, but there is no shortage of IETF and non-IETF = protocols that can signal flow semantics and characteristics = out-of-band, either path-coupled or path-decoupled, e.g., in the control = or management plane. As a result, there are protocol "layers" for that = signaling, but they are not in-band. There may also be other ways to fix = this problem (e.g., by adding "end-to-end" or "inter-domain" instead of = "in-band"). "Interdomain, in-band" would work for me here and be more accurate. = "End-to-end" would imply to my ears that we only want the endpoints to = participate, for which we don't need a layer -- that's transport's job. Note that the current requirements document is not explicitly limited to = in-band approaches, but the fact that the signaling has to get the same = NAT and forwarding treatment would seem to be an implicit limit. Cheers, Brian > Michael >=20 >=20 > -----Original Message----- > From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On = Behalf Of Brian Trammell > Sent: Thursday, May 19, 2016 5:07 PM > To: stackevo-discuss@iab.org > Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD = BoF >=20 > Greetings, all, >=20 > Forwarding this to the correct address for this mailing list (oops). = Please discuss at spud@ietf.org. >=20 > Thanks, cheers, >=20 > Brian >=20 >> Begin forwarded message: >>=20 >> From: Brian Trammell >> Subject: Possible WG-forming follow-on to SPUD BoF >> Date: 19 May 2016 at 17:04:50 GMT+2 >> To: spud@ietf.org >> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >> (IETF)" , Spencer Dawkins at IETF >> >>=20 >> Greetings, all, >>=20 >> We propose to hold a working-group forming BoF in Berlin as a = follow-on to the SPUD work, to define a common substrate protocol for = encrypted transports based on the requirements derived from = experimentation with the SPUD prototype. >>=20 >> First, note that since the acronym "SPUD" refers primarily to the = prototype itself, any follow-on working group should have a different = name. We're using the derived requirements, not starting for the = prototype. The name is a subject for discussion, and suggestions are = welcome. To have something to put in the proposed charter, we'd propose = "Path Layer UDP Substrate" (PLUS) as a starting point. >>=20 >> The proposed charter appears below. We're interested in hearing = initial feedback on the proposed charter in preparation for a BoF = proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). = Is there work to do here within the IETF? Is the scope of the proposed = charter appropriate? Is there energy to do this work? >>=20 >> Thanks, cheers, >>=20 >> Brian and Mirja >>=20 >>=20 >> Path Layer UDP Substrate (PLUS) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>=20 >> The PLUS working group=E2=80=99s goal is to enable the deployment of = new, >> encrypted transport protocols, while providing a = transport-independent >> method to signal flow semantics under transport and application = control. >>=20 >> The current Internet protocol stack has no layer for explicit >> signaling of flow semantics and characteristics to network elements, >> nor an integrated signaling mechanism from network elements to back = to >> endpoints and applications. This layer never evolved within the = stack, >> because middleboxes and other devices on path could simply inspect = and >> modify headers and payload of unencrypted traffic at every layer. = This >> implicit use of information from the transport and application layers >> is a key origin of the ossification that makes it hard or impossible = to deploy new protocols. >>=20 >> In order to support more ubiquitous deployment of encryption, = explicit >> signaling must be added to the stack, and it must be transport >> protocol independent. 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. Additionally, 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. >>=20 >> The PLUS working group will specify a new protocol as a Path Layer >> User Substrate (PLUS), to support experimental deployment of explicit >> cooperation between endpoints and devices on path, with the following = goals: >>=20 >> - enable ubiquitous deployment of encrypted higher layer protocols by >> providing exposure of similar semantics to existing protocols (e.g. >> TCP) to devices on path (e.g. NATs and firewalls) >>=20 >> - allow applications and transport protocols to explicitly provide >> limited information to devices on path >>=20 >> - allow devices on path to provide feedback and information about the >> path to sending endpoints, under sending endpoint control >>=20 >> - allow devices on path to provide information about the path to >> receiving endpoints, with feedback to the sending endpoint, under >> sending endpoint control >>=20 >> Note that 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 >> at the level of detail that is useful for the network, while >> encrypting everything else. This is important to avoid future = implicit >> treatment and the resulting ossification, as well as to leverage the >> principle of least exposure to minimize privacy risks presented by = explicit cooperation. >>=20 >> Given that the primary goal of PLUS is to enable the deployment of >> arbitrary, fully encrypted transport protocols, 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. >>=20 >> 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 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 these >> use cases and requirements. The working group will close if it is not >> able to come to consensus on a protocol design to meet these = requirements. >>=20 >> The working group will additionally aim to identify other working >> groups that could or should 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. TLS) which could = be >> used for encryption of transport protocols running over PLUS. >>=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_6E180729-66C2-4EB0-9456-F5A3DE61001C 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 iQIcBAEBCgAGBQJXPs7SAAoJEIoSt78L6kajJLkP/R4jfF9+Cl25zsbSENANidFq uUN6LqEeV6i01bUdRP2BPWAErAWEUovr4lxbKpAmrT33k9IozpSM5zpfA5McBqlz nXSVkz6vDVYVtaP9zodmsseD2TOI3bAen0cHayRhWdAQRQ/nfFQQoAHrfY+dXmAK jJumDwd9NKYUKKvUEsk4thJgpjiOLWAh9EphsnI+cIML/V9WLSB0tg4m48vEJBr+ aEV5esMKNPhGXdkQAd+L7QhJ0RX30JvLYi4wyJUL28nG2Ak7IdvcKAl4Ub4SwOYf ORdskLzoxw37eGDeDiIoRviUg78N6pj0oCcRe2oL95RgMFlC4G9/yNcGYMhBBkPp zEymJ/uGrtA+X2YuZ2C8mjF21yZdTeLkJnMcghjoFpE5KuAXQe0OmrQ8UNxO0P0n tvK0En3Z84qvh574Xdc4ZQP+1AYsW5uBngp3aSm+rMaZR8Jxwk175avlF4v+M4Wh SI9IVG0cgDH5utC/szZzyQVsIf4XLvOerHfs55bEjkE1Z4FlCxMuZdw5uCAYNP9i GTRPoEps2Y+Y4cMOs0MlMUlcxj9magW5lfoyQk6BRzcZwn6xxMGEsV0fit16GA8b qlui9C5qCPA+VaXHXPUNMVV2g6bki+XxhjMXiAQvPrqO1mZeSVKiznZ1Zw1/DWV9 SUTvlZwnNGJ9dkPcVxun =xQkk -----END PGP SIGNATURE----- --Apple-Mail=_6E180729-66C2-4EB0-9456-F5A3DE61001C-- From nobody Fri May 20 03:08:11 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 6E3BF12DC5A for ; Fri, 20 May 2016 03:08:09 -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 cRBWwdNATbRN for ; Fri, 20 May 2016 03:08:07 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5516212DC4C for ; Fri, 20 May 2016 03:08:06 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 2637D1A0CAB; Fri, 20 May 2016 12:08:05 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_573C6BDA-1EF8-4442-95BE-7BCB9899D8D2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Fri, 20 May 2016 12:08:04 +0200 Message-Id: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 10:08:10 -0000 --Apple-Mail=_573C6BDA-1EF8-4442-95BE-7BCB9899D8D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Tom, > On 19 May 2016, at 19:50, Tom Herbert wrote: >=20 > On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) > wrote: >> Does the sentence ... >>=20 >> The current Internet protocol stack has no layer for explicit = signaling of flow semantics and characteristics to network elements ... >>=20 >> actually wants to say something like >>=20 >> The current Internet protocol stack has no layer for explicit = *in-band* signaling of flow semantics and characteristics ... ? >>=20 >> I may be wrong, but there is no shortage of IETF and non-IETF = protocols that can signal flow semantics and characteristics = out-of-band, either path-coupled or path-decoupled, e.g., in the control = or management plane. As a result, there are protocol "layers" for that = signaling, but they are not in-band. There may also be other ways to fix = this problem (e.g., by adding "end-to-end" or "inter-domain" instead of = "in-band"). >>=20 > Not to mention that TOS and diff-serv are in-band signaling mechanisms > to the network, ECN is explicitly signaling from the network. DSCP is properly network-layer. If you believe in a "path layer" (which = I'm pretty sure I do), you can argue that ECN is the first path layer = protocol. > Given > that they've been around for many years but have never been widely > deployed on the Internet DCSP was defined in such a way that it makes little sense in an = interdomain context, and its widespread intradomain deployment means = that it will never deploy across domains in the general case. I still hold out a (potentially irrational) hope for ECN's deployment. > makes me wonder if any in-band signaling > mechanism will ever catch on. The use of out of band signaling should > be considered, especially considered that in many cases like NAT and > firewall the network elements that need signaling are likely in local > networks of one side of the connection. As noted, out of band signaling is not explicitly out of scope in the = current > I have a similar concern about the statement that IP options/EH and > extension headers are being left off the table as part of a solution. I don't think they are off the table; a protocol such as what we propose = to develop in PLUS could certainly use IPv6 extension headers, provided = they can be implemented such that applications actually get access to = those headers. IPv4 options are more of a stretch, simply due to = questions about how well the path treats them. > The fact that neither have these caught on in the Internet and that > tells me two things 1) No IP option is needed for the Internet to > operate and be successful which makes me wonder if signaling between > network and hosts is even required 2) If the extensibility mechanisms > of IP are chronically not deployable, I wonder why any alternative > that does not yet exist but intends to solve the same problem would be > any more deployable. I'd assert that encapsulating things in UDP is certainly much more = deployable *at the endpoints*. The open question is about adoption by = on-path devices. Cheers, Brian >=20 > Tom >=20 >> Michael >>=20 >>=20 >> -----Original Message----- >> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On = Behalf Of Brian Trammell >> Sent: Thursday, May 19, 2016 5:07 PM >> To: stackevo-discuss@iab.org >> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to = SPUD BoF >>=20 >> Greetings, all, >>=20 >> Forwarding this to the correct address for this mailing list (oops). = Please discuss at spud@ietf.org. >>=20 >> Thanks, cheers, >>=20 >> Brian >>=20 >>> Begin forwarded message: >>>=20 >>> From: Brian Trammell >>> Subject: Possible WG-forming follow-on to SPUD BoF >>> Date: 19 May 2016 at 17:04:50 GMT+2 >>> To: spud@ietf.org >>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >>> (IETF)" , Spencer Dawkins at IETF >>> >>>=20 >>> Greetings, all, >>>=20 >>> We propose to hold a working-group forming BoF in Berlin as a = follow-on to the SPUD work, to define a common substrate protocol for = encrypted transports based on the requirements derived from = experimentation with the SPUD prototype. >>>=20 >>> First, note that since the acronym "SPUD" refers primarily to the = prototype itself, any follow-on working group should have a different = name. We're using the derived requirements, not starting for the = prototype. The name is a subject for discussion, and suggestions are = welcome. To have something to put in the proposed charter, we'd propose = "Path Layer UDP Substrate" (PLUS) as a starting point. >>>=20 >>> The proposed charter appears below. We're interested in hearing = initial feedback on the proposed charter in preparation for a BoF = proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). = Is there work to do here within the IETF? Is the scope of the proposed = charter appropriate? Is there energy to do this work? >>>=20 >>> Thanks, cheers, >>>=20 >>> Brian and Mirja >>>=20 >>>=20 >>> Path Layer UDP Substrate (PLUS) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>=20 >>> The PLUS working group=E2=80=99s goal is to enable the deployment of = new, >>> encrypted transport protocols, while providing a = transport-independent >>> method to signal flow semantics under transport and application = control. >>>=20 >>> The current Internet protocol stack has no layer for explicit >>> signaling of flow semantics and characteristics to network elements, >>> nor an integrated signaling mechanism from network elements to back = to >>> endpoints and applications. This layer never evolved within the = stack, >>> because middleboxes and other devices on path could simply inspect = and >>> modify headers and payload of unencrypted traffic at every layer. = This >>> implicit use of information from the transport and application = layers >>> is a key origin of the ossification that makes it hard or impossible = to deploy new protocols. >>>=20 >>> In order to support more ubiquitous deployment of encryption, = explicit >>> signaling must be added to the stack, and it must be transport >>> protocol independent. 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. Additionally, 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. >>>=20 >>> The PLUS working group will specify a new protocol as a Path Layer >>> User Substrate (PLUS), to support experimental deployment of = explicit >>> cooperation between endpoints and devices on path, with the = following goals: >>>=20 >>> - enable ubiquitous deployment of encrypted higher layer protocols = by >>> providing exposure of similar semantics to existing protocols (e.g. >>> TCP) to devices on path (e.g. NATs and firewalls) >>>=20 >>> - allow applications and transport protocols to explicitly provide >>> limited information to devices on path >>>=20 >>> - allow devices on path to provide feedback and information about = the >>> path to sending endpoints, under sending endpoint control >>>=20 >>> - allow devices on path to provide information about the path to >>> receiving endpoints, with feedback to the sending endpoint, under >>> sending endpoint control >>>=20 >>> Note that 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 >>> at the level of detail that is useful for the network, while >>> encrypting everything else. This is important to avoid future = implicit >>> treatment and the resulting ossification, as well as to leverage the >>> principle of least exposure to minimize privacy risks presented by = explicit cooperation. >>>=20 >>> Given that the primary goal of PLUS is to enable the deployment of >>> arbitrary, fully encrypted transport protocols, 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. >>>=20 >>> 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 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 these >>> use cases and requirements. The working group will close if it is = not >>> able to come to consensus on a protocol design to meet these = requirements. >>>=20 >>> The working group will additionally aim to identify other working >>> groups that could or should 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. TLS) which could = be >>> used for encryption of transport protocols running over PLUS. >>>=20 >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_573C6BDA-1EF8-4442-95BE-7BCB9899D8D2 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 iQIcBAEBCgAGBQJXPuIEAAoJEIoSt78L6kajfaIP/3wo9wEosBQkoAUzd/o0Knzq bKXm1al1AMI0kuyGPFIFpuUSQKis14an3nsGH9HvuqMExWEXhnvL2//rWxlB9HiQ 7aocGIYVpMW6I/hGtvIpBLP+nTN+GiEctRW/w2xc74XprsriptSfuwoN22E0VnB2 pN9AuRyS+7npkwPvWZ9zVvzfgki3VIAM3lYun0QVotrokz1nd0sPowE4p7gM0LPv GsjKGmfZ5KjHLWqybnX6V74+iMfHs9CHi+uY4inl2ZR91yhxPZ7TcLUpn52G6Gcl EmaZ/bGfRo7F0QsfFv2OtFrz4hncxEYTxD3NmbkkZSptB0bXJ6OE0nXwhZNWkRkf 3riVJvJVrND/Mi3KBYVfJRJZ6XIIjy529H9PIQbrwv9mQ4JmTQV5oBZ3vfmkJZ7A 9EcDNzsNFOon/dv6hzZCgPi9taamDQacr0QaHoz5W0qcSChe1YJ+AaY4mPsOKdtg oPfelPuVHH4eAYzGktbBuvQCJM7CwG/zbEt4UucWx+bFiq5xG7NtHBHFLCWPSuNa C0It50CpSyCmVwGxDB/8J4nyCifL3zHjpIT6acg/aH8vVkeozMUtKfEqAfGSCHbi QImbU9qhd73Nv5LrX46fvLw8TuiXifvm8woagqTCEd2KhziXRdvkvVQwuvNJ+xdr xKs7BqZKgEyv1U/BVPnS =qcia -----END PGP SIGNATURE----- --Apple-Mail=_573C6BDA-1EF8-4442-95BE-7BCB9899D8D2-- From nobody Fri May 20 03:33: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 0ADD412DCA7 for ; Fri, 20 May 2016 03:33:29 -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 ER_9XV3m05er for ; Fri, 20 May 2016 03:33:27 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8D78D12B02E for ; Fri, 20 May 2016 03:33:26 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id DB4E11A0F5B; Fri, 20 May 2016 12:32:55 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_250CB2BF-9A02-4B70-9D05-2FEB14F412CE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Fri, 20 May 2016 12:32:55 +0200 Message-Id: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Toerless Eckert , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 10:33:29 -0000 --Apple-Mail=_250CB2BF-9A02-4B70-9D05-2FEB14F412CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 19 May 2016, at 21:17, Tom Herbert wrote: >=20 > On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert = wrote: >>=20 >> If a NAT/FW does support any flow signaling, its most likely inband. = Every NAT/firwall >> supports flow recognition via the explicit signaling of flow-based = transport protoocols >> like TCP. They do try to do the same for UDP and because that has no = explicit flow signaling, >> thats where the problem starts. NAT/FW do deep packet inspection = which has all these problems >> we know. SPUD sets out to solve/reduce these NAT/FW issues. >>=20 > There seems to be a lot of UDP going through NAT/FW today without any > sort of in-band signaling, and protocols like QUIC are already seeing > deployment without that (according to their slide deck "About half of > Google to Chrome"). Considering that there is no deployment of a SPUD > aware firewall and we can't want to wait for every device on the > Internet to upgrade, SPUD will have to work with NAT/FW as is or we > couldn't consider it. TBH I'm really having a hard time seeing that > any extra signaling is required in the Internet other than what is in > the IP header, at best it seems like an optimization for certain > networks or configurations. There's a couple of problems here which could (IMO should) be handled = better in a transport protocol independent way: (1) Generic indication of flow start/end. Firewalls use TCP semantics, = for the most part, and new protocols should expose at least these to get = better treatment. Yes, this would have most of the same problems than = SYNs, RSTs, and FINs do in TCP right now, but we can do better than the = status quo. One of the things we looked at with the SPUD header is using = a tube ID in a sparse identifier space to at least provide better = protection against RST/FIN with guessed sequence numbers (which outside = BGP is still a threat to deployed TCP, see [1]). (2) Indication of NAT/FW state timeout and timeout expectation, to = minimize unproductive keepalive traffic. Even with generic flow state = indication you still need timers, and always will, but exposing = information makes the average case performance better. We could consider adding these as key use cases in the protocol, but I = still think we want to have the broader use case discussion within any = eventual PLUS WG. If we *don't* care about the general deployability of new transport = protocols, if we think that QUIC is the Last Transport We'll Ever Need = (i.e., what SCTP was supposed to be), then we can just make sure QUIC = exposes enough to make this possible, and go home. While QUIC is a = definite improvement for the application semantics it's meant to = support, and a widely deployable SCTP would be a improvement for other = media applications, I'm not convinced that The Last Transport We'll Ever = Need is a thing that exists, or that we should want to exist. >> Non-support of anything like IP options is IMHO primarily driven by = the absence of >> unform cross-OS/Dev-language APIs for them. Yes. It may suck = architecturally by designing >> protocol stacks based on reality like: applications will only be able = to use UDP and TCP, >> so lets do new work on top of them, but to me the most important goal = is to find the best >> deployable solution to a problem. Not the architecturally cleanest = one. If you give me >> research money to work outside of reality i will happily take it = though and represent a >> different perspective. >>=20 >=20 > There has been a lot of discussion about this in v6ops, many networks > are simply dropping packets with extension headers. Please look at > draft-ietf-v6ops-ipv6-ehs-in-real-world-02 and > draft-gont-v6ops-ipv6-ehs-packet-drops-03. Because of this and the > fact that there hasn't been any interesting options defined worth > sending to date means that we (speaking for applications) have no use > to send them (btw all the major OSes support options AFAIK). If some > interesting options did come about, then we would probably apply a > happy eyeballs approach to deploy. There's an additional problem in that the way v6 EH are defined makes it = difficult to handle them on path: building silicon to handle arbitrary = header chains is expensive. So one of the functional requirements for = PLUS should be "information that forwarding devices need to see needs to = (usually) to be not very far into the packet, at a constate offset if = possible; see [2]. > With something like SPUD (basically anything not simple TCP/IPv4) we > are always faced with the same problem that some networks on the > Internet may arbitrarily drop or otherwise restrict packets (we know > for instance that some network operators choose to severely rate limit > all UDP because of DOS concerns). So even if we do manage to start > deploying transport protocols over UDP we are going have TCP as a > fallback for indefinite future, i.e. more happy eyeballs. Yes, and if we do manage to start deploying transport protocols over = IPv6, we are going to have IPv4 fallback for an indefinite future. I = share your concern about happy eyeballs state explosion (a phenomenon we = refer to around the office as "angry eyeballs" -> eight orthogonal = network/transport layer choices to test at startup means that every flow = begins with a 256 packet burst)... but the benefit of doing this to = transport flexibility is potentially worth the cost, which is the = fundamental question we want to address in PLUS. Cheers, Brian [1] Luckie et al "Resilience of Deployed TCP to Blind Attacks", IMC = 2015, http://conferences.sigcomm.org/imc/2015/papers/p13.pdf [2] Scudder "How a router actually works" IEPG at IETF 94, = http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf --Apple-Mail=_250CB2BF-9A02-4B70-9D05-2FEB14F412CE 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 iQIcBAEBCgAGBQJXPufXAAoJEIoSt78L6kajhiEQAIBi7N0ngdkCV11DFe5M5qwS tYWT8DsEZrAIkJE36HRTq/SpIAmfej7kfsZVZfrsu2lz0OO9IVaR1dckDgye2jvJ v85GX8/ChFNe5laewYVt0YRXIRqgYn/ceWCBN9jHR5yXVFtjpo88OGjIuZkipCnh OecviKrcsTs7Hbmc80KqXxOLxFHt3pvw0FIBnPRwo8tICi4TVPerJlJP5QGx0oZU FF1SZ1r9es88M9de1uJtrVbSAf7rVU4T9pwuzSdlwrN7TikZJJYJqqAsb5mmPSP1 w3W2p1SZF1VWGOjtRCZOO3PFdQU5f2mGkKaP55p5Awd7Lhv+yDxP2OkdQ5iiwzs0 1Li9EoeWNbe53ynAbjeZPqUnas5IFayRr8biq/uU7B+lwdNxF2xKwkJ0yBZ6czIa ZZd/mv7/5ZOcSHFtYp7Ys+2cuABSQvJ2WYpkAPyThGTVJHQnC4WRxpwjbUbs2yZJ sGa9/5vQdtpgj5aGqXXX0DlG0mAqmHnmhgU+QhA/B3Zo0FWMpcTjqCdHbt+6tSzW HS2fZwrZ6nbixzzogBHsZyM0pZR9WY5QGqs6cqKi9L6e1LLTMFx1oqDFJOo3OTwp MHjIoh4/9WG9XrzuD2KX/Qmo+dtIQMCQR+WOFnYST4sKzDM9wMhg4hXGyb7G/O32 o0JBtPIsRZ68I7Ikrbmv =qARW -----END PGP SIGNATURE----- --Apple-Mail=_250CB2BF-9A02-4B70-9D05-2FEB14F412CE-- From nobody Fri May 20 03:46: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 D4E8412D554 for ; Fri, 20 May 2016 03:46:07 -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 9dzm8cajKVe6 for ; Fri, 20 May 2016 03:46:04 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id EABBD12D610 for ; Fri, 20 May 2016 03:46:01 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 7DE471A0170; Fri, 20 May 2016 12:46:00 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7D7CCD1F-8898-435E-A153-A605D81EB19D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <20160520022957.5697621.53774.85449@sandvine.com> Date: Fri, 20 May 2016 12:45:59 +0200 Message-Id: <3A7C1A99-FB42-4F1B-81EB-AFC5D19F4DE9@trammell.ch> References: <20160520022957.5697621.53774.85449@sandvine.com> To: Dave Dolson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Tom Herbert , Toerless Eckert , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 10:46:08 -0000 --Apple-Mail=_7D7CCD1F-8898-435E-A153-A605D81EB19D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Dave, > On 20 May 2016, at 04:29, Dave Dolson wrote: >=20 > Please also think about how a network operator can monitor how well = things are working, This is one of the aims of section 9 "In-band Measurement" of = draft-kuehlewind-spud-use-cases. > and how DDoS traffic may be discriminated from non-attack traffic. Good point; this is a bit harder in the general case. One feature of the = SPUD prototype, which we abstract out in section 6.6 "Protection against = trivial abuse" of draft-trammell-spud-req, also provided by = draft-herbert-udp-magic-numbers, is that by carefully designing the UDP = payload of an encapsulation layer, and making that encapsulation layer = reflection-resistent, you can make it easy to discriminate = reflection-amplification traffic from encapsulated traffic. > Today, > - TCP packet loss can be measured by observing sequence numbers ...and making some assumptions that usually hold, and being very careful = about where your observation point is located with respect to sender and = receiver, yes; > - round-trip times can be measured =E2=80=8Efrom TCP sequence/ack = numbers ...if you're not terribly concerned about accuracy (see [1]), but yes; > - non-attack traffic properly completes connections, whereas attack = traffic often does not ...an assumption which mostly holds, and will probably remain valid for = one class of attacks; > - some fair-queuing approaches apply fairness by TCP connections=E2=80=8E= > - ECMP and load-balancers try to make individual sessions follow a = single path ...the universal utility of both of which is questionable: it might be = nice to expose more information which would allow senders to indicate = better partitions of their traffic than "per-flow fairness", or to = indicate a future application/transport that has much better reordering = tolerance to make ECMP trunking irrelevant, both of which would be = potential applications for the type of think we're talking about in = PLUS. > If packets become completely opaque, I think =E2=80=8Ein general the = internet would operate less well. > It would be good for SPUD and QUIC =E2=80=8Eto provide enough = information for monitoring devices to measure progress, handshakes, = round-trip times, as can be done with TCP carrying TCP. This opinion led to the initial work here; I think we should have a = discussion about how opaque we can get while having everything still = work, where the ideal is "as opaque as possible while retaining = acceptable performance and operational manageability". Cheers, Brian [1] Ding and Rabinovich, "TCP Stretch Acknowledgements and Timestamps: = Findings and Implications for Passive RTT Measurement", ACM CCR July = 2015 > Original Message > From: Tom Herbert > Sent: Thursday, May 19, 2016 3:17 PM > To: Toerless Eckert > Cc: Brian Trammell; Scharf, Michael (Nokia - DE); spud@ietf.org > Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming = follow-on to SPUD BoF >=20 > On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert = wrote: >> Tom, Michael >>=20 >> I am reading your positions and i am confused: >>=20 >> DSCP is very successfull in enterprise networks. SPUD does not have = to >> be successfull "on the Internet". To me it would already be a great = success if it would >> help to improve controlled network services (like enterprise or 4G/5G = networks). And >> their transit traffic across the Internet (without changing anything = on the Internet >> itself). >>=20 > Yes, that is my point about localizing the problem. A client device > should know what network it's on an be able to signal to that network > to get the services it wants. A server on the other side of the planet > that the node is talking to really shouldn't be concerned with this > and not required to implement some complex protocol to accommodate it. >=20 >> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even = if we often think about >> them as per-flow and ould maybe like them to be restrict to per-flow. = At least i don't know >> any normative reference that defines them to be per-flow. >>=20 >> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the = analysis that all those >> mechanisms fail to provide an easily deplopyale framework in the face = of middleboxes. Aka: their >> presence and mostly non-success should be an argument FOR working on = spud. Not against it. >>=20 >> If a NAT/FW does support any flow signaling, its most likely inband. = Every NAT/firwall >> supports flow recognition via the explicit signaling of flow-based = transport protoocols >> like TCP. They do try to do the same for UDP and because that has no = explicit flow signaling, >> thats where the problem starts. NAT/FW do deep packet inspection = which has all these problems >> we know. SPUD sets out to solve/reduce these NAT/FW issues. >>=20 > There seems to be a lot of UDP going through NAT/FW today without any > sort of in-band signaling, and protocols like QUIC are already seeing > deployment without that (according to their slide deck "About half of > Google to Chrome"). Considering that there is no deployment of a SPUD > aware firewall and we can't want to wait for every device on the > Internet to upgrade, SPUD will have to work with NAT/FW as is or we > couldn't consider it. TBH I'm really having a hard time seeing that > any extra signaling is required in the Internet other than what is in > the IP header, at best it seems like an optimization for certain > networks or configurations. >=20 >> Non-support of anything like IP options is IMHO primarily driven by = the absence of >> unform cross-OS/Dev-language APIs for them. Yes. It may suck = architecturally by designing >> protocol stacks based on reality like: applications will only be able = to use UDP and TCP, >> so lets do new work on top of them, but to me the most important goal = is to find the best >> deployable solution to a problem. Not the architecturally cleanest = one. If you give me >> research money to work outside of reality i will happily take it = though and represent a >> different perspective. >>=20 >=20 > There has been a lot of discussion about this in v6ops, many networks > are simply dropping packets with extension headers. Please look at > draft-ietf-v6ops-ipv6-ehs-in-real-world-02 and > draft-gont-v6ops-ipv6-ehs-packet-drops-03. Because of this and the > fact that there hasn't been any interesting options defined worth > sending to date means that we (speaking for applications) have no use > to send them (btw all the major OSes support options AFAIK). If some > interesting options did come about, then we would probably apply a > happy eyeballs approach to deploy. >=20 > With something like SPUD (basically anything not simple TCP/IPv4) we > are always faced with the same problem that some networks on the > Internet may arbitrarily drop or otherwise restrict packets (we know > for instance that some network operators choose to severely rate limit > all UDP because of DOS concerns). So even if we do manage to start > deploying transport protocols over UDP we are going have TCP as a > fallback for indefinite future, i.e. more happy eyeballs. >=20 > Tom >=20 >> Please, i do not want to dismiss your opposition, i just don't = understand how the >> arguments you make are working out. Maybe you can explain to me where = i am going wrong >> in my interpretations above. >>=20 >> Cheers >> Toerless >>=20 >> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >>> wrote: >>>> Does the sentence ... >>>>=20 >>>> The current Internet protocol stack has no layer for explicit = signaling of flow semantics and characteristics to network elements ... >>>>=20 >>>> actually wants to say something like >>>>=20 >>>> The current Internet protocol stack has no layer for explicit = *in-band* signaling of flow semantics and characteristics ... ? >>>>=20 >>>> I may be wrong, but there is no shortage of IETF and non-IETF = protocols that can signal flow semantics and characteristics = out-of-band, either path-coupled or path-decoupled, e.g., in the control = or management plane. As a result, there are protocol "layers" for that = signaling, but they are not in-band. There may also be other ways to fix = this problem (e.g., by adding "end-to-end" or "inter-domain" instead of = "in-band"). >>>>=20 >>> Not to mention that TOS and diff-serv are in-band signaling = mechanisms >>> to the network, ECN is explicitly signaling from the network. Given >>> that they've been around for many years but have never been widely >>> deployed on the Internet makes me wonder if any in-band signaling >>> mechanism will ever catch on. The use of out of band signaling = should >>> be considered, especially considered that in many cases like NAT and >>> firewall the network elements that need signaling are likely in = local >>> networks of one side of the connection. >>>=20 >>> I have a similar concern about the statement that IP options/EH and >>> extension headers are being left off the table as part of a = solution. >>> The fact that neither have these caught on in the Internet and that >>> tells me two things 1) No IP option is needed for the Internet to >>> operate and be successful which makes me wonder if signaling between >>> network and hosts is even required 2) If the extensibility = mechanisms >>> of IP are chronically not deployable, I wonder why any alternative >>> that does not yet exist but intends to solve the same problem would = be >>> any more deployable. >>>=20 >>> Tom >>>=20 >>>> Michael >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On = Behalf Of Brian Trammell >>>> Sent: Thursday, May 19, 2016 5:07 PM >>>> To: stackevo-discuss@iab.org >>>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to = SPUD BoF >>>>=20 >>>> Greetings, all, >>>>=20 >>>> Forwarding this to the correct address for this mailing list = (oops). Please discuss at spud@ietf.org. >>>>=20 >>>> Thanks, cheers, >>>>=20 >>>> Brian >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> From: Brian Trammell >>>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>>> To: spud@ietf.org >>>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja = Kuehlewind >>>>> (IETF)" , Spencer Dawkins at IETF >>>>> >>>>>=20 >>>>> Greetings, all, >>>>>=20 >>>>> We propose to hold a working-group forming BoF in Berlin as a = follow-on to the SPUD work, to define a common substrate protocol for = encrypted transports based on the requirements derived from = experimentation with the SPUD prototype. >>>>>=20 >>>>> First, note that since the acronym "SPUD" refers primarily to the = prototype itself, any follow-on working group should have a different = name. We're using the derived requirements, not starting for the = prototype. The name is a subject for discussion, and suggestions are = welcome. To have something to put in the proposed charter, we'd propose = "Path Layer UDP Substrate" (PLUS) as a starting point. >>>>>=20 >>>>> The proposed charter appears below. We're interested in hearing = initial feedback on the proposed charter in preparation for a BoF = proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). = Is there work to do here within the IETF? Is the scope of the proposed = charter appropriate? Is there energy to do this work? >>>>>=20 >>>>> Thanks, cheers, >>>>>=20 >>>>> Brian and Mirja >>>>>=20 >>>>>=20 >>>>> Path Layer UDP Substrate (PLUS) >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> The PLUS working group???s goal is to enable the deployment of = new, >>>>> encrypted transport protocols, while providing a = transport-independent >>>>> method to signal flow semantics under transport and application = control. >>>>>=20 >>>>> The current Internet protocol stack has no layer for explicit >>>>> signaling of flow semantics and characteristics to network = elements, >>>>> nor an integrated signaling mechanism from network elements to = back to >>>>> endpoints and applications. This layer never evolved within the = stack, >>>>> because middleboxes and other devices on path could simply inspect = and >>>>> modify headers and payload of unencrypted traffic at every layer. = This >>>>> implicit use of information from the transport and application = layers >>>>> is a key origin of the ossification that makes it hard or = impossible to deploy new protocols. >>>>>=20 >>>>> In order to support more ubiquitous deployment of encryption, = explicit >>>>> signaling must be added to the stack, and it must be transport >>>>> protocol independent. 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. Additionally, 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. >>>>>=20 >>>>> The PLUS working group will specify a new protocol as a Path Layer >>>>> User Substrate (PLUS), to support experimental deployment of = explicit >>>>> cooperation between endpoints and devices on path, with the = following goals: >>>>>=20 >>>>> - enable ubiquitous deployment of encrypted higher layer protocols = by >>>>> providing exposure of similar semantics to existing protocols = (e.g. >>>>> TCP) to devices on path (e.g. NATs and firewalls) >>>>>=20 >>>>> - allow applications and transport protocols to explicitly provide >>>>> limited information to devices on path >>>>>=20 >>>>> - allow devices on path to provide feedback and information about = the >>>>> path to sending endpoints, under sending endpoint control >>>>>=20 >>>>> - allow devices on path to provide information about the path to >>>>> receiving endpoints, with feedback to the sending endpoint, under >>>>> sending endpoint control >>>>>=20 >>>>> Note that 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 >>>>> at the level of detail that is useful for the network, while >>>>> encrypting everything else. This is important to avoid future = implicit >>>>> treatment and the resulting ossification, as well as to leverage = the >>>>> principle of least exposure to minimize privacy risks presented by = explicit cooperation. >>>>>=20 >>>>> Given that the primary goal of PLUS is to enable the deployment of >>>>> arbitrary, fully encrypted transport protocols, 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. >>>>>=20 >>>>> 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 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 = these >>>>> use cases and requirements. The working group will close if it is = not >>>>> able to come to consensus on a protocol design to meet these = requirements. >>>>>=20 >>>>> The working group will additionally aim to identify other working >>>>> groups that could or should 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. TLS) which = could be >>>>> used for encryption of transport protocols running over PLUS. >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Spud mailing list >>>> Spud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spud >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>=20 >> -- >> --- >> Toerless Eckert, eckert@cisco.com >=20 > _______________________________________________ > 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 --Apple-Mail=_7D7CCD1F-8898-435E-A153-A605D81EB19D 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 iQIcBAEBCgAGBQJXPuroAAoJEIoSt78L6kajcKwQAMZ9hZN+5LtDLd/uv73IidPc 0NYRCY5DfrIPLV8eZwEICHfOycDVFtt9sifTl5qFIEq8NBppQBETqK6oopm+0gqs u/vcEKAs1SN+Vnohq33Tu15pl+KTUpLq/SNybn19Uyy93R9NBrw3yytB53cNC01/ 6SMZ9Sn6IDrtqtK4i25BCZNqDYun6q0/OUU20klf5RI5c+WvztLKmdSCiWlSx3O+ YQA3UcvVwWlsZQfcKo9Lt+BxywSCTy9Zt27vFMz3Fl29IfubAoRwUOmR4fpDqTrx YtIc1VSH89oLjNIiTMSiz4UFROJIhNUT2L1oQ99ya+tqk80HEev2ijMLC6y9TRNo vrWNV50nBOV2zCQXrfCIM7bI49nJ5Orbo0730lzk3FpeXP9ab1voEH0PEBfyTGSz ueYhS/dDwIf8HusjgqlOGuYMG7aMIjhMLKbo4HjUPOesuDEuWwCwwjZJagIOn77b PtjgbntEr7YwJZHu2L42VEKs/sl0zTnpVIggGJrQfxj3/BzIJGPucHn53bt0qkwT IEqpmjbWoCKnfwTF9S5o+nOtAYUpABukbnudYk2hGrV+KcsWc3VwQi1n7TMwVrhA PGZMSMjAoJYOMRC34qLA0Cf/PuoOFT8metKBoHgGrkRZOvIW9WpaBatJvlRWEKtw d/P2zDnl9gqJlYhxRKy8 =4xyx -----END PGP SIGNATURE----- --Apple-Mail=_7D7CCD1F-8898-435E-A153-A605D81EB19D-- From nobody Fri May 20 04:02: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 5EDA412D804 for ; Fri, 20 May 2016 04:02:04 -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 MMyyTrklsD9J for ; Fri, 20 May 2016 04:02:02 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 27F7D12D811 for ; Fri, 20 May 2016 04:02:02 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 6F8FA1A0B1D for ; Fri, 20 May 2016 13:02:01 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_9F9F95B6-CE77-4BC1-AB8E-0BC82CD3F220"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 20 May 2016 13:02:00 +0200 Message-Id: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "spud@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 11:02:04 -0000 --Apple-Mail=_9F9F95B6-CE77-4BC1-AB8E-0BC82CD3F220 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, all, I've heard one concrete charter suggestion so far; the edited draft = charter (changed paragraph 2) is below. If others would like to see = points clarified to answer their questions, please send suggested edits. = :) I take the fact that we're diving into technical discussion as an = indication that those participating are at least interested in the BoF, = if not (yet ;) ) convinced of the need for a WG at this space? Thanks, cheers, Brian Path Layer UDP Substrate (PLUS) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D The PLUS working group's goal is to enable the deployment of new, encrypted transport protocols, while providing a transport-independent method to signal flow semantics under transport and application control. The current Internet protocol stack has no layer for explicit, in-band signaling of flow semantics and characteristics to network elements in an interdomain context, nor an integrated signaling mechanism from network elements to back to endpoints and applications. This layer never evolved within the stack, because middleboxes and other devices on path could simply inspect and modify headers and payload of unencrypted traffic at every layer. This implicit use of information from the transport and application layers is a key cause of the ossification that makes it hard or impossible to deploy new protocols. In order to support more ubiquitous deployment of encryption, explicit signaling must be added to the stack, and it must be transport protocol independent. 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. Additionally, 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. The PLUS working group will specify a new protocol as a Path Layer User 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 similar semantics to existing protocols (e.g. TCP) to devices on path (e.g. NATs and firewalls) - allow applications and transport protocols to explicitly provide limited information to devices on path - allow devices on path to provide feedback and information about the path to sending endpoints, under sending endpoint control - allow devices on path to provide information about the path to receiving endpoints, with feedback to the sending endpoint, under sending endpoint control Note that 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 at the level of detail that is useful for the network, while encrypting everything else. This is important to avoid future implicit treatment and the resulting ossification, as well as to leverage the principle of least exposure to minimize privacy risks presented by explicit cooperation. Given that the primary goal of PLUS is to enable the deployment of arbitrary, fully encrypted transport protocols, 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 these use cases and requirements. 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 other working groups that could or should 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. TLS) which could be used for encryption of transport protocols running over PLUS. > On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) = wrote: >=20 > My comment is *only* that the sentence "The current Internet protocol = stack has no layer for explicit signaling of flow semantics and = characteristics to network elements" needs to be improved, in my = personal point of view. >=20 > For instance, for NAT/FW control, there are many existing out-of-band = protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, = etc., not to mention all the SDN protocols, which are typically all = flow-based. They are all out-of-band but e.g. NSIS would have been = end-to-end. The intention and deployment model of these protocols may be = very different to what SPUD aims for, and none of them is deployed = end-to-end in the Internet. But I think this sentence has to be slightly = more specific how to differentiate e.g. from control plane solutions. >=20 > Michael >=20 >=20 > -----Original Message----- > From: Toerless Eckert [mailto:eckert@cisco.com] > Sent: Thursday, May 19, 2016 8:27 PM > To: Tom Herbert > Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org > Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming = follow-on to SPUD BoF >=20 > Tom, Michael >=20 > I am reading your positions and i am confused: >=20 > DSCP is very successfull in enterprise networks. SPUD does not have to = be successfull "on the Internet". To me it would already be a great = success if it would help to improve controlled network services (like = enterprise or 4G/5G networks). And their transit traffic across the = Internet (without changing anything on the Internet itself). >=20 > AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even = if we often think about them as per-flow and ould maybe like them to be = restrict to per-flow. At least i don't know any normative reference that = defines them to be per-flow. >=20 > Wrt to out-of-band/out-of-path: The whole reason for SPUD is the = analysis that all those mechanisms fail to provide an easily deplopyale = framework in the face of middleboxes. Aka: their presence and mostly = non-success should be an argument FOR working on spud. Not against it. >=20 > If a NAT/FW does support any flow signaling, its most likely inband. = Every NAT/firwall supports flow recognition via the explicit signaling = of flow-based transport protoocols like TCP. They do try to do the same = for UDP and because that has no explicit flow signaling, thats where the = problem starts. NAT/FW do deep packet inspection which has all these = problems we know. SPUD sets out to solve/reduce these NAT/FW issues. >=20 > Non-support of anything like IP options is IMHO primarily driven by = the absence of unform cross-OS/Dev-language APIs for them. Yes. It may = suck architecturally by designing protocol stacks based on reality like: = applications will only be able to use UDP and TCP, so lets do new work = on top of them, but to me the most important goal is to find the best = deployable solution to a problem. Not the architecturally cleanest one. = If you give me research money to work outside of reality i will happily = take it though and represent a different perspective. >=20 > Please, i do not want to dismiss your opposition, i just don't = understand how the arguments you make are working out. Maybe you can = explain to me where i am going wrong in my interpretations above. >=20 > Cheers > Toerless >=20 > On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >> wrote: >>> Does the sentence ... >>>=20 >>> The current Internet protocol stack has no layer for explicit = signaling of flow semantics and characteristics to network elements ... >>>=20 >>> actually wants to say something like >>>=20 >>> The current Internet protocol stack has no layer for explicit = *in-band* signaling of flow semantics and characteristics ... ? >>>=20 >>> I may be wrong, but there is no shortage of IETF and non-IETF = protocols that can signal flow semantics and characteristics = out-of-band, either path-coupled or path-decoupled, e.g., in the control = or management plane. As a result, there are protocol "layers" for that = signaling, but they are not in-band. There may also be other ways to fix = this problem (e.g., by adding "end-to-end" or "inter-domain" instead of = "in-band"). >>>=20 >> Not to mention that TOS and diff-serv are in-band signaling = mechanisms >> to the network, ECN is explicitly signaling from the network. Given >> that they've been around for many years but have never been widely >> deployed on the Internet makes me wonder if any in-band signaling >> mechanism will ever catch on. The use of out of band signaling should >> be considered, especially considered that in many cases like NAT and >> firewall the network elements that need signaling are likely in local >> networks of one side of the connection. >>=20 >> I have a similar concern about the statement that IP options/EH and >> extension headers are being left off the table as part of a solution. >> The fact that neither have these caught on in the Internet and that >> tells me two things 1) No IP option is needed for the Internet to >> operate and be successful which makes me wonder if signaling between >> network and hosts is even required 2) If the extensibility mechanisms >> of IP are chronically not deployable, I wonder why any alternative >> that does not yet exist but intends to solve the same problem would = be >> any more deployable. >>=20 >> Tom >>=20 >>> Michael >>>=20 >>>=20 >>> -----Original Message----- >>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On >>> Behalf Of Brian Trammell >>> Sent: Thursday, May 19, 2016 5:07 PM >>> To: stackevo-discuss@iab.org >>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to >>> SPUD BoF >>>=20 >>> Greetings, all, >>>=20 >>> Forwarding this to the correct address for this mailing list (oops). = Please discuss at spud@ietf.org. >>>=20 >>> Thanks, cheers, >>>=20 >>> Brian >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> From: Brian Trammell >>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>> To: spud@ietf.org >>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >>>> (IETF)" , Spencer Dawkins at IETF >>>> >>>>=20 >>>> Greetings, all, >>>>=20 >>>> We propose to hold a working-group forming BoF in Berlin as a = follow-on to the SPUD work, to define a common substrate protocol for = encrypted transports based on the requirements derived from = experimentation with the SPUD prototype. >>>>=20 >>>> First, note that since the acronym "SPUD" refers primarily to the = prototype itself, any follow-on working group should have a different = name. We're using the derived requirements, not starting for the = prototype. The name is a subject for discussion, and suggestions are = welcome. To have something to put in the proposed charter, we'd propose = "Path Layer UDP Substrate" (PLUS) as a starting point. >>>>=20 >>>> The proposed charter appears below. We're interested in hearing = initial feedback on the proposed charter in preparation for a BoF = proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). = Is there work to do here within the IETF? Is the scope of the proposed = charter appropriate? Is there energy to do this work? >>>>=20 >>>> Thanks, cheers, >>>>=20 >>>> Brian and Mirja >>>>=20 >>>>=20 >>>> Path Layer UDP Substrate (PLUS) >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> The PLUS working group???s goal is to enable the deployment of new, >>>> encrypted transport protocols, while providing a >>>> transport-independent method to signal flow semantics under = transport and application control. >>>>=20 >>>> The current Internet protocol stack has no layer for explicit >>>> signaling of flow semantics and characteristics to network >>>> elements, nor an integrated signaling mechanism from network >>>> elements to back to endpoints and applications. This layer never >>>> evolved within the stack, because middleboxes and other devices on >>>> path could simply inspect and modify headers and payload of >>>> unencrypted traffic at every layer. This implicit use of >>>> information from the transport and application layers is a key = origin of the ossification that makes it hard or impossible to deploy = new protocols. >>>>=20 >>>> In order to support more ubiquitous deployment of encryption, >>>> explicit signaling must be added to the stack, and it must be >>>> transport protocol independent. 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. >>>> Additionally, 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. >>>>=20 >>>> The PLUS working group will specify a new protocol as a Path Layer >>>> User Substrate (PLUS), to support experimental deployment of >>>> explicit cooperation between endpoints and devices on path, with = the following goals: >>>>=20 >>>> - enable ubiquitous deployment of encrypted higher layer protocols >>>> by providing exposure of similar semantics to existing protocols = (e.g. >>>> TCP) to devices on path (e.g. NATs and firewalls) >>>>=20 >>>> - allow applications and transport protocols to explicitly provide >>>> limited information to devices on path >>>>=20 >>>> - allow devices on path to provide feedback and information about >>>> the path to sending endpoints, under sending endpoint control >>>>=20 >>>> - allow devices on path to provide information about the path to >>>> receiving endpoints, with feedback to the sending endpoint, under >>>> sending endpoint control >>>>=20 >>>> Note that 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 at the level of detail that is useful for the network, >>>> while encrypting everything else. This is important to avoid future >>>> implicit treatment and the resulting ossification, as well as to >>>> leverage the principle of least exposure to minimize privacy risks = presented by explicit cooperation. >>>>=20 >>>> Given that the primary goal of PLUS is to enable the deployment of >>>> arbitrary, fully encrypted transport protocols, 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. >>>>=20 >>>> 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 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 >>>> these use cases and requirements. The working group will close if >>>> it is not able to come to consensus on a protocol design to meet = these requirements. >>>>=20 >>>> The working group will additionally aim to identify other working >>>> groups that could or should 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. >>>> TLS) which could be used for encryption of transport protocols = running over PLUS. >>>>=20 >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >=20 > -- > --- > Toerless Eckert, eckert@cisco.com --Apple-Mail=_9F9F95B6-CE77-4BC1-AB8E-0BC82CD3F220 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 iQIcBAEBCgAGBQJXPu6pAAoJEIoSt78L6kajCNsQAKQOV5JIcZKhfzQET4mR9khy bi6tzsos5W5Prpxv8AREKl+MtTTBRepd2Tkb9k+NhnmpXVHCz6hi7dQtfKBtFTnK G8QkKy1un3Mot8whrL+TFj15z786bwZouPiQ/2tl9RRm8Zbjy5unIyEfk7o8YhkR bxRHCKcpHhcsGhVkEfhBshsrP/QMhksxfy5kTxToVuR+19R0NenMPfYLmxKEdZli X0b50VAd7DhMeYSNlVvfp1XG3Ye3WmnaLnewtmA6riGg3UcCJmUbWOcADFS91HqQ u0vLh0AWPZKEUBB5xr6Zq9WQEyMnnKzfj/88qmIoVGxBD0hIUFShbUlSF3J79Y0U X6cmcjp7LRG3+8cpOygtQD88gSPNUlzE7x1VA5/GZ86ql8DhbdByRoN3h73bFyLX VOAUpgD20LyV+itwrVpodf+iH/HE1GIGLe36ZHsfsGinQBqv39/FNZ8w6gqfp6qc 6aGB5JfGPBFFm+imU2heiwHLsYiUaCpFu6ce9E0zYlpThdGuz3Yvs8a8P+msJGmV 3/FeaENMdDctJrfBwe8NKrCk+TrzW2gaLRgc2EmoMx1j0CW9YQWj2wfTlMNvj/AL AWoxkBaXNPCH3KTalgbfd51wAI3QmiaV4NW78BZbkdHq+c/6cvknQxOUMTgG3SCX U1AqG0tjX98e6c4P9L/S =Pius -----END PGP SIGNATURE----- --Apple-Mail=_9F9F95B6-CE77-4BC1-AB8E-0BC82CD3F220-- From nobody Fri May 20 04:16: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 2010012D837 for ; Fri, 20 May 2016 04:16:02 -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 0rAJN4LUYgIp for ; Fri, 20 May 2016 04:16:00 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 033B612D79D for ; Fri, 20 May 2016 04:16:00 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 229A31A0A20; Fri, 20 May 2016 13:15:29 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C7F3E014-79FE-4CB9-A923-7B384F0EEB76"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Fri, 20 May 2016 13:15:28 +0200 Message-Id: <2BDF2B03-386E-4942-945C-D0C5AA20B2C5@trammell.ch> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> To: Michael Welzl X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Tom Herbert , Ca By , spud , Toerless Eckert , Joe Touch Subject: Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 11:16:02 -0000 --Apple-Mail=_C7F3E014-79FE-4CB9-A923-7B384F0EEB76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Michael, > On 20 May 2016, at 09:33, Michael Welzl wrote: >=20 > BRAAAAAAA TOOOOOOOOOOOOOTTT TOOOOOOOOOOT BRRRAAAAA TOOOOOOOOOOOTT = !!!!! >=20 > This was the ugly sound of me blowing my own horn. I just have to do = this, I can't resist: >=20 >>> 2) udp is blocked in many places, so thinga like quic fall back to = tcp. >>>=20 >> Yes, that is a given. Anything new we deploy on the Internet, be it >> IPv6, SCTP, UDP, TFO, extension headers will necessitate fallback to >> least common denominator like simple TCP/IP. >=20 > ....... this is so true, and this is happening so little for = transports because applications are tied to the protocol (or at least = can't use features of protocols other than TCP or UDP, even with = higher-level APIs), and this is why the TAPS WG is so important. >=20 > TAPS needs more activity I think... Agree completely; I think one of the things that will drive *that* is = more diversity of transports to choose from. Cheers, Brian --Apple-Mail=_C7F3E014-79FE-4CB9-A923-7B384F0EEB76 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 iQIcBAEBCgAGBQJXPvHQAAoJEIoSt78L6kaj2c4QAJOrd2U62dYlxr+LMnqavazl yqVYwJSISwESPuZWQDIlbEycUAacVsK1iSBFs2i4mbpxG0qS8Oq7EZ+k1CE3DkGK 7pLW3PLTHkf3p60/vkZRFYNQgzMj8FaKNiRnbZeSPFMmANryBo3yuzVEIYHCl73p PZN3rnTImXVa7nQWBMqu8/eieyGLdd4+G7Cl3e6hGf53U2HB9dQe8N1uFz7TqCD4 uBNC7GzzmTNy1jOd++LeY+1oY/N5TFgTbV7W5ZwJEoCp/Rxfq8t7nsoMuN9KfSyP 26m/hykD47nKpKtI3zpbJ5pnugXyBDCtYmPJeBi4XEJ0TLyq7x36vYuvCZaNcRNf ZfzYN2Wi+f/ORnySSVEdz457ASyncZAg/LVWBjHJ50fkhaweDNNj6ZKXw6olSjQL ADihkJOsxbErweyZDzu7SCoJGPy2LI/j5p9fuMc4+hFQlBIPZNSqQmDedGBPmDGu P5IdxDyeEnJvCVhC7YsHxGax9v0WrWr8fAD1iLusvNnyjV30r6pv1tMpVNrMIcDy va2v0loHkzJ+xe+5JirLKtCPg1nhNDaUKLyIcsdUbngJiI0n0JXJiW1qbZBZ80/T CglNYOT0E2zb23BPBtL5sPzKaYpbkgrD1l/KTNTzWKrr8xV4HYqUaTxFHwDD4DIs 2bGcxg1UWtp9F6xZOiRU =+vSR -----END PGP SIGNATURE----- --Apple-Mail=_C7F3E014-79FE-4CB9-A923-7B384F0EEB76-- From nobody Fri May 20 04:23: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 918A112D850 for ; Fri, 20 May 2016 04:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 RGMo3qo-h9VI for ; Fri, 20 May 2016 04:23: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 95BBD12D863 for ; Fri, 20 May 2016 04:23:48 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Fri, 20 May 2016 07:23:46 -0400 From: Dave Dolson To: Brian Trammell , "spud@ietf.org" Thread-Topic: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF Thread-Index: AQHRsfbuJ2cvNkb2DUuyKJNQQWe2WZ/A1zKAgAAIQQCAAQ29AP//wwiY Date: Fri, 20 May 2016 11:23:46 +0000 Message-ID: <20160520112345.5697621.10376.85507@sandvine.com> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 11:23:55 -0000 Brian, I see no explicit mention of congestion avoidance or requirements on the se= nder to back off under congestion. Arguably it is implicit; does it deserve mention in the charter? (one of the hazards of placing control in the application is having varying= ideas about how to do this, which won't compete fairly with each other. Fi= guring out how to deal with cheaters is another thing...) -Dave Original Message From: Brian Trammell Sent: Friday, May 20, 2016 7:02 AM To: spud@ietf.org Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on t= o SPUD BoF Hi, all, I've heard one concrete charter suggestion so far; the edited draft charter= (changed paragraph 2) is below. If others would like to see points clarifi= ed to answer their questions, please send suggested edits. :) I take the fact that we're diving into technical discussion as an indicatio= n that those participating are at least interested in the BoF, if not (yet = ;) ) convinced of the need for a WG at this space? Thanks, cheers, Brian Path Layer UDP Substrate (PLUS) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D The PLUS working group's goal is to enable the deployment of new, encrypted transport protocols, while providing a transport-independent method to signal flow semantics under transport and application control. The current Internet protocol stack has no layer for explicit, in-band signaling of flow semantics and characteristics to network elements in an interdomain context, nor an integrated signaling mechanism from network elements to back to endpoints and applications. This layer never evolved within the stack, because middleboxes and other devices on path could simply inspect and modify headers and payload of unencrypted traffic at every layer. This implicit use of information from the transport and application layers is a key cause of the ossification that makes it hard or impossible to deploy new protocols. In order to support more ubiquitous deployment of encryption, explicit signaling must be added to the stack, and it must be transport protocol independent. 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. Additionally, 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. The PLUS working group will specify a new protocol as a Path Layer User Substrate (PLUS), to support experimental deployment of explicit cooperation between endpoints and devices on path, with the follow= ing goals: - enable ubiquitous deployment of encrypted higher layer protocols by providing exposure of similar semantics to existing protocols (e.g. TCP) to devices on path (e.g. NATs and firewalls) - allow applications and transport protocols to explicitly provide limited information to devices on path - allow devices on path to provide feedback and information about the path to sending endpoints, under sending endpoint control - allow devices on path to provide information about the path to receiving endpoints, with feedback to the sending endpoint, under sending endpoint control Note that 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 at the level of detail that is useful for the network, while encrypting everything else. This is important to avoid future implicit treatment and the resulting ossification, as well as to leverage the principle of least exposure to minimize privacy risks presented by explicit cooperation. Given that the primary goal of PLUS is to enable the deployment of arbitrary, fully encrypted transport protocols, 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 modification= s. 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 these use cases and requirements. 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 other working groups that could or should 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. TLS) which could be used for encryption of transport protocols running over PLUS. > On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) wrote: > > My comment is *only* that the sentence "The current Internet protocol sta= ck has no layer for explicit signaling of flow semantics and characteristic= s to network elements" needs to be improved, in my personal point of view. > > For instance, for NAT/FW control, there are many existing out-of-band pro= tocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, etc., not= to mention all the SDN protocols, which are typically all flow-based. They= are all out-of-band but e.g. NSIS would have been end-to-end. The intentio= n and deployment model of these protocols may be very different to what SPU= D aims for, and none of them is deployed end-to-end in the Internet. But I = think this sentence has to be slightly more specific how to differentiate e= .g. from control plane solutions. > > Michael > > > -----Original Message----- > From: Toerless Eckert [mailto:eckert@cisco.com] > Sent: Thursday, May 19, 2016 8:27 PM > To: Tom Herbert > Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org > Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on= to SPUD BoF > > Tom, Michael > > I am reading your positions and i am confused: > > DSCP is very successfull in enterprise networks. SPUD does not have to be= successfull "on the Internet". To me it would already be a great success i= f it would help to improve controlled network services (like enterprise or = 4G/5G networks). And their transit traffic across the Internet (without cha= nging anything on the Internet itself). > > AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if = we often think about them as per-flow and ould maybe like them to be restri= ct to per-flow. At least i don't know any normative reference that defines = them to be per-flow. > > Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis= that all those mechanisms fail to provide an easily deplopyale framework i= n the face of middleboxes. Aka: their presence and mostly non-success shoul= d be an argument FOR working on spud. Not against it. > > If a NAT/FW does support any flow signaling, its most likely inband. Ever= y NAT/firwall supports flow recognition via the explicit signaling of flow-= based transport protoocols like TCP. They do try to do the same for UDP and= because that has no explicit flow signaling, thats where the problem start= s. NAT/FW do deep packet inspection which has all these problems we know. S= PUD sets out to solve/reduce these NAT/FW issues. > > Non-support of anything like IP options is IMHO primarily driven by the a= bsence of unform cross-OS/Dev-language APIs for them. Yes. It may suck arch= itecturally by designing protocol stacks based on reality like: application= s will only be able to use UDP and TCP, so lets do new work on top of them,= but to me the most important goal is to find the best deployable solution = to a problem. Not the architecturally cleanest one. If you give me research= money to work outside of reality i will happily take it though and represe= nt a different perspective. > > Please, i do not want to dismiss your opposition, i just don't understand= how the arguments you make are working out. Maybe you can explain to me wh= ere i am going wrong in my interpretations above. > > Cheers > Toerless > > On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >> wrote: >>> Does the sentence ... >>> >>> The current Internet protocol stack has no layer for explicit signalin= g of flow semantics and characteristics to network elements ... >>> >>> actually wants to say something like >>> >>> The current Internet protocol stack has no layer for explicit *in-band= * signaling of flow semantics and characteristics ... ? >>> >>> I may be wrong, but there is no shortage of IETF and non-IETF protocols= that can signal flow semantics and characteristics out-of-band, either pat= h-coupled or path-decoupled, e.g., in the control or management plane. As a= result, there are protocol "layers" for that signaling, but they are not i= n-band. There may also be other ways to fix this problem (e.g., by adding "= end-to-end" or "inter-domain" instead of "in-band"). >>> >> Not to mention that TOS and diff-serv are in-band signaling mechanisms >> to the network, ECN is explicitly signaling from the network. Given >> that they've been around for many years but have never been widely >> deployed on the Internet makes me wonder if any in-band signaling >> mechanism will ever catch on. The use of out of band signaling should >> be considered, especially considered that in many cases like NAT and >> firewall the network elements that need signaling are likely in local >> networks of one side of the connection. >> >> I have a similar concern about the statement that IP options/EH and >> extension headers are being left off the table as part of a solution. >> The fact that neither have these caught on in the Internet and that >> tells me two things 1) No IP option is needed for the Internet to >> operate and be successful which makes me wonder if signaling between >> network and hosts is even required 2) If the extensibility mechanisms >> of IP are chronically not deployable, I wonder why any alternative >> that does not yet exist but intends to solve the same problem would be >> any more deployable. >> >> Tom >> >>> Michael >>> >>> >>> -----Original Message----- >>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On >>> Behalf Of Brian Trammell >>> Sent: Thursday, May 19, 2016 5:07 PM >>> To: stackevo-discuss@iab.org >>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to >>> SPUD BoF >>> >>> Greetings, all, >>> >>> Forwarding this to the correct address for this mailing list (oops). Pl= ease discuss at spud@ietf.org. >>> >>> Thanks, cheers, >>> >>> Brian >>> >>>> Begin forwarded message: >>>> >>>> From: Brian Trammell >>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>> To: spud@ietf.org >>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >>>> (IETF)" , Spencer Dawkins at IETF >>>> >>>> >>>> Greetings, all, >>>> >>>> We propose to hold a working-group forming BoF in Berlin as a follow-o= n to the SPUD work, to define a common substrate protocol for encrypted tra= nsports based on the requirements derived from experimentation with the SPU= D prototype. >>>> >>>> First, note that since the acronym "SPUD" refers primarily to the prot= otype itself, any follow-on working group should have a different name. We'= re using the derived requirements, not starting for the prototype. The name= is a subject for discussion, and suggestions are welcome. To have somethin= g to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (= PLUS) as a starting point. >>>> >>>> The proposed charter appears below. We're interested in hearing initia= l feedback on the proposed charter in preparation for a BoF proposal (the c= utoff date is two weeks from tomorrow, on Friday 3 June). Is there work to = do here within the IETF? Is the scope of the proposed charter appropriate? = Is there energy to do this work? >>>> >>>> Thanks, cheers, >>>> >>>> Brian and Mirja >>>> >>>> >>>> Path Layer UDP Substrate (PLUS) >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> The PLUS working group???s goal is to enable the deployment of new, >>>> encrypted transport protocols, while providing a >>>> transport-independent method to signal flow semantics under transport = and application control. >>>> >>>> The current Internet protocol stack has no layer for explicit >>>> signaling of flow semantics and characteristics to network >>>> elements, nor an integrated signaling mechanism from network >>>> elements to back to endpoints and applications. This layer never >>>> evolved within the stack, because middleboxes and other devices on >>>> path could simply inspect and modify headers and payload of >>>> unencrypted traffic at every layer. This implicit use of >>>> information from the transport and application layers is a key origin = of the ossification that makes it hard or impossible to deploy new protocol= s. >>>> >>>> In order to support more ubiquitous deployment of encryption, >>>> explicit signaling must be added to the stack, and it must be >>>> transport protocol independent. 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. >>>> Additionally, 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 c= ooperation approach. >>>> >>>> The PLUS working group will specify a new protocol as a Path Layer >>>> User Substrate (PLUS), to support experimental deployment of >>>> explicit cooperation between endpoints and devices on path, with the f= ollowing goals: >>>> >>>> - enable ubiquitous deployment of encrypted higher layer protocols >>>> by providing exposure of similar semantics to existing protocols (e.g. >>>> TCP) to devices on path (e.g. NATs and firewalls) >>>> >>>> - allow applications and transport protocols to explicitly provide >>>> limited information to devices on path >>>> >>>> - allow devices on path to provide feedback and information about >>>> the path to sending endpoints, under sending endpoint control >>>> >>>> - allow devices on path to provide information about the path to >>>> receiving endpoints, with feedback to the sending endpoint, under >>>> sending endpoint control >>>> >>>> Note that 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 at the level of detail that is useful for the network, >>>> while encrypting everything else. This is important to avoid future >>>> implicit treatment and the resulting ossification, as well as to >>>> leverage the principle of least exposure to minimize privacy risks pre= sented by explicit cooperation. >>>> >>>> Given that the primary goal of PLUS is to enable the deployment of >>>> arbitrary, fully encrypted transport protocols, 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 modific= ations. >>>> >>>> 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 Pro= tocol for User Datagrams 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 >>>> these use cases and requirements. 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 other working >>>> groups that could or should 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. >>>> TLS) which could be used for encryption of transport protocols running= over 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 > > -- > --- > Toerless Eckert, eckert@cisco.com From nobody Fri May 20 05:19:11 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 DCA1412D8F7 for ; Fri, 20 May 2016 05:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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.426, SPF_PASS=-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 HPQKHzzmrzPj for ; Fri, 20 May 2016 05:19:08 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6977B12D8F3 for ; Fri, 20 May 2016 05:19:08 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id f8so10977505ioe.3 for ; Fri, 20 May 2016 05:19: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=VfoUkby7nUmqrpCLHAbT2pgDK9Nc1gQcI8DeBaszh5k=; b=Kk5O1AdXSJlUp9RhpFb0RzNJfUAshmc3QevvaO+dBo8s84Oha46VVXQF5/Hp3xz2c0 Mw5Xjg+AZHcJ58W8P0lf/jS+NmK+297ictXGYFjbcQ+o6TjjmBAYkVfeq3xw2A1/T7i5 C2cuCEqL3YMTVlTk0kjZ74MUAvbRI5H4LXdaVj6delbkLulJchVCSYjYQJn6FpJ71yz8 xTSvtjVotCYOPq22HCSMzHAYQOWqPG7vgTcvb06Xmr9DtkZvMEc06sibt9/NNCo3xaGr uGn9anLUCiVsUUrHd+G2NhP+tpTntSl21kNdj3Es9u8nva6F8KOJgoXKi+56OmlWUneh /J+A== 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=VfoUkby7nUmqrpCLHAbT2pgDK9Nc1gQcI8DeBaszh5k=; b=kreJXK/x+PwsAxJ0t8RxigTrXttMEe7/uAh44Wm7TepmTNQolwyteGKI/+H1nBeFmJ 1e/XHgigIU3ef6ZsNTPOEiT3Vv/2fwhf9co21mwY0THtvNh0AAoYrVupL3STEZsoCS1u b7s0R/EhYxEYnKgcz2H7+hAHRFxV/kElt+5S56k+kacKLPn/MrWQc2WE6H1kx52Dxybs AHqfuoA6VBhyo97Eyf1II2kah6opwAopcvM9efoOPf+w/5NugHg6Qn563u6o4Wa+io8A +2tdWnoKaGu2vUyOeavViX7Msgs4bJYyQJKpjHCawX5N4nebModkooKRdqDJjxnFQLOw UGQg== X-Gm-Message-State: AOPr4FULEIpUdnLjmOTjcRX4ttif+gftMP+pQoPm5bESANxk0KyOWueOelrFvosL+W0N3P5W8LxTZ7z4lLOZhvID X-Received: by 10.107.59.70 with SMTP id i67mr2632685ioa.33.1463746747475; Fri, 20 May 2016 05:19:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.227.227 with HTTP; Fri, 20 May 2016 05:18:47 -0700 (PDT) In-Reply-To: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> From: Ian Swett Date: Fri, 20 May 2016 08:18:47 -0400 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=94eb2c0633e8ed1c3d0533451824 Archived-At: Cc: Tom Herbert , Toerless Eckert , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 12:19:11 -0000 --94eb2c0633e8ed1c3d0533451824 Content-Type: text/plain; charset=UTF-8 On Fri, May 20, 2016 at 6:32 AM, Brian Trammell wrote: > > > On 19 May 2016, at 21:17, Tom Herbert wrote: > > > > On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert > wrote: > >> > >> If a NAT/FW does support any flow signaling, its most likely inband. > Every NAT/firwall > >> supports flow recognition via the explicit signaling of flow-based > transport protoocols > >> like TCP. They do try to do the same for UDP and because that has no > explicit flow signaling, > >> thats where the problem starts. NAT/FW do deep packet inspection which > has all these problems > >> we know. SPUD sets out to solve/reduce these NAT/FW issues. > >> > > There seems to be a lot of UDP going through NAT/FW today without any > > sort of in-band signaling, and protocols like QUIC are already seeing > > deployment without that (according to their slide deck "About half of > > Google to Chrome"). Considering that there is no deployment of a SPUD > > aware firewall and we can't want to wait for every device on the > > Internet to upgrade, SPUD will have to work with NAT/FW as is or we > > couldn't consider it. TBH I'm really having a hard time seeing that > > any extra signaling is required in the Internet other than what is in > > the IP header, at best it seems like an optimization for certain > > networks or configurations. > > There's a couple of problems here which could (IMO should) be handled > better in a transport protocol independent way: > > (1) Generic indication of flow start/end. Firewalls use TCP semantics, for > the most part, and new protocols should expose at least these to get better > treatment. Yes, this would have most of the same problems than SYNs, RSTs, > and FINs do in TCP right now, but we can do better than the status quo. One > of the things we looked at with the SPUD header is using a tube ID in a > sparse identifier space to at least provide better protection against > RST/FIN with guessed sequence numbers (which outside BGP is still a threat > to deployed TCP, see [1]). > > (2) Indication of NAT/FW state timeout and timeout expectation, to > minimize unproductive keepalive traffic. Even with generic flow state > indication you still need timers, and always will, but exposing information > makes the average case performance better. > > We could consider adding these as key use cases in the protocol, but I > still think we want to have the broader use case discussion within any > eventual PLUS WG. > > If we *don't* care about the general deployability of new transport > protocols, if we think that QUIC is the Last Transport We'll Ever Need > (i.e., what SCTP was supposed to be), then we can just make sure QUIC > exposes enough to make this possible, and go home. While QUIC is a definite > improvement for the application semantics it's meant to support, and a > widely deployable SCTP would be a improvement for other media applications, > I'm not convinced that The Last Transport We'll Ever Need is a thing that > exists, or that we should want to exist. > I think QUIC is great, but it's certainly not "The Last Transport We'll Ever Need.". I don't think such a thing exists. > > >> Non-support of anything like IP options is IMHO primarily driven by the > absence of > >> unform cross-OS/Dev-language APIs for them. Yes. It may suck > architecturally by designing > >> protocol stacks based on reality like: applications will only be able > to use UDP and TCP, > >> so lets do new work on top of them, but to me the most important goal > is to find the best > >> deployable solution to a problem. Not the architecturally cleanest one. > If you give me > >> research money to work outside of reality i will happily take it though > and represent a > >> different perspective. > >> > > > > There has been a lot of discussion about this in v6ops, many networks > > are simply dropping packets with extension headers. Please look at > > draft-ietf-v6ops-ipv6-ehs-in-real-world-02 and > > draft-gont-v6ops-ipv6-ehs-packet-drops-03. Because of this and the > > fact that there hasn't been any interesting options defined worth > > sending to date means that we (speaking for applications) have no use > > to send them (btw all the major OSes support options AFAIK). If some > > interesting options did come about, then we would probably apply a > > happy eyeballs approach to deploy. > > There's an additional problem in that the way v6 EH are defined makes it > difficult to handle them on path: building silicon to handle arbitrary > header chains is expensive. So one of the functional requirements for PLUS > should be "information that forwarding devices need to see needs to > (usually) to be not very far into the packet, at a constate offset if > possible; see [2]. > > > With something like SPUD (basically anything not simple TCP/IPv4) we > > are always faced with the same problem that some networks on the > > Internet may arbitrarily drop or otherwise restrict packets (we know > > for instance that some network operators choose to severely rate limit > > all UDP because of DOS concerns). So even if we do manage to start > > deploying transport protocols over UDP we are going have TCP as a > > fallback for indefinite future, i.e. more happy eyeballs. > > Yes, and if we do manage to start deploying transport protocols over IPv6, > we are going to have IPv4 fallback for an indefinite future. I share your > concern about happy eyeballs state explosion (a phenomenon we refer to > around the office as "angry eyeballs" -> eight orthogonal network/transport > layer choices to test at startup means that every flow begins with a 256 > packet burst)... but the benefit of doing this to transport flexibility is > potentially worth the cost, which is the fundamental question we want to > address in PLUS. > > Cheers, > > Brian > > [1] Luckie et al "Resilience of Deployed TCP to Blind Attacks", IMC 2015, > http://conferences.sigcomm.org/imc/2015/papers/p13.pdf > > [2] Scudder "How a router actually works" IEPG at IETF 94, > http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > > --94eb2c0633e8ed1c3d0533451824 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, May 20, 2016 at 6:32 AM, Brian Trammell <ietf@trammell.ch> wrote:

> On 19 May 2016, at 21:17, Tom Herbert <tom@herbertland.com> wrote:
>
> On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert <eckert@cisco.com> wrote:
>>
>> If a NAT/FW does support any flow signalin= g, its most likely inband. Every NAT/firwall
>> supports flow recognition via the explicit signaling of flow-based= transport protoocols
>> like TCP. They do try to do the same for UDP and because that has = no explicit flow signaling,
>> thats where the problem starts. NAT/FW do deep packet inspection w= hich has all these problems
>> we know. SPUD sets out to solve/reduce these NAT/FW issues.
>>
> There seems to be a lot of UDP going through NAT/FW today without any<= br> > sort of in-band signaling, and protocols like QUIC are already seeing<= br> > deployment without that (according to their slide deck "About hal= f of
> Google to Chrome"). Considering that there is no deployment of a = SPUD
> aware firewall and we can't want to wait for every device on the > Internet to upgrade, SPUD will have to work with NAT/FW as is or we > couldn't consider it. TBH I'm really having a hard time seeing= that
> any extra signaling is required in the Internet other than what is in<= br> > the IP header, at best it seems like an optimization for certain
> networks or configurations.

There's a couple of problems here which could (IMO should) be ha= ndled better in a transport protocol independent way:

(1) Generic indication of flow start/end. Firewalls use TCP semantics, for = the most part, and new protocols should expose at least these to get better= treatment. Yes, this would have most of the same problems than SYNs, RSTs,= and FINs do in TCP right now, but we can do better than the status quo. On= e of the things we looked at with the SPUD header is using a tube ID in a s= parse identifier space to at least provide better protection against RST/FI= N with guessed sequence numbers (which outside BGP is still a threat to dep= loyed TCP, see [1]).

(2) Indication of NAT/FW state timeout and timeout expectation, to minimize= unproductive keepalive traffic. Even with generic flow state indication yo= u still need timers, and always will, but exposing information makes the av= erage case performance better.

We could consider adding these as key use cases in the protocol, but I stil= l think we want to have the broader use case discussion within any eventual= PLUS WG.

If we *don't* care about the general deployability of new transport pro= tocols, if we think that QUIC is the Last Transport We'll Ever Need (i.= e., what SCTP was supposed to be), then we can just make sure QUIC exposes = enough to make this possible, and go home. While QUIC is a definite improve= ment for the application semantics it's meant to support, and a widely = deployable SCTP would be a improvement for other media applications, I'= m not convinced that The Last Transport We'll Ever Need is a thing that= exists, or that we should want to exist.

I think QUIC is great, but it's certainly not "The Last Transpo= rt We'll Ever Need.".=C2=A0 I don't think such a thing exists.=
=C2=A0

>> Non-support of anything like IP options is IMHO primarily driven b= y the absence of
>> unform cross-OS/Dev-language APIs for them. Yes. It may suck archi= tecturally by designing
>> protocol stacks based on reality like: applications will only be a= ble to use UDP and TCP,
>> so lets do new work on top of them, but to me the most important g= oal is to find the best
>> deployable solution to a problem. Not the architecturally cleanest= one. If you give me
>> research money to work outside of reality i will happily take it t= hough and represent a
>> different perspective.
>>
>
> There has been a lot of discussion about this in v6ops, many networks<= br> > are simply dropping packets with extension headers. Please look at
> draft-ietf-v6ops-ipv6-ehs-in-real-world-02 and
> draft-gont-v6ops-ipv6-ehs-packet-drops-03. Because of this and the
> fact that there hasn't been any interesting options defined worth<= br> > sending to date means that we (speaking for applications) have no use<= br> > to send them (btw all the major OSes support options AFAIK). If some > interesting options did come about, then we would probably apply a
> happy eyeballs approach to deploy.

There's an additional problem in that the way v6 EH are defined = makes it difficult to handle them on path: building silicon to handle arbit= rary header chains is expensive. So one of the functional requirements for = PLUS should be "information that forwarding devices need to see needs = to (usually) to be not very far into the packet, at a constate offset if po= ssible; see [2].

> With something like SPUD (basically anything not simple TCP/IPv4) we > are always faced with the same problem that some networks on the
> Internet may arbitrarily drop or otherwise restrict packets (we know > for instance that some network operators choose to severely rate limit=
> all UDP because of DOS concerns).=C2=A0 So even if we do manage to sta= rt
> deploying transport protocols over UDP we are going have TCP as a
> fallback for indefinite future, i.e. more happy eyeballs.

Yes, and if we do manage to start deploying transport protocols over= IPv6, we are going to have IPv4 fallback for an indefinite future. I share= your concern about happy eyeballs state explosion (a phenomenon we refer t= o around the office as "angry eyeballs" -> eight orthogonal ne= twork/transport layer choices to test at startup means that every flow begi= ns with a 256 packet burst)... but the benefit of doing this to transport f= lexibility is potentially worth the cost, which is the fundamental question= we want to address in PLUS.

Cheers,

Brian

[1] Luckie et al "Resilience of Deployed TCP to Blind Attacks", I= MC 2015, http://conferences.sigcomm.org/imc/20= 15/papers/p13.pdf

[2] Scudder "How a router actually works" IEPG at IETF 94, http://www.iepg.org/2015-11-01-ietf94= /IEPG-RouterArchitecture-jgs.pdf


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


--94eb2c0633e8ed1c3d0533451824-- From nobody Fri May 20 07:07: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 A26A412D99D for ; Fri, 20 May 2016 07:07:25 -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 kfAkkSm--zO4 for ; Fri, 20 May 2016 07:07:23 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 84B9112D99B for ; Fri, 20 May 2016 07:07:23 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:52c8:8000::e9e] (unknown [IPv6:2001:67c:10ec:52c8:8000::e9e]) by trammell.ch (Postfix) with ESMTPSA id E12A91A0C57; Fri, 20 May 2016 16:07:21 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_98BC8FF2-AB5B-41F6-A5D0-C38E9984ED35"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Fri, 20 May 2016 16:06:51 +0200 Message-Id: <1019B343-3E01-4FD7-9C58-2F73E78A11E9@trammell.ch> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> To: Ian Swett X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Tom Herbert , Toerless Eckert , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 14:07:25 -0000 --Apple-Mail=_98BC8FF2-AB5B-41F6-A5D0-C38E9984ED35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Ian, >> There's a couple of problems here which could (IMO should) be handled = better in a transport protocol independent way: >>=20 >> (1) Generic indication of flow start/end. Firewalls use TCP = semantics, for the most part, and new protocols should expose at least = these to get better treatment. Yes, this would have most of the same = problems than SYNs, RSTs, and FINs do in TCP right now, but we can do = better than the status quo. One of the things we looked at with the SPUD = header is using a tube ID in a sparse identifier space to at least = provide better protection against RST/FIN with guessed sequence numbers = (which outside BGP is still a threat to deployed TCP, see [1]). >>=20 >> (2) Indication of NAT/FW state timeout and timeout expectation, to = minimize unproductive keepalive traffic. Even with generic flow state = indication you still need timers, and always will, but exposing = information makes the average case performance better. >>=20 >> We could consider adding these as key use cases in the protocol, but = I still think we want to have the broader use case discussion within any = eventual PLUS WG. >>=20 >> If we *don't* care about the general deployability of new transport = protocols, if we think that QUIC is the Last Transport We'll Ever Need = (i.e., what SCTP was supposed to be), then we can just make sure QUIC = exposes enough to make this possible, and go home. While QUIC is a = definite improvement for the application semantics it's meant to = support, and a widely deployable SCTP would be a improvement for other = media applications, I'm not convinced that The Last Transport We'll Ever = Need is a thing that exists, or that we should want to exist. >>=20 > I think QUIC is great, but it's certainly not "The Last Transport = We'll Ever Need.". I don't think such a thing exists. To be clear, I agree with every part of this statement. :) There is an alternate approach that might be worth discussion here: = Instead of defining an encapsulation layer for handling these two core = use cases, we can define a set of behaviors along with expected bits and = offsets in headers under the UDP header that can be used for state and = (maybe) timer management purposes. If a QUIC header and a PLUS header = look the same to the path for these purposes, then we can still solve = this problem once for both. Of course a set of behaviors and bits at given offsets is a "header", so = the distinction is probably academic. Cheers, Brian --Apple-Mail=_98BC8FF2-AB5B-41F6-A5D0-C38E9984ED35 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 iQIcBAEBCgAGBQJXPxn8AAoJEIoSt78L6kajs30QAIwEbJ/lIOcnSD3ZF7GPzdzm JRmELUH2mO8cVIadKTDCPbVbgLRnm05MfV5K4RTBIAWD4SeFK9KaAICotL10YRif riR1bxiAXFZKi84dFFSVXt7I7vphv9UdhkGjz1Zsl8PCL9gHJAmb+ccmc0M4+B7u bhukSimG3dgMWgxosGS4ZtcmIFiVs2PdqKdLhwqVGuJeIGYgVlvZj9CpgNhU/2Hw wwN7JRtwi/OE7EchZgqNvb9ZExRklvreemVDVikrw2aLb34OSd51Pd9vrxaEFxlQ Rp5siB1VA3UNPZX3eq0eTS+H1igYY7XvVXwcavef0RXhXd92I2Au6KjUUI3kpcoA E5aRAPBGGisAJxzkr6magI7pKGQnoISQIgFNg7fy35Nv/m0v7L3jyFZu1avcHyUF x9FpDEOGEQxviC1nYeqbUVoTc6U9RTBlAEowzb7LHikDeefqSnzw1g+RzPVSeKtG LVC+637VP+nfiXrBQcLavqliC1gCR9xKMuvrtTitwDMoNYcRXzvq9IlvkRIr7154 qxJ38LqERPpUTrY9YLC5pTwXO9gUx0D2A9JGdvSx86rIEYrfeENIlkizst6uhrnT Edrp92MWqkx2Yoy5EPCl6+6QO95Uj2t+HFLvoDf5h5LqdG9nTPsAocMjrRdbYoRp ryl5OZOVEOUfj3Km2Q2B =XNQo -----END PGP SIGNATURE----- --Apple-Mail=_98BC8FF2-AB5B-41F6-A5D0-C38E9984ED35-- From nobody Fri May 20 07:26: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 06F5D12D0B6 for ; Fri, 20 May 2016 07:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 HIy1zr3ZSzaK for ; Fri, 20 May 2016 07:26:04 -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 66F7312D99B for ; Fri, 20 May 2016 07:26:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9BB7FD9314; Fri, 20 May 2016 16:26:02 +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 XgsaOcqH33EY; Fri, 20 May 2016 16:26:02 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 54A6FD930B; Fri, 20 May 2016 16:26:02 +0200 (MEST) To: Dave Dolson , Brian Trammell , "spud@ietf.org" References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160520112345.5697621.10376.85507@sandvine.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <573F1E77.3010708@tik.ee.ethz.ch> Date: Fri, 20 May 2016 16:25:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160520112345.5697621.10376.85507@sandvine.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 14:26:08 -0000 Hi Dave, PLUS is a new path (shim) layer mainly focused on signaling. However, congestion control/avoidance is clearly a function of the transport layer itself and has to stay there. So I would say it's actually not relevant for PLUS except, you'd like to integrate any additional signaling mechanisms here. Some use cases listed in draft-kuehlewind-spud-use-cases are kind of related to congestion avoidance but I don't think that this must be mentioned separately in the charter (as it is just one function of many in the transport layer). If your goal is to make it easier to use the same congestion control in different transports, that's another topic and more related to the taps working group than PLUS/SPUD but I believe also not in scope for them (yet). Mirja On 20.05.2016 13:23, Dave Dolson wrote: > Brian, > I see no explicit mention of congestion avoidance or requirements on the sender to back off under congestion. > > Arguably it is implicit; does it deserve mention in the charter? > > (one of the hazards of placing control in the application is having varying ideas about how to do this, which won't compete fairly with each other. Figuring out how to deal with cheaters is another thing...) > > -Dave > > Original Message > From: Brian Trammell > Sent: Friday, May 20, 2016 7:02 AM > To: spud@ietf.org > Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF > > > Hi, all, > > I've heard one concrete charter suggestion so far; the edited draft charter (changed paragraph 2) is below. If others would like to see points clarified to answer their questions, please send suggested edits. :) > > I take the fact that we're diving into technical discussion as an indication that those participating are at least interested in the BoF, if not (yet ;) ) convinced of the need for a WG at this space? > > Thanks, cheers, > > Brian > > > Path Layer UDP Substrate (PLUS) > =============================== > > The PLUS working group's goal is to enable the deployment of new, > encrypted transport protocols, while providing a > transport-independent method to signal flow semantics under > transport and application control. > > The current Internet protocol stack has no layer for explicit, > in-band signaling of flow semantics and characteristics to network > elements in an interdomain context, nor an integrated signaling > mechanism from network elements to back to endpoints and applications. > This layer never evolved within the stack, because middleboxes and > other devices on path could simply inspect and modify headers and > payload of unencrypted traffic at every layer. This implicit use of > information from the transport and application layers is a > key cause of the ossification that makes it hard or impossible > to deploy new protocols. > > In order to support more ubiquitous deployment of encryption, > explicit signaling must be added to the stack, and it must be > transport protocol independent. 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. > Additionally, 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. > > The PLUS working group will specify a new protocol as a Path Layer > User 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 similar semantics to existing protocols (e.g. > TCP) to devices on path (e.g. NATs and firewalls) > > - allow applications and transport protocols to explicitly provide > limited information to devices on path > > - allow devices on path to provide feedback and information about > the path to sending endpoints, under sending endpoint control > > - allow devices on path to provide information about the path to > receiving endpoints, with feedback to the sending endpoint, under > sending endpoint control > > Note that 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 at the level of detail that is useful for the network, > while encrypting everything else. This is important to avoid future > implicit treatment and the resulting ossification, as well as to > leverage the principle of least exposure to minimize privacy risks > presented by explicit cooperation. > > Given that the primary goal of PLUS is to enable the deployment of > arbitrary, fully encrypted transport protocols, 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 > these use cases and requirements. 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 other working > groups that could or should 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. > TLS) which could be used for encryption of transport protocols > running over PLUS. > > > > >> On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) wrote: >> >> My comment is *only* that the sentence "The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements" needs to be improved, in my personal point of view. >> >> For instance, for NAT/FW control, there are many existing out-of-band protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, etc., not to mention all the SDN protocols, which are typically all flow-based. They are all out-of-band but e.g. NSIS would have been end-to-end. The intention and deployment model of these protocols may be very different to what SPUD aims for, and none of them is deployed end-to-end in the Internet. But I think this sentence has to be slightly more specific how to differentiate e.g. from control plane solutions. >> >> Michael >> >> >> -----Original Message----- >> From: Toerless Eckert [mailto:eckert@cisco.com] >> Sent: Thursday, May 19, 2016 8:27 PM >> To: Tom Herbert >> Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org >> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF >> >> Tom, Michael >> >> I am reading your positions and i am confused: >> >> DSCP is very successfull in enterprise networks. SPUD does not have to be successfull "on the Internet". To me it would already be a great success if it would help to improve controlled network services (like enterprise or 4G/5G networks). And their transit traffic across the Internet (without changing anything on the Internet itself). >> >> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if we often think about them as per-flow and ould maybe like them to be restrict to per-flow. At least i don't know any normative reference that defines them to be per-flow. >> >> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis that all those mechanisms fail to provide an easily deplopyale framework in the face of middleboxes. Aka: their presence and mostly non-success should be an argument FOR working on spud. Not against it. >> >> If a NAT/FW does support any flow signaling, its most likely inband. Every NAT/firwall supports flow recognition via the explicit signaling of flow-based transport protoocols like TCP. They do try to do the same for UDP and because that has no explicit flow signaling, thats where the problem starts. NAT/FW do deep packet inspection which has all these problems we know. SPUD sets out to solve/reduce these NAT/FW issues. >> >> Non-support of anything like IP options is IMHO primarily driven by the absence of unform cross-OS/Dev-language APIs for them. Yes. It may suck architecturally by designing protocol stacks based on reality like: applications will only be able to use UDP and TCP, so lets do new work on top of them, but to me the most important goal is to find the best deployable solution to a problem. Not the architecturally cleanest one. If you give me research money to work outside of reality i will happily take it though and represent a different perspective. >> >> Please, i do not want to dismiss your opposition, i just don't understand how the arguments you make are working out. Maybe you can explain to me where i am going wrong in my interpretations above. >> >> Cheers >> Toerless >> >> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >>> wrote: >>>> Does the sentence ... >>>> >>>> The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements ... >>>> >>>> actually wants to say something like >>>> >>>> The current Internet protocol stack has no layer for explicit *in-band* signaling of flow semantics and characteristics ... ? >>>> >>>> I may be wrong, but there is no shortage of IETF and non-IETF protocols that can signal flow semantics and characteristics out-of-band, either path-coupled or path-decoupled, e.g., in the control or management plane. As a result, there are protocol "layers" for that signaling, but they are not in-band. There may also be other ways to fix this problem (e.g., by adding "end-to-end" or "inter-domain" instead of "in-band"). >>>> >>> Not to mention that TOS and diff-serv are in-band signaling mechanisms >>> to the network, ECN is explicitly signaling from the network. Given >>> that they've been around for many years but have never been widely >>> deployed on the Internet makes me wonder if any in-band signaling >>> mechanism will ever catch on. The use of out of band signaling should >>> be considered, especially considered that in many cases like NAT and >>> firewall the network elements that need signaling are likely in local >>> networks of one side of the connection. >>> >>> I have a similar concern about the statement that IP options/EH and >>> extension headers are being left off the table as part of a solution. >>> The fact that neither have these caught on in the Internet and that >>> tells me two things 1) No IP option is needed for the Internet to >>> operate and be successful which makes me wonder if signaling between >>> network and hosts is even required 2) If the extensibility mechanisms >>> of IP are chronically not deployable, I wonder why any alternative >>> that does not yet exist but intends to solve the same problem would be >>> any more deployable. >>> >>> Tom >>> >>>> Michael >>>> >>>> >>>> -----Original Message----- >>>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On >>>> Behalf Of Brian Trammell >>>> Sent: Thursday, May 19, 2016 5:07 PM >>>> To: stackevo-discuss@iab.org >>>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to >>>> SPUD BoF >>>> >>>> Greetings, all, >>>> >>>> Forwarding this to the correct address for this mailing list (oops). Please discuss at spud@ietf.org. >>>> >>>> Thanks, cheers, >>>> >>>> Brian >>>> >>>>> Begin forwarded message: >>>>> >>>>> From: Brian Trammell >>>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>>> To: spud@ietf.org >>>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >>>>> (IETF)" , Spencer Dawkins at IETF >>>>> >>>>> >>>>> Greetings, all, >>>>> >>>>> We propose to hold a working-group forming BoF in Berlin as a follow-on to the SPUD work, to define a common substrate protocol for encrypted transports based on the requirements derived from experimentation with the SPUD prototype. >>>>> >>>>> First, note that since the acronym "SPUD" refers primarily to the prototype itself, any follow-on working group should have a different name. We're using the derived requirements, not starting for the prototype. The name is a subject for discussion, and suggestions are welcome. To have something to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (PLUS) as a starting point. >>>>> >>>>> The proposed charter appears below. We're interested in hearing initial feedback on the proposed charter in preparation for a BoF proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work to do here within the IETF? Is the scope of the proposed charter appropriate? Is there energy to do this work? >>>>> >>>>> Thanks, cheers, >>>>> >>>>> Brian and Mirja >>>>> >>>>> >>>>> Path Layer UDP Substrate (PLUS) >>>>> =============================== >>>>> >>>>> The PLUS working group???s goal is to enable the deployment of new, >>>>> encrypted transport protocols, while providing a >>>>> transport-independent method to signal flow semantics under transport and application control. >>>>> >>>>> The current Internet protocol stack has no layer for explicit >>>>> signaling of flow semantics and characteristics to network >>>>> elements, nor an integrated signaling mechanism from network >>>>> elements to back to endpoints and applications. This layer never >>>>> evolved within the stack, because middleboxes and other devices on >>>>> path could simply inspect and modify headers and payload of >>>>> unencrypted traffic at every layer. This implicit use of >>>>> information from the transport and application layers is a key origin of the ossification that makes it hard or impossible to deploy new protocols. >>>>> >>>>> In order to support more ubiquitous deployment of encryption, >>>>> explicit signaling must be added to the stack, and it must be >>>>> transport protocol independent. 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. >>>>> Additionally, 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. >>>>> >>>>> The PLUS working group will specify a new protocol as a Path Layer >>>>> User 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 similar semantics to existing protocols (e.g. >>>>> TCP) to devices on path (e.g. NATs and firewalls) >>>>> >>>>> - allow applications and transport protocols to explicitly provide >>>>> limited information to devices on path >>>>> >>>>> - allow devices on path to provide feedback and information about >>>>> the path to sending endpoints, under sending endpoint control >>>>> >>>>> - allow devices on path to provide information about the path to >>>>> receiving endpoints, with feedback to the sending endpoint, under >>>>> sending endpoint control >>>>> >>>>> Note that 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 at the level of detail that is useful for the network, >>>>> while encrypting everything else. This is important to avoid future >>>>> implicit treatment and the resulting ossification, as well as to >>>>> leverage the principle of least exposure to minimize privacy risks presented by explicit cooperation. >>>>> >>>>> Given that the primary goal of PLUS is to enable the deployment of >>>>> arbitrary, fully encrypted transport protocols, 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 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 >>>>> these use cases and requirements. 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 other working >>>>> groups that could or should 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. >>>>> TLS) which could be used for encryption of transport protocols running over 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 >> >> -- >> --- >> Toerless Eckert, eckert@cisco.com > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Fri May 20 07:34: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 E1E8A12D9BF for ; Fri, 20 May 2016 07:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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.426, SPF_PASS=-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 ufnPEct9WseH for ; Fri, 20 May 2016 07:34:07 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 3D5F712D9BC for ; Fri, 20 May 2016 07:34:07 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id p64so56487493ioi.2 for ; Fri, 20 May 2016 07:34:07 -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=cGMUftNnDODYQFSsFAz1U23MVGFGaIAQ6ZSx/jb6OXM=; b=kauOTbv4FpA7qSfMSBI/8I0RTjnIKZKLXC6gOYDF1TBp2xiGQKjhDV6mJJDLsDOQ3y /yReKd5Q2D+GkeztR2h3jO7emvZI1S9UJa4XmKxmY2OCdgljrHnvxQ0eVXsya9OrUEVP eKz9VVqRts+fXsb9400wsgdlm+hRM2QFUZG4vhwJeQcCDSm0WeoDgaPDJQluo5yo5QxN hpgDAyrUkDl95vPyB3gi+QBkE6i0blp/BhFyokChN4GvuajAjEIbMVEjDzGmPN84Yz2W uF+TTlPtbt5R+9Czt314I6H1e6tqYJcgrEQTtBwoGlY05zUQ32C8jeWDHbprzWXIyduw aKzw== 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=cGMUftNnDODYQFSsFAz1U23MVGFGaIAQ6ZSx/jb6OXM=; b=R4e9XpwZkftTXxivL5t0pCzyGb6qYAGWPv5qx8IyVen8Fn8VjGDRLXtlrS4yijA4IL qxhGUfhaiLtRdOfzf0f4qlbSWEHqEE/j5ddiB9RsUUo69ypBX4xB3W/Os8y5NkATAphs 3r3UC0qFSNMGfXoLlDCdpS9R+Q2rZ7e1IRSmEmM5urp0XCG6ayL4JG5vtgbOPGuaCBD9 0FNqZb4GGrf+z+OJtHl1Rqe0k0ma6/9KVNg+rzSBAIJokCkabqMDZ11FNcGMj1CyeXbF rEsZz80Jyn6k1sQvo+dT/VbF+3bwRhUSXrdSDKvgVFpBcr6SK7LxLLA9XLQEV2Tp9GRL cJaA== X-Gm-Message-State: AOPr4FUxc+nsdq07s11rOylnWCREFVWAzqJAfHDroma9Jpf5t1C6LnX3yu30pWeGQKXg6MDUM1fy3HiPzMsmhoc4 X-Received: by 10.107.140.133 with SMTP id o127mr3381345iod.32.1463754846439; Fri, 20 May 2016 07:34:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.227.227 with HTTP; Fri, 20 May 2016 07:33:46 -0700 (PDT) In-Reply-To: <1019B343-3E01-4FD7-9C58-2F73E78A11E9@trammell.ch> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <1019B343-3E01-4FD7-9C58-2F73E78A11E9@trammell.ch> From: Ian Swett Date: Fri, 20 May 2016 10:33:46 -0400 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=94eb2c05c948a97d7e053346fb75 Archived-At: Cc: Tom Herbert , Toerless Eckert , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 14:34:09 -0000 --94eb2c05c948a97d7e053346fb75 Content-Type: text/plain; charset=UTF-8 You were clear, I just wanted to voice my support on that point. As you imply, there are a variety of ways to define a 'header', and as long as the peers and the on-path elements can interpret it correctly, it accomplishes the desired goal. That could be a PLUS header fully encapsulating another protocol, or as you mention, it could be defining a way to integrate PLUS into new and existing UDP protocols. On Fri, May 20, 2016 at 10:06 AM, Brian Trammell wrote: > hi Ian, > > >> There's a couple of problems here which could (IMO should) be handled > better in a transport protocol independent way: > >> > >> (1) Generic indication of flow start/end. Firewalls use TCP semantics, > for the most part, and new protocols should expose at least these to get > better treatment. Yes, this would have most of the same problems than SYNs, > RSTs, and FINs do in TCP right now, but we can do better than the status > quo. One of the things we looked at with the SPUD header is using a tube ID > in a sparse identifier space to at least provide better protection against > RST/FIN with guessed sequence numbers (which outside BGP is still a threat > to deployed TCP, see [1]). > >> > >> (2) Indication of NAT/FW state timeout and timeout expectation, to > minimize unproductive keepalive traffic. Even with generic flow state > indication you still need timers, and always will, but exposing information > makes the average case performance better. > >> > >> We could consider adding these as key use cases in the protocol, but I > still think we want to have the broader use case discussion within any > eventual PLUS WG. > >> > >> If we *don't* care about the general deployability of new transport > protocols, if we think that QUIC is the Last Transport We'll Ever Need > (i.e., what SCTP was supposed to be), then we can just make sure QUIC > exposes enough to make this possible, and go home. While QUIC is a definite > improvement for the application semantics it's meant to support, and a > widely deployable SCTP would be a improvement for other media applications, > I'm not convinced that The Last Transport We'll Ever Need is a thing that > exists, or that we should want to exist. > >> > > I think QUIC is great, but it's certainly not "The Last Transport We'll > Ever Need.". I don't think such a thing exists. > > To be clear, I agree with every part of this statement. :) > > There is an alternate approach that might be worth discussion here: > Instead of defining an encapsulation layer for handling these two core use > cases, we can define a set of behaviors along with expected bits and > offsets in headers under the UDP header that can be used for state and > (maybe) timer management purposes. If a QUIC header and a PLUS header look > the same to the path for these purposes, then we can still solve this > problem once for both. > > Of course a set of behaviors and bits at given offsets is a "header", so > the distinction is probably academic. > > Cheers, > > Brian > --94eb2c05c948a97d7e053346fb75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You were clear, I just wanted to voice my support on that = point.

As you imply, there are a variety of ways to defi= ne a 'header', and as long as the peers and the on-path elements ca= n interpret it correctly, it accomplishes the desired goal.=C2=A0 That coul= d be a PLUS header fully encapsulating another protocol, or as you mention,= it could be defining a way to integrate PLUS into new and existing UDP pro= tocols.=C2=A0

On Fri, May 20, 2016 at 10:06 AM, Brian Trammell = <ietf@trammell.ch<= /a>> wrote:
hi Ian,

>> There's a couple of problems here which could (IMO should) be = handled better in a transport protocol independent way:
>>
>> (1) Generic indication of flow start/end. Firewalls use TCP semant= ics, for the most part, and new protocols should expose at least these to g= et better treatment. Yes, this would have most of the same problems than SY= Ns, RSTs, and FINs do in TCP right now, but we can do better than the statu= s quo. One of the things we looked at with the SPUD header is using a tube = ID in a sparse identifier space to at least provide better protection again= st RST/FIN with guessed sequence numbers (which outside BGP is still a thre= at to deployed TCP, see [1]).
>>
>> (2) Indication of NAT/FW state timeout and timeout expectation, to= minimize unproductive keepalive traffic. Even with generic flow state indi= cation you still need timers, and always will, but exposing information mak= es the average case performance better.
>>
>> We could consider adding these as key use cases in the protocol, b= ut I still think we want to have the broader use case discussion within any= eventual PLUS WG.
>>
>> If we *don't* care about the general deployability of new tran= sport protocols, if we think that QUIC is the Last Transport We'll Ever= Need (i.e., what SCTP was supposed to be), then we can just make sure QUIC= exposes enough to make this possible, and go home. While QUIC is a definit= e improvement for the application semantics it's meant to support, and = a widely deployable SCTP would be a improvement for other media application= s, I'm not convinced that The Last Transport We'll Ever Need is a t= hing that exists, or that we should want to exist.
>>
> I think QUIC is great, but it's certainly not "The Last Trans= port We'll Ever Need.".=C2=A0 I don't think such a thing exist= s.

To be clear, I agree with every part of this statement. :)

There is an alternate approach that might be worth discussion here: Instead= of defining an encapsulation layer for handling these two core use cases, = we can define a set of behaviors along with expected bits and offsets in he= aders under the UDP header that can be used for state and (maybe) timer man= agement purposes. If a QUIC header and a PLUS header look the same to the p= ath for these purposes, then we can still solve this problem once for both.=

Of course a set of behaviors and bits at given offsets is a "header&qu= ot;, so the distinction is probably academic.

Cheers,

Brian

--94eb2c05c948a97d7e053346fb75-- From nobody Fri May 20 08:02: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 ED37812D9BD for ; Fri, 20 May 2016 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 tQcZvOYcPI4D for ; Fri, 20 May 2016 08:02:25 -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 8DE3512D9A6 for ; Fri, 20 May 2016 08:02:25 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 20 May 2016 11:02:23 -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.0181.006; Fri, 20 May 2016 11:02:23 -0400 From: Dave Dolson To: =?iso-8859-1?Q?Mirja_K=FChlewind?= , Brian Trammell , "spud@ietf.org" Thread-Topic: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF Thread-Index: AQHRsfbuJ2cvNkb2DUuyKJNQQWe2WZ/A1zKAgAAIQQCAAQ29AP//wwiYgAB19oD//8NTUA== Date: Fri, 20 May 2016 15:02:22 +0000 Message-ID: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160520112345.5697621.10376.85507@sandvine.com> <573F1E77.3010708@tik.ee.ethz.ch> In-Reply-To: <573F1E77.3010708@tik.ee.ethz.ch> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 15:02:29 -0000 Mirja, Thanks for clarifying. Now that I read the proposed charter again, it is obvious that PLUS it not= =20 itself a transport protocol. Now I understand that the congestion control is the responsibility of protocol riding on top of PLUS. E.g., in "TCP-like-transport over PLUS" pr= otocol. -Dave -----Original Message----- From: Mirja K=FChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]=20 Sent: Friday, May 20, 2016 10:26 AM To: Dave Dolson; Brian Trammell; spud@ietf.org Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on t= o SPUD BoF Hi Dave, PLUS is a new path (shim) layer mainly focused on signaling. However,=20 congestion control/avoidance is clearly a function of the transport layer=20 itself and has to stay there. So I would say it's actually not relevant for= =20 PLUS except, you'd like to integrate any additional signaling mechanisms=20 here. Some use cases listed in draft-kuehlewind-spud-use-cases are kind of= =20 related to congestion avoidance but I don't think that this must be mention= ed=20 separately in the charter (as it is just one function of many in the=20 transport layer). If your goal is to make it easier to use the same congestion control in=20 different transports, that's another topic and more related to the taps=20 working group than PLUS/SPUD but I believe also not in scope for them (yet)= . Mirja On 20.05.2016 13:23, Dave Dolson wrote: > Brian, > I see no explicit mention of congestion avoidance or requirements on the = sender to back off under congestion. > > Arguably it is implicit; does it deserve mention in the charter? > > (one of the hazards of placing control in the application is having varyi= ng ideas about how to do this, which won't compete fairly with each other. = Figuring out how to deal with cheaters is another thing...) > > -Dave > > Original Message > From: Brian Trammell > Sent: Friday, May 20, 2016 7:02 AM > To: spud@ietf.org > Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on= to SPUD BoF > > > Hi, all, > > I've heard one concrete charter suggestion so far; the edited draft chart= er (changed paragraph 2) is below. If others would like to see points clari= fied to answer their questions, please send suggested edits. :) > > I take the fact that we're diving into technical discussion as an indicat= ion that those participating are at least interested in the BoF, if not (ye= t ;) ) convinced of the need for a WG at this space? > > Thanks, cheers, > > Brian > > > Path Layer UDP Substrate (PLUS) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > The PLUS working group's goal is to enable the deployment of new, > encrypted transport protocols, while providing a > transport-independent method to signal flow semantics under > transport and application control. > > The current Internet protocol stack has no layer for explicit, > in-band signaling of flow semantics and characteristics to network > elements in an interdomain context, nor an integrated signaling > mechanism from network elements to back to endpoints and applications. > This layer never evolved within the stack, because middleboxes and > other devices on path could simply inspect and modify headers and > payload of unencrypted traffic at every layer. This implicit use of > information from the transport and application layers is a > key cause of the ossification that makes it hard or impossible > to deploy new protocols. > > In order to support more ubiquitous deployment of encryption, > explicit signaling must be added to the stack, and it must be > transport protocol independent. 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. > Additionally, 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. > > The PLUS working group will specify a new protocol as a Path Layer > User Substrate (PLUS), to support experimental deployment of > explicit cooperation between endpoints and devices on path, with the foll= owing goals: > > - enable ubiquitous deployment of encrypted higher layer protocols > by providing exposure of similar semantics to existing protocols (e.g. > TCP) to devices on path (e.g. NATs and firewalls) > > - allow applications and transport protocols to explicitly provide > limited information to devices on path > > - allow devices on path to provide feedback and information about > the path to sending endpoints, under sending endpoint control > > - allow devices on path to provide information about the path to > receiving endpoints, with feedback to the sending endpoint, under > sending endpoint control > > Note that 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 at the level of detail that is useful for the network, > while encrypting everything else. This is important to avoid future > implicit treatment and the resulting ossification, as well as to > leverage the principle of least exposure to minimize privacy risks > presented by explicit cooperation. > > Given that the primary goal of PLUS is to enable the deployment of > arbitrary, fully encrypted transport protocols, 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 modificati= ons. > > 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 > these use cases and requirements. 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 other working > groups that could or should 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. > TLS) which could be used for encryption of transport protocols > running over PLUS. > > > > >> On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) wrote: >> >> My comment is *only* that the sentence "The current Internet protocol st= ack has no layer for explicit signaling of flow semantics and characteristi= cs to network elements" needs to be improved, in my personal point of view. >> >> For instance, for NAT/FW control, there are many existing out-of-band pr= otocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, etc., no= t to mention all the SDN protocols, which are typically all flow-based. The= y are all out-of-band but e.g. NSIS would have been end-to-end. The intenti= on and deployment model of these protocols may be very different to what SP= UD aims for, and none of them is deployed end-to-end in the Internet. But I= think this sentence has to be slightly more specific how to differentiate = e.g. from control plane solutions. >> >> Michael >> >> >> -----Original Message----- >> From: Toerless Eckert [mailto:eckert@cisco.com] >> Sent: Thursday, May 19, 2016 8:27 PM >> To: Tom Herbert >> Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org >> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-o= n to SPUD BoF >> >> Tom, Michael >> >> I am reading your positions and i am confused: >> >> DSCP is very successfull in enterprise networks. SPUD does not have to b= e successfull "on the Internet". To me it would already be a great success = if it would help to improve controlled network services (like enterprise or= 4G/5G networks). And their transit traffic across the Internet (without ch= anging anything on the Internet itself). >> >> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if= we often think about them as per-flow and ould maybe like them to be restr= ict to per-flow. At least i don't know any normative reference that defines= them to be per-flow. >> >> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysi= s that all those mechanisms fail to provide an easily deplopyale framework = in the face of middleboxes. Aka: their presence and mostly non-success shou= ld be an argument FOR working on spud. Not against it. >> >> If a NAT/FW does support any flow signaling, its most likely inband. Eve= ry NAT/firwall supports flow recognition via the explicit signaling of flow= -based transport protoocols like TCP. They do try to do the same for UDP an= d because that has no explicit flow signaling, thats where the problem star= ts. NAT/FW do deep packet inspection which has all these problems we know. = SPUD sets out to solve/reduce these NAT/FW issues. >> >> Non-support of anything like IP options is IMHO primarily driven by the = absence of unform cross-OS/Dev-language APIs for them. Yes. It may suck arc= hitecturally by designing protocol stacks based on reality like: applicatio= ns will only be able to use UDP and TCP, so lets do new work on top of them= , but to me the most important goal is to find the best deployable solution= to a problem. Not the architecturally cleanest one. If you give me researc= h money to work outside of reality i will happily take it though and repres= ent a different perspective. >> >> Please, i do not want to dismiss your opposition, i just don't understan= d how the arguments you make are working out. Maybe you can explain to me w= here i am going wrong in my interpretations above. >> >> Cheers >> Toerless >> >> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >>> wrote: >>>> Does the sentence ... >>>> >>>> The current Internet protocol stack has no layer for explicit signal= ing of flow semantics and characteristics to network elements ... >>>> >>>> actually wants to say something like >>>> >>>> The current Internet protocol stack has no layer for explicit *in-ba= nd* signaling of flow semantics and characteristics ... ? >>>> >>>> I may be wrong, but there is no shortage of IETF and non-IETF protocol= s that can signal flow semantics and characteristics out-of-band, either pa= th-coupled or path-decoupled, e.g., in the control or management plane. As = a result, there are protocol "layers" for that signaling, but they are not = in-band. There may also be other ways to fix this problem (e.g., by adding = "end-to-end" or "inter-domain" instead of "in-band"). >>>> >>> Not to mention that TOS and diff-serv are in-band signaling mechanisms >>> to the network, ECN is explicitly signaling from the network. Given >>> that they've been around for many years but have never been widely >>> deployed on the Internet makes me wonder if any in-band signaling >>> mechanism will ever catch on. The use of out of band signaling should >>> be considered, especially considered that in many cases like NAT and >>> firewall the network elements that need signaling are likely in local >>> networks of one side of the connection. >>> >>> I have a similar concern about the statement that IP options/EH and >>> extension headers are being left off the table as part of a solution. >>> The fact that neither have these caught on in the Internet and that >>> tells me two things 1) No IP option is needed for the Internet to >>> operate and be successful which makes me wonder if signaling between >>> network and hosts is even required 2) If the extensibility mechanisms >>> of IP are chronically not deployable, I wonder why any alternative >>> that does not yet exist but intends to solve the same problem would be >>> any more deployable. >>> >>> Tom >>> >>>> Michael >>>> >>>> >>>> -----Original Message----- >>>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On >>>> Behalf Of Brian Trammell >>>> Sent: Thursday, May 19, 2016 5:07 PM >>>> To: stackevo-discuss@iab.org >>>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to >>>> SPUD BoF >>>> >>>> Greetings, all, >>>> >>>> Forwarding this to the correct address for this mailing list (oops). P= lease discuss at spud@ietf.org. >>>> >>>> Thanks, cheers, >>>> >>>> Brian >>>> >>>>> Begin forwarded message: >>>>> >>>>> From: Brian Trammell >>>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>>> To: spud@ietf.org >>>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >>>>> (IETF)" , Spencer Dawkins at IETF >>>>> >>>>> >>>>> Greetings, all, >>>>> >>>>> We propose to hold a working-group forming BoF in Berlin as a follow-= on to the SPUD work, to define a common substrate protocol for encrypted tr= ansports based on the requirements derived from experimentation with the SP= UD prototype. >>>>> >>>>> First, note that since the acronym "SPUD" refers primarily to the pro= totype itself, any follow-on working group should have a different name. We= 're using the derived requirements, not starting for the prototype. The nam= e is a subject for discussion, and suggestions are welcome. To have somethi= ng to put in the proposed charter, we'd propose "Path Layer UDP Substrate" = (PLUS) as a starting point. >>>>> >>>>> The proposed charter appears below. We're interested in hearing initi= al feedback on the proposed charter in preparation for a BoF proposal (the = cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work to= do here within the IETF? Is the scope of the proposed charter appropriate?= Is there energy to do this work? >>>>> >>>>> Thanks, cheers, >>>>> >>>>> Brian and Mirja >>>>> >>>>> >>>>> Path Layer UDP Substrate (PLUS) >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> The PLUS working group???s goal is to enable the deployment of new, >>>>> encrypted transport protocols, while providing a >>>>> transport-independent method to signal flow semantics under transport= and application control. >>>>> >>>>> The current Internet protocol stack has no layer for explicit >>>>> signaling of flow semantics and characteristics to network >>>>> elements, nor an integrated signaling mechanism from network >>>>> elements to back to endpoints and applications. This layer never >>>>> evolved within the stack, because middleboxes and other devices on >>>>> path could simply inspect and modify headers and payload of >>>>> unencrypted traffic at every layer. This implicit use of >>>>> information from the transport and application layers is a key origin= of the ossification that makes it hard or impossible to deploy new protoco= ls. >>>>> >>>>> In order to support more ubiquitous deployment of encryption, >>>>> explicit signaling must be added to the stack, and it must be >>>>> transport protocol independent. 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. >>>>> Additionally, 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. >>>>> >>>>> The PLUS working group will specify a new protocol as a Path Layer >>>>> User 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 similar semantics to existing protocols (e.g= . >>>>> TCP) to devices on path (e.g. NATs and firewalls) >>>>> >>>>> - allow applications and transport protocols to explicitly provide >>>>> limited information to devices on path >>>>> >>>>> - allow devices on path to provide feedback and information about >>>>> the path to sending endpoints, under sending endpoint control >>>>> >>>>> - allow devices on path to provide information about the path to >>>>> receiving endpoints, with feedback to the sending endpoint, under >>>>> sending endpoint control >>>>> >>>>> Note that 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 at the level of detail that is useful for the network, >>>>> while encrypting everything else. This is important to avoid future >>>>> implicit treatment and the resulting ossification, as well as to >>>>> leverage the principle of least exposure to minimize privacy risks pr= esented by explicit cooperation. >>>>> >>>>> Given that the primary goal of PLUS is to enable the deployment of >>>>> arbitrary, fully encrypted transport protocols, 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 modifi= cations. >>>>> >>>>> 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 Pr= otocol for User Datagrams 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 >>>>> these use cases and requirements. The working group will close if >>>>> it is not able to come to consensus on a protocol design to meet thes= e requirements. >>>>> >>>>> The working group will additionally aim to identify other working >>>>> groups that could or should 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. >>>>> TLS) which could be used for encryption of transport protocols runnin= g over 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 >> >> -- >> --- >> Toerless Eckert, eckert@cisco.com > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Fri May 20 08:09:46 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 65FB812B018 for ; Fri, 20 May 2016 08:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 kejilKrZeWUS for ; Fri, 20 May 2016 08:09:39 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA1D12D1CA for ; Fri, 20 May 2016 08:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23755; q=dns/txt; s=iport; t=1463756979; x=1464966579; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=hSyzV7cswXgOy5p1LSqIOeKPDWcMudAbLVsuvQE7FiA=; b=ObZgQ17xeYksfsMNuAL+LkbZmo//5k1MZTa4vo6onWtdRqY8ZsxroMAj fjRio1RP6QgZG+e1n5obZ/8oELD6Ld5kpwzIy7lwPCXgWWzVkb+6G2Lo9 um4CHh0gS0z/diwjTOLdfsS44dOclXyA+bi1QzEen2BOu6EwfrYzsfJny A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgAVKD9X/5hdJa1IDAqDN1YtAU+uG?= =?us-ascii?q?otvAQ2BcQQXC4VvAoE2OBQBAQEBAQEBZSeEQgEBAQMBAQEBFyA0BAcFBwQLDgM?= =?us-ascii?q?DAQEBAQkMEgcPBQ0GHwkOExuHegMPCA6/Xw2EMAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARcFiW+BA4JDgUcFCARjhRsFjWR0iSkziHiDL4FvCoFphE+IZIdjh2geAQF?= =?us-ascii?q?CggYcgWscMoZFgT4BAQE?= X-IronPort-AV: E=Sophos;i="5.26,339,1459814400"; d="scan'208";a="104354309" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 May 2016 15:09:37 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4KF9bSl028157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2016 15:09:37 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 u4KF9aov031374; Fri, 20 May 2016 08:09:36 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4KF9amF031373; Fri, 20 May 2016 08:09:36 -0700 Date: Fri, 20 May 2016 08:09:36 -0700 From: Toerless Eckert To: Brian Trammell Message-ID: <20160520150936.GK2511@cisco.com> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> 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: "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 15:09:45 -0000 > Path Layer UDP Substrate (PLUS) > =============================== > > The PLUS working group's goal is to enable the deployment of new, > encrypted transport protocols, while providing a > transport-independent method to signal flow semantics under > transport and application control. Don't like don't understand this paragraph. - What if we do not develope new transprt protocols but recipes how to modify existing transport protocols to run in PLUS ? - "We are going to cook stew while juggling 4 balls". The relationship between the two is not really clear from the sentence. - What does "under transport and application control" mean ? - Does not cover the key aspect of being able to implement these protocols as part of application code. The goal of the PLUS working group is to overcome ossification of deployments of new transport layer work. PLUS will develop a new transport layer approach with the following properties: - The transport protocol is encrypted. - A transport protocol independent inband layer is used for signaling of flow semantics. - The transport layer can be implemented in application layer code. > The current Internet protocol stack has no layer for explicit, > in-band signaling of flow semantics and characteristics to network > elements in an interdomain context, nor an integrated signaling > mechanism from network elements to back to endpoints and applications. > > This layer never evolved within the stack, because middleboxes and > other devices on path could simply inspect and modify headers and > payload of unencrypted traffic at every layer. This implicit use of > information from the transport and application layers is a > key cause of the ossification that makes it hard or impossible > to deploy new protocols. First paragraph wrong if you take STUN/ICE/MALICE into account. Second paragraph unfair because it's hitting only one side. Give the IETF some friendly slapping too, please. Proposed text: Traditionally, the Internet protocols did not provide explicit, transport protocol independent signaling of flow characteristics to on-path network devices. In return, the industry developed the practice of inspecting protocol headers all the way from the transport layer ports to application payload. This practice is called DPI (Deep Packet Inspection. Later on, middleboxes started to filter or modify deep into packets as well, for example to fix up IP addresses in application layer protocols in NAT middleboxes. This was all possible because historically all these layers where (and partially are) unencrypted. Later IETF standards track onpath signaling work such as RSVP or NSIS could not overcome this practice because it could not not solely be implemented by applications interested in it because these protocols had to be implemented by OS vendors. Investmenting in these protocols was unattractive too, because by default middleboxes that do not support these protocols would simply drop them: The practice of unspecified, vendor specific DPI had lead to a "security" model in middleboxes where it was impossible to deploy new transport protocols that could be recognized and supported by pre-existing middleboxes without new work on these middleboxes. This lead to ossification in deployment of new transport work. In recent years, STUN/ICE and extensions to it started to introduce the ability for onpath inband explicit signaling to middleboxes, but being limited to be used purely with existing UDP based transport options, they do not address how to solve the problem for applications using non-UDP transport. > In order to support more ubiquitous deployment of encryption, > explicit signaling must be added to the stack, and it must be > transport protocol independent. > 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. Better: The natural layer for flow information is between Internet and Transport protocols - IP/IPv6 options/extensions or a common transport sublayer. Implementation in the IP/IPv6 layer makes it difficult o adopt though because it would not allow for implementation in application code. > Additionally, 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. > > The PLUS working group will specify a new protocol as a Path Layer > User 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 ^^^ transport and > by providing exposure of similar semantics to existing protocols (e.g. > TCP) to devices on path (e.g. NATs and firewalls) > > - allow applications and transport protocols to explicitly provide > limited information to devices on path > > - allow devices on path to provide feedback and information about > the path to sending endpoints, under sending endpoint control > > - allow devices on path to provide information about the path to > receiving endpoints, with feedback to the sending endpoint, under > sending endpoint control So.. The biggest discussion point i guess will be around the "limited", where the privacy advocacy segment of our population will argue "nothing", and the evil-network-doer will argue "everything". What i really want to see is this: - Allow the application to learn from the network devices what information it must present in the clear to have its traffic be passed through and/or receive additional treatment by the network. Aka: "Security guard: Sure, you can go through this door if you show me your else not" Then the app can decide if it wants to show . Otherwise the apps have to operate like corporate drones, carrying around their corp-ID in the open all the time hoping that thats the right credential. Or to rephrase: if we do not even attempt to overcome TCP port numbers as credentials then we're lame and will not be successful. > Note that this approach explicitly gives the control of information > exposure back the application and/or transport layer protocol on > the end host. remove "and/or transport layer protocols". We MUST have auditability of what is being sent in the clear by the application. We can not have transport protocols inserting information in the clear without the app knowing. > It is the goal of PLUS to minimize the information > exposed at the level of detail that is useful for the network, > while encrypting everything else. This is important to avoid future > implicit treatment and the resulting ossification, as well as to > leverage the principle of least exposure to minimize privacy risks > presented by explicit cooperation. How about a next paragraph about this: Text: In cases where middleboxes require auditability/unencrypted access to the encrypted information of a flow, PLUS can still be used, but the encryption keys need to be shared between application and middleboxes (or backend thereof). PLUS itself will not consider any mechanisms for such encryption key sharing, but instead expects this to be done by a higher layer in the application. End of text. I would like to see something to this extend, because to me there are two classes of key sharing and they have a crucial difference: One where the application is actually knowledgable about this and wants to support this key sharing, such as in banking applications for auditing middleboxes (money laundering rules etc..). And PLUS can be perfectly be used. the app/ middleboxes will just have to write up their key sharing as another layer in the app and middlebox backend. The other class of course is (L)I where the premise is that the app is unaware. I want to make it as clear as possible that there is nothing in PLUS or the encrypted transports it works on that enables this model. If somebody wants to make this model work, he has to define another secret key sharing layer in the application cocde or other layers, but PLUS needs to stay clean > > Given that the primary goal of PLUS is to enable the deployment of > arbitrary, fully encrypted transport protocols, 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 "threat model" == "attack vector" ?? > modification or deletion of exposed information by middleboxes and > other devices on path, by allowing a remote endpoint to detect modifications. Detection of messups is a pretty low bar. I do not need encryption for that. A protected checksum will suffice. The "encryption where needed" is also i think a basic question - eg: would be nice we we had clarity during charter: I as assuming in my above comments that we would ALWAYS have encryption, and that we would need application layer key sharing. Is that the model we want ?? If not, what are the criteria for not having encryption ? Do we think we can agree on criteria during charter ? > 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 > these use cases and requirements. 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 other working > groups that could or should 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. > TLS) which could be used for encryption of transport protocols > running over PLUS. > Cheers Teorless > > > > > On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) wrote: > > > > My comment is *only* that the sentence "The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements" needs to be improved, in my personal point of view. > > > > For instance, for NAT/FW control, there are many existing out-of-band protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, etc., not to mention all the SDN protocols, which are typically all flow-based. They are all out-of-band but e.g. NSIS would have been end-to-end. The intention and deployment model of these protocols may be very different to what SPUD aims for, and none of them is deployed end-to-end in the Internet. But I think this sentence has to be slightly more specific how to differentiate e.g. from control plane solutions. > > > > Michael > > > > > > -----Original Message----- > > From: Toerless Eckert [mailto:eckert@cisco.com] > > Sent: Thursday, May 19, 2016 8:27 PM > > To: Tom Herbert > > Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org > > Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF > > > > Tom, Michael > > > > I am reading your positions and i am confused: > > > > DSCP is very successfull in enterprise networks. SPUD does not have to be successfull "on the Internet". To me it would already be a great success if it would help to improve controlled network services (like enterprise or 4G/5G networks). And their transit traffic across the Internet (without changing anything on the Internet itself). > > > > AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if we often think about them as per-flow and ould maybe like them to be restrict to per-flow. At least i don't know any normative reference that defines them to be per-flow. > > > > Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis that all those mechanisms fail to provide an easily deplopyale framework in the face of middleboxes. Aka: their presence and mostly non-success should be an argument FOR working on spud. Not against it. > > > > If a NAT/FW does support any flow signaling, its most likely inband. Every NAT/firwall supports flow recognition via the explicit signaling of flow-based transport protoocols like TCP. They do try to do the same for UDP and because that has no explicit flow signaling, thats where the problem starts. NAT/FW do deep packet inspection which has all these problems we know. SPUD sets out to solve/reduce these NAT/FW issues. > > > > Non-support of anything like IP options is IMHO primarily driven by the absence of unform cross-OS/Dev-language APIs for them. Yes. It may suck architecturally by designing protocol stacks based on reality like: applications will only be able to use UDP and TCP, so lets do new work on top of them, but to me the most important goal is to find the best deployable solution to a problem. Not the architecturally cleanest one. If you give me research money to work outside of reality i will happily take it though and represent a different perspective. > > > > Please, i do not want to dismiss your opposition, i just don't understand how the arguments you make are working out. Maybe you can explain to me where i am going wrong in my interpretations above. > > > > Cheers > > Toerless > > > > On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: > >> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) > >> wrote: > >>> Does the sentence ... > >>> > >>> The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements ... > >>> > >>> actually wants to say something like > >>> > >>> The current Internet protocol stack has no layer for explicit *in-band* signaling of flow semantics and characteristics ... ? > >>> > >>> I may be wrong, but there is no shortage of IETF and non-IETF protocols that can signal flow semantics and characteristics out-of-band, either path-coupled or path-decoupled, e.g., in the control or management plane. As a result, there are protocol "layers" for that signaling, but they are not in-band. There may also be other ways to fix this problem (e.g., by adding "end-to-end" or "inter-domain" instead of "in-band"). > >>> > >> Not to mention that TOS and diff-serv are in-band signaling mechanisms > >> to the network, ECN is explicitly signaling from the network. Given > >> that they've been around for many years but have never been widely > >> deployed on the Internet makes me wonder if any in-band signaling > >> mechanism will ever catch on. The use of out of band signaling should > >> be considered, especially considered that in many cases like NAT and > >> firewall the network elements that need signaling are likely in local > >> networks of one side of the connection. > >> > >> I have a similar concern about the statement that IP options/EH and > >> extension headers are being left off the table as part of a solution. > >> The fact that neither have these caught on in the Internet and that > >> tells me two things 1) No IP option is needed for the Internet to > >> operate and be successful which makes me wonder if signaling between > >> network and hosts is even required 2) If the extensibility mechanisms > >> of IP are chronically not deployable, I wonder why any alternative > >> that does not yet exist but intends to solve the same problem would be > >> any more deployable. > >> > >> Tom > >> > >>> Michael > >>> > >>> > >>> -----Original Message----- > >>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On > >>> Behalf Of Brian Trammell > >>> Sent: Thursday, May 19, 2016 5:07 PM > >>> To: stackevo-discuss@iab.org > >>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to > >>> SPUD BoF > >>> > >>> Greetings, all, > >>> > >>> Forwarding this to the correct address for this mailing list (oops). Please discuss at spud@ietf.org. > >>> > >>> Thanks, cheers, > >>> > >>> Brian > >>> > >>>> Begin forwarded message: > >>>> > >>>> From: Brian Trammell > >>>> Subject: Possible WG-forming follow-on to SPUD BoF > >>>> Date: 19 May 2016 at 17:04:50 GMT+2 > >>>> To: spud@ietf.org > >>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind > >>>> (IETF)" , Spencer Dawkins at IETF > >>>> > >>>> > >>>> Greetings, all, > >>>> > >>>> We propose to hold a working-group forming BoF in Berlin as a follow-on to the SPUD work, to define a common substrate protocol for encrypted transports based on the requirements derived from experimentation with the SPUD prototype. > >>>> > >>>> First, note that since the acronym "SPUD" refers primarily to the prototype itself, any follow-on working group should have a different name. We're using the derived requirements, not starting for the prototype. The name is a subject for discussion, and suggestions are welcome. To have something to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (PLUS) as a starting point. > >>>> > >>>> The proposed charter appears below. We're interested in hearing initial feedback on the proposed charter in preparation for a BoF proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work to do here within the IETF? Is the scope of the proposed charter appropriate? Is there energy to do this work? > >>>> > >>>> Thanks, cheers, > >>>> > >>>> Brian and Mirja > >>>> > >>>> > >>>> Path Layer UDP Substrate (PLUS) > >>>> =============================== > >>>> > >>>> The PLUS working group???s goal is to enable the deployment of new, > >>>> encrypted transport protocols, while providing a > >>>> transport-independent method to signal flow semantics under transport and application control. > >>>> > >>>> The current Internet protocol stack has no layer for explicit > >>>> signaling of flow semantics and characteristics to network > >>>> elements, nor an integrated signaling mechanism from network > >>>> elements to back to endpoints and applications. This layer never > >>>> evolved within the stack, because middleboxes and other devices on > >>>> path could simply inspect and modify headers and payload of > >>>> unencrypted traffic at every layer. This implicit use of > >>>> information from the transport and application layers is a key origin of the ossification that makes it hard or impossible to deploy new protocols. > >>>> > >>>> In order to support more ubiquitous deployment of encryption, > >>>> explicit signaling must be added to the stack, and it must be > >>>> transport protocol independent. 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. > >>>> Additionally, 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. > >>>> > >>>> The PLUS working group will specify a new protocol as a Path Layer > >>>> User 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 similar semantics to existing protocols (e.g. > >>>> TCP) to devices on path (e.g. NATs and firewalls) > >>>> > >>>> - allow applications and transport protocols to explicitly provide > >>>> limited information to devices on path > >>>> > >>>> - allow devices on path to provide feedback and information about > >>>> the path to sending endpoints, under sending endpoint control > >>>> > >>>> - allow devices on path to provide information about the path to > >>>> receiving endpoints, with feedback to the sending endpoint, under > >>>> sending endpoint control > >>>> > >>>> Note that 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 at the level of detail that is useful for the network, > >>>> while encrypting everything else. This is important to avoid future > >>>> implicit treatment and the resulting ossification, as well as to > >>>> leverage the principle of least exposure to minimize privacy risks presented by explicit cooperation. > >>>> > >>>> Given that the primary goal of PLUS is to enable the deployment of > >>>> arbitrary, fully encrypted transport protocols, 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 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 > >>>> these use cases and requirements. 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 other working > >>>> groups that could or should 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. > >>>> TLS) which could be used for encryption of transport protocols running over 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 > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Fri May 20 08:33: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 17CFB12DA36 for ; Fri, 20 May 2016 08:33: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 fWWi_Mv72vTZ for ; Fri, 20 May 2016 08:33:54 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 E117912DA38 for ; Fri, 20 May 2016 08:33:37 -0700 (PDT) Received: by mail-ig0-x233.google.com with SMTP id ww4so7634413igb.1 for ; Fri, 20 May 2016 08:33:37 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=4TooYETSTJWjh8R9qR7ndHxW0dNLf1fsnc/xSHr4oZw=; b=TvI+/7xLkd7mE7bg53J6n9weKM0eAm1RtdOpz6eQGtDRFjz5MaAZhz+AbDr5d77xUa O5WhFI6L4lneUTXp64snBTl79Z58klrc5KOppLs6KYhjCBJsRNWbhD+nZXtbDAKYcLuB z9i8eo1D2gnNPCyNbKCz1twJ6Jo+8S3LL7bjj6U4Q2FeQ0kvWd2DSeECdCuQ1OVhZBWy m31vu7CUqWzL9M+pgjrpWR3ks1P7aYN4qaMSIprc9zgEAKR8T93u3Qw8wacjQNML8aeC bEFKfHg/PFYB2nfY+BwKff6Tdp/tssYLhWYjxe5VKkOeUiYzyuKss9yZ5QBjEsNA5yld 0a9g== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=4TooYETSTJWjh8R9qR7ndHxW0dNLf1fsnc/xSHr4oZw=; b=dfNGRbZfbbnlhjiC6zr9JmTJjHkoK/W0Nhgs+aQ52CqFr8DmDh5+bsLYc5HMjcypcw JXB10pYak2bIpPx2kYjJ9WfXsB9nnW91AOS+aGtdv5WyYbc23glJEftTTAF8UmY/+jdv GTkspbsGs1zfvyZc1ifpfGMw71Y4tLBFrwOZtIF9XE6c1XPY1v46RRqSLxn7RIYyVLXx xqPPTvQQQG6dmQgsmN8Gg7dfeTPs/umEb5FJoczv4Uj2uhipGT5W4DVngzLvjDwIrXye hM/CJobZsCXhuZbdkfoONnBwAuAPO8g9Wr8myqQoMLB5tSldg+gm8QmHsHyrLNSJ+nT/ TcXA== X-Gm-Message-State: AOPr4FUa0/scJ8o2FPG3cvM/yodUjRqNcTYByS2QFd0w5AabEOw6VtrNBVQRaND+pZ/JdiFd+1wjB52GyBTKMQ== MIME-Version: 1.0 X-Received: by 10.50.205.8 with SMTP id lc8mr3625228igc.94.1463758416952; Fri, 20 May 2016 08:33:36 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Fri, 20 May 2016 08:33:36 -0700 (PDT) In-Reply-To: <20160520022957.5697621.53774.85449@sandvine.com> References: <20160520022957.5697621.53774.85449@sandvine.com> Date: Fri, 20 May 2016 08:33:36 -0700 Message-ID: From: Tom Herbert To: Dave Dolson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Trammell , Toerless Eckert , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 15:33:57 -0000 On Thu, May 19, 2016 at 7:29 PM, Dave Dolson wrote: > Please also think about how a network operator can monitor how well thing= s are working, and how DDoS traffic may be discriminated from non-attack tr= affic. > Today, > - TCP packet loss can be measured by observing sequence numbers > - round-trip times can be measured =E2=80=8Efrom TCP sequence/ack numbers > - non-attack traffic properly completes connections, whereas attack traff= ic often does not > - some fair-queuing approaches apply fairness by TCP connections=E2=80=8E > - ECMP and load-balancers try to make individual sessions follow a single= path > > If packets become completely opaque, I think =E2=80=8Ein general the inte= rnet would operate less well. > It would be good for SPUD and QUIC =E2=80=8Eto provide enough information= for monitoring devices to measure progress, handshakes, round-trip times, = as can be done with TCP carrying TCP. > Dave, I agree that we need to consider the needs of network operators, but we also have to consider the perspective of the users. For instance, here at Facebook we operate on nearly every public network on the planet except in those places where we are prohibited. That means we need to deal with the policies and constraints across all network operators-- that quickly leads to application of the robustness principle in that we are going to be conservative in what we send to achieve maximum reachability. So my question regarding exposure of L4 information in SPUD is what are the _requirements_ for what we send? In order to establish that any information is a requirement, like that in the list you proposed, I think we need at least three things: 1) A specification as to what the required information is. This should include a description of how the network is allowed to use the information. Also the information should be common across all protocols and cannot be inferred by other means. For instance, exposing sequence numbers may make sense for TCP, but other protocols may not have a usable concept of sequence numbers or they may have multiple sequence numbers like in sub-streams. The ECMP problem is solved by IPv6 flow label which eliminating the need to otherwise expose L4 information for that purpose. If the information is used as part of maintaining flow state, like in tracking sequence numbers for a connection, then there must be a consideration for when the state is inaccurate or incomplete-- flow state tracking is inherently best effort since the Internet is packet-switched not circuit-switched. 2) A description of the effects if the information is misused by some node in the network, rather intentionally of not. Misuse must not be detrimental to the users. Unfortunately, I don't believe there's a lot of latitude in this one. For instance, if we exposure of a piece of information gives a performance benefit to 99% of our users but is security risk for 1%, that puts sixteen million of our users at risk. It's not a tradeoff we can easily make. 3) A description of the effects if end node fabricate the exposed information. Hosts cannot be allowed to gain an unfair advantage simply by lying about what is carried in the payload. This is the "setting priority" problem on the Internet, where if end users are allowed to indicate priority they will all say their packets are high priority. Generally, there is no trust relationship established between the end hosts and the network, so anything the network tells the host and vice versa cannot be implicitly trusted to be true. If the discussions in accord about exposing information beyond L4 are a bellwether, I think getting consensus here is going to be difficult, but this does seem like an important discussion to have in the context of SPUD. Tom > -Dave > =E2=80=8E > > Original Message > From: Tom Herbert > Sent: Thursday, May 19, 2016 3:17 PM > To: Toerless Eckert > Cc: Brian Trammell; Scharf, Michael (Nokia - DE); spud@ietf.org > Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on= to SPUD BoF > > On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert wrot= e: >> Tom, Michael >> >> I am reading your positions and i am confused: >> >> DSCP is very successfull in enterprise networks. SPUD does not have to >> be successfull "on the Internet". To me it would already be a great succ= ess if it would >> help to improve controlled network services (like enterprise or 4G/5G ne= tworks). And >> their transit traffic across the Internet (without changing anything on = the Internet >> itself). >> > Yes, that is my point about localizing the problem. A client device > should know what network it's on an be able to signal to that network > to get the services it wants. A server on the other side of the planet > that the node is talking to really shouldn't be concerned with this > and not required to implement some complex protocol to accommodate it. > >> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if= we often think about >> them as per-flow and ould maybe like them to be restrict to per-flow. At= least i don't know >> any normative reference that defines them to be per-flow. >> >> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysi= s that all those >> mechanisms fail to provide an easily deplopyale framework in the face of= middleboxes. Aka: their >> presence and mostly non-success should be an argument FOR working on spu= d. Not against it. >> >> If a NAT/FW does support any flow signaling, its most likely inband. Eve= ry NAT/firwall >> supports flow recognition via the explicit signaling of flow-based trans= port protoocols >> like TCP. They do try to do the same for UDP and because that has no exp= licit flow signaling, >> thats where the problem starts. NAT/FW do deep packet inspection which h= as all these problems >> we know. SPUD sets out to solve/reduce these NAT/FW issues. >> > There seems to be a lot of UDP going through NAT/FW today without any > sort of in-band signaling, and protocols like QUIC are already seeing > deployment without that (according to their slide deck "About half of > Google to Chrome"). Considering that there is no deployment of a SPUD > aware firewall and we can't want to wait for every device on the > Internet to upgrade, SPUD will have to work with NAT/FW as is or we > couldn't consider it. TBH I'm really having a hard time seeing that > any extra signaling is required in the Internet other than what is in > the IP header, at best it seems like an optimization for certain > networks or configurations. > >> Non-support of anything like IP options is IMHO primarily driven by the = absence of >> unform cross-OS/Dev-language APIs for them. Yes. It may suck architectur= ally by designing >> protocol stacks based on reality like: applications will only be able to= use UDP and TCP, >> so lets do new work on top of them, but to me the most important goal is= to find the best >> deployable solution to a problem. Not the architecturally cleanest one. = If you give me >> research money to work outside of reality i will happily take it though = and represent a >> different perspective. >> > > There has been a lot of discussion about this in v6ops, many networks > are simply dropping packets with extension headers. Please look at > draft-ietf-v6ops-ipv6-ehs-in-real-world-02 and > draft-gont-v6ops-ipv6-ehs-packet-drops-03. Because of this and the > fact that there hasn't been any interesting options defined worth > sending to date means that we (speaking for applications) have no use > to send them (btw all the major OSes support options AFAIK). If some > interesting options did come about, then we would probably apply a > happy eyeballs approach to deploy. > > With something like SPUD (basically anything not simple TCP/IPv4) we > are always faced with the same problem that some networks on the > Internet may arbitrarily drop or otherwise restrict packets (we know > for instance that some network operators choose to severely rate limit > all UDP because of DOS concerns). So even if we do manage to start > deploying transport protocols over UDP we are going have TCP as a > fallback for indefinite future, i.e. more happy eyeballs. > > Tom > >> Please, i do not want to dismiss your opposition, i just don't understan= d how the >> arguments you make are working out. Maybe you can explain to me where i = am going wrong >> in my interpretations above. >> >> Cheers >> Toerless >> >> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >>> wrote: >>> > Does the sentence ... >>> > >>> > The current Internet protocol stack has no layer for explicit signali= ng of flow semantics and characteristics to network elements ... >>> > >>> > actually wants to say something like >>> > >>> > The current Internet protocol stack has no layer for explicit *in-ban= d* signaling of flow semantics and characteristics ... ? >>> > >>> > I may be wrong, but there is no shortage of IETF and non-IETF protoco= ls that can signal flow semantics and characteristics out-of-band, either p= ath-coupled or path-decoupled, e.g., in the control or management plane. As= a result, there are protocol "layers" for that signaling, but they are not= in-band. There may also be other ways to fix this problem (e.g., by adding= "end-to-end" or "inter-domain" instead of "in-band"). >>> > >>> Not to mention that TOS and diff-serv are in-band signaling mechanisms >>> to the network, ECN is explicitly signaling from the network. Given >>> that they've been around for many years but have never been widely >>> deployed on the Internet makes me wonder if any in-band signaling >>> mechanism will ever catch on. The use of out of band signaling should >>> be considered, especially considered that in many cases like NAT and >>> firewall the network elements that need signaling are likely in local >>> networks of one side of the connection. >>> >>> I have a similar concern about the statement that IP options/EH and >>> extension headers are being left off the table as part of a solution. >>> The fact that neither have these caught on in the Internet and that >>> tells me two things 1) No IP option is needed for the Internet to >>> operate and be successful which makes me wonder if signaling between >>> network and hosts is even required 2) If the extensibility mechanisms >>> of IP are chronically not deployable, I wonder why any alternative >>> that does not yet exist but intends to solve the same problem would be >>> any more deployable. >>> >>> Tom >>> >>> > Michael >>> > >>> > >>> > -----Original Message----- >>> > From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On B= ehalf Of Brian Trammell >>> > Sent: Thursday, May 19, 2016 5:07 PM >>> > To: stackevo-discuss@iab.org >>> > Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPU= D BoF >>> > >>> > Greetings, all, >>> > >>> > Forwarding this to the correct address for this mailing list (oops). = Please discuss at spud@ietf.org. >>> > >>> > Thanks, cheers, >>> > >>> > Brian >>> > >>> >> Begin forwarded message: >>> >> >>> >> From: Brian Trammell >>> >> Subject: Possible WG-forming follow-on to SPUD BoF >>> >> Date: 19 May 2016 at 17:04:50 GMT+2 >>> >> To: spud@ietf.org >>> >> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >>> >> (IETF)" , Spencer Dawkins at IETF >>> >> >>> >> >>> >> Greetings, all, >>> >> >>> >> We propose to hold a working-group forming BoF in Berlin as a follow= -on to the SPUD work, to define a common substrate protocol for encrypted t= ransports based on the requirements derived from experimentation with the S= PUD prototype. >>> >> >>> >> First, note that since the acronym "SPUD" refers primarily to the pr= ototype itself, any follow-on working group should have a different name. W= e're using the derived requirements, not starting for the prototype. The na= me is a subject for discussion, and suggestions are welcome. To have someth= ing to put in the proposed charter, we'd propose "Path Layer UDP Substrate"= (PLUS) as a starting point. >>> >> >>> >> The proposed charter appears below. We're interested in hearing init= ial feedback on the proposed charter in preparation for a BoF proposal (the= cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work t= o do here within the IETF? Is the scope of the proposed charter appropriate= ? Is there energy to do this work? >>> >> >>> >> Thanks, cheers, >>> >> >>> >> Brian and Mirja >>> >> >>> >> >>> >> Path Layer UDP Substrate (PLUS) >>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >> >>> >> The PLUS working group???s goal is to enable the deployment of new, >>> >> encrypted transport protocols, while providing a transport-independe= nt >>> >> method to signal flow semantics under transport and application cont= rol. >>> >> >>> >> The current Internet protocol stack has no layer for explicit >>> >> signaling of flow semantics and characteristics to network elements, >>> >> nor an integrated signaling mechanism from network elements to back = to >>> >> endpoints and applications. This layer never evolved within the stac= k, >>> >> because middleboxes and other devices on path could simply inspect a= nd >>> >> modify headers and payload of unencrypted traffic at every layer. Th= is >>> >> implicit use of information from the transport and application layer= s >>> >> is a key origin of the ossification that makes it hard or impossible= to deploy new protocols. >>> >> >>> >> In order to support more ubiquitous deployment of encryption, explic= it >>> >> signaling must be added to the stack, and it must be transport >>> >> protocol independent. 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. Additionally, a feedback >>> >> channel that provides information from on-path devices back to >>> >> endpoints and applications, e.g. for error handling, is essential fo= r >>> >> the deployment and success of an explicit cooperation approach. >>> >> >>> >> The PLUS working group will specify a new protocol as a Path Layer >>> >> User Substrate (PLUS), to support experimental deployment of explici= t >>> >> cooperation between endpoints and devices on path, with the followin= g goals: >>> >> >>> >> - enable ubiquitous deployment of encrypted higher layer protocols b= y >>> >> providing exposure of similar semantics to existing protocols (e.g. >>> >> TCP) to devices on path (e.g. NATs and firewalls) >>> >> >>> >> - allow applications and transport protocols to explicitly provide >>> >> limited information to devices on path >>> >> >>> >> - allow devices on path to provide feedback and information about th= e >>> >> path to sending endpoints, under sending endpoint control >>> >> >>> >> - allow devices on path to provide information about the path to >>> >> receiving endpoints, with feedback to the sending endpoint, under >>> >> sending endpoint control >>> >> >>> >> Note that 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 >>> >> at the level of detail that is useful for the network, while >>> >> encrypting everything else. This is important to avoid future implic= it >>> >> treatment and the resulting ossification, as well as to leverage the >>> >> principle of least exposure to minimize privacy risks presented by e= xplicit cooperation. >>> >> >>> >> Given that the primary goal of PLUS is to enable the deployment of >>> >> arbitrary, fully encrypted transport protocols, 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 modif= ications. >>> >> >>> >> 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 P= rotocol for User Datagrams 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 these >>> >> use cases and requirements. The working group will close if it is no= t >>> >> able to come to consensus on a protocol design to meet these require= ments. >>> >> >>> >> The working group will additionally aim to identify other working >>> >> groups that could or should address parts of these requirements with= in >>> >> 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. TLS) which could = be >>> >> used for encryption of transport protocols running over 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 >> >> -- >> --- >> Toerless Eckert, eckert@cisco.com > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Fri May 20 09:04: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 96A8012DA57 for ; Fri, 20 May 2016 09:04:48 -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 vq1JOCbjpBFh for ; Fri, 20 May 2016 09:04:47 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C58112DD48 for ; Fri, 20 May 2016 09:03:50 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id p64so59683766ioi.2 for ; Fri, 20 May 2016 09:03:50 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=gavuXWLgxbidfVCFdUOJhxiZ+xaAJAvELamXYSXs33w=; b=KhCAmUWTC3CsZfz8JLUVyKx5Jsseh0AkFzVk9x5CylhQCcywRbmrMtzP/MIc0dCE3L 5qkuw8de/e4LdnMoUMgSkXo/tThgarWPgL/vxxOrCopv19tT8zsdWEhaqw+78aoIslSt wE46NaJiSeiven0JkejYMupryE/o6NWAZB7iQ5M2+vlv6B0Vwz52j9fCz5z3rpqHOrDF fJeB9JzBWV8ifWk69zbEoKByN2nOXy08zOH8todQkFVRHMlhEDadcofTgra/s4BmjLBh TmeJ8+nAsLf61IBgLr24FntARpVWTc/6j+i7FWGM+yTeSQSLsOAW5LTX9bDKT8aHXgl2 wyGA== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=gavuXWLgxbidfVCFdUOJhxiZ+xaAJAvELamXYSXs33w=; b=SE9ORQd/F1HLlvMOGjdCmNLFglR7jcXnxyqMa6R+NeiZ+5KAbbQPoPECPaPIam42Xd aLn+Ekk6M88wAFNsvElyd6oBBYk9MrQg5Av68Id5kRVl7hsrgb2C6+ivswbyCL/XKYw9 UT0ySEb6a8bO1GcO43WeDHNlincOCCf/6qYs189btiVl7oD04UVQg3Z3LJFnfV1VbsqP e49VhhZLVRNchdWJy9Avg5pfWYO87wBvwrwR6HZDZBf3wuXjE/ANr6WqeQc22l8vFjP3 I1dwWwXf5Efn1UA4L7K/J+k7mUGYEjJ3h57zsO1qdWB19TEJsslu5IYzf2+p/1OCU2Mz 8V2w== X-Gm-Message-State: AOPr4FXwSjzcmFHOyQcFgMOv35BMqYiGOpXf/GQK3JdPdBTuzNrJmQD340+uzGFiHDAYH9nJVJWR+C92BvPpFQ== MIME-Version: 1.0 X-Received: by 10.36.46.76 with SMTP id i73mr3759078ita.91.1463760229289; Fri, 20 May 2016 09:03:49 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Fri, 20 May 2016 09:03:49 -0700 (PDT) In-Reply-To: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 20 May 2016 09:03:49 -0700 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 16:04:48 -0000 On Fri, May 20, 2016 at 3:08 AM, Brian Trammell wrote: > hi Tom, > >> On 19 May 2016, at 19:50, Tom Herbert wrote: >> >> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >> wrote: >>> Does the sentence ... >>> >>> The current Internet protocol stack has no layer for explicit signalin= g of flow semantics and characteristics to network elements ... >>> >>> actually wants to say something like >>> >>> The current Internet protocol stack has no layer for explicit *in-band= * signaling of flow semantics and characteristics ... ? >>> >>> I may be wrong, but there is no shortage of IETF and non-IETF protocols= that can signal flow semantics and characteristics out-of-band, either pat= h-coupled or path-decoupled, e.g., in the control or management plane. As a= result, there are protocol "layers" for that signaling, but they are not i= n-band. There may also be other ways to fix this problem (e.g., by adding "= end-to-end" or "inter-domain" instead of "in-band"). >>> >> Not to mention that TOS and diff-serv are in-band signaling mechanisms >> to the network, ECN is explicitly signaling from the network. > > DSCP is properly network-layer. If you believe in a "path layer" (which I= 'm pretty sure I do), you can argue that ECN is the first path layer protoc= ol. > I'm not sure what "path layer" is. Yes every packet takes some path, but the Internet is packet-switched not circuit-switched, so not all packets for a flow are required to always take the same path. Maintaining flow state in intermediate nodes is only best effort. In the presence of multi-homing and mobility intermediate devices that track flow state will inevitably have it wrong. Anyone who has ever tried to build a front-end L4 load balancer understands this problem all too well :-) >> Given >> that they've been around for many years but have never been widely >> deployed on the Internet > > DCSP was defined in such a way that it makes little sense in an interdoma= in context, and its widespread intradomain deployment means that it will ne= ver deploy across domains in the general case. > Sure, but can you give a specific example of information exposure that is useful in interdomain context, does not diminish end user security, and does have any detrimental effects if the information is fabricated? > I still hold out a (potentially irrational) hope for ECN's deployment. > >> makes me wonder if any in-band signaling >> mechanism will ever catch on. The use of out of band signaling should >> be considered, especially considered that in many cases like NAT and >> firewall the network elements that need signaling are likely in local >> networks of one side of the connection. > > As noted, out of band signaling is not explicitly out of scope in the cur= rent > Great. >> I have a similar concern about the statement that IP options/EH and >> extension headers are being left off the table as part of a solution. > > I don't think they are off the table; a protocol such as what we propose = to develop in PLUS could certainly use IPv6 extension headers, provided the= y can be implemented such that applications actually get access to those he= aders. IPv4 options are more of a stretch, simply due to questions about ho= w well the path treats them. > Considering that there's already talk of sunsetting IPv4 I think it's less of a concern-- IPv6 is the future of the Internet. In fact, optimizing SPUD for IPv6 seems perfectly inline with encouraging adoption wider adoption of IPv6. >> The fact that neither have these caught on in the Internet and that >> tells me two things 1) No IP option is needed for the Internet to >> operate and be successful which makes me wonder if signaling between >> network and hosts is even required 2) If the extensibility mechanisms >> of IP are chronically not deployable, I wonder why any alternative >> that does not yet exist but intends to solve the same problem would be >> any more deployable. > > I'd assert that encapsulating things in UDP is certainly much more deploy= able *at the endpoints*. The open question is about adoption by on-path dev= ices. > I'm not sure in this specific case that UDP necessarily make things more deployable. For instance, there's the pesky problem of fragmentation. If L3 information is put into UDP and that packet is fragmented, only the first fragment contains the L3 information the others don't. Either the application needs to pick some minimal MTU and hope that packets make it through, or needs to implement PMTU discovery (rather or not ICMP PTB is delivered to the application is another story, in Linux it is at least). IPv6 nicely great here since minimum MTU is 1280, IPv4 might be harder to nail down. Tom > Cheers, > > Brian > >> >> Tom >> >>> Michael >>> >>> >>> -----Original Message----- >>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On Beh= alf Of Brian Trammell >>> Sent: Thursday, May 19, 2016 5:07 PM >>> To: stackevo-discuss@iab.org >>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD = BoF >>> >>> Greetings, all, >>> >>> Forwarding this to the correct address for this mailing list (oops). Pl= ease discuss at spud@ietf.org. >>> >>> Thanks, cheers, >>> >>> Brian >>> >>>> Begin forwarded message: >>>> >>>> From: Brian Trammell >>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>> To: spud@ietf.org >>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >>>> (IETF)" , Spencer Dawkins at IETF >>>> >>>> >>>> Greetings, all, >>>> >>>> We propose to hold a working-group forming BoF in Berlin as a follow-o= n to the SPUD work, to define a common substrate protocol for encrypted tra= nsports based on the requirements derived from experimentation with the SPU= D prototype. >>>> >>>> First, note that since the acronym "SPUD" refers primarily to the prot= otype itself, any follow-on working group should have a different name. We'= re using the derived requirements, not starting for the prototype. The name= is a subject for discussion, and suggestions are welcome. To have somethin= g to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (= PLUS) as a starting point. >>>> >>>> The proposed charter appears below. We're interested in hearing initia= l feedback on the proposed charter in preparation for a BoF proposal (the c= utoff date is two weeks from tomorrow, on Friday 3 June). Is there work to = do here within the IETF? Is the scope of the proposed charter appropriate? = Is there energy to do this work? >>>> >>>> Thanks, cheers, >>>> >>>> Brian and Mirja >>>> >>>> >>>> Path Layer UDP Substrate (PLUS) >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> The PLUS working group=E2=80=99s goal is to enable the deployment of n= ew, >>>> encrypted transport protocols, while providing a transport-independent >>>> method to signal flow semantics under transport and application contro= l. >>>> >>>> The current Internet protocol stack has no layer for explicit >>>> signaling of flow semantics and characteristics to network elements, >>>> nor an integrated signaling mechanism from network elements to back to >>>> endpoints and applications. This layer never evolved within the stack, >>>> because middleboxes and other devices on path could simply inspect and >>>> modify headers and payload of unencrypted traffic at every layer. This >>>> implicit use of information from the transport and application layers >>>> is a key origin of the ossification that makes it hard or impossible t= o deploy new protocols. >>>> >>>> In order to support more ubiquitous deployment of encryption, explicit >>>> signaling must be added to the stack, and it must be transport >>>> protocol independent. 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. Additionally, 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. >>>> >>>> The PLUS working group will specify a new protocol as a Path Layer >>>> User 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 similar semantics to existing protocols (e.g. >>>> TCP) to devices on path (e.g. NATs and firewalls) >>>> >>>> - allow applications and transport protocols to explicitly provide >>>> limited information to devices on path >>>> >>>> - allow devices on path to provide feedback and information about the >>>> path to sending endpoints, under sending endpoint control >>>> >>>> - allow devices on path to provide information about the path to >>>> receiving endpoints, with feedback to the sending endpoint, under >>>> sending endpoint control >>>> >>>> Note that 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 >>>> at the level of detail that is useful for the network, while >>>> encrypting everything else. This is important to avoid future implicit >>>> treatment and the resulting ossification, as well as to leverage the >>>> principle of least exposure to minimize privacy risks presented by exp= licit cooperation. >>>> >>>> Given that the primary goal of PLUS is to enable the deployment of >>>> arbitrary, fully encrypted transport protocols, 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 modific= ations. >>>> >>>> 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 Pro= tocol for User Datagrams 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 these >>>> use cases and requirements. The working group will close if it is not >>>> able to come to consensus on a protocol design to meet these requireme= nts. >>>> >>>> The working group will additionally aim to identify other working >>>> groups that could or should 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. TLS) which could be >>>> used for encryption of transport protocols running over 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 > From nobody Fri May 20 09:17: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 4296B12DD6F for ; Fri, 20 May 2016 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 kMjuFCzIhLTo for ; Fri, 20 May 2016 09:17:30 -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 D84F612D521 for ; Fri, 20 May 2016 09:17:29 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 20 May 2016 12:17:28 -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.0181.006; Fri, 20 May 2016 12:17:28 -0400 From: Dave Dolson To: Brian Trammell , "spud@ietf.org" Thread-Topic: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF Thread-Index: AQHRsfbuJ2cvNkb2DUuyKJNQQWe2WZ/A1zKAgAAIQQCAAQ29AIAAE5sw Date: Fri, 20 May 2016 16:17:28 +0000 Message-ID: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 16:17:33 -0000 Brian, The text of the proposed charter doesn't mention "UDP"; it's just in the ti= tle. If the intent is to require the use of UDP, it should be spelled out, I'd t= hink. -Dave -----Original Message----- From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Brian Trammell Sent: Friday, May 20, 2016 7:02 AM To: spud@ietf.org Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on t= o SPUD BoF Hi, all, I've heard one concrete charter suggestion so far; the edited draft charter= (changed paragraph 2) is below. If others would like to see points clarifi= ed to answer their questions, please send suggested edits. :) I take the fact that we're diving into technical discussion as an indicatio= n that those participating are at least interested in the BoF, if not (yet = ;) ) convinced of the need for a WG at this space? Thanks, cheers, Brian Path Layer UDP Substrate (PLUS) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D The PLUS working group's goal is to enable the deployment of new, encrypted transport protocols, while providing a transport-independent method to signal flow semantics under transport and application control. The current Internet protocol stack has no layer for explicit, in-band signaling of flow semantics and characteristics to network elements in an interdomain context, nor an integrated signaling mechanism from network elements to back to endpoints and applications. This layer never evolved within the stack, because middleboxes and other devices on path could simply inspect and modify headers and payload of unencrypted traffic at every layer. This implicit use of information from the transport and application layers is a key cause of the ossification that makes it hard or impossible to deploy new protocols. In order to support more ubiquitous deployment of encryption, explicit signaling must be added to the stack, and it must be transport protocol independent. 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. Additionally, 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. The PLUS working group will specify a new protocol as a Path Layer User Substrate (PLUS), to support experimental deployment of explicit cooperation between endpoints and devices on path, with the follow= ing goals: - enable ubiquitous deployment of encrypted higher layer protocols by providing exposure of similar semantics to existing protocols (e.g. TCP) to devices on path (e.g. NATs and firewalls) - allow applications and transport protocols to explicitly provide limited information to devices on path - allow devices on path to provide feedback and information about the path to sending endpoints, under sending endpoint control - allow devices on path to provide information about the path to receiving endpoints, with feedback to the sending endpoint, under sending endpoint control Note that 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 at the level of detail that is useful for the network, while encrypting everything else. This is important to avoid future implicit treatment and the resulting ossification, as well as to leverage the principle of least exposure to minimize privacy risks presented by explicit cooperation. Given that the primary goal of PLUS is to enable the deployment of arbitrary, fully encrypted transport protocols, 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 modification= s. 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 these use cases and requirements. 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 other working groups that could or should 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. TLS) which could be used for encryption of transport protocols running over PLUS. > On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) wrote: >=20 > My comment is *only* that the sentence "The current Internet protocol sta= ck has no layer for explicit signaling of flow semantics and characteristic= s to network elements" needs to be improved, in my personal point of view. >=20 > For instance, for NAT/FW control, there are many existing out-of-band pro= tocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, etc., not= to mention all the SDN protocols, which are typically all flow-based. They= are all out-of-band but e.g. NSIS would have been end-to-end. The intentio= n and deployment model of these protocols may be very different to what SPU= D aims for, and none of them is deployed end-to-end in the Internet. But I = think this sentence has to be slightly more specific how to differentiate e= .g. from control plane solutions. >=20 > Michael >=20 >=20 > -----Original Message----- > From: Toerless Eckert [mailto:eckert@cisco.com] > Sent: Thursday, May 19, 2016 8:27 PM > To: Tom Herbert > Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org > Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on= to SPUD BoF >=20 > Tom, Michael >=20 > I am reading your positions and i am confused: >=20 > DSCP is very successfull in enterprise networks. SPUD does not have to be= successfull "on the Internet". To me it would already be a great success i= f it would help to improve controlled network services (like enterprise or = 4G/5G networks). And their transit traffic across the Internet (without cha= nging anything on the Internet itself). >=20 > AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if = we often think about them as per-flow and ould maybe like them to be restri= ct to per-flow. At least i don't know any normative reference that defines = them to be per-flow. >=20 > Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis= that all those mechanisms fail to provide an easily deplopyale framework i= n the face of middleboxes. Aka: their presence and mostly non-success shoul= d be an argument FOR working on spud. Not against it. >=20 > If a NAT/FW does support any flow signaling, its most likely inband. Ever= y NAT/firwall supports flow recognition via the explicit signaling of flow-= based transport protoocols like TCP. They do try to do the same for UDP and= because that has no explicit flow signaling, thats where the problem start= s. NAT/FW do deep packet inspection which has all these problems we know. S= PUD sets out to solve/reduce these NAT/FW issues. >=20 > Non-support of anything like IP options is IMHO primarily driven by the a= bsence of unform cross-OS/Dev-language APIs for them. Yes. It may suck arch= itecturally by designing protocol stacks based on reality like: application= s will only be able to use UDP and TCP, so lets do new work on top of them,= but to me the most important goal is to find the best deployable solution = to a problem. Not the architecturally cleanest one. If you give me research= money to work outside of reality i will happily take it though and represe= nt a different perspective. >=20 > Please, i do not want to dismiss your opposition, i just don't understand= how the arguments you make are working out. Maybe you can explain to me wh= ere i am going wrong in my interpretations above. >=20 > Cheers > Toerless >=20 > On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >> wrote: >>> Does the sentence ... >>>=20 >>> The current Internet protocol stack has no layer for explicit signalin= g of flow semantics and characteristics to network elements ... >>>=20 >>> actually wants to say something like >>>=20 >>> The current Internet protocol stack has no layer for explicit *in-band= * signaling of flow semantics and characteristics ... ? >>>=20 >>> I may be wrong, but there is no shortage of IETF and non-IETF protocols= that can signal flow semantics and characteristics out-of-band, either pat= h-coupled or path-decoupled, e.g., in the control or management plane. As a= result, there are protocol "layers" for that signaling, but they are not i= n-band. There may also be other ways to fix this problem (e.g., by adding "= end-to-end" or "inter-domain" instead of "in-band"). >>>=20 >> Not to mention that TOS and diff-serv are in-band signaling mechanisms >> to the network, ECN is explicitly signaling from the network. Given >> that they've been around for many years but have never been widely >> deployed on the Internet makes me wonder if any in-band signaling >> mechanism will ever catch on. The use of out of band signaling should >> be considered, especially considered that in many cases like NAT and >> firewall the network elements that need signaling are likely in local >> networks of one side of the connection. >>=20 >> I have a similar concern about the statement that IP options/EH and >> extension headers are being left off the table as part of a solution. >> The fact that neither have these caught on in the Internet and that >> tells me two things 1) No IP option is needed for the Internet to >> operate and be successful which makes me wonder if signaling between >> network and hosts is even required 2) If the extensibility mechanisms >> of IP are chronically not deployable, I wonder why any alternative >> that does not yet exist but intends to solve the same problem would be >> any more deployable. >>=20 >> Tom >>=20 >>> Michael >>>=20 >>>=20 >>> -----Original Message----- >>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On >>> Behalf Of Brian Trammell >>> Sent: Thursday, May 19, 2016 5:07 PM >>> To: stackevo-discuss@iab.org >>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to >>> SPUD BoF >>>=20 >>> Greetings, all, >>>=20 >>> Forwarding this to the correct address for this mailing list (oops). Pl= ease discuss at spud@ietf.org. >>>=20 >>> Thanks, cheers, >>>=20 >>> Brian >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> From: Brian Trammell >>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>> To: spud@ietf.org >>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >>>> (IETF)" , Spencer Dawkins at IETF >>>> >>>>=20 >>>> Greetings, all, >>>>=20 >>>> We propose to hold a working-group forming BoF in Berlin as a follow-o= n to the SPUD work, to define a common substrate protocol for encrypted tra= nsports based on the requirements derived from experimentation with the SPU= D prototype. >>>>=20 >>>> First, note that since the acronym "SPUD" refers primarily to the prot= otype itself, any follow-on working group should have a different name. We'= re using the derived requirements, not starting for the prototype. The name= is a subject for discussion, and suggestions are welcome. To have somethin= g to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (= PLUS) as a starting point. >>>>=20 >>>> The proposed charter appears below. We're interested in hearing initia= l feedback on the proposed charter in preparation for a BoF proposal (the c= utoff date is two weeks from tomorrow, on Friday 3 June). Is there work to = do here within the IETF? Is the scope of the proposed charter appropriate? = Is there energy to do this work? >>>>=20 >>>> Thanks, cheers, >>>>=20 >>>> Brian and Mirja >>>>=20 >>>>=20 >>>> Path Layer UDP Substrate (PLUS) >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> The PLUS working group???s goal is to enable the deployment of new, >>>> encrypted transport protocols, while providing a >>>> transport-independent method to signal flow semantics under transport = and application control. >>>>=20 >>>> The current Internet protocol stack has no layer for explicit >>>> signaling of flow semantics and characteristics to network >>>> elements, nor an integrated signaling mechanism from network >>>> elements to back to endpoints and applications. This layer never >>>> evolved within the stack, because middleboxes and other devices on >>>> path could simply inspect and modify headers and payload of >>>> unencrypted traffic at every layer. This implicit use of >>>> information from the transport and application layers is a key origin = of the ossification that makes it hard or impossible to deploy new protocol= s. >>>>=20 >>>> In order to support more ubiquitous deployment of encryption, >>>> explicit signaling must be added to the stack, and it must be >>>> transport protocol independent. 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. >>>> Additionally, 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 c= ooperation approach. >>>>=20 >>>> The PLUS working group will specify a new protocol as a Path Layer >>>> User Substrate (PLUS), to support experimental deployment of >>>> explicit cooperation between endpoints and devices on path, with the f= ollowing goals: >>>>=20 >>>> - enable ubiquitous deployment of encrypted higher layer protocols >>>> by providing exposure of similar semantics to existing protocols (e.g. >>>> TCP) to devices on path (e.g. NATs and firewalls) >>>>=20 >>>> - allow applications and transport protocols to explicitly provide >>>> limited information to devices on path >>>>=20 >>>> - allow devices on path to provide feedback and information about >>>> the path to sending endpoints, under sending endpoint control >>>>=20 >>>> - allow devices on path to provide information about the path to >>>> receiving endpoints, with feedback to the sending endpoint, under >>>> sending endpoint control >>>>=20 >>>> Note that 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 at the level of detail that is useful for the network, >>>> while encrypting everything else. This is important to avoid future >>>> implicit treatment and the resulting ossification, as well as to >>>> leverage the principle of least exposure to minimize privacy risks pre= sented by explicit cooperation. >>>>=20 >>>> Given that the primary goal of PLUS is to enable the deployment of >>>> arbitrary, fully encrypted transport protocols, 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 modific= ations. >>>>=20 >>>> 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 Pro= tocol for User Datagrams 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 >>>> these use cases and requirements. The working group will close if >>>> it is not able to come to consensus on a protocol design to meet these= requirements. >>>>=20 >>>> The working group will additionally aim to identify other working >>>> groups that could or should 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. >>>> TLS) which could be used for encryption of transport protocols running= over PLUS. >>>>=20 >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >=20 > -- > --- > Toerless Eckert, eckert@cisco.com From nobody Fri May 20 09:43: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 83CE012DE0C for ; Fri, 20 May 2016 09:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, 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 hgTLXUKk7VY2 for ; Fri, 20 May 2016 09:43:55 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 8995312DE07 for ; Fri, 20 May 2016 09:43:55 -0700 (PDT) Received: by mail-qg0-x22a.google.com with SMTP id j18so15065534qge.2 for ; Fri, 20 May 2016 09:43:55 -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:date:message-id:subject :from:to:cc; bh=1mLmlBVsBr52hRTj5fMcRzX09FxiTda6xYz2J7tsEm8=; b=ulpRD/8g82ZkwzhQUuEcVHB3FSdVeoG8MeeUPY/K2dJ3R7ZeLCRQANHqKzV7C2Hw52 KuWNdeeQ0atkvOheheD5abrtkBChIQpwCQN3SxfPP3PAH0mnzAJxL/HX7tYFW/BapPWQ BHHxQdlq10sDBUeNAq/nj6UJPhteffus4XPqQXigINL5fq64zo/xmkTXJuz4XeVrtQGU T6jVh36f24/xfj8ZiuVFir7Xd7VSA5xmYT3hoOc4lGZYTbuhPYJE5AMAvQkt9Fq45jH0 mydaBJz6gnRcNOSbMtab8ZV11oNLtbxujDm8AmVSDtfySCxhCwl8bR1LwuwkpXK9FZak oqaQ== 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:date :message-id:subject:from:to:cc; bh=1mLmlBVsBr52hRTj5fMcRzX09FxiTda6xYz2J7tsEm8=; b=RNeTGejNZjRdRTnbLgbPfqsrVNBb/bqWM0qmk5NkSedAfda9hRAvJUKSYpjeDIj9Yd Zf4lB5gD/Hv2FKatomt4XAgAQmfJFGZHKqs16X5i/DmrQnhqgp83rOVoUkQ8Bh0imG2j H3jKzdR42gj6uwdsPY9qu+kvlOOhZxstxWCh4S3d61OSczzzHqkzy+NhPiAuRhQ8SFQC 8wKMFJz4D4SJnMapAH6KiMsaVdJoyG0S6tPdkCA2ZlR8jd/ZHaC9Xm/RWExOYDs6MsmU EjEllDVhc8GaCCsp0AHF+j6kJfbVaLH3aPegsYWZMYIsVnUuq3APiKRpASJ7amFC8Dj2 s0YA== X-Gm-Message-State: AOPr4FWUvFmFL+xa1pZ+w/9cyKHvPGA/oMmaUKWbi8qeOxQWZ/2kb42XaDbgkrUemPeNePmzQ2WXZkbcgZF1XQ== MIME-Version: 1.0 X-Received: by 10.140.238.66 with SMTP id j63mr4451946qhc.48.1463762634465; Fri, 20 May 2016 09:43:54 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.105 with HTTP; Fri, 20 May 2016 09:43:54 -0700 (PDT) In-Reply-To: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 20 May 2016 12:43:54 -0400 X-Google-Sender-Auth: 3syQdqFvPOel4zb6juNNad8EUik Message-ID: From: Phillip Hallam-Baker To: Dave Dolson Content-Type: multipart/alternative; boundary=001a1135933cdcea9d053348cb3c Archived-At: Cc: Brian Trammell , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 20 May 2016 16:43:57 -0000 --001a1135933cdcea9d053348cb3c Content-Type: text/plain; charset=UTF-8 The tension we always get caught up in here is 'make it work in the existing Internet' and 'write a proper transport layer'. Here is why I don't think the tension exists: You have to do the first as a precondition for the second. Adding features to TCP or developing new protocols that are transport layer but not organized as a single stream has a small design cost and an enormous deployment overhead. The fact that we can get fifty people to work on such protocols in IETF says absolutely nothing about the viability of the deployment of that protocol. When I did particle physics, one of the profs once told me 'you don't need five thousand people to do a billion dollar experiment but you need that and more to get the money to do a billion dollar experiment'. It is the same with protocol design. You don't need the hundreds of people who were involved to write HTML5 but you need thousands of developers bought in to move that ecosystem. What we need to focus on is deployment. Riding on UDP doesn't look as clean as riding on raw IP but it is much easier to get deployment because you only need buy in from a much smaller community. You don't need Microsoft or Apple or Linus to add your new protocol to their sockets implementation. And that is absolutely essential because a TCP implementation that has 20+ years of optimization is always going to outperform any transport protocol that abstracts to a single stream of data. If you are going to do anything interesting with SPUD, the API has to expand beyond BSD sockets so that you have the ability to provide the application layer programmer with abstractions such as separating the control stream from the data stream, how fast data can be sent before it starts being buffered and all the other capabilities that people use the UDP layer and multiplex schemes built on HTTP to provide. The WebSockets API is now implemented in Windows and in most other network stacks. It didn't get there because people thought the spec was a good idea and implemented it. It got there after WebSockets was being widely used in applications, then a specification was written and only later did the implementations appear. So for me, the core of what I want from SPUD is to tell me 'what information should I expose on my UDP packets to tell middleboxes the information they need to process it successfully in accordance with their network acceptable use policy'. SPUD can't provide a means of treating network gateways as damage and routing round them, nor for that matter can any standard because that particular trope only applies to the internetwork, the network between the networks, the network of networks. My network, my rules. And my rules say that my network devices don't decide which packets flow, I do. To do otherwise is to invite my devices to spend much of their time recruited to botnets, uploading confidential data from my local network to the cloud and worse. Right now we have a big problem in that the network gateways perform poorly because they can only apply heuristics to guess how traffic should be managed. The result is more false positives and more false negatives. --001a1135933cdcea9d053348cb3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The tension we always get caugh= t up in here is 'make it work in the existing Internet' and 'wr= ite a proper transport layer'.

Here is why I don't think the tension exis= ts: You have to do the first as a precondition for the second.


Adding features to TCP or developing new protocols that = are transport layer but not organized as a single stream has a small design= cost and an enormous deployment overhead. The fact that we can get fifty p= eople to work on such protocols in IETF says absolutely nothing about the v= iability of the deployment of that protocol.

When I did particle physics, one of = the profs once told me 'you don't need five thousand people to do a= billion dollar experiment but you need that and more to get the money to d= o a billion dollar experiment'. It is the same with protocol design. Yo= u don't need the hundreds of people who were involved to write HTML5 bu= t you need thousands of developers bought in to move that ecosystem.
<= div class=3D"gmail_extra">
What we need= to focus on is deployment. Riding on UDP doesn't look as clean as ridi= ng on raw IP but it is much easier to get deployment because you only need = buy in from a much smaller community. You don't need Microsoft or Apple= or Linus to add your new protocol to their sockets implementation. And tha= t is absolutely essential because a TCP implementation that has 20+ years o= f optimization is always going to outperform any transport protocol that ab= stracts to a single stream of data.

If you are going to do anything interesting w= ith SPUD, the API has to expand beyond BSD sockets so that you have the abi= lity to provide the application layer programmer with abstractions such as = separating the control stream from the data stream, how fast data can be se= nt before it starts being buffered and all the other capabilities that peop= le use the UDP layer and multiplex schemes built on HTTP to provide.
<= div class=3D"gmail_extra">
The WebSocke= ts API is now implemented in Windows and in most other network stacks. It d= idn't get there because people thought the spec was a good idea and imp= lemented it. It got there after WebSockets was being widely used in applica= tions, then a specification was written and only later did the implementati= ons appear.


So for me, the core of what I wa= nt from SPUD is to tell me 'what information should I expose on my UDP = packets to tell middleboxes the information they need to process it success= fully in accordance with their network acceptable use policy'.

SPUD can't= provide a means of treating network gateways as damage and routing round t= hem, nor for that matter can any standard because that particular trope onl= y applies to the internetwork, the network between the networks, the networ= k of networks.

My network, my rules. And my rules say that my network devices don= 't decide which packets flow, I do. To do otherwise is to invite my dev= ices to spend much of their time recruited to botnets, uploading confidenti= al data from my local network to the cloud and worse.

Right now we have a big pro= blem in that the network gateways perform poorly because they can only appl= y heuristics to guess how traffic should be managed. The result is more fal= se positives and more false negatives.

=


<= /div>
--001a1135933cdcea9d053348cb3c-- From nobody Fri May 20 10:22: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 C49B812DA23 for ; Fri, 20 May 2016 10:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 p8qDGGK74wMe for ; Fri, 20 May 2016 10:22:36 -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 5B63C12D5D8 for ; Fri, 20 May 2016 10:22:36 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u4KHM5na024972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 20 May 2016 10:22:05 -0700 (PDT) To: Toerless Eckert References: <573E31E1.807@isi.edu> <573E3C9F.202@isi.edu> <20160519225859.GV12994@cisco.com> <573E4636.70001@isi.edu> <20160519234836.GA2511@cisco.com> <573E528C.3080303@isi.edu> <20160520002014.GD2511@cisco.com> <573E6393.4090701@isi.edu> <20160520012624.GG2511@cisco.com> From: Joe Touch Message-ID: <573F47BC.1030201@isi.edu> Date: Fri, 20 May 2016 10:22:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160520012624.GG2511@cisco.com> 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: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 17:22:38 -0000 On 5/19/2016 6:26 PM, Toerless Eckert wrote: > O there are only minute benefits of in-kernel transport protocol. I'd be happy > to have them die out. OS vendors can happily implement TCP wih UDP ports as > a library. >> Some do. I recall that there were ways to update old versions of Windows >> with new transport stacks (Trumpet, I think?). > Sure, but i want to have a network architecture whose API standards allow all OSs to do this. > The solutions you're talking about have OS specific APIs. ANd i want UDP as the cross-OS > demux layer. UDP is not an API. Posix is what you want to extend, not the Internet. Joe From nobody Fri May 20 10:22: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 3494812D8E1 for ; Fri, 20 May 2016 10:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 kHs-ilFAQP7K for ; Fri, 20 May 2016 10:22:40 -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 CFBAE12D5D8 for ; Fri, 20 May 2016 10:22:38 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u4KHM9mi024981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 20 May 2016 10:22:09 -0700 (PDT) To: Toerless Eckert References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> From: Joe Touch Message-ID: <573F47C0.3010501@isi.edu> Date: Fri, 20 May 2016 10:22:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160520012431.GF2511@cisco.com> 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: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 17:22:46 -0000 On 5/19/2016 6:24 PM, Toerless Eckert wrote: > On Thu, May 19, 2016 at 06:06:11PM -0700, Joe Touch wrote: >> I don't disagree with the potential benefits. I disagree with using UDP >> encapsulation to achieve an end-run around the OS exerting control. > Don't think of it as UDP. Think of it as creating multiple layers inside the current > transport layer. The lowest layer is demultiplexing. Architecturally very clean. Here's why it's not: TCP isn't a layer by itself; it relies on the IP pseudoheader. TCP in UDP in IP is architecturally incomplete. TCP in IP in UDP in IP would be fine, as would TCP in IP in IP. But we already have those. That's why we don't need this and why it's a mess. That's also why other tunnels - which encapsulate transport through net or link inside transport, net, or link - are much more architecturally clean and have not generated this reaction. Joe From nobody Fri May 20 11:21: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 DA61812D558 for ; Fri, 20 May 2016 11:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 gtEI7-JD1eIq for ; Fri, 20 May 2016 11:21:35 -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 84BF912D109 for ; Fri, 20 May 2016 11:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1492; q=dns/txt; s=iport; t=1463768495; x=1464978095; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=3qMuWvFLNcMcI4WfABBEiu/+a2L8oA61iqmmf3T77Fg=; b=OU8ijIHGWpbEYI2VokbHnwk6KhURiUUUWJKpb5c+pE5JKoay2ul48kW4 aAqcCsvZ8KqTJbqOe9lNO6TlIRZTUE/gVMR9e8zWb3yz91I9X46Hg2dqw OzO87NKBciffwq9OJAGCFa7OAw6j+AVPa3iYTT0uwpbAV91Yf26S6djp5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgBcVT9X/49dJa1eDoMpu1wBDYF1h?= =?us-ascii?q?hECgTc4FAEBAQEBAQFlJ4RCAQEBAwE6PQIFCwsYCSUPBUkuiAwIxDYBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEcinKKGQEEjliJXI4WCo8cj0seAQFCgjh6WxyINQEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.26,340,1459814400"; d="scan'208";a="110145594" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 May 2016 18:21:16 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4KILGEP001473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2016 18:21:16 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 u4KILG0T014936; Fri, 20 May 2016 11:21:16 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4KILF4J014935; Fri, 20 May 2016 11:21:15 -0700 Date: Fri, 20 May 2016 11:21:15 -0700 From: Toerless Eckert To: Joe Touch Message-ID: <20160520182115.GO2511@cisco.com> References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573F47C0.3010501@isi.edu> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 18:21:37 -0000 Thanks, Joe, inline On Fri, May 20, 2016 at 10:22:08AM -0700, Joe Touch wrote: > On 5/19/2016 6:24 PM, Toerless Eckert wrote: > > On Thu, May 19, 2016 at 06:06:11PM -0700, Joe Touch wrote: > >> I don't disagree with the potential benefits. I disagree with using UDP > >> encapsulation to achieve an end-run around the OS exerting control. > > Don't think of it as UDP. Think of it as creating multiple layers inside the current > > transport layer. The lowest layer is demultiplexing. Architecturally very clean. > Here's why it's not: > > TCP isn't a layer by itself; it relies on the IP pseudoheader. Ack. > TCP in UDP in IP is architecturally incomplete. Right. but i am claiming that is possible and not too difficult. Eg: remove TCP header port fields, just rely on UDP port fields, adopt pseudoheader rules for TCP/UDP, etc. pp. > TCP in IP in UDP in IP would be fine, as would TCP in IP in IP. But we > already have those. > That's why we don't need this and why it's a mess. Still not clear how you jump from architectural incomplete to "no need, it's a mess". > That's also why other tunnels - which encapsulate transport through net > or link inside transport, net, or link - are much more architecturally > clean and have not generated this reaction. I think network layer overlay solutions are architecturally fare less clean that modularizing the transport layer and cleaning up historic dependencies against network layer. Toerless From nobody Fri May 20 11:24:55 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 C760C12D558 for ; Fri, 20 May 2016 11:24:53 -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 565IoB0pt1QD for ; Fri, 20 May 2016 11:24:52 -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 8FF9512D109 for ; Fri, 20 May 2016 11:24:52 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id f8so22836119ioe.3 for ; Fri, 20 May 2016 11:24:52 -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:date:message-id:subject:from:to :cc; bh=w/IqB0p0HSUa2uzGefT3Ms4VcljLA/iYyEJndDDxxRA=; b=tDK6bPpm8wqaUhkf7Zq80m7MH09qzvJm/k5dgU65y7cQoO4nG4pTHzUsDvlumtBmvD rYQVNX9qnV3kgPnTMZU/m6ZXEO0vQ1jGjdUfXSaG5M8tUyW4N0tXbBHUbAudGix6Vg5M FYEIy6xezkjRYPFce+36jCGP6J0ula0fXuTtsJcoKjRq28FDxd6v7j/pN5Lj7GNQfOs6 tq+JZ+eCntSaVdtuCZ1G2fbbn27tI2GfxxjTj8PyUzs4C81/NkNxkFl5grAV6Fh242Sy eUUn191ybGV9RHp3MBo5AH7j0w18BuJMsPUNQ2vfOlnZwDv+BFBmh+60PzrBWfzggyCD osfQ== 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:date :message-id:subject:from:to:cc; bh=w/IqB0p0HSUa2uzGefT3Ms4VcljLA/iYyEJndDDxxRA=; b=VCXb2sad7Nzs9mtrBSmmRNQqBYgoA+nH0eijewNr1yidv6kb9Nqx6JyN40srgld7OC jvwaqwUOJEtG1FBZqDkm4T4EboE/sWml1o6T5LVgESOIwyhv9WwAsA8F+C6yMq5/gII+ +ryro+JvSo93zpFOCQ+ukkrRBa8taZRtMLdjO3cgc+9oMoJ9zkGhMwGUcgWZuV0bjVQJ hMOgWuGtj15pUKslCRPiGpthukHoSsYl1pqigNMTAwjbECen7mnT2gF8AoZYEi88a5DF R9kgTwEm5yJ0ci5LAezBr/Sclr+wUtZPisyRE2g4Vz9F4f267AHJe5gYauGAjPHpixSC Y1Qw== X-Gm-Message-State: AOPr4FXIpKsZr8cCVwZj302S7vbO9//Sn/tFN198aTGa7wLMjT7dEtFuQuhMluFv4clCvQfmbut3PQCRsE22Cg== MIME-Version: 1.0 X-Received: by 10.107.142.18 with SMTP id q18mr4229500iod.84.1463768691920; Fri, 20 May 2016 11:24:51 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Fri, 20 May 2016 11:24:51 -0700 (PDT) In-Reply-To: <573F47C0.3010501@isi.edu> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> Date: Fri, 20 May 2016 11:24:51 -0700 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Toerless Eckert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 18:24:54 -0000 On Fri, May 20, 2016 at 10:22 AM, Joe Touch wrote: > > > On 5/19/2016 6:24 PM, Toerless Eckert wrote: >> On Thu, May 19, 2016 at 06:06:11PM -0700, Joe Touch wrote: >>> I don't disagree with the potential benefits. I disagree with using UDP >>> encapsulation to achieve an end-run around the OS exerting control. >> Don't think of it as UDP. Think of it as creating multiple layers inside the current >> transport layer. The lowest layer is demultiplexing. Architecturally very clean. > Here's why it's not: > > TCP isn't a layer by itself; it relies on the IP pseudoheader. > > TCP in UDP in IP is architecturally incomplete. > > TCP in IP in UDP in IP would be fine, as would TCP in IP in IP. But we > already have those. > > That's why we don't need this and why it's a mess. > If it's more palatable we can accurately call this a new application layer protocol that implements reliability and congestion control instead of phrasing it encapsulation of TCP over UDP. In one variant, the protocol has the same packet format and same algorithm processing as TCP except for how connection lookup is done (other variants would be things that look like SCTP, DCCP, etc). The implementation of this application layer protocol in no way affects the existing transport protocols or otherwise affects the network (network just sees UDP packets). There are many instances of applications implementing their own congestion controlled and reliable protocols, so I don't see that we're doing anything different than those in this except that are trying leverage existing transport protocols and implementation. Tom > That's also why other tunnels - which encapsulate transport through net > or link inside transport, net, or link - are much more architecturally > clean and have not generated this reaction. > > Joe From nobody Fri May 20 11:32: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 44A0012D5E8 for ; Fri, 20 May 2016 11:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 3JHhDBLGT7b0 for ; Fri, 20 May 2016 11:32:25 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 F277012D5C3 for ; Fri, 20 May 2016 11:32:24 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4KIVmmi019352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 20 May 2016 11:31:48 -0700 (PDT) To: Toerless Eckert References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> From: Joe Touch Message-ID: <573F5814.1040101@isi.edu> Date: Fri, 20 May 2016 11:31:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160520182115.GO2511@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u4KIVmmi019352 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 18:32:26 -0000 On 5/20/2016 11:21 AM, Toerless Eckert wrote: > ... >>> Don't think of it as UDP. Think of it as creating multiple layers inside the current >>> transport layer. The lowest layer is demultiplexing. Architecturally very clean. >> Here's why it's not: >> >> TCP isn't a layer by itself; it relies on the IP pseudoheader. > Ack. > >> TCP in UDP in IP is architecturally incomplete. > Right. but i am claiming that is possible and not too difficult. Eg: > remove TCP header port fields, just rely on UDP port fields, adopt > pseudoheader rules for TCP/UDP, etc. pp. But the port fields don't add entropy - you wouldn't want to do that within a transport. At best, they represent a portion of the entropy of the TCP ports. However, that's a poor (and smaller) substitute for the IPv6 flow field (and you are assuming IPv6). Further, you've just admitted this is a mess architecturally. >> TCP in IP in UDP in IP would be fine, as would TCP in IP in IP. But we >> already have those. >> That's why we don't need this and why it's a mess. > Still not clear how you jump from architectural incomplete to "no need, it's a mess". I've already repeatedly explained why this isn't needed, including the port demux issue above, as well as the existence of numerous other more appropriate tunneling mechanisms below. It's a mess exactly because of the hack you need to define an appropriate pseudoheader. Adding protocols and layers we don't actually need only makes the Internet architecture messier. >> That's also why other tunnels - which encapsulate transport through net >> or link inside transport, net, or link - are much more architecturally >> clean and have not generated this reaction. > I think network layer overlay solutions are architecturally fare less clean > that modularizing the transport layer and cleaning up historic dependencies > against network layer. If you want to clean up transport dependencies, have at it. That's not the goal of this doc. I've written quite a bit over the past 20 years about why network layer overlay solutions are architecturally clean. I'll let that work - and the prevalence of their current use - speak for itself. I've registered my position. At this point, it would be useful for others to speak up. Joe From nobody Fri May 20 11:32: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 10BDC12D566 for ; Fri, 20 May 2016 11:32:39 -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 0mobnFNntCuX for ; Fri, 20 May 2016 11:32:31 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001: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 F1ECB12DA7E for ; Fri, 20 May 2016 11:32:30 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id f8so23043307ioe.3 for ; Fri, 20 May 2016 11:32:30 -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:date:message-id:subject:from:to :cc; bh=7rj+KoZgZ4iifY/8HD22RFx8idF16SGOQwGW7ijU+rg=; b=c8dWpoxleajGsxgR62itzSUxeYPl4NO5ugkN1moFQTVpJe7K3m0FUPcNIs3kg1H0AL Zz6FlFUIKMuc+wVAfLO2phJwS3fG7q6GVZDOtrPQoTQsgjUl0lXhSll8Q74n8WBr2uof KjyfoBVaq6nFzdr04zgbADBNNJncZPVwlHt6ctKxlRfJITOObIWCyyfQPAv9SDyyPUpQ ECFFKgriaLTa+9v/E/HvGyH0YnYNgGtO7p9jFbHzOZnO9tORDO9SOdwwijSB0b0fGUXa 9riucQMAqoUwlQx9A1ekw4/Bi0T0HvHqGPB+2yMxe3KZ+33BqScXmuinQq6UiBVieh71 5Y4g== 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:date :message-id:subject:from:to:cc; bh=7rj+KoZgZ4iifY/8HD22RFx8idF16SGOQwGW7ijU+rg=; b=ZFX6vLXonCtBq3aVRsXpOLpUo2q+QoYarbWxyaRZHqAYi1Lk6ugOn1ozSCbw2vsPcy WcqLVCPmf+eAbMPOTLIOAHI/VGAZfUhst69dW3SMqLAEvS+dar7kNqZCjAZinwDs5bj4 4vLzPAegc7c+5FVLtDsN9iZBEHUah7UonwwoYw+K06z/mXUti9zk/qT+96HjaB/TMrFG /CFsESKjyN/FJygkux1QwKKRKRgoqA+jM18iseI/ErTnTNbtmQjHEbZCx5W9McnaDK5W quN//2PjS8oRVSre+ld+L70ynX3whtQXdkPHr0NmSWwBnze9LayIxBb20t+yeZAJnZFP JDJA== X-Gm-Message-State: AOPr4FVj30dg+g94kM4WtTV8i9J4yqJyL5TJS+lcBXwHlrUerPApKJuJY+YjYHwTnNpDR9zMrncJ5r9Fbt4Wig== MIME-Version: 1.0 X-Received: by 10.107.142.18 with SMTP id q18mr4253087iod.84.1463769150270; Fri, 20 May 2016 11:32:30 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Fri, 20 May 2016 11:32:30 -0700 (PDT) In-Reply-To: <20160520182115.GO2511@cisco.com> References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> Date: Fri, 20 May 2016 11:32:30 -0700 Message-ID: From: Tom Herbert To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: spud , Joe Touch Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 18:32:39 -0000 On Fri, May 20, 2016 at 11:21 AM, Toerless Eckert wrote: > Thanks, Joe, inline > > On Fri, May 20, 2016 at 10:22:08AM -0700, Joe Touch wrote: >> On 5/19/2016 6:24 PM, Toerless Eckert wrote: >> > On Thu, May 19, 2016 at 06:06:11PM -0700, Joe Touch wrote: >> >> I don't disagree with the potential benefits. I disagree with using UDP >> >> encapsulation to achieve an end-run around the OS exerting control. >> > Don't think of it as UDP. Think of it as creating multiple layers inside the current >> > transport layer. The lowest layer is demultiplexing. Architecturally very clean. >> Here's why it's not: >> >> TCP isn't a layer by itself; it relies on the IP pseudoheader. > > Ack. > >> TCP in UDP in IP is architecturally incomplete. > > Right. but i am claiming that is possible and not too difficult. Eg: > remove TCP header port fields, just rely on UDP port fields, adopt > pseudoheader rules for TCP/UDP, etc. pp. > NAT makes life complicated, especially if we want to have connections survive across UDP NAT address/port remapping. Most of the draft is about dealing with this. One nice feature (that I borrowed from QUIC) is to negotiate a shared session identifier for the connection that is unique to both sides. With this a connection is identified (at the end nodes) without using the addresses or UDP port numbers. So connection identification becomes location independent which solves the NAP remapping problem and also allows for mobility. Tom >> TCP in IP in UDP in IP would be fine, as would TCP in IP in IP. But we >> already have those. >> That's why we don't need this and why it's a mess. > > Still not clear how you jump from architectural incomplete to "no need, it's a mess". > >> That's also why other tunnels - which encapsulate transport through net >> or link inside transport, net, or link - are much more architecturally >> clean and have not generated this reaction. > > I think network layer overlay solutions are architecturally fare less clean > that modularizing the transport layer and cleaning up historic dependencies > against network layer. > > Toerless From nobody Fri May 20 11:40: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 E2EF412D1B3 for ; Fri, 20 May 2016 11:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 32SkBzeQlrjW for ; Fri, 20 May 2016 11:40:26 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 25AF812D56E for ; Fri, 20 May 2016 11:35:10 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4KIYnC4019543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 20 May 2016 11:34:49 -0700 (PDT) To: Tom Herbert References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> From: Joe Touch Message-ID: <573F58C9.8010605@isi.edu> Date: Fri, 20 May 2016 11:34:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u4KIYnC4019543 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Toerless Eckert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 18:40:27 -0000 On 5/20/2016 11:24 AM, Tom Herbert wrote: > On Fri, May 20, 2016 at 10:22 AM, Joe Touch wrote: >> >> On 5/19/2016 6:24 PM, Toerless Eckert wrote: >>> On Thu, May 19, 2016 at 06:06:11PM -0700, Joe Touch wrote: >>>> I don't disagree with the potential benefits. I disagree with using UDP >>>> encapsulation to achieve an end-run around the OS exerting control. >>> Don't think of it as UDP. Think of it as creating multiple layers inside the current >>> transport layer. The lowest layer is demultiplexing. Architecturally very clean. >> Here's why it's not: >> >> TCP isn't a layer by itself; it relies on the IP pseudoheader. >> >> TCP in UDP in IP is architecturally incomplete. >> >> TCP in IP in UDP in IP would be fine, as would TCP in IP in IP. But we >> already have those. >> >> That's why we don't need this and why it's a mess. >> > If it's more palatable we can accurately call this a new application > layer protocol that implements reliability and congestion control > instead of phrasing it encapsulation of TCP over UDP. You're trying very hard to find a nail for this hammer. Instead, you might consider DCCP or SCTP. If you need to tunnel those to transit a NAT, we already have support for that with other tunnel mechanisms. There is no clear rationale for needing this solution except to overcome OS implementation issues. Again, that is my position and I've made it fairly clear at this point. I'd like to see how others feel. Joe From nobody Fri May 20 12: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 084FC12D626 for ; Fri, 20 May 2016 12:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ok74p3l0_u2z for ; Fri, 20 May 2016 12:14:01 -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 1AA6312D5CE for ; Fri, 20 May 2016 12:14:01 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id E7F244B65CF60; Fri, 20 May 2016 19:13:51 +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 u4KJDsVs005034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 May 2016 19:13:54 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4KJDspx025751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 May 2016 21:13:54 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 20 May 2016 21:13:54 +0200 From: "Scharf, Michael (Nokia - DE)" To: Tom Herbert , Toerless Eckert Thread-Topic: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt Thread-Index: AQHRsfsP/nejVyQy8k+Tx9VhJVm8r5/Ae7eAgAALB4CAACDLgIAACaIAgAAC3gCAAB9RgIAADsGAgAAFH4CAAQuOAIAAEIWAgAADJACAACP3sA== Date: Fri, 20 May 2016 19:13:53 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Joe Touch , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 19:14:03 -0000 > NAT makes life complicated, especially if we want to have connections sur= vive across UDP NAT address/port remapping. Most of the draft is about deal= ing with this. One nice feature (that I borrowed from > QUIC) is to negotia= te a shared session identifier for the connection that is unique to both si= des. With this a connection is identified (at the end > nodes) without using the addresses or UDP port numbers. So connection ide= ntification becomes location independent which solves the NAP remapping pro= blem and also allows for mobility. Ahhh, Section 3.2 is really cool... I can clearly see the tremendous improvement for user privacy if the highly= privacy-sensitive TCP header fields finally get all encrypted, including t= hings like flags, sequence numbers etc., if there is now a new clear text i= dentifier that just happens to be unique per subscriber. What a great impro= vement for privacy in the Internet! And even better that it seems compatibl= e with QUIC... Sorry, I really could not resist. Michael From nobody Fri May 20 16:38: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 D70DA12D0DA for ; Fri, 20 May 2016 16:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, 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 6zLmj5tayQVh for ; Fri, 20 May 2016 16:38:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0746.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:746]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7C612D633 for ; Fri, 20 May 2016 16:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L8AK5kPEz1dwOhHJIZiyvA/zOlNPHagQUQQXFXjN2Fk=; b=WO0CEFrq6DGkskPM9cc8/UIsm/f/O5hrzg/kRajL/uX35JTX3+HqH7i3ay0Rg+zWmKCRU9aXFESs1V3C7Y9VUh7BcMwLvtg47c/h170Qe2RdaPPVIkAf9YDwEzqnkixs0Yu5rt5xwFRXv6OHIStDRWBQhcmeeEUsxP1hkWX74fU= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.497.12; Fri, 20 May 2016 23:38:07 +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.0492.020; Fri, 20 May 2016 23:38:07 +0000 From: Christian Huitema To: "Scharf, Michael (Nokia - DE)" , Tom Herbert , Toerless Eckert Thread-Topic: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt Thread-Index: AQHRsfsGYDSX8MgGWEKHGbttTcpdgJ/AnT6AgAALB4CAACDLgIAACaIAgAAC3wCAAB9QgIAADsGAgAAFH4CAAQuOAIAAEIWAgAADJACAAAuQgIAASC7A Date: Fri, 20 May 2016 23:38:07 +0000 Message-ID: References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [72.235.151.78] x-ms-office365-filtering-correlation-id: 90fba097-1bdc-459b-c8b0-08d38107cbc0 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:AVN01Fm6Tj1B0yWk5wFw/JP6YxRAUty5m5UaLif2KiG2Gsxp5VcM2FhUYi7rn5QnHQdtiH3NKphbGNVFKKBC66Wz5waor39tsYmV8UseJ+Jxgf2kGo3p4Zkn7YmblfM/hSTYmUJTkYD61dhQPC2EHg==; 24:6GXcZ+2MvEMbBEhFo4O/6f8M3HyaUrglBGx3r2PN6axVf2X7ZSjY2urnKisJbe+tgf4q33JqHH/1+IptxL1Ag/iYL/nkFBAKhXyxOXgIXbc=; 7:Jug9DzW5aRGebvhXE9RaCEZWHt4BRWvOpetcbyEvScTR3RmAuiafa94PjV8GSf9lan8NmCFxCGIsE5AegZ4g0/3B3eHkxpePhpQHbwn2JdK5Mh/j3SeBfNFNJ+ZTwhTlbLVz6KAU6bo5E5syVwsWOSHKrdtk8WI1Q1dRkE4STrPSqrx3g6q+ZITw/KsIYi3PR2zwL3CdZVA74eBd7T5kSA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(1220700001)(77096005)(5008740100001)(2900100001)(4326007)(2950100001)(2906002)(3846002)(8936002)(10400500002)(10290500002)(76576001)(5003600100002)(3660700001)(8676002)(230783001)(6116002)(5001770100001)(5005710100001)(189998001)(9686002)(3280700002)(5002640100001)(66066001)(81166006)(19580405001)(106116001)(93886004)(76176999)(54356999)(99286002)(50986999)(10090500001)(11100500001)(102836003)(33656002)(74316001)(86362001)(122556002)(87936001)(19580395003)(92566002)(15650500001)(586003)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 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: 20 May 2016 23:38:07.0660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Cc: spud , Joe Touch Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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, 20 May 2016 23:38:27 -0000 On Friday, May 20, 2016 9:14 AM, Michael Scharf wrote:=20 > To: Tom Herbert ; Toerless Eckert > > Cc: Joe Touch ; spud > Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert- > transports-over-udp-00.txt >=20 > > NAT makes life complicated, especially if we want to have connections > survive across UDP NAT address/port remapping. Most of the draft is about > dealing with this. One nice feature (that I borrowed from > QUIC) is to > negotiate a shared session identifier for the connection that is unique t= o both > sides. With this a connection is identified (at the end > > nodes) without using the addresses or UDP port numbers. So connection > identification becomes location independent which solves the NAP > remapping problem and also allows for mobility. >=20 > Ahhh, Section 3.2 is really cool... >=20 > I can clearly see the tremendous improvement for user privacy if the high= ly > privacy-sensitive TCP header fields finally get all encrypted, including = things > like flags, sequence numbers etc., if there is now a new clear text ident= ifier > that just happens to be unique per subscriber. What a great improvement f= or > privacy in the Internet! And even better that it seems compatible with QU= IC... >=20 > Sorry, I really could not resist. Actually, using a 64 bit QUIC-like identifier to support mobility or multi = path is a terrible idea. The best way to describe it is, "clear text super = cookie." It allows adversaries to link connections originating from differe= nt IP addresses. Providing such linkability is a boon for traffic analysis = and user tracking, and of course a big loss for privacy. And yes, MP-TCP is= doing something similar, but at least they acknowledge the problem and wan= t to find a solution. If we want privacy, the identifiers used to link seve= ral connections together have to be placed inside the crypto envelope, not = in a clear text header. -- Christian Huitema From nobody Fri May 20 23:04: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 A378E12D1CB for ; Fri, 20 May 2016 23:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 T16_prdiVHaY for ; Fri, 20 May 2016 23:04: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 1069A12D1A0 for ; Fri, 20 May 2016 23:04:44 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 90431C37FF6FE; Sat, 21 May 2016 06:04: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 u4L64gFu030551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 May 2016 06:04:42 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4L64fst030896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 21 May 2016 08:04:41 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sat, 21 May 2016 08:04:41 +0200 From: "Scharf, Michael (Nokia - DE)" To: Christian Huitema , Tom Herbert , Toerless Eckert Thread-Topic: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt Thread-Index: AQHRsfsP/nejVyQy8k+Tx9VhJVm8r5/Ae7eAgAALB4CAACDLgIAACaIAgAAC3gCAAB9RgIAADsGAgAAFH4CAAQuOAIAAEIWAgAADJACAACP3sIAAMW2AgAB+7bA= Date: Sat, 21 May 2016 06:04:39 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4886128D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: spud , Joe Touch Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Sat, 21 May 2016 06:04:46 -0000 > > I can clearly see the tremendous improvement for user privacy if the > highly > > privacy-sensitive TCP header fields finally get all encrypted, > including things > > like flags, sequence numbers etc., if there is now a new clear text > identifier > > that just happens to be unique per subscriber. What a great > improvement for > > privacy in the Internet! And even better that it seems compatible > with QUIC... > > > > Sorry, I really could not resist. >=20 > Actually, using a 64 bit QUIC-like identifier to support mobility or > multi path is a terrible idea. The best way to describe it is, "clear > text super cookie." It allows adversaries to link connections > originating from different IP addresses. Providing such linkability is > a boon for traffic analysis and user tracking, and of course a big loss > for privacy. And yes, MP-TCP is doing something similar, but at least > they acknowledge the problem and want to find a solution. If we want > privacy, the identifiers used to link several connections together have > to be placed inside the crypto envelope, not in a clear text header. But in a user space UDP-based transport protocol the app has full control o= ver how the super cookie is used, and where it is placed in the packet, rig= ht? What prevents this from becoming the common substrate for super cookies? Michael From nobody Sat May 21 07: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 11F2A12D58A for ; Sat, 21 May 2016 07:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 VlTj24-F5LHr for ; Sat, 21 May 2016 07:23:59 -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 98C1812D1E8 for ; Sat, 21 May 2016 07:23:59 -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.0195.001; Sat, 21 May 2016 10:23:57 -0400 From: Dave Dolson To: Joe Touch , Tom Herbert Thread-Topic: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt Thread-Index: AQHRsfsEcdzexRgd/ESGO9c6erL1Vp/A4EyAgAALB4CAACDLgIAACaIAgAAC3wCAAB9RgIAADsCAgAAFH4CAAQuOAIAAEYaAgAACyYCAAQkwwA== Date: Sat, 21 May 2016 14:23:57 +0000 Message-ID: <20160521142356.5697621.84991.85659@sandvine.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> , <573F58C9.8010605@isi.edu> In-Reply-To: <573F58C9.8010605@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Toerless Eckert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Sat, 21 May 2016 14:24:01 -0000 Another way of explaining the need for PLUS is that the internet architectu= re is deficient because it only provides connectivity between hosts, wherea= s there is a need to provide connectivity between applications running on h= osts. This is becoming more relevant as processes are jailed (using various= approaches) for security. Raw sockets require root privilege to prevent different apps from reading o= r forging each others' packets. I think this restriction still makes sense = on single-user machines=FD, so it would not be right to say the fix is to l= oosen O/S security. So, one role of the PLUS layer is to extend the network-layer address to be= ing able to address the application at IP address + port. This is why I don't think there is a layering travesty here. It's redefinin= g the network layer to be between applications. -Dave Original Message From: Joe Touch Sent: Friday, May 20, 2016 2:40 PM To: Tom Herbert Cc: Toerless Eckert; spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transpo= rts-over-udp-00.txt On 5/20/2016 11:24 AM, Tom Herbert wrote: > On Fri, May 20, 2016 at 10:22 AM, Joe Touch wrote: >> >> On 5/19/2016 6:24 PM, Toerless Eckert wrote: >>> On Thu, May 19, 2016 at 06:06:11PM -0700, Joe Touch wrote: >>>> I don't disagree with the potential benefits. I disagree with using UD= P >>>> encapsulation to achieve an end-run around the OS exerting control. >>> Don't think of it as UDP. Think of it as creating multiple layers insid= e the current >>> transport layer. The lowest layer is demultiplexing. Architecturally ve= ry clean. >> Here's why it's not: >> >> TCP isn't a layer by itself; it relies on the IP pseudoheader. >> >> TCP in UDP in IP is architecturally incomplete. >> >> TCP in IP in UDP in IP would be fine, as would TCP in IP in IP. But we >> already have those. >> >> That's why we don't need this and why it's a mess. >> > If it's more palatable we can accurately call this a new application > layer protocol that implements reliability and congestion control > instead of phrasing it encapsulation of TCP over UDP. You're trying very hard to find a nail for this hammer. Instead, you might consider DCCP or SCTP. If you need to tunnel those to transit a NAT, we already have support for that with other tunnel mechanisms. There is no clear rationale for needing this solution except to overcome OS implementation issues. Again, that is my position and I've made it fairly clear at this point. I'd like to see how others feel. Joe _______________________________________________ Spud mailing list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud From nobody Sat May 21 08:53: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 E406012B062 for ; Sat, 21 May 2016 08:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 KvxG4Edfa08Z for ; Sat, 21 May 2016 08:53:03 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11F3128E19 for ; Sat, 21 May 2016 08:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1934; q=dns/txt; s=iport; t=1463845982; x=1465055582; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Bu6gQs4rYbEY5d4MmuiHTt3SGMbXA6eExjwYom9RS6s=; b=L/QF5jweNOruoIju2FC8N5glHp76LOz5B6dD73mcOevbWVpTsuUZBDMd nNqZL5guhwC5fCCQsS7RqkWQLsFNVlmURTHOsZcaZO5SQuz13lTaiA7EP x/84BwGY9WN+VrEAoVFgsibcj6y8173Xp/Twew5QoZoP+ij/+V0wckvwq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgAThEBX/40NJK1TCYM3gVO5fwENg?= =?us-ascii?q?XWGEQKBIzgUAQEBAQEBAWUnhEMBAQQ6PQIQCxgJJQ8FSRMbiBTDZAEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBHYlxgQOEGIYBAQSOWYlejhYKgWmHe4U4j0weAQFCgjiBV?= =?us-ascii?q?RwyiUABAQE?= X-IronPort-AV: E=Sophos;i="5.26,344,1459814400"; d="scan'208";a="105006126" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 May 2016 15:53:01 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u4LFr1V7026105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 May 2016 15:53:01 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 u4LFr1wa029800; Sat, 21 May 2016 08:53:01 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4LFr0cO029799; Sat, 21 May 2016 08:53:00 -0700 Date: Sat, 21 May 2016 08:53:00 -0700 From: Toerless Eckert To: Christian Huitema Message-ID: <20160521155300.GV2511@cisco.com> References: <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> 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: Tom Herbert , "Scharf, Michael \(Nokia - DE\)" , spud , Joe Touch Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Sat, 21 May 2016 15:53:04 -0000 On Fri, May 20, 2016 at 11:38:07PM +0000, Christian Huitema wrote: > > I can clearly see the tremendous improvement for user privacy if the highly > > privacy-sensitive TCP header fields finally get all encrypted, including things > > like flags, sequence numbers etc., if there is now a new clear text identifier > > that just happens to be unique per subscriber. What a great improvement for > > privacy in the Internet! And even better that it seems compatible with QUIC... > > > > Sorry, I really could not resist. > > Actually, using a 64 bit QUIC-like identifier to support mobility or multi path is a terrible idea. The best way to describe it is, "clear text super cookie." It allows adversaries to link connections originating from different IP addresses. Providing such linkability is a boon for traffic analysis and user tracking, and of course a big loss for privacy. And yes, MP-TCP is doing something similar, but at least they acknowledge the problem and want to find a solution. If we want privacy, the identifiers used to link several connections together have to be placed inside the crypto envelope, not in a clear text header. Is there actually some good text to read up on how today tracking of IP addresses is used today by any party with only transit-path access, aka: anyone who is neither one of my access-SP nor one of the cloud services i talk to and provide an app-level-identity to. And neither a party in collusion with these, exchanging info with them. I am asking, because i need legal protection against perpass by those parties, not technical ones. Or competition that does give me legal promises beyond what the law guarantees me by default. Eg: doing improvements on this piece and declaring privacy achieved when you've got it encrypted looks like security theater to me. Toerless > > -- Christian Huitema > > -- --- Toerless Eckert, eckert@cisco.com From nobody Sat May 21 08:53: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 0409A128E19 for ; Sat, 21 May 2016 08:53: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, 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 Mi-4ObV5eTRI for ; Sat, 21 May 2016 08:53:21 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 605EB12B062 for ; Sat, 21 May 2016 08:53:21 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id ww4so10085889igb.1 for ; Sat, 21 May 2016 08:53:21 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=4rma0YrxTSwOh++iguKk9TTtYeyau7h616mcdUzx4IY=; b=d2962ucuDEVYtGDyUbWpQruAG0U2QAYrG7BZ9QSYQJAvPXQ++3KnvIiGYvryXbMpVk 7A+jpRia0Lv8oNY9zawq9fV0nh9UabU8vCgWo5jTJv953jlSJH/YuHjGKcpwnFyhq6yw ErV0L3nNarPclrv/rRMYN9VJ4PZYIychlb0oiPZ9XdQtOVHLeTzN//IkKgr+pMO0Wmu5 iwasqZIFkMHwIM8DPb3lWU0gHUKxl4+O9w2q3ShM7pwhl5m/PRzEZ4Sxh7AbG7jp633B 4KrEkpaTKYHxhDuF8tjz/FOFwNLcMz7fm/Kz6dpUA+kHbRQWINDOzjoVzBM91gj2NS/k Mk6g== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=4rma0YrxTSwOh++iguKk9TTtYeyau7h616mcdUzx4IY=; b=mWSlGGRCLwqzK97GIdwfVq0s6Z9ue8Fns3I7GgQV2Lfx1HCBK+RKorDmYaHNDDtSy9 0FcPp0ufhH9CmppCoJIBIb6xmLAhtg86PMuh9rGBRoASnBzgbsb1zL5fhsOk9qCCTj9W W/u0H2MYWUX8i5/7qHEFsiI3+Qv2toOi2pqo+s1zqF9Tkb+z3WP8IWDQF217Dd+4m4FP UJTmTOJtLzUN6yNgpF7oeEwAiAhxOvNI3xS8iBx1GjjzRFUE8Tk1a0Y8/UVzRDzpFeP6 latQEZI0M4r6SmSv2BlHLSqGYgGOcL2L057IvXj05tMr66kJXUE3gnwyqalgDcXlrPTL EgxA== X-Gm-Message-State: AOPr4FXrC4173Pj2v/H1DaqNXPJQr8U5V7UdtiRwWbzlGVQ/RFsFozd2leU4xmTPZhzyTNpNzGb/J2vG7Sq6rA== MIME-Version: 1.0 X-Received: by 10.50.205.8 with SMTP id lc8mr7275795igc.94.1463846000587; Sat, 21 May 2016 08:53:20 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Sat, 21 May 2016 08:53:20 -0700 (PDT) In-Reply-To: References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Sat, 21 May 2016 08:53:20 -0700 Message-ID: From: Tom Herbert To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Toerless Eckert , "Scharf, Michael \(Nokia - DE\)" , spud , Joe Touch Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Sat, 21 May 2016 15:53:23 -0000 On Fri, May 20, 2016 at 4:38 PM, Christian Huitema wrote: > On Friday, May 20, 2016 9:14 AM, Michael Scharf wrote: >> To: Tom Herbert ; Toerless Eckert >> >> Cc: Joe Touch ; spud >> Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert- >> transports-over-udp-00.txt >> >> > NAT makes life complicated, especially if we want to have connections >> survive across UDP NAT address/port remapping. Most of the draft is abou= t >> dealing with this. One nice feature (that I borrowed from > QUIC) is to >> negotiate a shared session identifier for the connection that is unique = to both >> sides. With this a connection is identified (at the end >> > nodes) without using the addresses or UDP port numbers. So connection >> identification becomes location independent which solves the NAP >> remapping problem and also allows for mobility. >> >> Ahhh, Section 3.2 is really cool... >> >> I can clearly see the tremendous improvement for user privacy if the hig= hly >> privacy-sensitive TCP header fields finally get all encrypted, including= things >> like flags, sequence numbers etc., if there is now a new clear text iden= tifier >> that just happens to be unique per subscriber. What a great improvement = for >> privacy in the Internet! And even better that it seems compatible with Q= UIC... >> >> Sorry, I really could not resist. > > Actually, using a 64 bit QUIC-like identifier to support mobility or mult= i path is a terrible idea. The best way to describe it is, "clear text supe= r cookie." It allows adversaries to link connections originating from diffe= rent IP addresses. Providing such linkability is a boon for traffic analysi= s and user tracking, and of course a big loss for privacy. And yes, MP-TCP = is doing something similar, but at least they acknowledge the problem and w= ant to find a solution. If we want privacy, the identifiers used to link se= veral connections together have to be placed inside the crypto envelope, no= t in a clear text header. > We assume that strong security must be applied, so unlike MP-TCP the transport headers are encrypted and the only information sent in plain text is the session identifier (serving as an SPI) and DTLS headers. In the case of a connection surviving across NAT remapping an attacker could observe that the connection has been remapped, but that reveals no new information about the connection than it had previously except that the it was remapped by an intermediate device. That does potentially reveal information about the NAT device, for instance it could probably ascertain the timeout, but I don't know how useful that would be in and it could probably be determined by other means. But even given that, yes, I would prefer that anything that identifies flows on the network (UDP tuples, session identifiers, flow labels) is periodically rotated to reduce the ability of intermediate nodes to track my flows over long periods of time. The protocol to negotiate a new session identifier can be implemented in the encrypted portion of the packet. To change the UDP tuple a client can pick a different ephemeral source port (in userspace sockets implementation this would close one socket and create a new and do a connect without explicit bind). Tom > -- Christian Huitema > > From nobody Sat May 21 20:03: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 DC49E12B068 for ; Sat, 21 May 2016 20:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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.426, SPF_PASS=-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 jWUsOZTGnX7M for ; Sat, 21 May 2016 20:03:28 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 55CEA12B005 for ; Sat, 21 May 2016 20:03:28 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id x189so143050697ywe.3 for ; Sat, 21 May 2016 20:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=SLr+yO2Eu7+q4Klrzuj5MABOKSKdbRHzKRPwDbD7VIc=; b=GocwNwhvLFn0QfNCMm9xPM/fP87jGe59uvKL8USiFmhWwQS0LN4wcWDYCNA5QORFhT ZeM2k9h4odvPB1KWuCwDbXtSj8EX3l9cA7fmIxFHrpAHzkz6AF1LLPqJ9h3MlXh6wA4m MPvmKZKRFHXhOLFrcoQLW7vlOuV5OTD3oxyZsNNxBjj91P1L/b1W6mpp5ns3i8RfRT0w lbEcEH6wWTyiXHET8yc7Dbe+zw4dGJamNBvrgKwkCZlPs3KiBLAFPqnDx+/QtzwQEkLw LjHk6MS/48tH9S5pwX0ePrXHJGz2ZeWr2NuLYsjJ8ZjipFErB3P++ChSjj/TojbWONh6 zh3g== 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:date :message-id:subject:from:to:cc; bh=SLr+yO2Eu7+q4Klrzuj5MABOKSKdbRHzKRPwDbD7VIc=; b=eNjR0J8vZJgnPBbBn8EgZYlnFPDY0fjjqoZiwmB8QRyCheNjCItXZc8bZVjzYjpU1Y si/SQzmA7qfcjYE26gbebzjC2msSObuOFUR17qzwAUkY7ZPbBJq/OqkDwjQ0n9nGgvkh vGkPX1vENNEkkK7a4WBX+0nLl8zgGZVHdx2wQPSKCDe9auuvi3Tc0TviPzKMPvQE37LP mPKPEPn+ISsFqVM0Z53wyHThmykjr8nVKy+Nu3VLcNU2wOBmMW5O3ETjbqk40vz08pBh /dxCBnlQiVygaF/eYEbKzcFrEOXq/HDIjN1COIp9pTDEh9309XHa6UMOpEO+XKxYhmnU JX5Q== X-Gm-Message-State: AOPr4FVSdSKBJlkAWwOPyFLNnSZBwVzAdpShj8me1ulj55UQjUxxbtf2Oi4FxisG0lIx6BFhN82StziCVPG7q8uf MIME-Version: 1.0 X-Received: by 10.13.198.197 with SMTP id i188mr5711553ywd.207.1463886207316; Sat, 21 May 2016 20:03:27 -0700 (PDT) Received: by 10.37.221.193 with HTTP; Sat, 21 May 2016 20:03:26 -0700 (PDT) Received: by 10.37.221.193 with HTTP; Sat, 21 May 2016 20:03:26 -0700 (PDT) In-Reply-To: References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Sat, 21 May 2016 20:03:26 -0700 Message-ID: From: Jana Iyengar To: Tom Herbert Content-Type: multipart/alternative; boundary=001a114d6f746181ed05336591b2 Archived-At: Cc: Christian Huitema , "Toerless Eckert \(eckert\)" , Joe Touch , "Scharf, Michael \(Nokia - DE\)" , spud@ietf.org Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Sun, 22 May 2016 03:03:31 -0000 --001a114d6f746181ed05336591b2 Content-Type: text/plain; charset=UTF-8 Possibly unsurprisingly, I like this draft. I'd like to argue some of the choices made in the draft but I'll do that separately. For now, I just wanted to articulate a few thoughts as I caught up on this thread: - The ship has sailed on new native-IP transports. I worked on SCTP for 6 years and tried and watched it get nowhere in terms of deployment over native-IP. It wasn't because it was in the kernel, it was primarily because of NATs and various middleboxes. Yes this is definitely my opinion, but arguing this point is silly. No new native IP transport has seen significant deployment over the internet over the past 20 years, and it's not for lack of trying. - People reasonably consider timescales of a few years when thinking about building and deploying a new transport. QUIC took a few years to build and deploy over UDP, and the Adobe folks did RTMFP over UDP as well (a while ago) in a reasonable time frame. - Encryption is the *only* way to attempt avoiding ossification. Its certainly reasonable to consider that it may not do the job, but without an alternative, I'm afraid it will have to do for now. - Michael raised a point about QUIC connection ID, which is incorrect: The QUIC connection ID is NOT unique per user. It's a connection ID, and on a single-path connection, it exposes exactly as much as TCP, DCCP, or SCTP do (unique per 4-tuple). On a multipath connection, it exposes exactly as much as MPTCP does. We can perhaps do better than MPTCP for multipath in terms of privacy, I don't want to engage on this point on this thread since it's not relevant to this thread. - jana On May 21, 2016 8:53 AM, "Tom Herbert" wrote: > On Fri, May 20, 2016 at 4:38 PM, Christian Huitema > wrote: > > On Friday, May 20, 2016 9:14 AM, Michael Scharf wrote: > >> To: Tom Herbert ; Toerless Eckert > >> > >> Cc: Joe Touch ; spud > >> Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert- > >> transports-over-udp-00.txt > >> > >> > NAT makes life complicated, especially if we want to have connections > >> survive across UDP NAT address/port remapping. Most of the draft is > about > >> dealing with this. One nice feature (that I borrowed from > QUIC) is to > >> negotiate a shared session identifier for the connection that is unique > to both > >> sides. With this a connection is identified (at the end > >> > nodes) without using the addresses or UDP port numbers. So connection > >> identification becomes location independent which solves the NAP > >> remapping problem and also allows for mobility. > >> > >> Ahhh, Section 3.2 is really cool... > >> > >> I can clearly see the tremendous improvement for user privacy if the > highly > >> privacy-sensitive TCP header fields finally get all encrypted, > including things > >> like flags, sequence numbers etc., if there is now a new clear text > identifier > >> that just happens to be unique per subscriber. What a great improvement > for > >> privacy in the Internet! And even better that it seems compatible with > QUIC... > >> > >> Sorry, I really could not resist. > > > > Actually, using a 64 bit QUIC-like identifier to support mobility or > multi path is a terrible idea. The best way to describe it is, "clear text > super cookie." It allows adversaries to link connections originating from > different IP addresses. Providing such linkability is a boon for traffic > analysis and user tracking, and of course a big loss for privacy. And yes, > MP-TCP is doing something similar, but at least they acknowledge the > problem and want to find a solution. If we want privacy, the identifiers > used to link several connections together have to be placed inside the > crypto envelope, not in a clear text header. > > > We assume that strong security must be applied, so unlike MP-TCP the > transport headers are encrypted and the only information sent in plain > text is the session identifier (serving as an SPI) and DTLS headers. > In the case of a connection surviving across NAT remapping an attacker > could observe that the connection has been remapped, but that reveals > no new information about the connection than it had previously except > that the it was remapped by an intermediate device. That does > potentially reveal information about the NAT device, for instance it > could probably ascertain the timeout, but I don't know how useful that > would be in and it could probably be determined by other means. > > But even given that, yes, I would prefer that anything that identifies > flows on the network (UDP tuples, session identifiers, flow labels) is > periodically rotated to reduce the ability of intermediate nodes to > track my flows over long periods of time. The protocol to negotiate a > new session identifier can be implemented in the encrypted portion of > the packet. To change the UDP tuple a client can pick a different > ephemeral source port (in userspace sockets implementation this would > close one socket and create a new and do a connect without explicit > bind). > > Tom > > > > > > > > -- Christian Huitema > > > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --001a114d6f746181ed05336591b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Possibly unsurprisingly, I like this draft. I'd like to = argue some of the choices made in the draft but I'll do that separately= . For now, I just wanted to articulate a few thoughts as I caught up on thi= s thread:

- The ship has sailed on new native-IP transports. I worked = on SCTP for 6 years and tried and watched it get nowhere in terms of deploy= ment over native-IP. It wasn't because it was in the kernel, it was pri= marily because of NATs and various middleboxes. Yes this is definitely my o= pinion, but arguing this point is silly. No new native IP transport has see= n significant deployment over the internet over the past 20 years, and it&#= 39;s not for lack of trying.

- People reasonably consider timescales of a few years when = thinking about building and deploying a new transport. QUIC took a few year= s to build and deploy over UDP, and the Adobe folks did RTMFP over UDP as w= ell (a while ago) in a reasonable time frame.

- Encryption is the *only* way to attempt avoiding ossificat= ion. Its certainly reasonable to consider that it may not do the job, but w= ithout an alternative, I'm afraid it will have to do for now.

- Michael raised a point about QUIC connection ID, which is = incorrect: The QUIC connection ID is NOT unique per user. It's a connec= tion ID, and on a single-path connection, it exposes exactly as much as TCP= , DCCP, or SCTP do (unique per 4-tuple). On a multipath connection, it expo= ses exactly as much as MPTCP does. We can perhaps do better than MPTCP for = multipath in terms of privacy, I don't want to engage on this point on = this thread since it's not relevant to this thread.

- jana

On May 21, 2016 8:53 AM, "Tom Herbert"= <tom@herbertland.com> wro= te:
On Fri, May 20, = 2016 at 4:38 PM, Christian Huitema
<huitema@microsoft.com> = wrote:
> On Friday, May 20, 2016 9:14 AM, Michael Scharf wrote:
>> To: Tom Herbert <tom@her= bertland.com>; Toerless Eckert
>> <eckert@cisco.com> >> Cc: Joe Touch <touch@isi.edu>; spud <spud@ietf.org>
>> Subject: Re: [Spud] Fwd: New Version Notification for draft-herber= t-
>> transports-over-udp-00.txt
>>
>> > NAT makes life complicated, especially if we want to have con= nections
>> survive across UDP NAT address/port remapping. Most of the draft i= s about
>> dealing with this. One nice feature (that I borrowed from > QUI= C) is to
>> negotiate a shared session identifier for the connection that is u= nique to both
>> sides. With this a connection is identified (at the end
>> > nodes) without using the addresses or UDP port numbers. So co= nnection
>> identification becomes location independent which solves the NAP >> remapping problem and also allows for mobility.
>>
>> Ahhh, Section 3.2 is really cool...
>>
>> I can clearly see the tremendous improvement for user privacy if t= he highly
>> privacy-sensitive TCP header fields finally get all encrypted, inc= luding things
>> like flags, sequence numbers etc., if there is now a new clear tex= t identifier
>> that just happens to be unique per subscriber. What a great improv= ement for
>> privacy in the Internet! And even better that it seems compatible = with QUIC...
>>
>> Sorry, I really could not resist.
>
> Actually, using a 64 bit QUIC-like identifier to support mobility or m= ulti path is a terrible idea. The best way to describe it is, "clear t= ext super cookie." It allows adversaries to link connections originati= ng from different IP addresses. Providing such linkability is a boon for tr= affic analysis and user tracking, and of course a big loss for privacy. And= yes, MP-TCP is doing something similar, but at least they acknowledge the = problem and want to find a solution. If we want privacy, the identifiers us= ed to link several connections together have to be placed inside the crypto= envelope, not in a clear text header.
>
We assume that strong security must be applied, so unlike MP-TCP the
transport headers are encrypted and the only information sent in plain
text is the session identifier (serving as an SPI) and DTLS headers.
In the case of a connection surviving across NAT remapping an attacker
could observe that the connection has been remapped, but that reveals
no new information about the connection than it had previously except
that the it was remapped by an intermediate device. That does
potentially reveal information about the NAT device, for instance it
could probably ascertain the timeout, but I don't know how useful that<= br> would be in and it could probably be determined by other means.

But even given that, yes, I would prefer that anything that identifies
flows on the network (UDP tuples, session identifiers, flow labels) is
periodically rotated to reduce the ability of intermediate nodes to
track my flows over long periods of time. The protocol to negotiate a
new session identifier can be implemented in the encrypted portion of
the packet. To change the UDP tuple a client can pick a different
ephemeral source port (in userspace sockets implementation this would
close one socket and create a new and do a connect without explicit
bind).

Tom






> -- Christian Huitema
>
>

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud
--001a114d6f746181ed05336591b2-- From nobody Sat May 21 21: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 B5CD812D1DF for ; Sat, 21 May 2016 21:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 oGDAfoTr_Vmn for ; Sat, 21 May 2016 21:14:56 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 1241812D1BC for ; Sat, 21 May 2016 21:14:56 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4M4EAY4007416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 21 May 2016 21:14:12 -0700 (PDT) To: Dave Dolson , Tom Herbert References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <573F58C9.8010605@isi.edu> <20160521142356.5697621.84991.85659@sandvine.com> From: Joe Touch Message-ID: <57413212.4040406@isi.edu> Date: Sat, 21 May 2016 21:14:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160521142356.5697621.84991.85659@sandvine.com> Content-Type: multipart/alternative; boundary="------------020709040906090608070509" X-MailScanner-ID: u4M4EAY4007416 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Toerless Eckert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Sun, 22 May 2016 04:14:58 -0000 This is a multi-part message in MIME format. --------------020709040906090608070509 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 8bit On 5/21/2016 7:23 AM, Dave Dolson wrote: > Another way of explaining the need for PLUS is that the internet architecture is deficient because it only provides connectivity between hosts, whereas there is a need to provide connectivity between applications running on hosts. Tunnels already provide that. A tunnel is fundamentally a link layer over which network layer(s) transit. UDP/IP can provide that capability through a variety of existing ways. However, it's nonsensical to expect a transport to use a tunnel directly, just as TCP doesn't run over Ethernet. > This is becoming more relevant as processes are jailed (using various approaches) for security. > > Raw sockets require root privilege to prevent different apps from reading or forging each others' packets. I think this restriction still makes sense on single-user machinesý, so it would not be right to say the fix is to loosen O/S security. Again, now you're getting at an OS implementation issue. That is never usefully fixed by the network architecture. > So, one role of the PLUS layer is to extend the network-layer address to being able to address the application at IP address + port. That's what IP in UDP already accomplishes. > This is why I don't think there is a layering travesty here. It's redefining the network layer to be between applications. Apps live inside hosts, and are identified by transport ports. Hosts are identified by IP addresses. If you have a host inside a host, you need to treat the outer host as a router+host, and the guest OSes as other hosts on that router. See: J. Touch, T. Faber, “Dynamic Host Routing for Production Use of Developmental Networks ,” in /Proc. ICNP ’97/, Atlanta, Oct. 1997, pp. 285-292. There's no problem solving any of this with a network layer inside UDP. The problem is assuming that you can virtualize a network using just the transport layer - a layer that fundamentally depends on addresses at a network layer you fail to provide. UDP already is used for tunnels in ways that solve this problem correctly. Why do we need an incorrect approach? Joe --------------020709040906090608070509 Content-Type: text/html; charset=windows-1256 Content-Transfer-Encoding: 8bit

On 5/21/2016 7:23 AM, Dave Dolson wrote:
Another way of explaining the need for PLUS is that the internet architecture is deficient because it only provides connectivity between hosts, whereas there is a need to provide connectivity between applications running on hosts.

Tunnels already provide that.

A tunnel is fundamentally a link layer over which network layer(s) transit. UDP/IP can provide that capability through a variety of existing ways.

However, it's nonsensical to expect a transport to use a tunnel directly, just as TCP doesn't run over Ethernet.

This is becoming more relevant as processes are jailed (using various approaches) for security.

Raw sockets require root privilege to prevent different apps from reading or forging each others' packets. I think this restriction still makes sense on single-user machinesý, so it would not be right to say the fix is to loosen O/S security.

Again, now you're getting at an OS implementation issue. That is never usefully fixed by the network architecture. 


So, one role of the PLUS layer is to extend the network-layer address to being able to address the application at IP address + port.
That's what IP in UDP already accomplishes.
This is why I don't think there is a layering travesty here. It's redefining the network layer to be between applications.

Apps live inside hosts, and are identified by transport ports. Hosts are identified by IP addresses. If you have a host inside a host, you need to treat the outer host as a router+host, and the guest OSes as other hosts on that router. See:
J. Touch, T. Faber, “Dynamic Host Routing for Production Use of Developmental Networks,” in Proc. ICNP ’97, Atlanta, Oct. 1997, pp. 285-292.

There's no problem solving any of this with a network layer inside UDP. The problem is assuming that you can virtualize a network using just the transport layer - a layer that fundamentally depends on addresses at a network layer you fail to provide.

UDP already is used for tunnels in ways that solve this problem correctly. Why do we need an incorrect approach?

Joe
--------------020709040906090608070509-- From nobody Sat May 21 21:21: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 B5DC312D1AE for ; Sat, 21 May 2016 21:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, 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 sSXh8sMVoEHS for ; Sat, 21 May 2016 21:21:32 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (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 80DC912D141 for ; Sat, 21 May 2016 21:21:32 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id w36so77050815qge.3 for ; Sat, 21 May 2016 21:21:32 -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:date:message-id:subject :from:to:cc; bh=wU08I2ZG10b2fmIPa9LwHOccoGJhUMJmgP8DNKpnQ8w=; b=CZzwcG+jm3Nl6lM03/hOeaFfCqWUn6t/QEP7JMSGtvMi5weUQpufiK8ZVhcDn8HmXj Tjt/gxfmhyVv2noCuSDcMDjZoYVuzyzEEz/ti+SCnSLmFI0e3hVEEjvlySujJebbfmhU uczje2tnwCh7f8B3lysn7gX+hgTzExEgOvCG++lVBSgJmLkDfKF06TiLKsaNKXenCa05 Nq/iGYZJKtLApCDwH1EpUh5IqturJdemWjWzAa8yNuIegs2/uO0QLtSgvRz6yy1HCDI5 oTsvbH5kpVDhTEquWrRghKiVb34qfa51ib4cgb/U3lBJTLyo5yXiq7SjBs78jHqNh34F cINw== 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:date :message-id:subject:from:to:cc; bh=wU08I2ZG10b2fmIPa9LwHOccoGJhUMJmgP8DNKpnQ8w=; b=DmACwJm0gx6jFetgtUe5Bf6d+M/eKGSeOdzcnOWBao4Lj8XzX2E6A0oDYxUesCoMmL jGoxpQI+d0EWAGhE9G54EO7GpBYOolH1u18gImdHMRhgKuqp3TI9aiAZ3PUKQv3yBuZ1 FNEBUsDbTizwOQWjWLa5lqR8nbup/fXCbu5sFGNkTReSYorSIddWJN2JoZBhaulv7YUq id7ZP4ktfOsfB+xZnQdMCOntL4kHxfKsWaNfuf35eqi2xJboFn5tybOiweTFERjSsxoj ywGKlKxM6uOcU4NxblIFOrpWDiFxatt98m5Zzeh3C5ioccr6C0qNZDIYIXPD6IdilJY7 M9GA== X-Gm-Message-State: AOPr4FVd257mqZMAzxylGmxGEbeonHYZbkufrjGZfqvjiTkEc4SDmEZpKNQL2jsUT97U8PdUz1lnP3CsfvXO4w== MIME-Version: 1.0 X-Received: by 10.140.41.200 with SMTP id z66mr9985279qgz.20.1463890891641; Sat, 21 May 2016 21:21:31 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.105 with HTTP; Sat, 21 May 2016 21:21:31 -0700 (PDT) In-Reply-To: <20160519202134.GP12994@cisco.com> References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <20160519185943.GM12994@cisco.com> <20160519202134.GP12994@cisco.com> Date: Sun, 22 May 2016 00:21:31 -0400 X-Google-Sender-Auth: JugKPW60ytD-TLSICZpx8AmdvTk Message-ID: From: Phillip Hallam-Baker To: Toerless Eckert Content-Type: multipart/alternative; boundary=001a11c13b84961aff053366a8c8 Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Sun, 22 May 2016 04:21:33 -0000 --001a11c13b84961aff053366a8c8 Content-Type: text/plain; charset=UTF-8 On Thu, May 19, 2016 at 4:21 PM, Toerless Eckert wrote: > > TLS should not be attackable this way. Isn't this fixed in 1.3 ? You don't > want > to be a baby sitter for TLS. TLS has to be a standalone babysitter. That > why we > hired it ;-) There is nothing in TLS to stop it being attacked. All TLS can do is to prevent certain attacks from succeeding and it is only designed to prevent Confidentiality or Integrity attacks. TLS isn't at all good at stopping denial of service attacks. When an attack occurs, there isn't much that can be done apart from closing the socket and trying again. If you want to add in robustness, you need to be able to detect which of your TCP packets were mangled and that really isn't possible in user space. --001a11c13b84961aff053366a8c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 19, 2016 at 4:21 PM, Toerless Eckert <= eckert@cisco.com&= gt; wrote:

TLS should not be attackable this way. Isn't this fixed in 1.3 ? You do= n't want
to be a baby sitter for TLS. TLS has to be a standalone babysitter. That wh= y we
hired it ;-)

There is nothing in TLS to sto= p it being attacked. All TLS can do is to prevent certain attacks from succ= eeding and it is only designed to prevent Confidentiality or Integrity atta= cks.

TLS isn't at all good at stopping denial = of service attacks. When an attack occurs, there isn't much that can be= done apart from closing the socket and trying again.=C2=A0

<= /div>
If you want to add in robustness, you need to be able to detect w= hich of your TCP packets were mangled and that really isn't possible in= user space.

--001a11c13b84961aff053366a8c8-- From nobody Sun May 22 10:30:40 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 CF67B12D10B for ; Sun, 22 May 2016 10:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 iZxdahGM3zqc for ; Sun, 22 May 2016 10:30:38 -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 072C112D0F5 for ; Sun, 22 May 2016 10:30:37 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id D69CF1B414A99; Sun, 22 May 2016 17:30:32 +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 u4MHUZiW028398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 May 2016 17:30:35 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 u4MHUYQL028672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 May 2016 19:30:34 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Sun, 22 May 2016 19:30:34 +0200 From: "Scharf, Michael (Nokia - DE)" To: Tom Herbert , Christian Huitema Thread-Topic: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt Thread-Index: AQHRsfsP/nejVyQy8k+Tx9VhJVm8r5/Ae7eAgAALB4CAACDLgIAACaIAgAAC3gCAAB9RgIAADsGAgAAFH4CAAQuOAIAAEIWAgAADJACAACP3sIAAMW2AgAEQeQCAAbOWYA== Date: Sun, 22 May 2016 17:30:33 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48862006@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Toerless Eckert , spud , Joe Touch Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Sun, 22 May 2016 17:30:40 -0000 PiBXZSBhc3N1bWUgdGhhdCBzdHJvbmcgc2VjdXJpdHkgbXVzdCBiZSBhcHBsaWVkLCBzbyB1bmxp a2UgTVAtVENQIHRoZQ0KPiB0cmFuc3BvcnQgaGVhZGVycyBhcmUgZW5jcnlwdGVkIGFuZCB0aGUg b25seSBpbmZvcm1hdGlvbiBzZW50IGluIHBsYWluDQo+IHRleHQgaXMgdGhlIHNlc3Npb24gaWRl bnRpZmllciAoc2VydmluZyBhcyBhbiBTUEkpIGFuZCBEVExTIGhlYWRlcnMuDQo+IEluIHRoZSBj YXNlIG9mIGEgY29ubmVjdGlvbiBzdXJ2aXZpbmcgYWNyb3NzIE5BVCByZW1hcHBpbmcgYW4gYXR0 YWNrZXINCj4gY291bGQgb2JzZXJ2ZSB0aGF0IHRoZSBjb25uZWN0aW9uIGhhcyBiZWVuIHJlbWFw cGVkLCBidXQgdGhhdCByZXZlYWxzDQo+IG5vIG5ldyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29u bmVjdGlvbiB0aGFuIGl0IGhhZCBwcmV2aW91c2x5IGV4Y2VwdA0KPiB0aGF0IHRoZSBpdCB3YXMg cmVtYXBwZWQgYnkgYW4gaW50ZXJtZWRpYXRlIGRldmljZS4gVGhhdCBkb2VzDQo+IHBvdGVudGlh bGx5IHJldmVhbCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgTkFUIGRldmljZSwgZm9yIGluc3RhbmNl IGl0DQo+IGNvdWxkIHByb2JhYmx5IGFzY2VydGFpbiB0aGUgdGltZW91dCwgYnV0IEkgZG9uJ3Qg a25vdyBob3cgdXNlZnVsIHRoYXQNCj4gd291bGQgYmUgaW4gYW5kIGl0IGNvdWxkIHByb2JhYmx5 IGJlIGRldGVybWluZWQgYnkgb3RoZXIgbWVhbnMuDQoNCkkgYW0gbm90IHN1cmUgd2hvIHdvdWxk IGNhcmUgc28gbXVjaCBhYm91dCB0aGUgTkFUIGRldmljZS4gQnV0LCBlLmcuLCB3aGF0IGFib3V0 IHRoZSBwcml2YWN5IGltcGFjdCBvbiB1c2VycyBvZiBjYXNjYWRlZCBOQVRzIG9yIHNvbWUgZm9y bSBvZiBvbmlvbiByb3V0aW5nIChlLmcuIFRPUi1saWtlKT8NCg0KKERpc2NsYWltZXI6IEkgYW0g bm90IGFuIGV4cGVydCBmb3IgdGhvc2UsIHNvIEkgYXBvbG9naXplIGlmIEkgbWlzcyBzb21ldGhp bmcgaGVyZS4pDQoNCj4gQnV0IGV2ZW4gZ2l2ZW4gdGhhdCwgeWVzLCBJIHdvdWxkIHByZWZlciB0 aGF0IGFueXRoaW5nIHRoYXQgaWRlbnRpZmllcw0KPiBmbG93cyBvbiB0aGUgbmV0d29yayAoVURQ IHR1cGxlcywgc2Vzc2lvbiBpZGVudGlmaWVycywgZmxvdyBsYWJlbHMpIGlzDQo+IHBlcmlvZGlj YWxseSByb3RhdGVkIHRvIHJlZHVjZSB0aGUgYWJpbGl0eSBvZiBpbnRlcm1lZGlhdGUgbm9kZXMg dG8NCj4gdHJhY2sgbXkgZmxvd3Mgb3ZlciBsb25nIHBlcmlvZHMgb2YgdGltZS4gVGhlIHByb3Rv Y29sIHRvIG5lZ290aWF0ZSBhDQo+IG5ldyBzZXNzaW9uIGlkZW50aWZpZXIgY2FuIGJlIGltcGxl bWVudGVkIGluIHRoZSBlbmNyeXB0ZWQgcG9ydGlvbiBvZg0KPiB0aGUgcGFja2V0LiBUbyBjaGFu Z2UgdGhlIFVEUCB0dXBsZSBhIGNsaWVudCBjYW4gcGljayBhIGRpZmZlcmVudA0KPiBlcGhlbWVy YWwgc291cmNlIHBvcnQgKGluIHVzZXJzcGFjZSBzb2NrZXRzIGltcGxlbWVudGF0aW9uIHRoaXMg d291bGQNCj4gY2xvc2Ugb25lIHNvY2tldCBhbmQgY3JlYXRlIGEgbmV3IGFuZCBkbyBhIGNvbm5l Y3Qgd2l0aG91dCBleHBsaWNpdA0KPiBiaW5kKS4NCg0KV2VsbCwgInBlcmlvZGljIHJvdGF0aW9u IiByb3RhdGlvbiBjYW4gbWVhbiBhIGxvdCwgaW5jbHVkaW5nIDEwIHllYXJzIG9yIHNvLiBXaGF0 IG9yZGVyIG9mIG1hZ25pdHVkZSB3b3VsZCB5b3Ugc3VnZ2VzdD8gDQoNCk1pY2hhZWwNCg0K From nobody Sun May 22 10:31: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 4381A12D12F for ; Sun, 22 May 2016 10:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 tposWmTaY9Wk for ; Sun, 22 May 2016 10:31:08 -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 3F2FC12D0AB for ; Sun, 22 May 2016 10:31:08 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 2E0E8C4E13FB0; Sun, 22 May 2016 17:31:03 +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 u4MHV4kt010596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 May 2016 17:31:04 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 u4MHTvfh028979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 May 2016 19:31:03 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sun, 22 May 2016 19:30:08 +0200 From: "Scharf, Michael (Nokia - DE)" To: Jana Iyengar , Tom Herbert Thread-Topic: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt Thread-Index: AQHRsfsP/nejVyQy8k+Tx9VhJVm8r5/Ae7eAgAALB4CAACDLgIAACaIAgAAC3gCAAB9RgIAADsGAgAAFH4CAAQuOAIAAEIWAgAADJACAACP3sIAAMW2AgAEQeQCAALs5AIAA+SkQ Date: Sun, 22 May 2016 17:30:07 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48861FF5@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48861FF5FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Cc: Christian Huitema , "Toerless Eckert \(eckert\)" , Joe Touch , "spud@ietf.org" Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Sun, 22 May 2016 17:31:11 -0000 --_000_655C07320163294895BBADA28372AF5D48861FF5FR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVnYXJkaW5nIHRoZSBzdGF0ZW1lbnQgdGhhdCBteSBjb21tZW50IGlzIGluY29ycmVjdDoNCg0K DQrCtyAgICAgICAgIEkgZGlkIG5vdCB3YW50IHRvIGltcGx5IHRoYXQgdGhlIFFVSUMgY29ubmVj dGlvbiBJRCAqaXMqIHVuaXF1ZSBwZXIgc3Vic2NyaWJlciBpbiB0aGUgY3VycmVudCBwcm90b3R5 cGUuIEkgaGF2ZW7igJl0IGNoZWNrZWQgdGhlIGNvZGUgYnV0IGZvciBzdXJlIEkgYXNzdW1lIHRo YXQgaXQgaXMgbm90IGltcGxlbWVudGVkIHRoaXMgd2F5LiBNeSBjb25jZXJuIGlzIGFib3V0IGEg cHJvdG9jb2wgdGhhdCBieSBkZXNpZ24gKmRvZXMgbm90IHByZXZlbnQqIHRoYXQgYW5kIGxlYXZl cyB0aGUgZGVjaXNpb24gZS5nLiB1cCB0byBhbiBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgZGVjaXNp b24uDQoNCsK3ICAgICAgICAgVGhlIHJvb3QgY2F1c2Ugb2YgdGhlIHByb2JsZW0gbWF5IGJlIHRo YXQgZHJhZnQtdHN2d2ctcXVpYy1wcm90b2NvbC0wMiBsYWNrcyBhIHNlY3VyaXR5IGNvbnNpZGVy YXRpb24gc2VjdGlvbi4gVGhlIHByaXZhY3kgaW1wbGljYXRpb25zIG9mIHRoZSBjb25uZWN0aW9u IElEIHJlcXVpcmUgSU1ITyBzaWduaWZpY2FudCBhdHRlbnRpb24gdGhlcmUuIEJ1dCwgaW5kZWVk LCB0aGlzIGRpc2N1c3Npb24gZG9lcyBub3QgYmVsb25nIG9uIHRoaXMgbGlzdC4NCg0KwrcgICAg ICAgICBJIGRpc2FncmVlIHRoYXQgYW55IGNvbm5lY3Rpb24gSUQgdGhhdCBpcyBtZWFudCB0byBi ZSBsb2NhdGlvbi1pbmRlcGVuZGVudCAoaS5lLiwgaW5kZXBlbmRlbnQgb2YgdGhlIDUtdHVwbGUp IGV4YWN0bHkgZXhwb3NlcyB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyB0aGUgNSB0dXBsZS4gQSB0 cml2aWFsIGNvdW50ZXItZXhhbXBsZSBpcyBhIGNvbm5lY3Rpb24gSUQgdGhhdCBpcyBidWlsZCBm cm9tIHRoZSBNQUMgYWRkcmVzcyBjb25jYXRlbmF0ZWQgYnkgc29tZSByYW5kb20gYml0cy4gRm9y IGluc3RhbmNlLCB0aGlzIHdvdWxkIGJlIGFuIGVhc3kgd2F5IHRvIGNvbnN0cnVjdCBhIHVuaXF1 ZSA2NGJpdCBpZGVudGlmaWVyIHRoYXQgd291bGQgc3Vydml2ZSBOQVQgcmViaW5kaW5nLCBidXQs IHdlbGwsIHRoaXMgd291bGQgaGF2ZSBzb21lIHByaXZhY3kgaW1wYWN0LCBubz8gU3BlY2lmaWNh bGx5LCBzaW5jZSBpdCBtYXkgc2hvdyB1cCBpbiBldmVyeSBwYWNrZXQgYXQgYSBjb25zdGFudCBv ZmZzZXQsIG9uZSBjb3VsZCB1c2UgdGhpcyBJRCBmb3Ig4oCcaW50ZXJlc3RpbmfigJ0gcHVycG9z ZXMsIG9yIGRvIEkgbWlzcyBzb21ldGhpbmc/IFdoYXQgcHJldmVudHMgYSB1c2VyLXNwYWNlIHRy YW5zcG9ydCBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbiBmcm9tIHBpY2tpbmcgdGhlIE1BQyBhZGRy ZXNzPyBTb21lIE1VU1QgaW4gc29tZSBJLUQ/DQoNCkZ1cnRoZXJtb3JlLCBJIGJlbGlldmUgdGhh dCB0aGlzIGRpc2N1c3Npb25zIG1hdHRlcnMgZm9yIFBMVVMvU1BVRCwgc2luY2U6DQoNCg0Kwrcg ICAgICAgICBJZiB0d28gZGlmZmVyZW50LCB3b3JrZWQtb3V0IGNhbmRpZGF0ZSB1c2VycyBvZiB0 aGUgY29tbW9uIHN1YnN0cmF0ZSBzZWVtIHRvIGhhdmUgc2ltaWxhciByZXF1aXJlbWVudHMgZm9y IHNpZ25hbGluZyBpbmZvcm1hdGlvbiBpbiBjbGVhci10ZXh0LCB0aGlzIGNvdWxkIGJlIHNvbWUg bGVzc29ucyBsZWFybnQgZm9yIHdoYXQgbWF5IGJlIHJlcXVpcmVkIGluIHRoZSBjb21tb24gc3Vi c3RyYXRlLg0KDQrCtyAgICAgICAgIEV2ZW4gaWYgdGhpcyBpcyBub3QgdGhlIGNhc2UsIHRoZSBj dXJyZW50IGV4Y2Vzc2l2ZSB1c2Ugb2YgdGhlIHRlcm0g4oCcZW5jcnlwdGlvbuKAnSBpbiB0aGUg UExVUy9TUFVEIGNoYXJ0ZXIgSU1ITyBoYXMgdG8gYmUgcmV2aWV3ZWQsIHNpbmNlIGF0IGxlYXN0 IHR3byBwb3RlbnRpYWwgY2FuZGlkYXRlIHByb3RvY29scyBhY3R1YWxseSBzZWVtcyB0byB1c2Ug aW5mb3JtYXRpb24gaW4gY2xlYXIgdGV4dC4gRXhhbXBsZTog4oCcVGhlIHByaW1hcnkgZ29hbCBv ZiBQTFVTIGlzIHRvIGVuYWJsZSB0aGUgZGVwbG95bWVudCBvZiBhcmJpdHJhcnksIGZ1bGx5IGVu Y3J5cHRlZCB0cmFuc3BvcnQgcHJvdG9jb2xz4oCdLiBXZWxsLCBhdCBsZWFzdCBJIGxlYXJuIG5v dyB0aGF0IG5vdCBldmVyeXRoaW5nIGlzIOKAnGZ1bGx54oCdIGVuY3J5cHRlZOKApg0KDQrCtyAg ICAgICAgIEZpbmFsbHksIGZyb20gdGhlIGN1cnJlbnQgY2hhcnRlciBJIGRvbuKAmXQgdW5kZXJz dGFuZCB3aGV0aGVyIFBMVVMvU1BVRCB3b3VsZCBjb25zaWRlciB0aGUgcmVxdWlyZW1lbnRzIG9m IG1pZGRsZWJveGVzIGRlc2lnbmVkIHRvIHByb3ZpZGUgdXNlciBhbm9ueW1pdHkgKGUuZy4sIFRP Ui1saWtlKS4gSeKAmWQgcGVyc29uYWxseSBiZSBmaW5lIHdpdGggZmxhZ2dpbmcgdGhlaXIgc3Bl Y2lmaWMgcmVxdWlyZW1lbnRzIGFzIG91dC1vZi1zY29wZS4gQnV0IGZvciBzdXJlIHRoZXJlIGlz IGEgdXNlciBjb21tdW5pdHkgb2YgdGhhdCBzb3J0IG9mIGluZnJhc3RydWN0dXJlIGFuZCBpdCBt YXkgbWFrZSBzZW5zZSB0byBkaXNjdXNzIGVhcmx5IGhvdyB0byBkZWFsIHdpdGggdGhhdC4NCg0K TWljaGFlbA0KDQpGcm9tOiBKYW5hIEl5ZW5nYXIgW21haWx0bzpqcmlAZ29vZ2xlLmNvbV0NClNl bnQ6IFN1bmRheSwgTWF5IDIyLCAyMDE2IDU6MDMgQU0NClRvOiBUb20gSGVyYmVydA0KQ2M6IFRv ZXJsZXNzIEVja2VydCAoZWNrZXJ0KTsgc3B1ZEBpZXRmLm9yZzsgQ2hyaXN0aWFuIEh1aXRlbWE7 IEpvZSBUb3VjaDsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKQ0KU3ViamVjdDogUmU6IFtT cHVkXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGVyYmVydC10cmFu c3BvcnRzLW92ZXItdWRwLTAwLnR4dA0KDQoNClBvc3NpYmx5IHVuc3VycHJpc2luZ2x5LCBJIGxp a2UgdGhpcyBkcmFmdC4gSSdkIGxpa2UgdG8gYXJndWUgc29tZSBvZiB0aGUgY2hvaWNlcyBtYWRl IGluIHRoZSBkcmFmdCBidXQgSSdsbCBkbyB0aGF0IHNlcGFyYXRlbHkuIEZvciBub3csIEkganVz dCB3YW50ZWQgdG8gYXJ0aWN1bGF0ZSBhIGZldyB0aG91Z2h0cyBhcyBJIGNhdWdodCB1cCBvbiB0 aGlzIHRocmVhZDoNCg0KLSBUaGUgc2hpcCBoYXMgc2FpbGVkIG9uIG5ldyBuYXRpdmUtSVAgdHJh bnNwb3J0cy4gSSB3b3JrZWQgb24gU0NUUCBmb3IgNiB5ZWFycyBhbmQgdHJpZWQgYW5kIHdhdGNo ZWQgaXQgZ2V0IG5vd2hlcmUgaW4gdGVybXMgb2YgZGVwbG95bWVudCBvdmVyIG5hdGl2ZS1JUC4g SXQgd2Fzbid0IGJlY2F1c2UgaXQgd2FzIGluIHRoZSBrZXJuZWwsIGl0IHdhcyBwcmltYXJpbHkg YmVjYXVzZSBvZiBOQVRzIGFuZCB2YXJpb3VzIG1pZGRsZWJveGVzLiBZZXMgdGhpcyBpcyBkZWZp bml0ZWx5IG15IG9waW5pb24sIGJ1dCBhcmd1aW5nIHRoaXMgcG9pbnQgaXMgc2lsbHkuIE5vIG5l dyBuYXRpdmUgSVAgdHJhbnNwb3J0IGhhcyBzZWVuIHNpZ25pZmljYW50IGRlcGxveW1lbnQgb3Zl ciB0aGUgaW50ZXJuZXQgb3ZlciB0aGUgcGFzdCAyMCB5ZWFycywgYW5kIGl0J3Mgbm90IGZvciBs YWNrIG9mIHRyeWluZy4NCg0KLSBQZW9wbGUgcmVhc29uYWJseSBjb25zaWRlciB0aW1lc2NhbGVz IG9mIGEgZmV3IHllYXJzIHdoZW4gdGhpbmtpbmcgYWJvdXQgYnVpbGRpbmcgYW5kIGRlcGxveWlu ZyBhIG5ldyB0cmFuc3BvcnQuIFFVSUMgdG9vayBhIGZldyB5ZWFycyB0byBidWlsZCBhbmQgZGVw bG95IG92ZXIgVURQLCBhbmQgdGhlIEFkb2JlIGZvbGtzIGRpZCBSVE1GUCBvdmVyIFVEUCBhcyB3 ZWxsIChhIHdoaWxlIGFnbykgaW4gYSByZWFzb25hYmxlIHRpbWUgZnJhbWUuDQoNCi0gRW5jcnlw dGlvbiBpcyB0aGUgKm9ubHkqIHdheSB0byBhdHRlbXB0IGF2b2lkaW5nIG9zc2lmaWNhdGlvbi4g SXRzIGNlcnRhaW5seSByZWFzb25hYmxlIHRvIGNvbnNpZGVyIHRoYXQgaXQgbWF5IG5vdCBkbyB0 aGUgam9iLCBidXQgd2l0aG91dCBhbiBhbHRlcm5hdGl2ZSwgSSdtIGFmcmFpZCBpdCB3aWxsIGhh dmUgdG8gZG8gZm9yIG5vdy4NCg0KLSBNaWNoYWVsIHJhaXNlZCBhIHBvaW50IGFib3V0IFFVSUMg Y29ubmVjdGlvbiBJRCwgd2hpY2ggaXMgaW5jb3JyZWN0OiBUaGUgUVVJQyBjb25uZWN0aW9uIElE IGlzIE5PVCB1bmlxdWUgcGVyIHVzZXIuIEl0J3MgYSBjb25uZWN0aW9uIElELCBhbmQgb24gYSBz aW5nbGUtcGF0aCBjb25uZWN0aW9uLCBpdCBleHBvc2VzIGV4YWN0bHkgYXMgbXVjaCBhcyBUQ1As IERDQ1AsIG9yIFNDVFAgZG8gKHVuaXF1ZSBwZXIgNC10dXBsZSkuIE9uIGEgbXVsdGlwYXRoIGNv bm5lY3Rpb24sIGl0IGV4cG9zZXMgZXhhY3RseSBhcyBtdWNoIGFzIE1QVENQIGRvZXMuIFdlIGNh biBwZXJoYXBzIGRvIGJldHRlciB0aGFuIE1QVENQIGZvciBtdWx0aXBhdGggaW4gdGVybXMgb2Yg cHJpdmFjeSwgSSBkb24ndCB3YW50IHRvIGVuZ2FnZSBvbiB0aGlzIHBvaW50IG9uIHRoaXMgdGhy ZWFkIHNpbmNlIGl0J3Mgbm90IHJlbGV2YW50IHRvIHRoaXMgdGhyZWFkLg0KDQotIGphbmENCk9u IE1heSAyMSwgMjAxNiA4OjUzIEFNLCAiVG9tIEhlcmJlcnQiIDx0b21AaGVyYmVydGxhbmQuY29t PG1haWx0bzp0b21AaGVyYmVydGxhbmQuY29tPj4gd3JvdGU6DQpPbiBGcmksIE1heSAyMCwgMjAx NiBhdCA0OjM4IFBNLCBDaHJpc3RpYW4gSHVpdGVtYQ0KPGh1aXRlbWFAbWljcm9zb2Z0LmNvbTxt YWlsdG86aHVpdGVtYUBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQo+IE9uIEZyaWRheSwgTWF5IDIw LCAyMDE2IDk6MTQgQU0sIE1pY2hhZWwgU2NoYXJmIHdyb3RlOg0KPj4gVG86IFRvbSBIZXJiZXJ0 IDx0b21AaGVyYmVydGxhbmQuY29tPG1haWx0bzp0b21AaGVyYmVydGxhbmQuY29tPj47IFRvZXJs ZXNzIEVja2VydA0KPj4gPGVja2VydEBjaXNjby5jb208bWFpbHRvOmVja2VydEBjaXNjby5jb20+ Pg0KPj4gQ2M6IEpvZSBUb3VjaCA8dG91Y2hAaXNpLmVkdTxtYWlsdG86dG91Y2hAaXNpLmVkdT4+ OyBzcHVkIDxzcHVkQGlldGYub3JnPG1haWx0bzpzcHVkQGlldGYub3JnPj4NCj4+IFN1YmplY3Q6 IFJlOiBbU3B1ZF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhlcmJl cnQtDQo+PiB0cmFuc3BvcnRzLW92ZXItdWRwLTAwLnR4dA0KPj4NCj4+ID4gTkFUIG1ha2VzIGxp ZmUgY29tcGxpY2F0ZWQsIGVzcGVjaWFsbHkgaWYgd2Ugd2FudCB0byBoYXZlIGNvbm5lY3Rpb25z DQo+PiBzdXJ2aXZlIGFjcm9zcyBVRFAgTkFUIGFkZHJlc3MvcG9ydCByZW1hcHBpbmcuIE1vc3Qg b2YgdGhlIGRyYWZ0IGlzIGFib3V0DQo+PiBkZWFsaW5nIHdpdGggdGhpcy4gT25lIG5pY2UgZmVh dHVyZSAodGhhdCBJIGJvcnJvd2VkIGZyb20gPiBRVUlDKSBpcyB0bw0KPj4gbmVnb3RpYXRlIGEg c2hhcmVkIHNlc3Npb24gaWRlbnRpZmllciBmb3IgdGhlIGNvbm5lY3Rpb24gdGhhdCBpcyB1bmlx dWUgdG8gYm90aA0KPj4gc2lkZXMuIFdpdGggdGhpcyBhIGNvbm5lY3Rpb24gaXMgaWRlbnRpZmll ZCAoYXQgdGhlIGVuZA0KPj4gPiBub2Rlcykgd2l0aG91dCB1c2luZyB0aGUgYWRkcmVzc2VzIG9y IFVEUCBwb3J0IG51bWJlcnMuIFNvIGNvbm5lY3Rpb24NCj4+IGlkZW50aWZpY2F0aW9uIGJlY29t ZXMgbG9jYXRpb24gaW5kZXBlbmRlbnQgd2hpY2ggc29sdmVzIHRoZSBOQVANCj4+IHJlbWFwcGlu ZyBwcm9ibGVtIGFuZCBhbHNvIGFsbG93cyBmb3IgbW9iaWxpdHkuDQo+Pg0KPj4gQWhoaCwgU2Vj dGlvbiAzLjIgaXMgcmVhbGx5IGNvb2wuLi4NCj4+DQo+PiBJIGNhbiBjbGVhcmx5IHNlZSB0aGUg dHJlbWVuZG91cyBpbXByb3ZlbWVudCBmb3IgdXNlciBwcml2YWN5IGlmIHRoZSBoaWdobHkNCj4+ IHByaXZhY3ktc2Vuc2l0aXZlIFRDUCBoZWFkZXIgZmllbGRzIGZpbmFsbHkgZ2V0IGFsbCBlbmNy eXB0ZWQsIGluY2x1ZGluZyB0aGluZ3MNCj4+IGxpa2UgZmxhZ3MsIHNlcXVlbmNlIG51bWJlcnMg ZXRjLiwgaWYgdGhlcmUgaXMgbm93IGEgbmV3IGNsZWFyIHRleHQgaWRlbnRpZmllcg0KPj4gdGhh dCBqdXN0IGhhcHBlbnMgdG8gYmUgdW5pcXVlIHBlciBzdWJzY3JpYmVyLiBXaGF0IGEgZ3JlYXQg aW1wcm92ZW1lbnQgZm9yDQo+PiBwcml2YWN5IGluIHRoZSBJbnRlcm5ldCEgQW5kIGV2ZW4gYmV0 dGVyIHRoYXQgaXQgc2VlbXMgY29tcGF0aWJsZSB3aXRoIFFVSUMuLi4NCj4+DQo+PiBTb3JyeSwg SSByZWFsbHkgY291bGQgbm90IHJlc2lzdC4NCj4NCj4gQWN0dWFsbHksIHVzaW5nIGEgNjQgYml0 IFFVSUMtbGlrZSBpZGVudGlmaWVyIHRvIHN1cHBvcnQgbW9iaWxpdHkgb3IgbXVsdGkgcGF0aCBp cyBhIHRlcnJpYmxlIGlkZWEuIFRoZSBiZXN0IHdheSB0byBkZXNjcmliZSBpdCBpcywgImNsZWFy IHRleHQgc3VwZXIgY29va2llLiIgSXQgYWxsb3dzIGFkdmVyc2FyaWVzIHRvIGxpbmsgY29ubmVj dGlvbnMgb3JpZ2luYXRpbmcgZnJvbSBkaWZmZXJlbnQgSVAgYWRkcmVzc2VzLiBQcm92aWRpbmcg c3VjaCBsaW5rYWJpbGl0eSBpcyBhIGJvb24gZm9yIHRyYWZmaWMgYW5hbHlzaXMgYW5kIHVzZXIg dHJhY2tpbmcsIGFuZCBvZiBjb3Vyc2UgYSBiaWcgbG9zcyBmb3IgcHJpdmFjeS4gQW5kIHllcywg TVAtVENQIGlzIGRvaW5nIHNvbWV0aGluZyBzaW1pbGFyLCBidXQgYXQgbGVhc3QgdGhleSBhY2tu b3dsZWRnZSB0aGUgcHJvYmxlbSBhbmQgd2FudCB0byBmaW5kIGEgc29sdXRpb24uIElmIHdlIHdh bnQgcHJpdmFjeSwgdGhlIGlkZW50aWZpZXJzIHVzZWQgdG8gbGluayBzZXZlcmFsIGNvbm5lY3Rp b25zIHRvZ2V0aGVyIGhhdmUgdG8gYmUgcGxhY2VkIGluc2lkZSB0aGUgY3J5cHRvIGVudmVsb3Bl LCBub3QgaW4gYSBjbGVhciB0ZXh0IGhlYWRlci4NCj4NCldlIGFzc3VtZSB0aGF0IHN0cm9uZyBz ZWN1cml0eSBtdXN0IGJlIGFwcGxpZWQsIHNvIHVubGlrZSBNUC1UQ1AgdGhlDQp0cmFuc3BvcnQg aGVhZGVycyBhcmUgZW5jcnlwdGVkIGFuZCB0aGUgb25seSBpbmZvcm1hdGlvbiBzZW50IGluIHBs YWluDQp0ZXh0IGlzIHRoZSBzZXNzaW9uIGlkZW50aWZpZXIgKHNlcnZpbmcgYXMgYW4gU1BJKSBh bmQgRFRMUyBoZWFkZXJzLg0KSW4gdGhlIGNhc2Ugb2YgYSBjb25uZWN0aW9uIHN1cnZpdmluZyBh Y3Jvc3MgTkFUIHJlbWFwcGluZyBhbiBhdHRhY2tlcg0KY291bGQgb2JzZXJ2ZSB0aGF0IHRoZSBj b25uZWN0aW9uIGhhcyBiZWVuIHJlbWFwcGVkLCBidXQgdGhhdCByZXZlYWxzDQpubyBuZXcgaW5m b3JtYXRpb24gYWJvdXQgdGhlIGNvbm5lY3Rpb24gdGhhbiBpdCBoYWQgcHJldmlvdXNseSBleGNl cHQNCnRoYXQgdGhlIGl0IHdhcyByZW1hcHBlZCBieSBhbiBpbnRlcm1lZGlhdGUgZGV2aWNlLiBU aGF0IGRvZXMNCnBvdGVudGlhbGx5IHJldmVhbCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgTkFUIGRl dmljZSwgZm9yIGluc3RhbmNlIGl0DQpjb3VsZCBwcm9iYWJseSBhc2NlcnRhaW4gdGhlIHRpbWVv dXQsIGJ1dCBJIGRvbid0IGtub3cgaG93IHVzZWZ1bCB0aGF0DQp3b3VsZCBiZSBpbiBhbmQgaXQg Y291bGQgcHJvYmFibHkgYmUgZGV0ZXJtaW5lZCBieSBvdGhlciBtZWFucy4NCg0KQnV0IGV2ZW4g Z2l2ZW4gdGhhdCwgeWVzLCBJIHdvdWxkIHByZWZlciB0aGF0IGFueXRoaW5nIHRoYXQgaWRlbnRp Zmllcw0KZmxvd3Mgb24gdGhlIG5ldHdvcmsgKFVEUCB0dXBsZXMsIHNlc3Npb24gaWRlbnRpZmll cnMsIGZsb3cgbGFiZWxzKSBpcw0KcGVyaW9kaWNhbGx5IHJvdGF0ZWQgdG8gcmVkdWNlIHRoZSBh YmlsaXR5IG9mIGludGVybWVkaWF0ZSBub2RlcyB0bw0KdHJhY2sgbXkgZmxvd3Mgb3ZlciBsb25n IHBlcmlvZHMgb2YgdGltZS4gVGhlIHByb3RvY29sIHRvIG5lZ290aWF0ZSBhDQpuZXcgc2Vzc2lv biBpZGVudGlmaWVyIGNhbiBiZSBpbXBsZW1lbnRlZCBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24g b2YNCnRoZSBwYWNrZXQuIFRvIGNoYW5nZSB0aGUgVURQIHR1cGxlIGEgY2xpZW50IGNhbiBwaWNr IGEgZGlmZmVyZW50DQplcGhlbWVyYWwgc291cmNlIHBvcnQgKGluIHVzZXJzcGFjZSBzb2NrZXRz IGltcGxlbWVudGF0aW9uIHRoaXMgd291bGQNCmNsb3NlIG9uZSBzb2NrZXQgYW5kIGNyZWF0ZSBh IG5ldyBhbmQgZG8gYSBjb25uZWN0IHdpdGhvdXQgZXhwbGljaXQNCmJpbmQpLg0KDQpUb20NCg0K DQoNCg0KDQoNCj4gLS0gQ2hyaXN0aWFuIEh1aXRlbWENCj4NCj4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNwdWQgbWFpbGluZyBsaXN0DQpTcHVk QGlldGYub3JnPG1haWx0bzpTcHVkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHVkDQo= --_000_655C07320163294895BBADA28372AF5D48861FF5FR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K CW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207 DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bh bi5FLU1haWxGb3JtYXR2b3JsYWdlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjA1MDU2 NjY5MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTEz NTc3MTg5MCA2NzU2NzYxNyA2NzU2NzYxOSA2NzU2NzYyMSA2NzU2NzYxNyA2NzU2NzYxOSA2NzU2 NzYyMSA2NzU2NzYxNyA2NzU2NzYxOSA2NzU2NzYyMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkaW5n IHRoZSBzdGF0ZW1lbnQgdGhhdCBteSBjb21tZW50IGlzIGluY29ycmVjdDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIGRpZCBub3Qgd2FudCB0byBpbXBseSB0aGF0IHRoZSBRVUlDIGNvbm5lY3Rpb24gSUQg KjxiPmlzPC9iPiogdW5pcXVlIHBlciBzdWJzY3JpYmVyIGluIHRoZSBjdXJyZW50IHByb3RvdHlw ZS4gSSBoYXZlbuKAmXQgY2hlY2tlZCB0aGUNCiBjb2RlIGJ1dCBmb3Igc3VyZSBJIGFzc3VtZSB0 aGF0IGl0IGlzIG5vdCBpbXBsZW1lbnRlZCB0aGlzIHdheS4gTXkgY29uY2VybiBpcyBhYm91dCBh IHByb3RvY29sIHRoYXQgYnkgZGVzaWduICo8Yj5kb2VzIG5vdCBwcmV2ZW50PC9iPiogdGhhdCBh bmQgbGVhdmVzIHRoZSBkZWNpc2lvbiBlLmcuIHVwIHRvIGFuIGFwcGxpY2F0aW9uIGRldmVsb3Bl ciBkZWNpc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHJvb3QgY2F1c2Ugb2YgdGhl IHByb2JsZW0gbWF5IGJlIHRoYXQgZHJhZnQtdHN2d2ctcXVpYy1wcm90b2NvbC0wMiBsYWNrcyBh IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbi4gVGhlIHByaXZhY3kgaW1wbGljYXRpb25z DQogb2YgdGhlIGNvbm5lY3Rpb24gSUQgcmVxdWlyZSBJTUhPIHNpZ25pZmljYW50IGF0dGVudGlv biB0aGVyZS4gQnV0LCBpbmRlZWQsIHRoaXMgZGlzY3Vzc2lvbiBkb2VzIG5vdCBiZWxvbmcgb24g dGhpcyBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRpc2FncmVlIHRoYXQgYW55IGNv bm5lY3Rpb24gSUQgdGhhdCBpcyBtZWFudCB0byBiZSBsb2NhdGlvbi1pbmRlcGVuZGVudCAoaS5l LiwgaW5kZXBlbmRlbnQgb2YgdGhlIDUtdHVwbGUpIGV4YWN0bHkgZXhwb3NlcyB0aGUgc2FtZQ0K IGluZm9ybWF0aW9uIGFzIHRoZSA1IHR1cGxlLiBBIHRyaXZpYWwgY291bnRlci1leGFtcGxlIGlz IGEgY29ubmVjdGlvbiBJRCB0aGF0IGlzIGJ1aWxkIGZyb20gdGhlIE1BQyBhZGRyZXNzIGNvbmNh dGVuYXRlZCBieSBzb21lIHJhbmRvbSBiaXRzLiBGb3IgaW5zdGFuY2UsIHRoaXMgd291bGQgYmUg YW4gZWFzeSB3YXkgdG8gY29uc3RydWN0IGEgdW5pcXVlIDY0Yml0IGlkZW50aWZpZXIgdGhhdCB3 b3VsZCBzdXJ2aXZlIE5BVCByZWJpbmRpbmcsIGJ1dCwNCiB3ZWxsLCB0aGlzIHdvdWxkIGhhdmUg c29tZSBwcml2YWN5IGltcGFjdCwgbm8/IFNwZWNpZmljYWxseSwgc2luY2UgaXQgbWF5IHNob3cg dXAgaW4gZXZlcnkgcGFja2V0IGF0IGEgY29uc3RhbnQgb2Zmc2V0LCBvbmUgY291bGQgdXNlIHRo aXMgSUQgZm9yIOKAnGludGVyZXN0aW5n4oCdIHB1cnBvc2VzLCBvciBkbyBJIG1pc3Mgc29tZXRo aW5nPyBXaGF0IHByZXZlbnRzIGEgdXNlci1zcGFjZSB0cmFuc3BvcnQgcHJvdG9jb2wgaW1wbGVt ZW50YXRpb24gZnJvbQ0KIHBpY2tpbmcgdGhlIE1BQyBhZGRyZXNzPyBTb21lIE1VU1QgaW4gc29t ZSBJLUQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZ1cnRoZXJtb3JlLCBJ IGJlbGlldmUgdGhhdCB0aGlzIGRpc2N1c3Npb25zIG1hdHRlcnMgZm9yIFBMVVMvU1BVRCwgc2lu Y2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdHdvIGRpZmZlcmVudCwgd29ya2VkLW91dCBjYW5kaWRh dGUgdXNlcnMgb2YgdGhlIGNvbW1vbiBzdWJzdHJhdGUgc2VlbSB0byBoYXZlIHNpbWlsYXIgcmVx dWlyZW1lbnRzIGZvciBzaWduYWxpbmcgaW5mb3JtYXRpb24gaW4gY2xlYXItdGV4dCwNCiB0aGlz IGNvdWxkIGJlIHNvbWUgbGVzc29ucyBsZWFybnQgZm9yIHdoYXQgbWF5IGJlIHJlcXVpcmVkIGlu IHRoZSBjb21tb24gc3Vic3RyYXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FdmVuIGlmIHRo aXMgaXMgbm90IHRoZSBjYXNlLCB0aGUgY3VycmVudCBleGNlc3NpdmUgdXNlIG9mIHRoZSB0ZXJt IOKAnGVuY3J5cHRpb27igJ0gaW4gdGhlIFBMVVMvU1BVRCBjaGFydGVyIElNSE8gaGFzIHRvIGJl IHJldmlld2VkLCBzaW5jZQ0KIGF0IGxlYXN0IHR3byBwb3RlbnRpYWwgY2FuZGlkYXRlIHByb3Rv Y29scyBhY3R1YWxseSBzZWVtcyB0byB1c2UgaW5mb3JtYXRpb24gaW4gY2xlYXIgdGV4dC4gRXhh bXBsZTog4oCcVGhlIHByaW1hcnkgZ29hbCBvZiBQTFVTIGlzIHRvIGVuYWJsZSB0aGUgZGVwbG95 bWVudCBvZiBhcmJpdHJhcnksIGZ1bGx5IGVuY3J5cHRlZCB0cmFuc3BvcnQgcHJvdG9jb2xz4oCd LiBXZWxsLCBhdCBsZWFzdCBJIGxlYXJuIG5vdyB0aGF0IG5vdCBldmVyeXRoaW5nIGlzDQog4oCc ZnVsbHnigJ0gZW5jcnlwdGVk4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpbmFsbHksIGZy b20gdGhlIGN1cnJlbnQgY2hhcnRlciBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aGV0aGVyIFBMVVMv U1BVRCB3b3VsZCBjb25zaWRlciB0aGUgcmVxdWlyZW1lbnRzIG9mIG1pZGRsZWJveGVzIGRlc2ln bmVkIHRvIHByb3ZpZGUNCiB1c2VyIGFub255bWl0eSAoZS5nLiwgVE9SLWxpa2UpLiBJ4oCZZCBw ZXJzb25hbGx5IGJlIGZpbmUgd2l0aCBmbGFnZ2luZyB0aGVpciBzcGVjaWZpYyByZXF1aXJlbWVu dHMgYXMgb3V0LW9mLXNjb3BlLiBCdXQgZm9yIHN1cmUgdGhlcmUgaXMgYSB1c2VyIGNvbW11bml0 eSBvZiB0aGF0IHNvcnQgb2YgaW5mcmFzdHJ1Y3R1cmUgYW5kIGl0IG1heSBtYWtlIHNlbnNlIHRv IGRpc2N1c3MgZWFybHkgaG93IHRvIGRlYWwgd2l0aCB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5NaWNoYWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEphbmEg SXllbmdhciBbbWFpbHRvOmpyaUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRh eSwgTWF5IDIyLCAyMDE2IDU6MDMgQU08YnI+DQo8Yj5Ubzo8L2I+IFRvbSBIZXJiZXJ0PGJyPg0K PGI+Q2M6PC9iPiBUb2VybGVzcyBFY2tlcnQgKGVja2VydCk7IHNwdWRAaWV0Zi5vcmc7IENocmlz dGlhbiBIdWl0ZW1hOyBKb2UgVG91Y2g7IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTcHVkXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtaGVyYmVydC10cmFuc3BvcnRzLW92ZXItdWRwLTAwLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+UG9zc2libHkgdW5z dXJwcmlzaW5nbHksIEkgbGlrZSB0aGlzIGRyYWZ0LiBJJ2QgbGlrZSB0byBhcmd1ZSBzb21lIG9m IHRoZSBjaG9pY2VzIG1hZGUgaW4gdGhlIGRyYWZ0IGJ1dCBJJ2xsIGRvIHRoYXQgc2VwYXJhdGVs eS4gRm9yIG5vdywgSSBqdXN0IHdhbnRlZCB0byBhcnRpY3VsYXRlIGEgZmV3IHRob3VnaHRzIGFz IEkgY2F1Z2h0IHVwIG9uIHRoaXMgdGhyZWFkOjxvOnA+PC9vOnA+PC9wPg0KPHA+LSBUaGUgc2hp cCBoYXMgc2FpbGVkIG9uIG5ldyBuYXRpdmUtSVAgdHJhbnNwb3J0cy4gSSB3b3JrZWQgb24gU0NU UCBmb3IgNiB5ZWFycyBhbmQgdHJpZWQgYW5kIHdhdGNoZWQgaXQgZ2V0IG5vd2hlcmUgaW4gdGVy bXMgb2YgZGVwbG95bWVudCBvdmVyIG5hdGl2ZS1JUC4gSXQgd2Fzbid0IGJlY2F1c2UgaXQgd2Fz IGluIHRoZSBrZXJuZWwsIGl0IHdhcyBwcmltYXJpbHkgYmVjYXVzZSBvZiBOQVRzIGFuZCB2YXJp b3VzIG1pZGRsZWJveGVzLg0KIFllcyB0aGlzIGlzIGRlZmluaXRlbHkgbXkgb3BpbmlvbiwgYnV0 IGFyZ3VpbmcgdGhpcyBwb2ludCBpcyBzaWxseS4gTm8gbmV3IG5hdGl2ZSBJUCB0cmFuc3BvcnQg aGFzIHNlZW4gc2lnbmlmaWNhbnQgZGVwbG95bWVudCBvdmVyIHRoZSBpbnRlcm5ldCBvdmVyIHRo ZSBwYXN0IDIwIHllYXJzLCBhbmQgaXQncyBub3QgZm9yIGxhY2sgb2YgdHJ5aW5nLjxvOnA+PC9v OnA+PC9wPg0KPHA+LSBQZW9wbGUgcmVhc29uYWJseSBjb25zaWRlciB0aW1lc2NhbGVzIG9mIGEg ZmV3IHllYXJzIHdoZW4gdGhpbmtpbmcgYWJvdXQgYnVpbGRpbmcgYW5kIGRlcGxveWluZyBhIG5l dyB0cmFuc3BvcnQuIFFVSUMgdG9vayBhIGZldyB5ZWFycyB0byBidWlsZCBhbmQgZGVwbG95IG92 ZXIgVURQLCBhbmQgdGhlIEFkb2JlIGZvbGtzIGRpZCBSVE1GUCBvdmVyIFVEUCBhcyB3ZWxsIChh IHdoaWxlIGFnbykgaW4gYSByZWFzb25hYmxlIHRpbWUgZnJhbWUuDQo8bzpwPjwvbzpwPjwvcD4N CjxwPi0gRW5jcnlwdGlvbiBpcyB0aGUgKm9ubHkqIHdheSB0byBhdHRlbXB0IGF2b2lkaW5nIG9z c2lmaWNhdGlvbi4gSXRzIGNlcnRhaW5seSByZWFzb25hYmxlIHRvIGNvbnNpZGVyIHRoYXQgaXQg bWF5IG5vdCBkbyB0aGUgam9iLCBidXQgd2l0aG91dCBhbiBhbHRlcm5hdGl2ZSwgSSdtIGFmcmFp ZCBpdCB3aWxsIGhhdmUgdG8gZG8gZm9yIG5vdy48bzpwPjwvbzpwPjwvcD4NCjxwPi0gTWljaGFl bCByYWlzZWQgYSBwb2ludCBhYm91dCBRVUlDIGNvbm5lY3Rpb24gSUQsIHdoaWNoIGlzIGluY29y cmVjdDogVGhlIFFVSUMgY29ubmVjdGlvbiBJRCBpcyBOT1QgdW5pcXVlIHBlciB1c2VyLiBJdCdz IGEgY29ubmVjdGlvbiBJRCwgYW5kIG9uIGEgc2luZ2xlLXBhdGggY29ubmVjdGlvbiwgaXQgZXhw b3NlcyBleGFjdGx5IGFzIG11Y2ggYXMgVENQLCBEQ0NQLCBvciBTQ1RQIGRvICh1bmlxdWUgcGVy IDQtdHVwbGUpLiBPbiBhIG11bHRpcGF0aA0KIGNvbm5lY3Rpb24sIGl0IGV4cG9zZXMgZXhhY3Rs eSBhcyBtdWNoIGFzIE1QVENQIGRvZXMuIFdlIGNhbiBwZXJoYXBzIGRvIGJldHRlciB0aGFuIE1Q VENQIGZvciBtdWx0aXBhdGggaW4gdGVybXMgb2YgcHJpdmFjeSwgSSBkb24ndCB3YW50IHRvIGVu Z2FnZSBvbiB0aGlzIHBvaW50IG9uIHRoaXMgdGhyZWFkIHNpbmNlIGl0J3Mgbm90IHJlbGV2YW50 IHRvIHRoaXMgdGhyZWFkLg0KPG86cD48L286cD48L3A+DQo8cD4tIGphbmE8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXkgMjEsIDIwMTYgODo1MyBBTSwg JnF1b3Q7VG9tIEhlcmJlcnQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0b21AaGVyYmVydGxh bmQuY29tIj50b21AaGVyYmVydGxhbmQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE1heSAyMCwgMjAxNiBhdCA0OjM4IFBNLCBD aHJpc3RpYW4gSHVpdGVtYTxicj4NCiZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBtaWNyb3Nv ZnQuY29tIj5odWl0ZW1hQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IE9u IEZyaWRheSwgTWF5IDIwLCAyMDE2IDk6MTQgQU0sIE1pY2hhZWwgU2NoYXJmIHdyb3RlOjxicj4N CiZndDsmZ3Q7IFRvOiBUb20gSGVyYmVydCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbUBoZXJiZXJ0 bGFuZC5jb20iPnRvbUBoZXJiZXJ0bGFuZC5jb208L2E+Jmd0OzsgVG9lcmxlc3MgRWNrZXJ0PGJy Pg0KJmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzplY2tlcnRAY2lzY28uY29tIj5lY2tlcnRA Y2lzY28uY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyBDYzogSm9lIFRvdWNoICZsdDs8YSBocmVm PSJtYWlsdG86dG91Y2hAaXNpLmVkdSI+dG91Y2hAaXNpLmVkdTwvYT4mZ3Q7OyBzcHVkICZsdDs8 YSBocmVmPSJtYWlsdG86c3B1ZEBpZXRmLm9yZyI+c3B1ZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K Jmd0OyZndDsgU3ViamVjdDogUmU6IFtTcHVkXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtaGVyYmVydC08YnI+DQomZ3Q7Jmd0OyB0cmFuc3BvcnRzLW92ZXItdWRwLTAw LnR4dDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBOQVQgbWFrZXMgbGlmZSBjb21w bGljYXRlZCwgZXNwZWNpYWxseSBpZiB3ZSB3YW50IHRvIGhhdmUgY29ubmVjdGlvbnM8YnI+DQom Z3Q7Jmd0OyBzdXJ2aXZlIGFjcm9zcyBVRFAgTkFUIGFkZHJlc3MvcG9ydCByZW1hcHBpbmcuIE1v c3Qgb2YgdGhlIGRyYWZ0IGlzIGFib3V0PGJyPg0KJmd0OyZndDsgZGVhbGluZyB3aXRoIHRoaXMu IE9uZSBuaWNlIGZlYXR1cmUgKHRoYXQgSSBib3Jyb3dlZCBmcm9tICZndDsgUVVJQykgaXMgdG88 YnI+DQomZ3Q7Jmd0OyBuZWdvdGlhdGUgYSBzaGFyZWQgc2Vzc2lvbiBpZGVudGlmaWVyIGZvciB0 aGUgY29ubmVjdGlvbiB0aGF0IGlzIHVuaXF1ZSB0byBib3RoPGJyPg0KJmd0OyZndDsgc2lkZXMu IFdpdGggdGhpcyBhIGNvbm5lY3Rpb24gaXMgaWRlbnRpZmllZCAoYXQgdGhlIGVuZDxicj4NCiZn dDsmZ3Q7ICZndDsgbm9kZXMpIHdpdGhvdXQgdXNpbmcgdGhlIGFkZHJlc3NlcyBvciBVRFAgcG9y dCBudW1iZXJzLiBTbyBjb25uZWN0aW9uPGJyPg0KJmd0OyZndDsgaWRlbnRpZmljYXRpb24gYmVj b21lcyBsb2NhdGlvbiBpbmRlcGVuZGVudCB3aGljaCBzb2x2ZXMgdGhlIE5BUDxicj4NCiZndDsm Z3Q7IHJlbWFwcGluZyBwcm9ibGVtIGFuZCBhbHNvIGFsbG93cyBmb3IgbW9iaWxpdHkuPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBaGhoLCBTZWN0aW9uIDMuMiBpcyByZWFsbHkgY29vbC4u Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBjYW4gY2xlYXJseSBzZWUgdGhlIHRyZW1l bmRvdXMgaW1wcm92ZW1lbnQgZm9yIHVzZXIgcHJpdmFjeSBpZiB0aGUgaGlnaGx5PGJyPg0KJmd0 OyZndDsgcHJpdmFjeS1zZW5zaXRpdmUgVENQIGhlYWRlciBmaWVsZHMgZmluYWxseSBnZXQgYWxs IGVuY3J5cHRlZCwgaW5jbHVkaW5nIHRoaW5nczxicj4NCiZndDsmZ3Q7IGxpa2UgZmxhZ3MsIHNl cXVlbmNlIG51bWJlcnMgZXRjLiwgaWYgdGhlcmUgaXMgbm93IGEgbmV3IGNsZWFyIHRleHQgaWRl bnRpZmllcjxicj4NCiZndDsmZ3Q7IHRoYXQganVzdCBoYXBwZW5zIHRvIGJlIHVuaXF1ZSBwZXIg c3Vic2NyaWJlci4gV2hhdCBhIGdyZWF0IGltcHJvdmVtZW50IGZvcjxicj4NCiZndDsmZ3Q7IHBy aXZhY3kgaW4gdGhlIEludGVybmV0ISBBbmQgZXZlbiBiZXR0ZXIgdGhhdCBpdCBzZWVtcyBjb21w YXRpYmxlIHdpdGggUVVJQy4uLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgU29ycnksIEkg cmVhbGx5IGNvdWxkIG5vdCByZXNpc3QuPGJyPg0KJmd0Ozxicj4NCiZndDsgQWN0dWFsbHksIHVz aW5nIGEgNjQgYml0IFFVSUMtbGlrZSBpZGVudGlmaWVyIHRvIHN1cHBvcnQgbW9iaWxpdHkgb3Ig bXVsdGkgcGF0aCBpcyBhIHRlcnJpYmxlIGlkZWEuIFRoZSBiZXN0IHdheSB0byBkZXNjcmliZSBp dCBpcywgJnF1b3Q7Y2xlYXIgdGV4dCBzdXBlciBjb29raWUuJnF1b3Q7IEl0IGFsbG93cyBhZHZl cnNhcmllcyB0byBsaW5rIGNvbm5lY3Rpb25zIG9yaWdpbmF0aW5nIGZyb20gZGlmZmVyZW50IElQ IGFkZHJlc3Nlcy4gUHJvdmlkaW5nIHN1Y2gNCiBsaW5rYWJpbGl0eSBpcyBhIGJvb24gZm9yIHRy YWZmaWMgYW5hbHlzaXMgYW5kIHVzZXIgdHJhY2tpbmcsIGFuZCBvZiBjb3Vyc2UgYSBiaWcgbG9z cyBmb3IgcHJpdmFjeS4gQW5kIHllcywgTVAtVENQIGlzIGRvaW5nIHNvbWV0aGluZyBzaW1pbGFy LCBidXQgYXQgbGVhc3QgdGhleSBhY2tub3dsZWRnZSB0aGUgcHJvYmxlbSBhbmQgd2FudCB0byBm aW5kIGEgc29sdXRpb24uIElmIHdlIHdhbnQgcHJpdmFjeSwgdGhlIGlkZW50aWZpZXJzIHVzZWQN CiB0byBsaW5rIHNldmVyYWwgY29ubmVjdGlvbnMgdG9nZXRoZXIgaGF2ZSB0byBiZSBwbGFjZWQg aW5zaWRlIHRoZSBjcnlwdG8gZW52ZWxvcGUsIG5vdCBpbiBhIGNsZWFyIHRleHQgaGVhZGVyLjxi cj4NCiZndDs8YnI+DQpXZSBhc3N1bWUgdGhhdCBzdHJvbmcgc2VjdXJpdHkgbXVzdCBiZSBhcHBs aWVkLCBzbyB1bmxpa2UgTVAtVENQIHRoZTxicj4NCnRyYW5zcG9ydCBoZWFkZXJzIGFyZSBlbmNy eXB0ZWQgYW5kIHRoZSBvbmx5IGluZm9ybWF0aW9uIHNlbnQgaW4gcGxhaW48YnI+DQp0ZXh0IGlz IHRoZSBzZXNzaW9uIGlkZW50aWZpZXIgKHNlcnZpbmcgYXMgYW4gU1BJKSBhbmQgRFRMUyBoZWFk ZXJzLjxicj4NCkluIHRoZSBjYXNlIG9mIGEgY29ubmVjdGlvbiBzdXJ2aXZpbmcgYWNyb3NzIE5B VCByZW1hcHBpbmcgYW4gYXR0YWNrZXI8YnI+DQpjb3VsZCBvYnNlcnZlIHRoYXQgdGhlIGNvbm5l Y3Rpb24gaGFzIGJlZW4gcmVtYXBwZWQsIGJ1dCB0aGF0IHJldmVhbHM8YnI+DQpubyBuZXcgaW5m b3JtYXRpb24gYWJvdXQgdGhlIGNvbm5lY3Rpb24gdGhhbiBpdCBoYWQgcHJldmlvdXNseSBleGNl cHQ8YnI+DQp0aGF0IHRoZSBpdCB3YXMgcmVtYXBwZWQgYnkgYW4gaW50ZXJtZWRpYXRlIGRldmlj ZS4gVGhhdCBkb2VzPGJyPg0KcG90ZW50aWFsbHkgcmV2ZWFsIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBOQVQgZGV2aWNlLCBmb3IgaW5zdGFuY2UgaXQ8YnI+DQpjb3VsZCBwcm9iYWJseSBhc2NlcnRh aW4gdGhlIHRpbWVvdXQsIGJ1dCBJIGRvbid0IGtub3cgaG93IHVzZWZ1bCB0aGF0PGJyPg0Kd291 bGQgYmUgaW4gYW5kIGl0IGNvdWxkIHByb2JhYmx5IGJlIGRldGVybWluZWQgYnkgb3RoZXIgbWVh bnMuPGJyPg0KPGJyPg0KQnV0IGV2ZW4gZ2l2ZW4gdGhhdCwgeWVzLCBJIHdvdWxkIHByZWZlciB0 aGF0IGFueXRoaW5nIHRoYXQgaWRlbnRpZmllczxicj4NCmZsb3dzIG9uIHRoZSBuZXR3b3JrIChV RFAgdHVwbGVzLCBzZXNzaW9uIGlkZW50aWZpZXJzLCBmbG93IGxhYmVscykgaXM8YnI+DQpwZXJp b2RpY2FsbHkgcm90YXRlZCB0byByZWR1Y2UgdGhlIGFiaWxpdHkgb2YgaW50ZXJtZWRpYXRlIG5v ZGVzIHRvPGJyPg0KdHJhY2sgbXkgZmxvd3Mgb3ZlciBsb25nIHBlcmlvZHMgb2YgdGltZS4gVGhl IHByb3RvY29sIHRvIG5lZ290aWF0ZSBhPGJyPg0KbmV3IHNlc3Npb24gaWRlbnRpZmllciBjYW4g YmUgaW1wbGVtZW50ZWQgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mPGJyPg0KdGhlIHBhY2tl dC4gVG8gY2hhbmdlIHRoZSBVRFAgdHVwbGUgYSBjbGllbnQgY2FuIHBpY2sgYSBkaWZmZXJlbnQ8 YnI+DQplcGhlbWVyYWwgc291cmNlIHBvcnQgKGluIHVzZXJzcGFjZSBzb2NrZXRzIGltcGxlbWVu dGF0aW9uIHRoaXMgd291bGQ8YnI+DQpjbG9zZSBvbmUgc29ja2V0IGFuZCBjcmVhdGUgYSBuZXcg YW5kIGRvIGEgY29ubmVjdCB3aXRob3V0IGV4cGxpY2l0PGJyPg0KYmluZCkuPGJyPg0KPGJyPg0K VG9tPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyAtLSBDaHJp c3RpYW4gSHVpdGVtYTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTcHVkIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpTcHVkQGlldGYub3JnIj5TcHVkQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3B1ZCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3B1 ZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_655C07320163294895BBADA28372AF5D48861FF5FR712WXCHMBA15z_-- From nobody Sun May 22 12:34:31 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 557F412D57A for ; Sun, 22 May 2016 12:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 D9_cMt1wqSAD for ; Sun, 22 May 2016 12:34:29 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 10AE312D577 for ; Sun, 22 May 2016 12:34:29 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b4Z8o-0005bF-G3; Sun, 22 May 2016 21:34:22 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.103]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b4Z8n-0003ZX-Ul; Sun, 22 May 2016 21:34:22 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Sun, 22 May 2016 21:34:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E98FD9B-B093-4636-AFBB-D4460871F8D2@ifi.uio.no> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> To: Brian Trammell X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 3 sum rcpts/h 12 sum msgs/h 4 total rcpts 41995 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 620F1FDBFA24803496F1053C312A33AE16BCA614 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1057 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Tom Herbert , Toerless Eckert , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 22 May 2016 19:34:30 -0000 Hi, I=E2=80=99m sorry for derailing this a little - it isn=E2=80=99t so = relevant to the BoF, but I=E2=80=99d really like to answer this part of = the discussion: > On 20. mai 2016, at 12.32, Brian Trammell wrote: >=20 >=20 >> On 19 May 2016, at 21:17, Tom Herbert wrote: >>=20 >> On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert = wrote: (snip) >> With something like SPUD (basically anything not simple TCP/IPv4) we >> are always faced with the same problem that some networks on the >> Internet may arbitrarily drop or otherwise restrict packets (we know >> for instance that some network operators choose to severely rate = limit >> all UDP because of DOS concerns). So even if we do manage to start >> deploying transport protocols over UDP we are going have TCP as a >> fallback for indefinite future, i.e. more happy eyeballs. >=20 > Yes, and if we do manage to start deploying transport protocols over = IPv6, we are going to have IPv4 fallback for an indefinite future. I = share your concern about happy eyeballs state explosion (a phenomenon we = refer to around the office as "angry eyeballs" -> eight orthogonal = network/transport layer choices to test at startup means that every flow = begins with a 256 packet burst)... but the benefit of doing this to = transport flexibility is potentially worth the cost, which is the = fundamental question we want to address in PLUS. I have a problem with this =E2=80=9Cangry eyeballs=E2=80=9D thing: = it=E2=80=99s assuming a very simplistic happy eyeballing algorithm and, = by calling it names, gives the impression as if the described problem = was universal to all possible happy eyeballing algorithms - which = isn=E2=80=99t the case. For example: we often surf to the same websites, which are often on = CDNs, on a path that doesn=E2=80=99t change very much. So if my computer = would happy eyeball slowly and store information in its cache, that = information is potentially valid and useful for a LONG time. Then, why = not use the favored transport *only* as long as the cache hasn=E2=80=99t = expired, and then try fall-backs if things fail? Also the = multiplicative effect that you=E2=80=99re pointing at can be = circumvented. E.g., if TCP doesn=E2=80=99t work over IPv6, it doesn=E2=80=99= t make much sense to try a different transport over v6=E2=80=A6 so the = number of tests can be gradually reduced. I=E2=80=99m just giving examples to say that much more reasonable = mechanisms than the one that you sketch here could be devised. Happy = Eyeballing doesn=E2=80=99t *need* to be =E2=80=9Cangry=E2=80=9D. Cheers, Michael From nobody Sun May 22 12:43: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 AB73B12D587 for ; Sun, 22 May 2016 12:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.625 X-Spam-Level: X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 2mWFtZKk7sB2 for ; Sun, 22 May 2016 12:43:56 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 B112012D119 for ; Sun, 22 May 2016 12:43:55 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b4ZHw-0003BR-4G; Sun, 22 May 2016 21:43:48 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.103]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b4ZHv-0001Iy-EI; Sun, 22 May 2016 21:43:48 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_C4BF7E57-DF79-482D-B087-DD266DFE6A20" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Sun, 22 May 2016 21:43:44 +0200 Message-Id: References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 4 sum rcpts/h 19 sum msgs/h 5 total rcpts 42002 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6BF79A8C9169B1AE366942FB74FF202B78938AD7 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 1058 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Toerless Eckert , Joe Touch , Tom Herbert , "Scharf, Michael \(Nokia - DE\)" , spud@ietf.org, Christian Huitema Subject: Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-00.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: Sun, 22 May 2016 19:43:57 -0000 --Apple-Mail=_C4BF7E57-DF79-482D-B087-DD266DFE6A20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I still didn=E2=80=99t get to read the draft - apologies! I probably = like it :-) but I hope it allows putting multiple TCP connections = under one single UDP 5-tuple. Anyway, not speaking pro- or con- this draft, just a comment in line: > On 22. mai 2016, at 05.03, Jana Iyengar wrote: >=20 > Possibly unsurprisingly, I like this draft. I'd like to argue some of = the choices made in the draft but I'll do that separately. For now, I = just wanted to articulate a few thoughts as I caught up on this thread: >=20 > - The ship has sailed on new native-IP transports. I worked on SCTP = for 6 years and tried and watched it get nowhere in terms of deployment = over native-IP. It wasn't because it was in the kernel, it was primarily = because of NATs and various middleboxes. Yes this is definitely my = opinion, but arguing this point is silly. No new native IP transport has = seen significant deployment over the internet over the past 20 years, = and it's not for lack of trying. >=20 =E2=80=9CThe ship has sailed=E2=80=9D and =E2=80=9Cit=E2=80=99s not for = lack of trying=E2=80=9D are both wrong IMO. How many applications have = tried to use SCTP/IP and fallen back to TCP in case it doesn=E2=80=99t = work? How many applications do you expect to change in order to get such = a change to happen? And why should anyone expect someone designing or = maintaining a router or middlebox to support native SCTP when they never = even see the packets and never even hear anyone say =E2=80=9Cmy = application works better elsewhere because of SCTP=E2=80=9D ? This is what TAPS is trying to address. It=E2=80=99s a very deep = architectural problem of the Internet - an inability to automate = fall-backs, which unnecessarily burdens application developers. Rant, = rant, rant, make me stop :-) Now all this being said, I also don=E2=80=99t fully get why some folks = have such a big problem with running stuff over UDP. I=E2=80=99m not = against doing that, if only as a temporary solution that would serve to = convince people that the transport (option, ..) is useful. In a TAPS world, it=E2=80=99s just another option to try=E2=80=A6 Cheers, Michael --Apple-Mail=_C4BF7E57-DF79-482D-B087-DD266DFE6A20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I = still didn=E2=80=99t get to read the draft - apologies!  I probably = like it  :-)   but I hope it allows putting multiple TCP = connections under one single UDP 5-tuple.
Anyway, = not speaking pro- or con- this draft, just a comment in line:


On = 22. mai 2016, at 05.03, Jana Iyengar <jri@google.com> wrote:

Possibly unsurprisingly, I like this draft. I'd like to argue = some of the choices made in the draft but I'll do that separately. For = now, I just wanted to articulate a few thoughts as I caught up on this = thread:

- The ship has sailed on new = native-IP transports. I worked on SCTP for 6 years and tried and watched = it get nowhere in terms of deployment over native-IP. It wasn't because = it was in the kernel, it was primarily because of NATs and various = middleboxes. Yes this is definitely my opinion, but arguing this point = is silly. No new native IP transport has seen significant deployment = over the internet over the past 20 years, and it's not for lack of = trying.

=E2=80=9CThe ship has sailed=E2=80=9D = and =E2=80=9Cit=E2=80=99s not for lack of trying=E2=80=9D are both wrong = IMO. How many applications have tried to use SCTP/IP and fallen back to = TCP in case it doesn=E2=80=99t work? How many applications do you expect = to change in order to get such a change to happen? And why should anyone = expect someone designing or maintaining a router or middlebox to support = native SCTP when they never even see the packets and never even hear = anyone say =E2=80=9Cmy application works better elsewhere because of = SCTP=E2=80=9D ?

This is what TAPS is = trying to address. It=E2=80=99s a very deep architectural problem of the = Internet - an inability to automate fall-backs, which unnecessarily = burdens application developers. Rant, rant, rant, make me stop   = :-)

Now all this being said, I = also don=E2=80=99t fully get why some folks have such a big problem with = running stuff over UDP. I=E2=80=99m not against doing that, if only as a = temporary solution that would serve to convince people that the = transport (option, ..) is useful.
In a TAPS world, it=E2=80=99s = just another option to try=E2=80=A6

Cheers,
Michael

= --Apple-Mail=_C4BF7E57-DF79-482D-B087-DD266DFE6A20-- From nobody Sun May 22 13:06: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 BCE9A12D146 for ; Sun, 22 May 2016 13:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 wJp8J5-tLSdS for ; Sun, 22 May 2016 13:06:25 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003: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 C325712D185 for ; Sun, 22 May 2016 13:06:25 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id k23so43490451oih.0 for ; Sun, 22 May 2016 13:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=H4tC7DiiI2mOGaEqh79QCNaVZ5DvX/MEl/ankQXY084=; b=CMngYcPLTAKHf1sbRJAVQYwlukYT925EXxysWbkIVVL1cHi17WYrvRruK/hHfGzMN1 oVtnMMI/eSbQjHU9TNNps5h0ODQkj0epkugyzl4IxYFWrACZuHEzhTI3teIkjNDcCFiR TLHEfY+elbDsNDBXGmNvIebOXyCuF7ItEYouI5kI3WSjvRh8ZJ78BiDlDpNZulYACs0t e+KI1c1HoPTfcHQxS9mUFPnaJqreTXGFWSMIJSkpNtUw6APUJMrMC3HxmfusAbPr6K31 +PUcPe1aQWKKUW/bOiMNRWmJ2+6jNT2FU2fM4uRjGW8vd1lOZlI6ffKgF335OEfUTqNX hCUw== 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:date :message-id:subject:from:to:cc; bh=H4tC7DiiI2mOGaEqh79QCNaVZ5DvX/MEl/ankQXY084=; b=GfKOiYdi0ai65N29QEtKxwiOPEYoQj1kpmIu3kun4awzIxYuAus2nX3+BD19g8i99j wVgD6Qxv8QgYpFyjvp6cs8lLif9BWgvLUjx6VkM7MP0LHgeQP/AH2Uox6y2Ex4C9/132 wTUIzrErww834hXQ4bCUyx9Rlyz6Av3j9E7QpwtCpZcyL685K0oCb+6tscT5Uqhy4p2a +LQO+6fgh27STo47GWgbXYowtPX7MYvgwyZL6eX68TTInBmMPO4+FoMgM6h98i+R7L8F Dvn9MFqXxj7PtPiE0E7v5m7jFaIf3vY6O5SVWppyp3Sglrjf2OJuKjQjzMHja2aDmNvO HsHQ== X-Gm-Message-State: AOPr4FU1069NwT8FrqG7jmSq+Wu7wsH0GH/3ACzPJHxRVaf1dLWp1vucoIhtD9Ef1+EzPSbKA93PmiPUF+m8vQ== MIME-Version: 1.0 X-Received: by 10.157.63.52 with SMTP id m49mr7830735otc.2.1463947585022; Sun, 22 May 2016 13:06:25 -0700 (PDT) Received: by 10.157.42.69 with HTTP; Sun, 22 May 2016 13:06:24 -0700 (PDT) In-Reply-To: References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Sun, 22 May 2016 13:06:24 -0700 Message-ID: From: Ca By To: Michael Welzl Content-Type: multipart/alternative; boundary=001a11473492c675ce053373db92 Archived-At: Cc: Toerless Eckert , Joe Touch , Tom Herbert , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" , Jana Iyengar , Christian Huitema Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Sun, 22 May 2016 20:06:28 -0000 --001a11473492c675ce053373db92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, May 22, 2016, Michael Welzl wrote: > Hi, > > I still didn=E2=80=99t get to read the draft - apologies! I probably lik= e it :-) > but I hope it allows putting multiple TCP connections under one single > UDP 5-tuple. > Anyway, not speaking pro- or con- this draft, just a comment in line: > > > On 22. mai 2016, at 05.03, Jana Iyengar > wrote: > > Possibly unsurprisingly, I like this draft. I'd like to argue some of the > choices made in the draft but I'll do that separately. For now, I just > wanted to articulate a few thoughts as I caught up on this thread: > > - The ship has sailed on new native-IP transports. I worked on SCTP for 6 > years and tried and watched it get nowhere in terms of deployment over > native-IP. It wasn't because it was in the kernel, it was primarily becau= se > of NATs and various middleboxes. Yes this is definitely my opinion, but > arguing this point is silly. No new native IP transport has seen > significant deployment over the internet over the past 20 years, and it's > not for lack of trying. > > =E2=80=9CThe ship has sailed=E2=80=9D and =E2=80=9Cit=E2=80=99s not for l= ack of trying=E2=80=9D are both wrong > IMO. How many applications have tried to use SCTP/IP and fallen back to T= CP > in case it doesn=E2=80=99t work? How many applications do you expect to c= hange in > order to get such a change to happen? And why should anyone expect someon= e > designing or maintaining a router or middlebox to support native SCTP whe= n > they never even see the packets and never even hear anyone say =E2=80=9Cm= y > application works better elsewhere because of SCTP=E2=80=9D ? > > This is what TAPS is trying to address. It=E2=80=99s a very deep architec= tural > problem of the Internet - an inability to automate fall-backs, which > unnecessarily burdens application developers. Rant, rant, rant, make me > stop :-) > > Now all this being said, I also don=E2=80=99t fully get why some folks ha= ve such a > big problem with running stuff over UDP. I=E2=80=99m not against doing th= at, if > only as a temporary solution that would serve to convince people that the > transport (option, ..) is useful. > In a TAPS world, it=E2=80=99s just another option to try=E2=80=A6 > > The fact that udp is mostly (by volume) internet attack traffic is my concern with udp. If legitimate traffic starts using udp in volume, it will make distiguishing and thwarting voulmetric attacks very difficult at scale. Without currently curbing n * 100g blasts of udp traffic with blanket policers, i would not be able to keep my network up... This is a daily issue. For example, my usual udp volume is about 1%. If it goes to 10% suddenly, it is likely smart to drop 11% and onwards as a 10x increase in udp is 100% certainly not legit. My request to quic and spud is simply use a different transport protocol number so that their interesting and innovative traffic does not run up against the many network policers that are required to enforce well known baselines of good normal udp traffic. The quic folks say that they cannot do that since 10 year old cpe only passes udp and tcp, then they rant about ossified stacks and how we need to put everything on udp to make progess ... Seems like they are just choosing to ossify on udp ... And udp is already considered trash (reflection attacks) ...So we agree to disagree, i guess https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 Cheers, > Michael > > --001a11473492c675ce053373db92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, May 22, 2016, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

I still d= idn=E2=80=99t get to read the draft - apologies!=C2=A0 I probably like it = =C2=A0:-) =C2=A0 but I hope it allows putting multiple TCP connections unde= r one single UDP 5-tuple.
Anyway, not speaking pro- or con- this = draft, just a comment in line:


On 22. mai 2016, at 05.03, Jana Iyengar <jri@google.com> wrote:

Possibly= unsurprisingly, I like this draft. I'd like to argue some of the choic= es made in the draft but I'll do that separately. For now, I just wante= d to articulate a few thoughts as I caught up on this thread:

- The ship has sailed on new native-IP transports. I worked on SCTP fo= r 6 years and tried and watched it get nowhere in terms of deployment over = native-IP. It wasn't because it was in the kernel, it was primarily bec= ause of NATs and various middleboxes. Yes this is definitely my opinion, bu= t arguing this point is silly. No new native IP transport has seen signific= ant deployment over the internet over the past 20 years, and it's not f= or lack of trying.

=E2=80=9CThe ship has sailed= =E2=80=9D and =E2=80=9Cit=E2=80=99s not for lack of trying=E2=80=9D are bot= h wrong IMO. How many applications have tried to use SCTP/IP and fallen bac= k to TCP in case it doesn=E2=80=99t work? How many applications do you expe= ct to change in order to get such a change to happen? And why should anyone= expect someone designing or maintaining a router or middlebox to support n= ative SCTP when they never even see the packets and never even hear anyone = say =E2=80=9Cmy application works better elsewhere because of SCTP=E2=80=9D= ?

This is what TAPS is trying to address. It=E2= =80=99s a very deep architectural problem of the Internet - an inability to= automate fall-backs, which unnecessarily burdens application developers. R= ant, rant, rant, make me stop =C2=A0 :-)

Now = all this being said, I also don=E2=80=99t fully get why some folks have suc= h a big problem with running stuff over UDP. I=E2=80=99m not against doing = that, if only as a temporary solution that would serve to convince people t= hat the transport (option, ..) is useful.
In a TAPS world, it=E2= =80=99s just another option to try=E2=80=A6


The fact that udp is mostly (= by volume)=C2=A0internet attack traffic=C2=A0=C2=A0is my concern with udp.= =C2=A0

If legitimate traffic starts using udp in v= olume, it will make distiguishing and thwarting voulmetric attacks very dif= ficult at scale. Without currently curbing n * 100g=C2=A0blasts=C2=A0of udp= traffic with blanket policers, i would not be able to keep my network up..= . This is a daily issue.=C2=A0 For example, my usual udp volume is about 1%= . If it goes to 10% suddenly, it is likely smart to drop 11% and onwards as= a 10x increase in udp is 100% certainly not legit.=C2=A0

My request to quic and spud is simply use a different transport pro= tocol number so that their interesting and innovative traffic does not run = up against the many network policers that are required to enforce well know= n baselines of good normal=C2=A0udp traffic. The quic folks say that they c= annot do that since 10 year old cpe only passes udp and tcp, then they rant= about ossified stacks and how we need to put everything on udp to make pro= gess ... Seems like they are just choosing to ossify on udp ...=C2=A0 And u= dp is already considered trash (reflection attacks) ...So we agree to disag= ree, i guess=C2=A0




<= div>
Cheers,
Michael

--001a11473492c675ce053373db92-- From nobody Sun May 22 13:25: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 5762B12D59C for ; Sun, 22 May 2016 13:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.625 X-Spam-Level: X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 VEAuLvZ0odn9 for ; Sun, 22 May 2016 13:25:03 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 5A38712D583 for ; Sun, 22 May 2016 13:24:59 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b4Zvg-0007zk-Im; Sun, 22 May 2016 22:24:52 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.103]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b4Zvf-0007lx-AA; Sun, 22 May 2016 22:24:52 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_8FD8A18E-DD11-4110-8F89-1DF444D7FB53" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Sun, 22 May 2016 22:24:49 +0200 Message-Id: References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: Ca By X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 1 sum rcpts/h 17 sum msgs/h 3 total rcpts 42010 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C68D18B617C3355ACFCEB902E7AB3A09AF5465A5 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1059 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Toerless Eckert , Joe Touch , Tom Herbert , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" , Jana Iyengar , Christian Huitema Subject: Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-00.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: Sun, 22 May 2016 20:25:05 -0000 --Apple-Mail=_8FD8A18E-DD11-4110-8F89-1DF444D7FB53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22. mai 2016, at 22.06, Ca By wrote: >=20 >=20 >=20 > On Sunday, May 22, 2016, Michael Welzl > wrote: > Hi, >=20 > I still didn=E2=80=99t get to read the draft - apologies! I probably = like it :-) but I hope it allows putting multiple TCP connections = under one single UDP 5-tuple. > Anyway, not speaking pro- or con- this draft, just a comment in line: >=20 >=20 >> On 22. mai 2016, at 05.03, Jana Iyengar > wrote: >>=20 >> Possibly unsurprisingly, I like this draft. I'd like to argue some of = the choices made in the draft but I'll do that separately. For now, I = just wanted to articulate a few thoughts as I caught up on this thread: >>=20 >> - The ship has sailed on new native-IP transports. I worked on SCTP = for 6 years and tried and watched it get nowhere in terms of deployment = over native-IP. It wasn't because it was in the kernel, it was primarily = because of NATs and various middleboxes. Yes this is definitely my = opinion, but arguing this point is silly. No new native IP transport has = seen significant deployment over the internet over the past 20 years, = and it's not for lack of trying. >>=20 > =E2=80=9CThe ship has sailed=E2=80=9D and =E2=80=9Cit=E2=80=99s not = for lack of trying=E2=80=9D are both wrong IMO. How many applications = have tried to use SCTP/IP and fallen back to TCP in case it doesn=E2=80=99= t work? How many applications do you expect to change in order to get = such a change to happen? And why should anyone expect someone designing = or maintaining a router or middlebox to support native SCTP when they = never even see the packets and never even hear anyone say =E2=80=9Cmy = application works better elsewhere because of SCTP=E2=80=9D ? >=20 > This is what TAPS is trying to address. It=E2=80=99s a very deep = architectural problem of the Internet - an inability to automate = fall-backs, which unnecessarily burdens application developers. Rant, = rant, rant, make me stop :-) >=20 > Now all this being said, I also don=E2=80=99t fully get why some folks = have such a big problem with running stuff over UDP. I=E2=80=99m not = against doing that, if only as a temporary solution that would serve to = convince people that the transport (option, ..) is useful. > In a TAPS world, it=E2=80=99s just another option to try=E2=80=A6 >=20 >=20 > The fact that udp is mostly (by volume) internet attack traffic is my = concern with udp.=20 >=20 > If legitimate traffic starts using udp in volume, it will make = distiguishing and thwarting voulmetric attacks very difficult at scale. = Without currently curbing n * 100g blasts of udp traffic with blanket = policers, i would not be able to keep my network up... This is a daily = issue. For example, my usual udp volume is about 1%. If it goes to 10% = suddenly, it is likely smart to drop 11% and onwards as a 10x increase = in udp is 100% certainly not legit.=20 >=20 > My request to quic and spud is simply use a different transport = protocol number so that their interesting and innovative traffic does = not run up against the many network policers that are required to = enforce well known baselines of good normal udp traffic. The quic folks = say that they cannot do that since 10 year old cpe only passes udp and = tcp, then they rant about ossified stacks and how we need to put = everything on udp to make progess ... Seems like they are just choosing = to ossify on udp ... And udp is already considered trash (reflection = attacks) ...So we agree to disagree, i guess=20 >=20 > https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 = Well - still wearing my TAPS glasses, I=E2=80=99d simply say =E2=80=9Cokay= , in this case, try native too, and prefer that if it works". Cheers, Michael --Apple-Mail=_8FD8A18E-DD11-4110-8F89-1DF444D7FB53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 22. mai 2016, at 22.06, Ca By <cb.list6@gmail.com> = wrote:



On Sunday, May 22, 2016, Michael Welzl <michawe@ifi.uio.no> = wrote:
Hi,

I still didn=E2=80=99t get to read the = draft - apologies!  I probably like it  :-)   but I hope = it allows putting multiple TCP connections under one single UDP = 5-tuple.
Anyway, not speaking pro- or con- this = draft, just a comment in line:


On 22. = mai 2016, at 05.03, Jana Iyengar <jri@google.com> wrote:

Possibly unsurprisingly, I like = this draft. I'd like to argue some of the choices made in the draft but = I'll do that separately. For now, I just wanted to articulate a few = thoughts as I caught up on this thread:

- = The ship has sailed on new native-IP transports. I worked on SCTP for 6 = years and tried and watched it get nowhere in terms of deployment over = native-IP. It wasn't because it was in the kernel, it was primarily = because of NATs and various middleboxes. Yes this is definitely my = opinion, but arguing this point is silly. No new native IP transport has = seen significant deployment over the internet over the past 20 years, = and it's not for lack of trying.

=E2=80=9CThe ship has sailed=E2=80=9D and =E2=80=9Cit=E2=80=99s= not for lack of trying=E2=80=9D are both wrong IMO. How many = applications have tried to use SCTP/IP and fallen back to TCP in case it = doesn=E2=80=99t work? How many applications do you expect to change in = order to get such a change to happen? And why should anyone expect = someone designing or maintaining a router or middlebox to support native = SCTP when they never even see the packets and never even hear anyone say = =E2=80=9Cmy application works better elsewhere because of SCTP=E2=80=9D = ?

This is what = TAPS is trying to address. It=E2=80=99s a very deep architectural = problem of the Internet - an inability to automate fall-backs, which = unnecessarily burdens application developers. Rant, rant, rant, make me = stop   :-)

Now all this being said, I also don=E2=80=99t = fully get why some folks have such a big problem with running stuff over = UDP. I=E2=80=99m not against doing that, if only as a temporary solution = that would serve to convince people that the transport (option, ..) is = useful.
In a TAPS world, it=E2=80=99s just another = option to try=E2=80=A6


The fact that udp is mostly (by = volume) internet attack traffic  is my concern with = udp. 

If = legitimate traffic starts using udp in volume, it will make = distiguishing and thwarting voulmetric attacks very difficult at scale. = Without currently curbing n * 100g blasts of udp traffic with = blanket policers, i would not be able to keep my network up... This is a = daily issue.  For example, my usual udp volume is about 1%. If it = goes to 10% suddenly, it is likely smart to drop 11% and onwards as a = 10x increase in udp is 100% certainly not legit. 

My request to quic and = spud is simply use a different transport protocol number so that their = interesting and innovative traffic does not run up against the many = network policers that are required to enforce well known baselines of = good normal udp traffic. The quic folks say that they cannot do = that since 10 year old cpe only passes udp and tcp, then they rant about = ossified stacks and how we need to put everything on udp to make progess = ... Seems like they are just choosing to ossify on udp ...  And udp = is already considered trash (reflection attacks) ...So we agree to = disagree, i guess 

https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00



= --Apple-Mail=_8FD8A18E-DD11-4110-8F89-1DF444D7FB53-- From nobody Sun May 22 14:42: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 53F8A12B040 for ; Sun, 22 May 2016 14:42:06 -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 CYrzXkA0_xoC for ; Sun, 22 May 2016 14:42:04 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7B57412B013 for ; Sun, 22 May 2016 14:42:03 -0700 (PDT) Received: from [172.30.194.98] (unknown [91.143.127.69]) by trammell.ch (Postfix) with ESMTPSA id B0D211A0F18; Sun, 22 May 2016 23:41:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3B45F1ED-192D-42BE-A12F-544BBCE04352"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <0E98FD9B-B093-4636-AFBB-D4460871F8D2@ifi.uio.no> Date: Sun, 22 May 2016 23:41:31 +0200 Message-Id: <7966EBB3-733C-406F-B172-C16AEB3A296B@trammell.ch> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <0E98FD9B-B093-4636-AFBB-D4460871F8D2@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Tom Herbert , Toerless Eckert , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 22 May 2016 21:42:06 -0000 --Apple-Mail=_3B45F1ED-192D-42BE-A12F-544BBCE04352 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 May 2016, at 21:34, Michael Welzl wrote: >=20 > Hi, >=20 > I=E2=80=99m sorry for derailing this a little - it isn=E2=80=99t so = relevant to the BoF, but I=E2=80=99d really like to answer this part of = the discussion: >=20 >> On 20. mai 2016, at 12.32, Brian Trammell wrote: >>=20 >>=20 >>> On 19 May 2016, at 21:17, Tom Herbert wrote: >>>=20 >>> On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert = wrote: >=20 > (snip) >=20 >=20 >>> With something like SPUD (basically anything not simple TCP/IPv4) we >>> are always faced with the same problem that some networks on the >>> Internet may arbitrarily drop or otherwise restrict packets (we know >>> for instance that some network operators choose to severely rate = limit >>> all UDP because of DOS concerns). So even if we do manage to start >>> deploying transport protocols over UDP we are going have TCP as a >>> fallback for indefinite future, i.e. more happy eyeballs. >>=20 >> Yes, and if we do manage to start deploying transport protocols over = IPv6, we are going to have IPv4 fallback for an indefinite future. I = share your concern about happy eyeballs state explosion (a phenomenon we = refer to around the office as "angry eyeballs" -> eight orthogonal = network/transport layer choices to test at startup means that every flow = begins with a 256 packet burst)... but the benefit of doing this to = transport flexibility is potentially worth the cost, which is the = fundamental question we want to address in PLUS. >=20 > I have a problem with this =E2=80=9Cangry eyeballs=E2=80=9D thing: = it=E2=80=99s assuming a very simplistic happy eyeballing algorithm and, = by calling it names, gives the impression as if the described problem = was universal to all possible happy eyeballing algorithms - which = isn=E2=80=99t the case. >=20 > For example: we often surf to the same websites, which are often on = CDNs, on a path that doesn=E2=80=99t change very much. So if my computer = would happy eyeball slowly and store information in its cache, that = information is potentially valid and useful for a LONG time. Then, why = not use the favored transport *only* as long as the cache hasn=E2=80=99t = expired, and then try fall-backs if things fail? Also the = multiplicative effect that you=E2=80=99re pointing at can be = circumvented. E.g., if TCP doesn=E2=80=99t work over IPv6, it doesn=E2=80=99= t make much sense to try a different transport over v6=E2=80=A6 so the = number of tests can be gradually reduced. >=20 > I=E2=80=99m just giving examples to say that much more reasonable = mechanisms than the one that you sketch here could be devised. Happy = Eyeballing doesn=E2=80=99t *need* to be =E2=80=9Cangry=E2=80=9D. I agree with you here. There are lots and lots of ways to keep the state = manageable. For example, quite a few impairments you might want to = happy-eyeball around seem to be linked to access networks, as opposed to = impairments along the path. For these, caching information on a = per-interface / per-connection-profile basis amortizes the measurement = overhead quite well. I think it *is* our responsibility, though, in standardizing things that = might not work everywhere, to carefully specify how the measurement of = multiple features should work, because the naive implementation of these = measurements done in an ad-hoc way, or designs which do not carefully = consider the tradeoff between cache management overhead and network = overhead, lead to the worst case, which does deserve the name. Cheers, Brian >=20 > Cheers, > Michael >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_3B45F1ED-192D-42BE-A12F-544BBCE04352 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 iQIcBAEBCgAGBQJXQieLAAoJEIoSt78L6kajf94QAI3jwHhpmUfSaYiTvNsPwSlJ ZBtjTyBcsxDankNDcWx2976FbgKcDNFRoIRJVmqViCCsm6Vi5kjHtLLjKLKOdWYN NHyMabxU6CQVf69G5cRKVySEWIIlTpVTI96QnTCFa/bdY5tyJRmCsRXvXGwfc8Te e8AkCG+XJmFe4URzUfp+p++YvqM0HiyABnAOM0z18mSmlMJPS56v4ZH8KTlngJEf o7ikqWUWKzKWABUmKaGBAnZOSURyWtPZh5cG/+AWnchausHB896wD0Ugn9GK3x90 V/I3Dsmj3YTB+reImRUjNPsqWp01hKOOgEV++GmXWR8OMvDmQqVcPgimfMbvtTOe 0O43Z5Ff3ig0Tc5u2/WrT1LyywElLSO4Ra4dKM8YYCUQMsnFaXUZdOrijoDLHAWn J3g5+rd4UyVEerVp0Zw0BH8VJmEo5qTbXy6xtgnVmM2QolSRE4f20Ze2RjHnZkHo Ox4Bdn8CwkDHQY8vnfuw2DgED+AzIlSJs8P4VNdF2wAYZb+7j7g2cLi2KEPljseQ hKS2+xIym54L8r1X7ICP8K/AmHu8z/0LsMVrzu88VtbH9hMePt0aEViYPibEcbrT Io7+vVcVLJXVpHJx1m6HmOPj6SIvikuRKECQO1OWUi8cqIYLnyROmG/voKTMR/Pl DpinDQcI0P1+4jOqZy8P =Mv63 -----END PGP SIGNATURE----- --Apple-Mail=_3B45F1ED-192D-42BE-A12F-544BBCE04352-- From nobody Sun May 22 15:07: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 E007312D154 for ; Sun, 22 May 2016 15:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 st3f4_VwBiIg for ; Sun, 22 May 2016 15:07:29 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5832912D100 for ; Sun, 22 May 2016 15:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4515; q=dns/txt; s=iport; t=1463954849; x=1465164449; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=xnTH5Q5phNvkVv72KaXcAUDk6OfjQJGWY+3L2C24Edw=; b=fToaMdTAVBoq4QyOQDwMDbK3WjYRJQDXZ7k53mzywsn2ZD/cv3CR6s1U UmChl4Z5aX+2byUKp7uEmSnVhBLgbt8T5TqWhjGb0buldRnlcxATRLfo0 5Jx4taNJiQF/9DY7tsmYxO73gAC46Vc4VjQIflurHXO4F9fodQ1MPptNJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAgBFLUJX/4wNJK1dgzdWfboBAQ2Bd?= =?us-ascii?q?RcLgi2DQgKBHDgUAQEBAQEBAWUnhEMBAQQBAQEkEzQLEAsOCgklDwUTNhOILw7?= =?us-ascii?q?DSwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFinSEHINPgi4FiACFZXQ+iSCOFgqPH?= =?us-ascii?q?I9MHgEBQoQNHDKIA4E9AQEB?= X-IronPort-AV: E=Sophos;i="5.26,351,1459814400"; d="scan'208";a="104912250" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 May 2016 22:07:28 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4MM7RIi027108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 May 2016 22:07:28 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 u4MM7RFv009883; Sun, 22 May 2016 15:07:27 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4MM7Qn7009882; Sun, 22 May 2016 15:07:26 -0700 Date: Sun, 22 May 2016 15:07:26 -0700 From: Toerless Eckert To: Brian Trammell Message-ID: <20160522220726.GC2511@cisco.com> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <0E98FD9B-B093-4636-AFBB-D4460871F8D2@ifi.uio.no> <7966EBB3-733C-406F-B172-C16AEB3A296B@trammell.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7966EBB3-733C-406F-B172-C16AEB3A296B@trammell.ch> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , "Scharf, Michael \(Nokia - DE\)" , Michael Welzl , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 22 May 2016 22:07:31 -0000 Not sure how close we are in standardizing things, but certainly it would be helped to have more writeups of experiences and experimentation. I am a bit concerned if things learned on different tracks is mutually reviewed to come to best common conclusions. Eg: v4/v6 happy eyeballs, transport happy eyeballs, figuring out redundant multipaths in MP-TCP/SCTP, ICE optimizations in RTCWEB/RTP, etc. pp. All problems may be slightly different from each other, but effectively, the complexity of a host transport stack will be to be able to do all of it, and i am sure there is a lot of overlap, and if we're lucky we figure out common recommendations if not standards. On Sun, May 22, 2016 at 11:41:31PM +0200, Brian Trammell wrote: > > > On 22 May 2016, at 21:34, Michael Welzl wrote: > > > > Hi, > > > > I???m sorry for derailing this a little - it isn???t so relevant to the BoF, but I???d really like to answer this part of the discussion: > > > >> On 20. mai 2016, at 12.32, Brian Trammell wrote: > >> > >> > >>> On 19 May 2016, at 21:17, Tom Herbert wrote: > >>> > >>> On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert wrote: > > > > (snip) > > > > > >>> With something like SPUD (basically anything not simple TCP/IPv4) we > >>> are always faced with the same problem that some networks on the > >>> Internet may arbitrarily drop or otherwise restrict packets (we know > >>> for instance that some network operators choose to severely rate limit > >>> all UDP because of DOS concerns). So even if we do manage to start > >>> deploying transport protocols over UDP we are going have TCP as a > >>> fallback for indefinite future, i.e. more happy eyeballs. > >> > >> Yes, and if we do manage to start deploying transport protocols over IPv6, we are going to have IPv4 fallback for an indefinite future. I share your concern about happy eyeballs state explosion (a phenomenon we refer to around the office as "angry eyeballs" -> eight orthogonal network/transport layer choices to test at startup means that every flow begins with a 256 packet burst)... but the benefit of doing this to transport flexibility is potentially worth the cost, which is the fundamental question we want to address in PLUS. > > > > I have a problem with this ???angry eyeballs??? thing: it???s assuming a very simplistic happy eyeballing algorithm and, by calling it names, gives the impression as if the described problem was universal to all possible happy eyeballing algorithms - which isn???t the case. > > > > For example: we often surf to the same websites, which are often on CDNs, on a path that doesn???t change very much. So if my computer would happy eyeball slowly and store information in its cache, that information is potentially valid and useful for a LONG time. Then, why not use the favored transport *only* as long as the cache hasn???t expired, and then try fall-backs if things fail? Also the multiplicative effect that you???re pointing at can be circumvented. E.g., if TCP doesn???t work over IPv6, it doesn???t make much sense to try a different transport over v6??? so the number of tests can be gradually reduced. > > > > I???m just giving examples to say that much more reasonable mechanisms than the one that you sketch here could be devised. Happy Eyeballing doesn???t *need* to be ???angry???. > > I agree with you here. There are lots and lots of ways to keep the state manageable. For example, quite a few impairments you might want to happy-eyeball around seem to be linked to access networks, as opposed to impairments along the path. For these, caching information on a per-interface / per-connection-profile basis amortizes the measurement overhead quite well. > > I think it *is* our responsibility, though, in standardizing things that might not work everywhere, to carefully specify how the measurement of multiple features should work, because the naive implementation of these measurements done in an ad-hoc way, or designs which do not carefully consider the tradeoff between cache management overhead and network overhead, lead to the worst case, which does deserve the name. > > Cheers, > > Brian > > > > > Cheers, > > Michael > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud > -- --- Toerless Eckert, eckert@cisco.com From nobody Sun May 22 19:07: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 6E9BE12D5F0 for ; Sun, 22 May 2016 19:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 lT2xkC6yYVzV for ; Sun, 22 May 2016 19:07:24 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 0D9BC12D5ED for ; Sun, 22 May 2016 19:07:23 -0700 (PDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 84BE322E255; Sun, 22 May 2016 22:07:19 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Mon, 23 May 2016 12:07:17 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <94911BF5-C313-4816-896B-A90FA630EE5B@mnot.net> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: Brian Trammell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 02:07:27 -0000 Hi Brian, At the BoF, I and several other people highlighted concerns about = privacy and SPUD: http://www.ietf.org/proceedings/92/minutes/minutes-92-spud (under = "Open Discussion") The response at that time was that these considerations were important, = and that work on them could happen in parallel with the SPUD experiment. Unfortunately, there doesn't appear to have been much obvious progress = in list discussion, and draft-trammell-spud-req is quite brief on the = topic: """ SPUD must allow endpoints to control the amount of information exposed = to middleboxes, with the default being the minimum necessary for correct = functioning. This includes the cryptographic protection of transport = layer headers from inspection by devices on path, in order to prevent = ossification of these headers. """ However, I can see that some thought along these lines has been put into = the proposed charter below. So, a few questions. * In the proposed approach, will it be possible for a network operator = to use PLUS mechanisms to insert arbitrary metadata (e.g., a user = identifier) in the server-bound stream of a client-server protocol? =20 * In the proposed approach, will it be possible for a network operator = to require a client to insert a particular kind of metadata into a = stream, e.g., to gain network access? * In the proposed approach, will it be possible for a network to offer a = different quality of service to servers that insert specific metadata = into their streams (thereby affecting network neutrality)? See also: http://mnot.github.io/I-D/transport-metadata-impact/ Cheers, > On 20 May 2016, at 9:02 PM, Brian Trammell wrote: >=20 > Hi, all, >=20 > I've heard one concrete charter suggestion so far; the edited draft = charter (changed paragraph 2) is below. If others would like to see = points clarified to answer their questions, please send suggested edits. = :) >=20 > I take the fact that we're diving into technical discussion as an = indication that those participating are at least interested in the BoF, = if not (yet ;) ) convinced of the need for a WG at this space? >=20 > Thanks, cheers, >=20 > Brian >=20 >=20 > Path Layer UDP Substrate (PLUS) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > The PLUS working group's goal is to enable the deployment of new, > encrypted transport protocols, while providing a > transport-independent method to signal flow semantics under > transport and application control. >=20 > The current Internet protocol stack has no layer for explicit, > in-band signaling of flow semantics and characteristics to network > elements in an interdomain context, nor an integrated signaling > mechanism from network elements to back to endpoints and applications. > This layer never evolved within the stack, because middleboxes and > other devices on path could simply inspect and modify headers and > payload of unencrypted traffic at every layer. This implicit use of > information from the transport and application layers is a > key cause of the ossification that makes it hard or impossible > to deploy new protocols. >=20 > In order to support more ubiquitous deployment of encryption, > explicit signaling must be added to the stack, and it must be > transport protocol independent. 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. > Additionally, 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. >=20 > The PLUS working group will specify a new protocol as a Path Layer > User Substrate (PLUS), to support experimental deployment of > explicit cooperation between endpoints and devices on path, with the = following goals: >=20 > - enable ubiquitous deployment of encrypted higher layer protocols > by providing exposure of similar semantics to existing protocols (e.g. > TCP) to devices on path (e.g. NATs and firewalls) >=20 > - allow applications and transport protocols to explicitly provide > limited information to devices on path >=20 > - allow devices on path to provide feedback and information about > the path to sending endpoints, under sending endpoint control >=20 > - allow devices on path to provide information about the path to > receiving endpoints, with feedback to the sending endpoint, under > sending endpoint control >=20 > Note that 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 at the level of detail that is useful for the network, > while encrypting everything else. This is important to avoid future > implicit treatment and the resulting ossification, as well as to > leverage the principle of least exposure to minimize privacy risks > presented by explicit cooperation. >=20 > Given that the primary goal of PLUS is to enable the deployment of > arbitrary, fully encrypted transport protocols, 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. >=20 > 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 > these use cases and requirements. The working group will close if > it is not able to come to consensus on a protocol design to meet > these requirements. >=20 > The working group will additionally aim to identify other working > groups that could or should 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. > TLS) which could be used for encryption of transport protocols > running over PLUS. >=20 >=20 >=20 >=20 >> On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) = wrote: >>=20 >> My comment is *only* that the sentence "The current Internet protocol = stack has no layer for explicit signaling of flow semantics and = characteristics to network elements" needs to be improved, in my = personal point of view. >>=20 >> For instance, for NAT/FW control, there are many existing out-of-band = protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, = etc., not to mention all the SDN protocols, which are typically all = flow-based. They are all out-of-band but e.g. NSIS would have been = end-to-end. The intention and deployment model of these protocols may be = very different to what SPUD aims for, and none of them is deployed = end-to-end in the Internet. But I think this sentence has to be slightly = more specific how to differentiate e.g. from control plane solutions. >>=20 >> Michael >>=20 >>=20 >> -----Original Message----- >> From: Toerless Eckert [mailto:eckert@cisco.com] >> Sent: Thursday, May 19, 2016 8:27 PM >> To: Tom Herbert >> Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org >> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming = follow-on to SPUD BoF >>=20 >> Tom, Michael >>=20 >> I am reading your positions and i am confused: >>=20 >> DSCP is very successfull in enterprise networks. SPUD does not have = to be successfull "on the Internet". To me it would already be a great = success if it would help to improve controlled network services (like = enterprise or 4G/5G networks). And their transit traffic across the = Internet (without changing anything on the Internet itself). >>=20 >> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even = if we often think about them as per-flow and ould maybe like them to be = restrict to per-flow. At least i don't know any normative reference that = defines them to be per-flow. >>=20 >> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the = analysis that all those mechanisms fail to provide an easily deplopyale = framework in the face of middleboxes. Aka: their presence and mostly = non-success should be an argument FOR working on spud. Not against it. >>=20 >> If a NAT/FW does support any flow signaling, its most likely inband. = Every NAT/firwall supports flow recognition via the explicit signaling = of flow-based transport protoocols like TCP. They do try to do the same = for UDP and because that has no explicit flow signaling, thats where the = problem starts. NAT/FW do deep packet inspection which has all these = problems we know. SPUD sets out to solve/reduce these NAT/FW issues. >>=20 >> Non-support of anything like IP options is IMHO primarily driven by = the absence of unform cross-OS/Dev-language APIs for them. Yes. It may = suck architecturally by designing protocol stacks based on reality like: = applications will only be able to use UDP and TCP, so lets do new work = on top of them, but to me the most important goal is to find the best = deployable solution to a problem. Not the architecturally cleanest one. = If you give me research money to work outside of reality i will happily = take it though and represent a different perspective. >>=20 >> Please, i do not want to dismiss your opposition, i just don't = understand how the arguments you make are working out. Maybe you can = explain to me where i am going wrong in my interpretations above. >>=20 >> Cheers >> Toerless >>=20 >> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >>> wrote: >>>> Does the sentence ... >>>>=20 >>>> The current Internet protocol stack has no layer for explicit = signaling of flow semantics and characteristics to network elements ... >>>>=20 >>>> actually wants to say something like >>>>=20 >>>> The current Internet protocol stack has no layer for explicit = *in-band* signaling of flow semantics and characteristics ... ? >>>>=20 >>>> I may be wrong, but there is no shortage of IETF and non-IETF = protocols that can signal flow semantics and characteristics = out-of-band, either path-coupled or path-decoupled, e.g., in the control = or management plane. As a result, there are protocol "layers" for that = signaling, but they are not in-band. There may also be other ways to fix = this problem (e.g., by adding "end-to-end" or "inter-domain" instead of = "in-band"). >>>>=20 >>> Not to mention that TOS and diff-serv are in-band signaling = mechanisms >>> to the network, ECN is explicitly signaling from the network. Given >>> that they've been around for many years but have never been widely >>> deployed on the Internet makes me wonder if any in-band signaling >>> mechanism will ever catch on. The use of out of band signaling = should >>> be considered, especially considered that in many cases like NAT and >>> firewall the network elements that need signaling are likely in = local >>> networks of one side of the connection. >>>=20 >>> I have a similar concern about the statement that IP options/EH and >>> extension headers are being left off the table as part of a = solution. >>> The fact that neither have these caught on in the Internet and that >>> tells me two things 1) No IP option is needed for the Internet to >>> operate and be successful which makes me wonder if signaling between >>> network and hosts is even required 2) If the extensibility = mechanisms >>> of IP are chronically not deployable, I wonder why any alternative >>> that does not yet exist but intends to solve the same problem would = be >>> any more deployable. >>>=20 >>> Tom >>>=20 >>>> Michael >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On >>>> Behalf Of Brian Trammell >>>> Sent: Thursday, May 19, 2016 5:07 PM >>>> To: stackevo-discuss@iab.org >>>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to >>>> SPUD BoF >>>>=20 >>>> Greetings, all, >>>>=20 >>>> Forwarding this to the correct address for this mailing list = (oops). Please discuss at spud@ietf.org. >>>>=20 >>>> Thanks, cheers, >>>>=20 >>>> Brian >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> From: Brian Trammell >>>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>>> To: spud@ietf.org >>>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja = Kuehlewind >>>>> (IETF)" , Spencer Dawkins at IETF >>>>> >>>>>=20 >>>>> Greetings, all, >>>>>=20 >>>>> We propose to hold a working-group forming BoF in Berlin as a = follow-on to the SPUD work, to define a common substrate protocol for = encrypted transports based on the requirements derived from = experimentation with the SPUD prototype. >>>>>=20 >>>>> First, note that since the acronym "SPUD" refers primarily to the = prototype itself, any follow-on working group should have a different = name. We're using the derived requirements, not starting for the = prototype. The name is a subject for discussion, and suggestions are = welcome. To have something to put in the proposed charter, we'd propose = "Path Layer UDP Substrate" (PLUS) as a starting point. >>>>>=20 >>>>> The proposed charter appears below. We're interested in hearing = initial feedback on the proposed charter in preparation for a BoF = proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). = Is there work to do here within the IETF? Is the scope of the proposed = charter appropriate? Is there energy to do this work? >>>>>=20 >>>>> Thanks, cheers, >>>>>=20 >>>>> Brian and Mirja >>>>>=20 >>>>>=20 >>>>> Path Layer UDP Substrate (PLUS) >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> The PLUS working group???s goal is to enable the deployment of = new, >>>>> encrypted transport protocols, while providing a >>>>> transport-independent method to signal flow semantics under = transport and application control. >>>>>=20 >>>>> The current Internet protocol stack has no layer for explicit >>>>> signaling of flow semantics and characteristics to network >>>>> elements, nor an integrated signaling mechanism from network >>>>> elements to back to endpoints and applications. This layer never >>>>> evolved within the stack, because middleboxes and other devices on >>>>> path could simply inspect and modify headers and payload of >>>>> unencrypted traffic at every layer. This implicit use of >>>>> information from the transport and application layers is a key = origin of the ossification that makes it hard or impossible to deploy = new protocols. >>>>>=20 >>>>> In order to support more ubiquitous deployment of encryption, >>>>> explicit signaling must be added to the stack, and it must be >>>>> transport protocol independent. 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. >>>>> Additionally, 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. >>>>>=20 >>>>> The PLUS working group will specify a new protocol as a Path Layer >>>>> User Substrate (PLUS), to support experimental deployment of >>>>> explicit cooperation between endpoints and devices on path, with = the following goals: >>>>>=20 >>>>> - enable ubiquitous deployment of encrypted higher layer protocols >>>>> by providing exposure of similar semantics to existing protocols = (e.g. >>>>> TCP) to devices on path (e.g. NATs and firewalls) >>>>>=20 >>>>> - allow applications and transport protocols to explicitly provide >>>>> limited information to devices on path >>>>>=20 >>>>> - allow devices on path to provide feedback and information about >>>>> the path to sending endpoints, under sending endpoint control >>>>>=20 >>>>> - allow devices on path to provide information about the path to >>>>> receiving endpoints, with feedback to the sending endpoint, under >>>>> sending endpoint control >>>>>=20 >>>>> Note that 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 at the level of detail that is useful for the network, >>>>> while encrypting everything else. This is important to avoid = future >>>>> implicit treatment and the resulting ossification, as well as to >>>>> leverage the principle of least exposure to minimize privacy risks = presented by explicit cooperation. >>>>>=20 >>>>> Given that the primary goal of PLUS is to enable the deployment of >>>>> arbitrary, fully encrypted transport protocols, 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. >>>>>=20 >>>>> 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 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 >>>>> these use cases and requirements. The working group will close if >>>>> it is not able to come to consensus on a protocol design to meet = these requirements. >>>>>=20 >>>>> The working group will additionally aim to identify other working >>>>> groups that could or should 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. >>>>> TLS) which could be used for encryption of transport protocols = running over PLUS. >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Spud mailing list >>>> Spud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spud >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>=20 >> -- >> --- >> Toerless Eckert, eckert@cisco.com >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- Mark Nottingham https://www.mnot.net/ From nobody Sun May 22 23:53: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 69FEA12D564 for ; Sun, 22 May 2016 23:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 hltXgXzkLsN8 for ; Sun, 22 May 2016 23:53:48 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 816E112D546 for ; Sun, 22 May 2016 23:53:48 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b4jkF-0000Y8-9r; Mon, 23 May 2016 08:53:43 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b4jkE-0001xz-Ml; Mon, 23 May 2016 08:53:43 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <20160522220726.GC2511@cisco.com> Date: Mon, 23 May 2016 08:53:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <0E98FD9B-B093-4636-AFBB-D4460871F8D2@ifi.uio.no> <7966EBB3-733C-406F-B172-C16AEB3A296B@trammell.ch> <20160522220726.GC2511@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 10 sum msgs/h 2 total rcpts 42017 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.646, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 618B79360C66A1F167B971F98BB50AEADA2067C5 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 10083 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 06:53:51 -0000 I agree with both of you. > On 23 May 2016, at 00:07, Toerless Eckert wrote: >=20 > Not sure how close we are in standardizing things, but certainly it = would be helped > to have more writeups of experiences and experimentation. I am a bit = concerned if > things learned on different tracks is mutually reviewed to come to = best common > conclusions. Eg: v4/v6 happy eyeballs, transport happy eyeballs, = figuring out redundant > multipaths in MP-TCP/SCTP, ICE optimizations in RTCWEB/RTP, etc. pp. >=20 > All problems may be slightly different from each other, but = effectively, the complexity > of a host transport stack will be to be able to do all of it, and i am = sure there is > a lot of overlap, and if we're lucky we figure out common = recommendations if not standards. >=20 > On Sun, May 22, 2016 at 11:41:31PM +0200, Brian Trammell wrote: >>=20 >>> On 22 May 2016, at 21:34, Michael Welzl wrote: >>>=20 >>> Hi, >>>=20 >>> I???m sorry for derailing this a little - it isn???t so relevant to = the BoF, but I???d really like to answer this part of the discussion: >>>=20 >>>> On 20. mai 2016, at 12.32, Brian Trammell wrote: >>>>=20 >>>>=20 >>>>> On 19 May 2016, at 21:17, Tom Herbert wrote: >>>>>=20 >>>>> On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert = wrote: >>>=20 >>> (snip) >>>=20 >>>=20 >>>>> With something like SPUD (basically anything not simple TCP/IPv4) = we >>>>> are always faced with the same problem that some networks on the >>>>> Internet may arbitrarily drop or otherwise restrict packets (we = know >>>>> for instance that some network operators choose to severely rate = limit >>>>> all UDP because of DOS concerns). So even if we do manage to = start >>>>> deploying transport protocols over UDP we are going have TCP as a >>>>> fallback for indefinite future, i.e. more happy eyeballs. >>>>=20 >>>> Yes, and if we do manage to start deploying transport protocols = over IPv6, we are going to have IPv4 fallback for an indefinite future. = I share your concern about happy eyeballs state explosion (a phenomenon = we refer to around the office as "angry eyeballs" -> eight orthogonal = network/transport layer choices to test at startup means that every flow = begins with a 256 packet burst)... but the benefit of doing this to = transport flexibility is potentially worth the cost, which is the = fundamental question we want to address in PLUS. >>>=20 >>> I have a problem with this ???angry eyeballs??? thing: it???s = assuming a very simplistic happy eyeballing algorithm and, by calling it = names, gives the impression as if the described problem was universal to = all possible happy eyeballing algorithms - which isn???t the case. >>>=20 >>> For example: we often surf to the same websites, which are often on = CDNs, on a path that doesn???t change very much. So if my computer would = happy eyeball slowly and store information in its cache, that = information is potentially valid and useful for a LONG time. Then, why = not use the favored transport *only* as long as the cache hasn???t = expired, and then try fall-backs if things fail? Also the = multiplicative effect that you???re pointing at can be circumvented. = E.g., if TCP doesn???t work over IPv6, it doesn???t make much sense to = try a different transport over v6??? so the number of tests can be = gradually reduced. >>>=20 >>> I???m just giving examples to say that much more reasonable = mechanisms than the one that you sketch here could be devised. Happy = Eyeballing doesn???t *need* to be ???angry???. >>=20 >> I agree with you here. There are lots and lots of ways to keep the = state manageable. For example, quite a few impairments you might want to = happy-eyeball around seem to be linked to access networks, as opposed to = impairments along the path. For these, caching information on a = per-interface / per-connection-profile basis amortizes the measurement = overhead quite well. >>=20 >> I think it *is* our responsibility, though, in standardizing things = that might not work everywhere, to carefully specify how the measurement = of multiple features should work, because the naive implementation of = these measurements done in an ad-hoc way, or designs which do not = carefully consider the tradeoff between cache management overhead and = network overhead, lead to the worst case, which does deserve the name. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>>=20 >>> Cheers, >>> Michael >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>=20 >=20 >=20 >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com From nobody Mon May 23 03:33: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 A3B2A12D533 for ; Mon, 23 May 2016 03:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 R97OqRLsK4lj for ; Mon, 23 May 2016 03:33: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 49CEF12D09A for ; Mon, 23 May 2016 03:33:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4F6E9D9307; Mon, 23 May 2016 12:33:15 +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 R-PNeulDp3D8; Mon, 23 May 2016 12:33:15 +0200 (MEST) Received: from [192.168.178.33] (p5DEC20E1.dip0.t-ipconnect.de [93.236.32.225]) (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 D8F8DD9304; Mon, 23 May 2016 12:33: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: <20160520150936.GK2511@cisco.com> Date: Mon, 23 May 2016 12:33:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160520150936.GK2511@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 10:33:22 -0000 Hi Toerless, thanks for the detailed feedback. Find selectively a few comments inline = for now. Brian and I will be working on updating the charter and then = come back to you and the list. > Am 20.05.2016 um 17:09 schrieb Toerless Eckert : >=20 >> Path Layer UDP Substrate (PLUS) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>=20 >> The PLUS working group's goal is to enable the deployment of new, >> encrypted transport protocols, while providing a >> transport-independent method to signal flow semantics under >> transport and application control. >=20 > Don't like don't understand this paragraph. > - What if we do not develope new transprt protocols but recipes > how to modify existing transport protocols to run in PLUS ? Sorry, that=E2=80=99s actually seems to be easily miss understandable. = What we wanted to say it, that PLUS will make it easier to deploy new = protocol as well as encrypted protocols. However, in the wg we do not = plan to design any new protocol and as a starting point we will = implement PLUS for the use with existing protocols of course. We will = clarify this sentences. > - "We are going to cook stew while juggling 4 balls". The relationship > between the two is not really clear from the sentence.=20 > - What does "under transport and application control" mean ? =E2=80=A6 vs. middlebox control. The big goals is to give the control = back to the owner which is the some layer in the endhost. > - Does not cover the key aspect of being able to implement these = protocols > as part of application code. Yes, for us that is not the main goals. However. you do find this in the = requirements doc (draft-trammels-spud-req). Of course we do not list all = requirements in the charter. For me this is rather a question of = deployability (than functionality). However, I know how important this = point is for application designers. Still providing PLUS functionality = should be possible in user space as well as in the kernel. I=E2=80=99m = sure we will have this discussion on-going in a potential wg. I don=E2=80=99= t think it not to be emphasized that much in the charter. For it is just = one aspect/benefit of many. >=20 > The goal of the PLUS working group is to overcome ossification of > deployments of new transport layer work. PLUS will develop a new > transport layer approach with the following properties: >=20 > - The transport protocol is encrypted. > - A transport protocol independent inband layer is used for signaling = of > flow semantics. > - The transport layer can be implemented in application layer code. >=20 >> The current Internet protocol stack has no layer for explicit, >> in-band signaling of flow semantics and characteristics to network >> elements in an interdomain context, nor an integrated signaling >> mechanism from network elements to back to endpoints and = applications. >>=20 >> This layer never evolved within the stack, because middleboxes and >> other devices on path could simply inspect and modify headers and >> payload of unencrypted traffic at every layer. This implicit use of >> information from the transport and application layers is a >> key cause of the ossification that makes it hard or impossible >> to deploy new protocols. >=20 > First paragraph wrong if you take STUN/ICE/MALICE into account. > Second paragraph unfair because it's hitting only one side. Give > the IETF some friendly slapping too, please. We already added the work in-band here. >=20 > Proposed text: >=20 > Traditionally, the Internet protocols did not provide explicit, > transport protocol independent signaling of flow characteristics to > on-path network devices. In return, the industry developed the = practice > of inspecting protocol headers all the way from the transport layer > ports to application payload. This practice is called DPI (Deep Packet > Inspection. Later on, middleboxes started to filter or modify deep > into packets as well, for example to fix up IP addresses in = application > layer protocols in NAT middleboxes. This was all possible because > historically all these layers where (and partially are) unencrypted.=20= >=20 > Later IETF standards track onpath signaling work such as RSVP or NSIS = could not > overcome this practice because it could not not solely be implemented = by > applications interested in it because these protocols had to be = implemented by > OS vendors. Investmenting in these protocols was unattractive too, = because > by default middleboxes that do not support these protocols would = simply > drop them: The practice of unspecified, vendor specific DPI had lead = to a > "security" model in middleboxes where it was impossible to deploy new > transport protocols that could be recognized and supported by = pre-existing > middleboxes without new work on these middleboxes. This lead to = ossification > in deployment of new transport work.=20 >=20 > In recent years, STUN/ICE and extensions to it started to introduce > the ability for onpath inband explicit signaling to middleboxes, but > being limited to be used purely with existing UDP based transport = options, > they do not address how to solve the problem for applications using > non-UDP transport. This is very much focused to the application view. This is also right = but we tried to keep the charter short and focused and therefore this = not further discuss these (as well as other) aspect in detail. Brian and = I will have another look at this, but as I said I don=E2=80=99t think it = is need to elaborate (only) this aspect that much. >=20 >> In order to support more ubiquitous deployment of encryption, >> explicit signaling must be added to the stack, and it must be >> transport protocol independent. >=20 >> 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. >=20 > Better: >=20 > The natural layer for flow information is between Internet and = Transport > protocols - IP/IPv6 options/extensions or a common transport sublayer. > Implementation in the IP/IPv6 layer makes it difficult o adopt though > because it would not allow for implementation in application code. Your last sentence is not the point we were trying to make here. Again = your view is very application-centric (which is not bad; just saying = that other people have other views on the problem). We simply wanted to = shortly note that there are deployment issues with IP option, e.g. slow = path processing of IPv6 options. >=20 >> Additionally, 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. >>=20 >> The PLUS working group will specify a new protocol as a Path Layer >> User Substrate (PLUS), to support experimental deployment of >> explicit cooperation between endpoints and devices on path, with the = following goals: >>=20 >> - enable ubiquitous deployment of encrypted higher layer protocols > ^^^ transport and Here our view on higher layer is everything above PLUS (higher than = PLUS) therefore including transport. >> by providing exposure of similar semantics to existing protocols = (e.g. >> TCP) to devices on path (e.g. NATs and firewalls) >>=20 >> - allow applications and transport protocols to explicitly provide >> limited information to devices on path >>=20 >> - allow devices on path to provide feedback and information about >> the path to sending endpoints, under sending endpoint control >>=20 >> - allow devices on path to provide information about the path to >> receiving endpoints, with feedback to the sending endpoint, under >> sending endpoint control >=20 > So.. The biggest discussion point i guess will be around the = "limited", > where the privacy advocacy segment of our population will argue > "nothing", and the evil-network-doer will argue "everything=E2=80=9C. Yes, that discussion need to take place in the wg. >=20 > What i really want to see is this: >=20 > - Allow the application to learn from the network devices what = information > it must present in the clear to have its traffic be passed through > and/or receive additional treatment by the network. >=20 > Aka: "Security guard: Sure, you can go through this door if you show = me your else not" >=20 > Then the app can decide if it wants to show . Otherwise = the > apps have to operate like corporate drones, carrying around their = corp-ID > in the open all the time hoping that thats the right credential. >=20 > Or to rephrase: if we do not even attempt to overcome TCP port numbers = as > credentials then we're lame and will not be successful. Okay=E2=80=A6 I first of all have to simply say no here. I don=E2=80=99t = want the middleboxes to require anything here, because why would a = middlebox not just say =E2=80=9Eeither you show me all you content in = plain or I don=E2=80=99t transport you data=E2=80=9C. I believe that=E2=80= =99s something we all don=E2=80=99t want and building a mechanism that = could lead to this, it the last thing I want. I know what you intention = is here, but we have to be more than careful here and the way you=E2=80=99= ve just phrased it, I can just disagree. However, I would propose to = have this discussion in a separate thread. >=20 >> Note that this approach explicitly gives the control of information >> exposure back the application and/or transport layer protocol on >> the end host. >=20 > remove "and/or transport layer protocols". We MUST have auditability > of what is being sent in the clear by the application. We can not > have transport protocols inserting information in the clear without > the app knowing. Also, again there is not only the application view here. iI e.g. TCP is = used over PLUS, it=E2=80=99s the transport that =E2=80=9Atells=E2=80=98 = PLUS, please expose the equivalent to my SYN such that a firewall knows = this is the first packet I=E2=80=99ve sent. More general, a transport = will decide about exposing transport semantics and the application might = expose traffic characteristics because only the applications know how = the traffic should be treated. >=20 >> It is the goal of PLUS to minimize the information >> exposed at the level of detail that is useful for the network, >> while encrypting everything else. This is important to avoid future >> implicit treatment and the resulting ossification, as well as to >> leverage the principle of least exposure to minimize privacy risks >> presented by explicit cooperation. >=20 > How about a next paragraph about this: >=20 > Text: > In cases where middleboxes require auditability/unencrypted access to > the encrypted information of a flow, PLUS can still be used, but the > encryption keys need to be shared between application and middleboxes > (or backend thereof). PLUS itself will not consider any mechanisms > for such encryption key sharing, but instead expects this to be done > by a higher layer in the application. > End of text. So also again, I think this point needs further discussion in a wg. = However, for me this is not the primary use case (and therefore not = mentioned explicitly in the charter; even though e=E2=80=99ve previously = discussed this point). My take is that given the higher layer needs to = set up the encryption context anyway, it is the responsibility of the = higher who should be allowed to decrypt something. I can see a point = that it might makes sense to encryption different part of the PLUS = header maybe with different keys. But that=E2=80=99s again just one = requirement that should be discussed in a potential wg. >=20 > I would like to see something to this extend, because to me there > are two classes of key sharing and they have a crucial difference: >=20 > One where the application is actually knowledgable about this and = wants > to support this key sharing, such as in banking applications for = auditing middleboxes > (money laundering rules etc..). And PLUS can be perfectly be used. the = app/ > middleboxes will just have to write up their key sharing as another = layer in the app > and middlebox backend. >=20 > The other class of course is (L)I where the premise is that the app is = unaware. > I want to make it as clear as possible that there is nothing in PLUS = or > the encrypted transports it works on that enables this model. If = somebody > wants to make this model work, he has to define another secret key = sharing > layer in the application cocde or other layers, but PLUS needs to stay = clean >=20 >>=20 >> Given that the primary goal of PLUS is to enable the deployment of >> arbitrary, fully encrypted transport protocols, 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 > "threat model" =3D=3D "attack vector" ?? >> modification or deletion of exposed information by middleboxes and >> other devices on path, by allowing a remote endpoint to detect = modifications. >=20 > Detection of messups is a pretty low bar. I do not need encryption for > that. A protected checksum will suffice. The "encryption where needed" = is > also i think a basic question - eg: would be nice we we had clarity = during > charter: >=20 > I as assuming in my above comments that we would ALWAYS have = encryption, > and that we would need application layer key sharing. Is that the = model > we want ?? If not, what are the criteria for not having encryption ? = Do > we think we can agree on criteria during charter ? Okay, here we are talking about different encryption and we should and = will clarify this in the charter (while I thought this was clear). We = would envisions that all higher layer protocols will encrypt everything, = incl. the transport header; however that=E2=80=99s the responsibility of = the higher layer protocol(s) and independent of what PLUS does. However, = PLUS will not negotiate an own encryption context, while it will use the = context from the higher protocol to encrypt potentially some data in the = PLUS header. Of course we will not encrypt the whole PLUS header given = the goal is to expose information to middleboxes (even when we don=E2=80=99= t have a trust relationship with them). However, there might be other = cases where we need even to encrypt something in the PLUS header, e.g. = an encrypted feedback channel might be useful. If we don=E2=80=99t have = any encryption context from the higher layer, because even unencrypted = traffic could decide to use PLUS, we however maybe cannot use all PLUS = features. Mirja >=20 >> 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 >> these use cases and requirements. The working group will close if >> it is not able to come to consensus on a protocol design to meet >> these requirements. >>=20 >> The working group will additionally aim to identify other working >> groups that could or should 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. >> TLS) which could be used for encryption of transport protocols >> running over PLUS. >>=20 >=20 > Cheers > Teorless >>=20 >>=20 >>=20 >>> On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) = wrote: >>>=20 >>> My comment is *only* that the sentence "The current Internet = protocol stack has no layer for explicit signaling of flow semantics and = characteristics to network elements" needs to be improved, in my = personal point of view. >>>=20 >>> For instance, for NAT/FW control, there are many existing = out-of-band protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and = SIMCO), COPS, etc., not to mention all the SDN protocols, which are = typically all flow-based. They are all out-of-band but e.g. NSIS would = have been end-to-end. The intention and deployment model of these = protocols may be very different to what SPUD aims for, and none of them = is deployed end-to-end in the Internet. But I think this sentence has to = be slightly more specific how to differentiate e.g. from control plane = solutions. >>>=20 >>> Michael >>>=20 >>>=20 >>> -----Original Message----- >>> From: Toerless Eckert [mailto:eckert@cisco.com] >>> Sent: Thursday, May 19, 2016 8:27 PM >>> To: Tom Herbert >>> Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org >>> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming = follow-on to SPUD BoF >>>=20 >>> Tom, Michael >>>=20 >>> I am reading your positions and i am confused: >>>=20 >>> DSCP is very successfull in enterprise networks. SPUD does not have = to be successfull "on the Internet". To me it would already be a great = success if it would help to improve controlled network services (like = enterprise or 4G/5G networks). And their transit traffic across the = Internet (without changing anything on the Internet itself). >>>=20 >>> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. = Even if we often think about them as per-flow and ould maybe like them = to be restrict to per-flow. At least i don't know any normative = reference that defines them to be per-flow. >>>=20 >>> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the = analysis that all those mechanisms fail to provide an easily deplopyale = framework in the face of middleboxes. Aka: their presence and mostly = non-success should be an argument FOR working on spud. Not against it. >>>=20 >>> If a NAT/FW does support any flow signaling, its most likely inband. = Every NAT/firwall supports flow recognition via the explicit signaling = of flow-based transport protoocols like TCP. They do try to do the same = for UDP and because that has no explicit flow signaling, thats where the = problem starts. NAT/FW do deep packet inspection which has all these = problems we know. SPUD sets out to solve/reduce these NAT/FW issues. >>>=20 >>> Non-support of anything like IP options is IMHO primarily driven by = the absence of unform cross-OS/Dev-language APIs for them. Yes. It may = suck architecturally by designing protocol stacks based on reality like: = applications will only be able to use UDP and TCP, so lets do new work = on top of them, but to me the most important goal is to find the best = deployable solution to a problem. Not the architecturally cleanest one. = If you give me research money to work outside of reality i will happily = take it though and represent a different perspective. >>>=20 >>> Please, i do not want to dismiss your opposition, i just don't = understand how the arguments you make are working out. Maybe you can = explain to me where i am going wrong in my interpretations above. >>>=20 >>> Cheers >>> Toerless >>>=20 >>> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >>>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >>>> wrote: >>>>> Does the sentence ... >>>>>=20 >>>>> The current Internet protocol stack has no layer for explicit = signaling of flow semantics and characteristics to network elements ... >>>>>=20 >>>>> actually wants to say something like >>>>>=20 >>>>> The current Internet protocol stack has no layer for explicit = *in-band* signaling of flow semantics and characteristics ... ? >>>>>=20 >>>>> I may be wrong, but there is no shortage of IETF and non-IETF = protocols that can signal flow semantics and characteristics = out-of-band, either path-coupled or path-decoupled, e.g., in the control = or management plane. As a result, there are protocol "layers" for that = signaling, but they are not in-band. There may also be other ways to fix = this problem (e.g., by adding "end-to-end" or "inter-domain" instead of = "in-band"). >>>>>=20 >>>> Not to mention that TOS and diff-serv are in-band signaling = mechanisms >>>> to the network, ECN is explicitly signaling from the network. Given >>>> that they've been around for many years but have never been widely >>>> deployed on the Internet makes me wonder if any in-band signaling >>>> mechanism will ever catch on. The use of out of band signaling = should >>>> be considered, especially considered that in many cases like NAT = and >>>> firewall the network elements that need signaling are likely in = local >>>> networks of one side of the connection. >>>>=20 >>>> I have a similar concern about the statement that IP options/EH and >>>> extension headers are being left off the table as part of a = solution. >>>> The fact that neither have these caught on in the Internet and that >>>> tells me two things 1) No IP option is needed for the Internet to >>>> operate and be successful which makes me wonder if signaling = between >>>> network and hosts is even required 2) If the extensibility = mechanisms >>>> of IP are chronically not deployable, I wonder why any alternative >>>> that does not yet exist but intends to solve the same problem would = be >>>> any more deployable. >>>>=20 >>>> Tom >>>>=20 >>>>> Michael >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] = On >>>>> Behalf Of Brian Trammell >>>>> Sent: Thursday, May 19, 2016 5:07 PM >>>>> To: stackevo-discuss@iab.org >>>>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to >>>>> SPUD BoF >>>>>=20 >>>>> Greetings, all, >>>>>=20 >>>>> Forwarding this to the correct address for this mailing list = (oops). Please discuss at spud@ietf.org. >>>>>=20 >>>>> Thanks, cheers, >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>> From: Brian Trammell >>>>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>>>> To: spud@ietf.org >>>>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja = Kuehlewind >>>>>> (IETF)" , Spencer Dawkins at IETF >>>>>> >>>>>>=20 >>>>>> Greetings, all, >>>>>>=20 >>>>>> We propose to hold a working-group forming BoF in Berlin as a = follow-on to the SPUD work, to define a common substrate protocol for = encrypted transports based on the requirements derived from = experimentation with the SPUD prototype. >>>>>>=20 >>>>>> First, note that since the acronym "SPUD" refers primarily to the = prototype itself, any follow-on working group should have a different = name. We're using the derived requirements, not starting for the = prototype. The name is a subject for discussion, and suggestions are = welcome. To have something to put in the proposed charter, we'd propose = "Path Layer UDP Substrate" (PLUS) as a starting point. >>>>>>=20 >>>>>> The proposed charter appears below. We're interested in hearing = initial feedback on the proposed charter in preparation for a BoF = proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). = Is there work to do here within the IETF? Is the scope of the proposed = charter appropriate? Is there energy to do this work? >>>>>>=20 >>>>>> Thanks, cheers, >>>>>>=20 >>>>>> Brian and Mirja >>>>>>=20 >>>>>>=20 >>>>>> Path Layer UDP Substrate (PLUS) >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>>>=20 >>>>>> The PLUS working group???s goal is to enable the deployment of = new, >>>>>> encrypted transport protocols, while providing a >>>>>> transport-independent method to signal flow semantics under = transport and application control. >>>>>>=20 >>>>>> The current Internet protocol stack has no layer for explicit >>>>>> signaling of flow semantics and characteristics to network >>>>>> elements, nor an integrated signaling mechanism from network >>>>>> elements to back to endpoints and applications. This layer never >>>>>> evolved within the stack, because middleboxes and other devices = on >>>>>> path could simply inspect and modify headers and payload of >>>>>> unencrypted traffic at every layer. This implicit use of >>>>>> information from the transport and application layers is a key = origin of the ossification that makes it hard or impossible to deploy = new protocols. >>>>>>=20 >>>>>> In order to support more ubiquitous deployment of encryption, >>>>>> explicit signaling must be added to the stack, and it must be >>>>>> transport protocol independent. 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. >>>>>> Additionally, 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. >>>>>>=20 >>>>>> The PLUS working group will specify a new protocol as a Path = Layer >>>>>> User Substrate (PLUS), to support experimental deployment of >>>>>> explicit cooperation between endpoints and devices on path, with = the following goals: >>>>>>=20 >>>>>> - enable ubiquitous deployment of encrypted higher layer = protocols >>>>>> by providing exposure of similar semantics to existing protocols = (e.g. >>>>>> TCP) to devices on path (e.g. NATs and firewalls) >>>>>>=20 >>>>>> - allow applications and transport protocols to explicitly = provide >>>>>> limited information to devices on path >>>>>>=20 >>>>>> - allow devices on path to provide feedback and information about >>>>>> the path to sending endpoints, under sending endpoint control >>>>>>=20 >>>>>> - allow devices on path to provide information about the path to >>>>>> receiving endpoints, with feedback to the sending endpoint, under >>>>>> sending endpoint control >>>>>>=20 >>>>>> Note that 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 at the level of detail that is useful for the network, >>>>>> while encrypting everything else. This is important to avoid = future >>>>>> implicit treatment and the resulting ossification, as well as to >>>>>> leverage the principle of least exposure to minimize privacy = risks presented by explicit cooperation. >>>>>>=20 >>>>>> Given that the primary goal of PLUS is to enable the deployment = of >>>>>> arbitrary, fully encrypted transport protocols, 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. >>>>>>=20 >>>>>> 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 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 >>>>>> these use cases and requirements. The working group will close if >>>>>> it is not able to come to consensus on a protocol design to meet = these requirements. >>>>>>=20 >>>>>> The working group will additionally aim to identify other working >>>>>> groups that could or should 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. >>>>>> TLS) which could be used for encryption of transport protocols = running over PLUS. >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Spud mailing list >>>>> Spud@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spud >>>>=20 >>>> _______________________________________________ >>>> Spud mailing list >>>> Spud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spud >>>=20 >>> -- >>> --- >>> Toerless Eckert, eckert@cisco.com >>=20 >=20 >=20 >=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >=20 >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon May 23 03:40: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 EF33912D5FA for ; Mon, 23 May 2016 03:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 05NJ0j_YqyVI for ; Mon, 23 May 2016 03:40:31 -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 5F1E712B025 for ; Mon, 23 May 2016 03:40:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 21061D930C; Mon, 23 May 2016 12:40:30 +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 4xAPsl1fHLbC; Mon, 23 May 2016 12:40:29 +0200 (MEST) Received: from [192.168.178.33] (p5DEC20E1.dip0.t-ipconnect.de [93.236.32.225]) (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 90AC8D9304; Mon, 23 May 2016 12:40:29 +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: <94911BF5-C313-4816-896B-A90FA630EE5B@mnot.net> Date: Mon, 23 May 2016 12:40:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94911BF5-C313-4816-896B-A90FA630EE5B@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , "spud@ietf.org" Subject: Re: [Spud] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 10:40:35 -0000 Hi Mark, just a very quick reply for now: None of the three points listed below = is something that we want to support, but is it really hard to prevent = those cases, isn=E2=80=99t it? You can always add additional data on any = layer. Our big goals is it to enable more encryption and only expose = selectively under the control of the endpoint (instead of simply = exposing everything by default as unencrypted traffic is doing it = today). I think the more important part to consider is draft-trammels-spud-req = is the following: =E2=80=9E=E2=80=A6 the use of SPUD for standard signaling must use a = common vocabulary with registered codepoints allocated under relatively restrictive policy.=E2=80=9C We want control about which information should be exposed including a = full spec explaining how those information should be used (and also = given good reason why it=E2=80=99s useful). I hope that=E2=80=99s helpful for now. More later. Mirja > Am 23.05.2016 um 04:07 schrieb Mark Nottingham : >=20 > Hi Brian, >=20 > At the BoF, I and several other people highlighted concerns about = privacy and SPUD: > http://www.ietf.org/proceedings/92/minutes/minutes-92-spud (under = "Open Discussion") >=20 > The response at that time was that these considerations were = important, and that work on them could happen in parallel with the SPUD = experiment. >=20 > Unfortunately, there doesn't appear to have been much obvious progress = in list discussion, and draft-trammell-spud-req is quite brief on the = topic: >=20 > """ > SPUD must allow endpoints to control the amount of information exposed = to middleboxes, with the default being the minimum necessary for correct = functioning. This includes the cryptographic protection of transport = layer headers from inspection by devices on path, in order to prevent = ossification of these headers. > """ >=20 > However, I can see that some thought along these lines has been put = into the proposed charter below. So, a few questions. >=20 > * In the proposed approach, will it be possible for a network operator = to use PLUS mechanisms to insert arbitrary metadata (e.g., a user = identifier) in the server-bound stream of a client-server protocol? =20 >=20 > * In the proposed approach, will it be possible for a network operator = to require a client to insert a particular kind of metadata into a = stream, e.g., to gain network access? >=20 > * In the proposed approach, will it be possible for a network to offer = a different quality of service to servers that insert specific metadata = into their streams (thereby affecting network neutrality)? >=20 > See also: http://mnot.github.io/I-D/transport-metadata-impact/ >=20 > Cheers, >=20 >=20 >> On 20 May 2016, at 9:02 PM, Brian Trammell wrote: >>=20 >> Hi, all, >>=20 >> I've heard one concrete charter suggestion so far; the edited draft = charter (changed paragraph 2) is below. If others would like to see = points clarified to answer their questions, please send suggested edits. = :) >>=20 >> I take the fact that we're diving into technical discussion as an = indication that those participating are at least interested in the BoF, = if not (yet ;) ) convinced of the need for a WG at this space? >>=20 >> Thanks, cheers, >>=20 >> Brian >>=20 >>=20 >> Path Layer UDP Substrate (PLUS) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>=20 >> The PLUS working group's goal is to enable the deployment of new, >> encrypted transport protocols, while providing a >> transport-independent method to signal flow semantics under >> transport and application control. >>=20 >> The current Internet protocol stack has no layer for explicit, >> in-band signaling of flow semantics and characteristics to network >> elements in an interdomain context, nor an integrated signaling >> mechanism from network elements to back to endpoints and = applications. >> This layer never evolved within the stack, because middleboxes and >> other devices on path could simply inspect and modify headers and >> payload of unencrypted traffic at every layer. This implicit use of >> information from the transport and application layers is a >> key cause of the ossification that makes it hard or impossible >> to deploy new protocols. >>=20 >> In order to support more ubiquitous deployment of encryption, >> explicit signaling must be added to the stack, and it must be >> transport protocol independent. 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. >> Additionally, 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. >>=20 >> The PLUS working group will specify a new protocol as a Path Layer >> User Substrate (PLUS), to support experimental deployment of >> explicit cooperation between endpoints and devices on path, with the = following goals: >>=20 >> - enable ubiquitous deployment of encrypted higher layer protocols >> by providing exposure of similar semantics to existing protocols = (e.g. >> TCP) to devices on path (e.g. NATs and firewalls) >>=20 >> - allow applications and transport protocols to explicitly provide >> limited information to devices on path >>=20 >> - allow devices on path to provide feedback and information about >> the path to sending endpoints, under sending endpoint control >>=20 >> - allow devices on path to provide information about the path to >> receiving endpoints, with feedback to the sending endpoint, under >> sending endpoint control >>=20 >> Note that 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 at the level of detail that is useful for the network, >> while encrypting everything else. This is important to avoid future >> implicit treatment and the resulting ossification, as well as to >> leverage the principle of least exposure to minimize privacy risks >> presented by explicit cooperation. >>=20 >> Given that the primary goal of PLUS is to enable the deployment of >> arbitrary, fully encrypted transport protocols, 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. >>=20 >> 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 >> these use cases and requirements. The working group will close if >> it is not able to come to consensus on a protocol design to meet >> these requirements. >>=20 >> The working group will additionally aim to identify other working >> groups that could or should 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. >> TLS) which could be used for encryption of transport protocols >> running over PLUS. >>=20 >>=20 >>=20 >>=20 >>> On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) = wrote: >>>=20 >>> My comment is *only* that the sentence "The current Internet = protocol stack has no layer for explicit signaling of flow semantics and = characteristics to network elements" needs to be improved, in my = personal point of view. >>>=20 >>> For instance, for NAT/FW control, there are many existing = out-of-band protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and = SIMCO), COPS, etc., not to mention all the SDN protocols, which are = typically all flow-based. They are all out-of-band but e.g. NSIS would = have been end-to-end. The intention and deployment model of these = protocols may be very different to what SPUD aims for, and none of them = is deployed end-to-end in the Internet. But I think this sentence has to = be slightly more specific how to differentiate e.g. from control plane = solutions. >>>=20 >>> Michael >>>=20 >>>=20 >>> -----Original Message----- >>> From: Toerless Eckert [mailto:eckert@cisco.com] >>> Sent: Thursday, May 19, 2016 8:27 PM >>> To: Tom Herbert >>> Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org >>> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming = follow-on to SPUD BoF >>>=20 >>> Tom, Michael >>>=20 >>> I am reading your positions and i am confused: >>>=20 >>> DSCP is very successfull in enterprise networks. SPUD does not have = to be successfull "on the Internet". To me it would already be a great = success if it would help to improve controlled network services (like = enterprise or 4G/5G networks). And their transit traffic across the = Internet (without changing anything on the Internet itself). >>>=20 >>> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. = Even if we often think about them as per-flow and ould maybe like them = to be restrict to per-flow. At least i don't know any normative = reference that defines them to be per-flow. >>>=20 >>> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the = analysis that all those mechanisms fail to provide an easily deplopyale = framework in the face of middleboxes. Aka: their presence and mostly = non-success should be an argument FOR working on spud. Not against it. >>>=20 >>> If a NAT/FW does support any flow signaling, its most likely inband. = Every NAT/firwall supports flow recognition via the explicit signaling = of flow-based transport protoocols like TCP. They do try to do the same = for UDP and because that has no explicit flow signaling, thats where the = problem starts. NAT/FW do deep packet inspection which has all these = problems we know. SPUD sets out to solve/reduce these NAT/FW issues. >>>=20 >>> Non-support of anything like IP options is IMHO primarily driven by = the absence of unform cross-OS/Dev-language APIs for them. Yes. It may = suck architecturally by designing protocol stacks based on reality like: = applications will only be able to use UDP and TCP, so lets do new work = on top of them, but to me the most important goal is to find the best = deployable solution to a problem. Not the architecturally cleanest one. = If you give me research money to work outside of reality i will happily = take it though and represent a different perspective. >>>=20 >>> Please, i do not want to dismiss your opposition, i just don't = understand how the arguments you make are working out. Maybe you can = explain to me where i am going wrong in my interpretations above. >>>=20 >>> Cheers >>> Toerless >>>=20 >>> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >>>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >>>> wrote: >>>>> Does the sentence ... >>>>>=20 >>>>> The current Internet protocol stack has no layer for explicit = signaling of flow semantics and characteristics to network elements ... >>>>>=20 >>>>> actually wants to say something like >>>>>=20 >>>>> The current Internet protocol stack has no layer for explicit = *in-band* signaling of flow semantics and characteristics ... ? >>>>>=20 >>>>> I may be wrong, but there is no shortage of IETF and non-IETF = protocols that can signal flow semantics and characteristics = out-of-band, either path-coupled or path-decoupled, e.g., in the control = or management plane. As a result, there are protocol "layers" for that = signaling, but they are not in-band. There may also be other ways to fix = this problem (e.g., by adding "end-to-end" or "inter-domain" instead of = "in-band"). >>>>>=20 >>>> Not to mention that TOS and diff-serv are in-band signaling = mechanisms >>>> to the network, ECN is explicitly signaling from the network. Given >>>> that they've been around for many years but have never been widely >>>> deployed on the Internet makes me wonder if any in-band signaling >>>> mechanism will ever catch on. The use of out of band signaling = should >>>> be considered, especially considered that in many cases like NAT = and >>>> firewall the network elements that need signaling are likely in = local >>>> networks of one side of the connection. >>>>=20 >>>> I have a similar concern about the statement that IP options/EH and >>>> extension headers are being left off the table as part of a = solution. >>>> The fact that neither have these caught on in the Internet and that >>>> tells me two things 1) No IP option is needed for the Internet to >>>> operate and be successful which makes me wonder if signaling = between >>>> network and hosts is even required 2) If the extensibility = mechanisms >>>> of IP are chronically not deployable, I wonder why any alternative >>>> that does not yet exist but intends to solve the same problem would = be >>>> any more deployable. >>>>=20 >>>> Tom >>>>=20 >>>>> Michael >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] = On >>>>> Behalf Of Brian Trammell >>>>> Sent: Thursday, May 19, 2016 5:07 PM >>>>> To: stackevo-discuss@iab.org >>>>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to >>>>> SPUD BoF >>>>>=20 >>>>> Greetings, all, >>>>>=20 >>>>> Forwarding this to the correct address for this mailing list = (oops). Please discuss at spud@ietf.org. >>>>>=20 >>>>> Thanks, cheers, >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>> From: Brian Trammell >>>>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>>>> To: spud@ietf.org >>>>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja = Kuehlewind >>>>>> (IETF)" , Spencer Dawkins at IETF >>>>>> >>>>>>=20 >>>>>> Greetings, all, >>>>>>=20 >>>>>> We propose to hold a working-group forming BoF in Berlin as a = follow-on to the SPUD work, to define a common substrate protocol for = encrypted transports based on the requirements derived from = experimentation with the SPUD prototype. >>>>>>=20 >>>>>> First, note that since the acronym "SPUD" refers primarily to the = prototype itself, any follow-on working group should have a different = name. We're using the derived requirements, not starting for the = prototype. The name is a subject for discussion, and suggestions are = welcome. To have something to put in the proposed charter, we'd propose = "Path Layer UDP Substrate" (PLUS) as a starting point. >>>>>>=20 >>>>>> The proposed charter appears below. We're interested in hearing = initial feedback on the proposed charter in preparation for a BoF = proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). = Is there work to do here within the IETF? Is the scope of the proposed = charter appropriate? Is there energy to do this work? >>>>>>=20 >>>>>> Thanks, cheers, >>>>>>=20 >>>>>> Brian and Mirja >>>>>>=20 >>>>>>=20 >>>>>> Path Layer UDP Substrate (PLUS) >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>>>=20 >>>>>> The PLUS working group???s goal is to enable the deployment of = new, >>>>>> encrypted transport protocols, while providing a >>>>>> transport-independent method to signal flow semantics under = transport and application control. >>>>>>=20 >>>>>> The current Internet protocol stack has no layer for explicit >>>>>> signaling of flow semantics and characteristics to network >>>>>> elements, nor an integrated signaling mechanism from network >>>>>> elements to back to endpoints and applications. This layer never >>>>>> evolved within the stack, because middleboxes and other devices = on >>>>>> path could simply inspect and modify headers and payload of >>>>>> unencrypted traffic at every layer. This implicit use of >>>>>> information from the transport and application layers is a key = origin of the ossification that makes it hard or impossible to deploy = new protocols. >>>>>>=20 >>>>>> In order to support more ubiquitous deployment of encryption, >>>>>> explicit signaling must be added to the stack, and it must be >>>>>> transport protocol independent. 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. >>>>>> Additionally, 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. >>>>>>=20 >>>>>> The PLUS working group will specify a new protocol as a Path = Layer >>>>>> User Substrate (PLUS), to support experimental deployment of >>>>>> explicit cooperation between endpoints and devices on path, with = the following goals: >>>>>>=20 >>>>>> - enable ubiquitous deployment of encrypted higher layer = protocols >>>>>> by providing exposure of similar semantics to existing protocols = (e.g. >>>>>> TCP) to devices on path (e.g. NATs and firewalls) >>>>>>=20 >>>>>> - allow applications and transport protocols to explicitly = provide >>>>>> limited information to devices on path >>>>>>=20 >>>>>> - allow devices on path to provide feedback and information about >>>>>> the path to sending endpoints, under sending endpoint control >>>>>>=20 >>>>>> - allow devices on path to provide information about the path to >>>>>> receiving endpoints, with feedback to the sending endpoint, under >>>>>> sending endpoint control >>>>>>=20 >>>>>> Note that 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 at the level of detail that is useful for the network, >>>>>> while encrypting everything else. This is important to avoid = future >>>>>> implicit treatment and the resulting ossification, as well as to >>>>>> leverage the principle of least exposure to minimize privacy = risks presented by explicit cooperation. >>>>>>=20 >>>>>> Given that the primary goal of PLUS is to enable the deployment = of >>>>>> arbitrary, fully encrypted transport protocols, 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. >>>>>>=20 >>>>>> 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 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 >>>>>> these use cases and requirements. The working group will close if >>>>>> it is not able to come to consensus on a protocol design to meet = these requirements. >>>>>>=20 >>>>>> The working group will additionally aim to identify other working >>>>>> groups that could or should 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. >>>>>> TLS) which could be used for encryption of transport protocols = running over PLUS. >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Spud mailing list >>>>> Spud@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spud >>>>=20 >>>> _______________________________________________ >>>> Spud mailing list >>>> Spud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spud >>>=20 >>> -- >>> --- >>> Toerless Eckert, eckert@cisco.com >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon May 23 06:44: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 46BB412D8F0 for ; Mon, 23 May 2016 06:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 IvULf9pg7Tho for ; Mon, 23 May 2016 06:43:54 -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 A11CE12D199 for ; Mon, 23 May 2016 06:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1981; q=dns/txt; s=iport; t=1464011030; x=1465220630; h=date:from:to:cc:subject:message-id:mime-version; bh=QkPXIcE6jPlzHBQEPokHJtLRm7mwGUHmF70OdUyul6A=; b=KE53tEHMrB9Wj6Iae1KFAsHEbMW7DNAP8sJtQDYOm5vbNUXVSX2/uZ5v PHV3g0PD4VqNQtaFFvXNWG+CUPf+9IL2SF+W7IXuR6fqhFVBl7EyBCzpC KNm67vGRHYUy/NSXKqOJkNFybR8vg6Pt4P0X0zOKk0VA4f7d3O9sgO1i7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClAgB9CENX/4oNJK1dgze5RIIPAQ2Bd?= =?us-ascii?q?YYRgS84FAEBAQEBAQFlJ4REBDs/PBoaBYkDCMQ7AQEBAQYBAQEBAQEhj3+CYII?= =?us-ascii?q?uBY5ZiV6BL4xnCoFphE+IZI9MHgEBQoI4gVUcigMBAQE?= X-IronPort-AV: E=Sophos;i="5.26,356,1459814400"; d="scan'208";a="275996046" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2016 13:43:50 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4NDhnk2024581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2016 13:43:50 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 u4NDhn3Q014465; Mon, 23 May 2016 06:43:49 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4NDhmjF014464; Mon, 23 May 2016 06:43:48 -0700 Date: Mon, 23 May 2016 06:43:48 -0700 From: Toerless Eckert To: mirja.kuehlewind@tik.ee.ethz.ch Message-ID: <20160523134348.GB15064@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: Cc: Brian Trammell , "spud@ietf.org" Subject: [Spud] What middleboxes are allowed to know (Re: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 13:43:56 -0000 Mirja: Your answer below "i don't want the middleboxes to require anything here" is letting me totally confused. If PLUS wants to define how talk with the middlebox (or however you want to call it "pass info to it, get info from it"), then it is clear that the resut of this interaction is that you will not achieve desirable outcomes if you do not send specific info to the middlebox Please give me an example how you think PLUS will help firewall middleboxes to decide whether or not to less some traffic flow pass. Lets assume that same firewall today is using TCP port number policies and/or DPI. What in your opinion should the firewall do. > > What i really want to see is this: > > > > - Allow the application to learn from the network devices what information > > it must present in the clear to have its traffic be passed through > > and/or receive additional treatment by the network. > > > > Aka: "Security guard: Sure, you can go through this door if you show me your else not" > > > > Then the app can decide if it wants to show . Otherwise the > > apps have to operate like corporate drones, carrying around their corp-ID > > in the open all the time hoping that thats the right credential. > > > > Or to rephrase: if we do not even attempt to overcome TCP port numbers as > > credentials then we're lame and will not be successful. > > Okay??? I first of all have to simply say no here. I don???t want the middleboxes to require anything here, because why would a middlebox not just say ???either you show me all you content in plain or I don???t transport you data???. I believe that???s something we all don???t want and building a mechanism that could lead to this, it the last thing I want. I know what you intention is here, but we have to be more than careful here and the way you???ve just phrased it, I can just disagree. However, I would propose to have this discussion in a separate thread. From nobody Mon May 23 06:44: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 6B37E12B034 for ; Mon, 23 May 2016 06:44:26 -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 pGiqr5mp1PBB for ; Mon, 23 May 2016 06:44:15 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 23AB912D199 for ; Mon, 23 May 2016 06:44:10 -0700 (PDT) Received: from [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0] (unknown [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0]) by trammell.ch (Postfix) with ESMTPSA id 936D81A13A6; Mon, 23 May 2016 15:44:09 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_72E723B9-3C77-4BB5-9CF9-4EF521DE303F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Mon, 23 May 2016 15:44:09 +0200 Message-Id: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: Dave Dolson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 13:44:26 -0000 --Apple-Mail=_72E723B9-3C77-4BB5-9CF9-4EF521DE303F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 20 May 2016, at 18:17, Dave Dolson wrote: >=20 > Brian, > The text of the proposed charter doesn't mention "UDP"; it's just in = the title. >=20 > If the intent is to require the use of UDP, it should be spelled out, = I'd think. I think the situation requires the use of UDP... especially, as Toerless = says, if we make it clear that userspace implementability is a hard = requirement (which IMO it is; longer reply to Toerless' charter comments = to follow) in the charter. So yes, this should be explicit in the charter. Thanks, cheers, Brian > -Dave >=20 >=20 > -----Original Message----- > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Friday, May 20, 2016 7:02 AM > To: spud@ietf.org > Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming = follow-on to SPUD BoF >=20 > Hi, all, >=20 > I've heard one concrete charter suggestion so far; the edited draft = charter (changed paragraph 2) is below. If others would like to see = points clarified to answer their questions, please send suggested edits. = :) >=20 > I take the fact that we're diving into technical discussion as an = indication that those participating are at least interested in the BoF, = if not (yet ;) ) convinced of the need for a WG at this space? >=20 > Thanks, cheers, >=20 > Brian >=20 >=20 > Path Layer UDP Substrate (PLUS) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > The PLUS working group's goal is to enable the deployment of new, > encrypted transport protocols, while providing a > transport-independent method to signal flow semantics under > transport and application control. >=20 > The current Internet protocol stack has no layer for explicit, > in-band signaling of flow semantics and characteristics to network > elements in an interdomain context, nor an integrated signaling > mechanism from network elements to back to endpoints and applications. > This layer never evolved within the stack, because middleboxes and > other devices on path could simply inspect and modify headers and > payload of unencrypted traffic at every layer. This implicit use of > information from the transport and application layers is a > key cause of the ossification that makes it hard or impossible > to deploy new protocols. >=20 > In order to support more ubiquitous deployment of encryption, > explicit signaling must be added to the stack, and it must be > transport protocol independent. 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. > Additionally, 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. >=20 > The PLUS working group will specify a new protocol as a Path Layer > User Substrate (PLUS), to support experimental deployment of > explicit cooperation between endpoints and devices on path, with the = following goals: >=20 > - enable ubiquitous deployment of encrypted higher layer protocols > by providing exposure of similar semantics to existing protocols (e.g. > TCP) to devices on path (e.g. NATs and firewalls) >=20 > - allow applications and transport protocols to explicitly provide > limited information to devices on path >=20 > - allow devices on path to provide feedback and information about > the path to sending endpoints, under sending endpoint control >=20 > - allow devices on path to provide information about the path to > receiving endpoints, with feedback to the sending endpoint, under > sending endpoint control >=20 > Note that 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 at the level of detail that is useful for the network, > while encrypting everything else. This is important to avoid future > implicit treatment and the resulting ossification, as well as to > leverage the principle of least exposure to minimize privacy risks > presented by explicit cooperation. >=20 > Given that the primary goal of PLUS is to enable the deployment of > arbitrary, fully encrypted transport protocols, 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. >=20 > 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 > these use cases and requirements. The working group will close if > it is not able to come to consensus on a protocol design to meet > these requirements. >=20 > The working group will additionally aim to identify other working > groups that could or should 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. > TLS) which could be used for encryption of transport protocols > running over PLUS. >=20 >=20 >=20 >=20 >> On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) = wrote: >>=20 >> My comment is *only* that the sentence "The current Internet protocol = stack has no layer for explicit signaling of flow semantics and = characteristics to network elements" needs to be improved, in my = personal point of view. >>=20 >> For instance, for NAT/FW control, there are many existing out-of-band = protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, = etc., not to mention all the SDN protocols, which are typically all = flow-based. They are all out-of-band but e.g. NSIS would have been = end-to-end. The intention and deployment model of these protocols may be = very different to what SPUD aims for, and none of them is deployed = end-to-end in the Internet. But I think this sentence has to be slightly = more specific how to differentiate e.g. from control plane solutions. >>=20 >> Michael >>=20 >>=20 >> -----Original Message----- >> From: Toerless Eckert [mailto:eckert@cisco.com] >> Sent: Thursday, May 19, 2016 8:27 PM >> To: Tom Herbert >> Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org >> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming = follow-on to SPUD BoF >>=20 >> Tom, Michael >>=20 >> I am reading your positions and i am confused: >>=20 >> DSCP is very successfull in enterprise networks. SPUD does not have = to be successfull "on the Internet". To me it would already be a great = success if it would help to improve controlled network services (like = enterprise or 4G/5G networks). And their transit traffic across the = Internet (without changing anything on the Internet itself). >>=20 >> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even = if we often think about them as per-flow and ould maybe like them to be = restrict to per-flow. At least i don't know any normative reference that = defines them to be per-flow. >>=20 >> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the = analysis that all those mechanisms fail to provide an easily deplopyale = framework in the face of middleboxes. Aka: their presence and mostly = non-success should be an argument FOR working on spud. Not against it. >>=20 >> If a NAT/FW does support any flow signaling, its most likely inband. = Every NAT/firwall supports flow recognition via the explicit signaling = of flow-based transport protoocols like TCP. They do try to do the same = for UDP and because that has no explicit flow signaling, thats where the = problem starts. NAT/FW do deep packet inspection which has all these = problems we know. SPUD sets out to solve/reduce these NAT/FW issues. >>=20 >> Non-support of anything like IP options is IMHO primarily driven by = the absence of unform cross-OS/Dev-language APIs for them. Yes. It may = suck architecturally by designing protocol stacks based on reality like: = applications will only be able to use UDP and TCP, so lets do new work = on top of them, but to me the most important goal is to find the best = deployable solution to a problem. Not the architecturally cleanest one. = If you give me research money to work outside of reality i will happily = take it though and represent a different perspective. >>=20 >> Please, i do not want to dismiss your opposition, i just don't = understand how the arguments you make are working out. Maybe you can = explain to me where i am going wrong in my interpretations above. >>=20 >> Cheers >> Toerless >>=20 >> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >>> wrote: >>>> Does the sentence ... >>>>=20 >>>> The current Internet protocol stack has no layer for explicit = signaling of flow semantics and characteristics to network elements ... >>>>=20 >>>> actually wants to say something like >>>>=20 >>>> The current Internet protocol stack has no layer for explicit = *in-band* signaling of flow semantics and characteristics ... ? >>>>=20 >>>> I may be wrong, but there is no shortage of IETF and non-IETF = protocols that can signal flow semantics and characteristics = out-of-band, either path-coupled or path-decoupled, e.g., in the control = or management plane. As a result, there are protocol "layers" for that = signaling, but they are not in-band. There may also be other ways to fix = this problem (e.g., by adding "end-to-end" or "inter-domain" instead of = "in-band"). >>>>=20 >>> Not to mention that TOS and diff-serv are in-band signaling = mechanisms >>> to the network, ECN is explicitly signaling from the network. Given >>> that they've been around for many years but have never been widely >>> deployed on the Internet makes me wonder if any in-band signaling >>> mechanism will ever catch on. The use of out of band signaling = should >>> be considered, especially considered that in many cases like NAT and >>> firewall the network elements that need signaling are likely in = local >>> networks of one side of the connection. >>>=20 >>> I have a similar concern about the statement that IP options/EH and >>> extension headers are being left off the table as part of a = solution. >>> The fact that neither have these caught on in the Internet and that >>> tells me two things 1) No IP option is needed for the Internet to >>> operate and be successful which makes me wonder if signaling between >>> network and hosts is even required 2) If the extensibility = mechanisms >>> of IP are chronically not deployable, I wonder why any alternative >>> that does not yet exist but intends to solve the same problem would = be >>> any more deployable. >>>=20 >>> Tom >>>=20 >>>> Michael >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On >>>> Behalf Of Brian Trammell >>>> Sent: Thursday, May 19, 2016 5:07 PM >>>> To: stackevo-discuss@iab.org >>>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to >>>> SPUD BoF >>>>=20 >>>> Greetings, all, >>>>=20 >>>> Forwarding this to the correct address for this mailing list = (oops). Please discuss at spud@ietf.org. >>>>=20 >>>> Thanks, cheers, >>>>=20 >>>> Brian >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> From: Brian Trammell >>>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>>> To: spud@ietf.org >>>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja = Kuehlewind >>>>> (IETF)" , Spencer Dawkins at IETF >>>>> >>>>>=20 >>>>> Greetings, all, >>>>>=20 >>>>> We propose to hold a working-group forming BoF in Berlin as a = follow-on to the SPUD work, to define a common substrate protocol for = encrypted transports based on the requirements derived from = experimentation with the SPUD prototype. >>>>>=20 >>>>> First, note that since the acronym "SPUD" refers primarily to the = prototype itself, any follow-on working group should have a different = name. We're using the derived requirements, not starting for the = prototype. The name is a subject for discussion, and suggestions are = welcome. To have something to put in the proposed charter, we'd propose = "Path Layer UDP Substrate" (PLUS) as a starting point. >>>>>=20 >>>>> The proposed charter appears below. We're interested in hearing = initial feedback on the proposed charter in preparation for a BoF = proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). = Is there work to do here within the IETF? Is the scope of the proposed = charter appropriate? Is there energy to do this work? >>>>>=20 >>>>> Thanks, cheers, >>>>>=20 >>>>> Brian and Mirja >>>>>=20 >>>>>=20 >>>>> Path Layer UDP Substrate (PLUS) >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> The PLUS working group???s goal is to enable the deployment of = new, >>>>> encrypted transport protocols, while providing a >>>>> transport-independent method to signal flow semantics under = transport and application control. >>>>>=20 >>>>> The current Internet protocol stack has no layer for explicit >>>>> signaling of flow semantics and characteristics to network >>>>> elements, nor an integrated signaling mechanism from network >>>>> elements to back to endpoints and applications. This layer never >>>>> evolved within the stack, because middleboxes and other devices on >>>>> path could simply inspect and modify headers and payload of >>>>> unencrypted traffic at every layer. This implicit use of >>>>> information from the transport and application layers is a key = origin of the ossification that makes it hard or impossible to deploy = new protocols. >>>>>=20 >>>>> In order to support more ubiquitous deployment of encryption, >>>>> explicit signaling must be added to the stack, and it must be >>>>> transport protocol independent. 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. >>>>> Additionally, 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. >>>>>=20 >>>>> The PLUS working group will specify a new protocol as a Path Layer >>>>> User Substrate (PLUS), to support experimental deployment of >>>>> explicit cooperation between endpoints and devices on path, with = the following goals: >>>>>=20 >>>>> - enable ubiquitous deployment of encrypted higher layer protocols >>>>> by providing exposure of similar semantics to existing protocols = (e.g. >>>>> TCP) to devices on path (e.g. NATs and firewalls) >>>>>=20 >>>>> - allow applications and transport protocols to explicitly provide >>>>> limited information to devices on path >>>>>=20 >>>>> - allow devices on path to provide feedback and information about >>>>> the path to sending endpoints, under sending endpoint control >>>>>=20 >>>>> - allow devices on path to provide information about the path to >>>>> receiving endpoints, with feedback to the sending endpoint, under >>>>> sending endpoint control >>>>>=20 >>>>> Note that 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 at the level of detail that is useful for the network, >>>>> while encrypting everything else. This is important to avoid = future >>>>> implicit treatment and the resulting ossification, as well as to >>>>> leverage the principle of least exposure to minimize privacy risks = presented by explicit cooperation. >>>>>=20 >>>>> Given that the primary goal of PLUS is to enable the deployment of >>>>> arbitrary, fully encrypted transport protocols, 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. >>>>>=20 >>>>> 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 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 >>>>> these use cases and requirements. The working group will close if >>>>> it is not able to come to consensus on a protocol design to meet = these requirements. >>>>>=20 >>>>> The working group will additionally aim to identify other working >>>>> groups that could or should 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. >>>>> TLS) which could be used for encryption of transport protocols = running over PLUS. >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Spud mailing list >>>> Spud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spud >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>=20 >> -- >> --- >> Toerless Eckert, eckert@cisco.com >=20 --Apple-Mail=_72E723B9-3C77-4BB5-9CF9-4EF521DE303F 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 iQIcBAEBCgAGBQJXQwkqAAoJEIoSt78L6kaj88oP/Rn2giuhNRmo7isLaSbxal6+ Pl4XRi7+1TL9Tffr4zzEgfEfBctN3DkpjNlg5M0A50g4SCtsS7NMytrVNa7fHgs3 bmQA1DSqyymwzVyPwGyiucg2+dIpBpH494tk6r78J5wxaWlBW3Mcr0qvoStltMF2 0Q08+1yDLdloAZBSW7uxJdXaH2icWK2B3ykMCuTN6yAgehlnERWFTWA8c7LOewcC EYX1ge00kmRU7GDeqrq8tAl2HSZjC7aH3WOnIn+/4CZCpSFHFd2H3lp+eE+L8WZ1 lAz4zV44Rcm/QzbBFaTO53CVXHqlwD3ONbjlW3yaG+2tkRQOX1nlmvbnsIjauguN 8//wiUnLjkUnMte5Ha+zS2NjNLNZTak3FfmsinUQ7Q6lp1kfOLdO6oFHIjmAkKqy O2guR5eZGxl06szlWl3dgVgv1YTDrcpuN6HX1HMn86dwj5bzQR6WYOukb5eytdMq b8sxsH+68X0ht61zw5LkHo8SBuLa3YLrXK3F2uK9Ftyp849fLl5Crv5fYLQf2kLw VzYWo7/I7O2tw1+uc8OQ+qPxXQ2iPLDhIUg26/tf+Mg6zyIamm+rPWZc535NfaTY R8W1ayCk0Ucc1mB1nmshsI0UaPXr//3AE7eJXUQe4VVUYKEvWbWRD14+TVIJ1epZ Ta4Nbk3mMFg4z+iq4dSs =5Zlp -----END PGP SIGNATURE----- --Apple-Mail=_72E723B9-3C77-4BB5-9CF9-4EF521DE303F-- From nobody Mon May 23 06:44: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 84BD612D199 for ; Mon, 23 May 2016 06:44: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 hrNCHGEVjfCc for ; Mon, 23 May 2016 06:44:27 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id AC1A412D8EF for ; Mon, 23 May 2016 06:44:25 -0700 (PDT) Received: from [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0] (unknown [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0]) by trammell.ch (Postfix) with ESMTPSA id E14F41A13A6; Mon, 23 May 2016 15:44:24 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_805FA587-5092-420E-98C7-48DDCC56EB00"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Mon, 23 May 2016 15:44:25 +0200 Message-Id: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 13:44:30 -0000 --Apple-Mail=_805FA587-5092-420E-98C7-48DDCC56EB00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 20 May 2016, at 18:03, Tom Herbert wrote: >=20 > On Fri, May 20, 2016 at 3:08 AM, Brian Trammell = wrote: >> hi Tom, >>=20 >>> On 19 May 2016, at 19:50, Tom Herbert wrote: >>>=20 >>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >>> wrote: >>>> Does the sentence ... >>>>=20 >>>> The current Internet protocol stack has no layer for explicit = signaling of flow semantics and characteristics to network elements ... >>>>=20 >>>> actually wants to say something like >>>>=20 >>>> The current Internet protocol stack has no layer for explicit = *in-band* signaling of flow semantics and characteristics ... ? >>>>=20 >>>> I may be wrong, but there is no shortage of IETF and non-IETF = protocols that can signal flow semantics and characteristics = out-of-band, either path-coupled or path-decoupled, e.g., in the control = or management plane. As a result, there are protocol "layers" for that = signaling, but they are not in-band. There may also be other ways to fix = this problem (e.g., by adding "end-to-end" or "inter-domain" instead of = "in-band"). >>>>=20 >>> Not to mention that TOS and diff-serv are in-band signaling = mechanisms >>> to the network, ECN is explicitly signaling from the network. >>=20 >> DSCP is properly network-layer. If you believe in a "path layer" = (which I'm pretty sure I do), you can argue that ECN is the first path = layer protocol. >>=20 > I'm not sure what "path layer" is. Yes every packet takes some path, > but the Internet is packet-switched not circuit-switched, so not all > packets for a flow are required to always take the same path. > Maintaining flow state in intermediate nodes is only best effort. In > the presence of multi-homing and mobility intermediate devices that > track flow state will inevitably have it wrong. Anyone who has ever > tried to build a front-end L4 load balancer understands this problem > all too well :-) Your L4 load balancer is a path layer device. The fact that the = architecture (and operational practice built around it) don't work well = with it is a consequence of the architecture ignoring the existence of = path layer devices. In short (and I need a better definition than this), the "path layer" is = a virtual layer in the stack comprised of those behaviors of on-path = devices that keep state derived from the data plane of the network layer = and/or use transport layer information (and therefore have to keep state = to operate properly, as the transport layer maintains end-to-end state = beyond the network interface at each endpoint). >>> Given >>> that they've been around for many years but have never been widely >>> deployed on the Internet >>=20 >> DCSP was defined in such a way that it makes little sense in an = interdomain context, and its widespread intradomain deployment means = that it will never deploy across domains in the general case. >>=20 > Sure, but can you give a specific example of information exposure that > is useful in interdomain context, does not diminish end user security, > and does have any detrimental effects if the information is > fabricated? SYN/FIN/RST, with higher probability than TCP affords that the thing = that sent the FIN or RST is at least on path. Very limited information about the transport protocol's tolerances: loss = and reordering tolerance come to mind. I'm a fan of timestamps with echoes (as with TSOPT, but with some way to = indicate local delta) for diagnostics, but given that clock drift = provides a few bits of fingerprint entropy, they might not meet the = "does not diminish end user security" requirement if your attacker model = includes people trying to track you via fingerprinting. Note that all of these are things you get on-path with TLS over TCP, = that you won't get with transport protocols that encrypt their headers, = so these are examples of the "giving back" of information taken away = when transport headers are encrypted, and/or the transport isn't TCP. > Considering that there's already talk of sunsetting IPv4 I think it's > less of a concern-- IPv6 is the future of the Internet. In fact, > optimizing SPUD for IPv6 seems perfectly inline with encouraging > adoption wider adoption of IPv6. I'm extremely sympathetic to this approach. "Optimize for v6" can't mean = "v6 only", though, unless we don't think it will deploy until v4 is on = the way out anyway. >>> The fact that neither have these caught on in the Internet and that >>> tells me two things 1) No IP option is needed for the Internet to >>> operate and be successful which makes me wonder if signaling between >>> network and hosts is even required 2) If the extensibility = mechanisms >>> of IP are chronically not deployable, I wonder why any alternative >>> that does not yet exist but intends to solve the same problem would = be >>> any more deployable. >>=20 >> I'd assert that encapsulating things in UDP is certainly much more = deployable *at the endpoints*. The open question is about adoption by = on-path devices. >>=20 > I'm not sure in this specific case that UDP necessarily make things > more deployable. For instance, there's the pesky problem of > fragmentation. If L3 information is put into UDP and that packet is > fragmented, only the first fragment contains the L3 information the > others don't. Either the application needs to pick some minimal MTU > and hope that packets make it through, or needs to implement PMTU > discovery (rather or not ICMP PTB is delivered to the application is > another story, in Linux it is at least). IPv6 nicely great here since > minimum MTU is 1280, IPv4 might be harder to nail down. Agreed. One of the things that works really well in an all-PLUS world is = you can actually have native signaling of path MTU. Until then, PLPMTUD = is your friend, and can live in the PLUS shim. Cheers, Brian >=20 --Apple-Mail=_805FA587-5092-420E-98C7-48DDCC56EB00 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 iQIcBAEBCgAGBQJXQwk5AAoJEIoSt78L6kajSwUP/A84Xp0cuFFmGRWi4Z87a3gC MH0u0so+JwGcHgZhercw414hotATPf9bmzs6QA7l6YGTeAQrjgQDG3qeF7pk2WKC AudIeO73Jr9/CEpBhF5MYSM19Ms4DMiwGSj5JZsulhPkPzaWmNO1x72qD05IM01h KzXbVZl3loRZ32CdtWGArlMjN2xLELK/wuQq1Tk4spEdz0U6Fk47vKi1i9wOj0Qr AtgSFSNGqw5K35cetUuNF4969OetcyfBOAl1W3Jgscl1xbG3QrY/5HjHirYEQPX/ wz3QRicHOFuto8WdwbzdVHVTX8ACrRNrWjb7usoij6roi9xFdkbx/nh+3wR1ktOW IDLvCgQHLSkHRTez6sCebxPUvzmZ4MHF/VKsUGwip1NfJKvwvhnd1LcNdiXD+KAO 0JV4Ev84q4Q7+0vtX14Fkewx2OWpPvnfgr2FA2uQ3VpxKw29ZXG15dyQqVW24X74 FgFq0hCqaxiz2FfWh7WkPDJGqmmIbE5kP/CPGEMfZ0BHQDVnUAap6mJRqjwyTwGF MaHIHhm/qRxJM485XXY7X6JJ3rzynG++sJ/sR8ukaXMfU7Der4qxj0E/w3SM76bW P3Jd9xq2nI+ce/ulzH6NmoBcbxEHsNjQWMLWPCAdSEGPay2Czxz8EVFiMpYl38Jo mVBq0mDyBRUzh+uTO7Dd =XcHg -----END PGP SIGNATURE----- --Apple-Mail=_805FA587-5092-420E-98C7-48DDCC56EB00-- From nobody Mon May 23 06:53: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 EF11612D8FA for ; Mon, 23 May 2016 06:53:44 -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 AJDF7DsPo7nr for ; Mon, 23 May 2016 06:53:40 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 29F0212D8F9 for ; Mon, 23 May 2016 06:53:38 -0700 (PDT) Received: from [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0] (unknown [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0]) by trammell.ch (Postfix) with ESMTPSA id DAC8C1A1357; Mon, 23 May 2016 15:43:54 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Trammell In-Reply-To: <94911BF5-C313-4816-896B-A90FA630EE5B@mnot.net> Date: Mon, 23 May 2016 15:43:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94911BF5-C313-4816-896B-A90FA630EE5B@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 13:53:45 -0000 hi Mark, Thanks for the questions. We have indeed spent a fair amount of time = thinking about how to address the threats to privacy discussed at the = Dallas BoF, and I'd like to get text into the draft charter that scopes = the work appropriately to address them. So let me answer them in terms of how we're thinking the PLUS protocol = will handle them; of course, we'll actually do the engineering in the = WG, should it be chartered: > On 23 May 2016, at 04:07, Mark Nottingham wrote: >=20 > Hi Brian, >=20 > At the BoF, I and several other people highlighted concerns about = privacy and SPUD: > http://www.ietf.org/proceedings/92/minutes/minutes-92-spud (under = "Open Discussion") >=20 > The response at that time was that these considerations were = important, and that work on them could happen in parallel with the SPUD = experiment. >=20 > Unfortunately, there doesn't appear to have been much obvious progress = in list discussion, and draft-trammell-spud-req is quite brief on the = topic: >=20 > """ > SPUD must allow endpoints to control the amount of information exposed = to middleboxes, with the default being the minimum necessary for correct = functioning. This includes the cryptographic protection of transport = layer headers from inspection by devices on path, in order to prevent = ossification of these headers. > """ >=20 > However, I can see that some thought along these lines has been put = into the proposed charter below. So, a few questions. >=20 > * In the proposed approach, will it be possible for a network operator = to use PLUS mechanisms to insert arbitrary metadata (e.g., a user = identifier) in the server-bound stream of a client-server protocol? =20 Short answer: No. Detailed answer: The "under endpoint control" language in the spud-req = and PLUS charters is meant to describe something like the following: A sending endpoint (here, the client) controls the type and content of = information exposed to the path (as TLV, CBOR, whatever; conceptually, = it's a key-value mapping). Each of the keys in this mapping has a = meaning. Some of the keys are "application-to-path" keys, and are set by = the sender and protected by a MAC using a secret derived from the = superstrate session key. Some of the keys are "path-to-application" = keys, or requests for information from the path to be sent to the far = endpoint (which can then echo them back, encrypted, in a subsequent = packet). These are set by the sender to a fixed-length array of 0x00 = bytes, to be filled in by anything along the path which understands = them. The presence of the key and the length of its data are protected = by the MAC, but *not* the content.=20 In this case, if everyone is following the protocol, the client has to = create a key ("path-to-application-user-id") to let the access network = put its user ID in it. As Mirja points out, I doubt that an IETF = following a restrictive key allocation policy would standardize such a = thing, given BCP 188. And if so, a client could simply fail to create = this key, and there would be no space in the PLUS header for the user = ID. (To answer your what I suspect your next question would be, "what if = the access network requires me to put the user ID path-to-app key in my = packets", see the answer to the questions below).=20 Of course, MUSTS and SHOULDS are nice, but what if an access network = gateway abuses the header? Two possibilities here: it could co-opt an = existing path-to-application key, or wedge new information into the = header underneath the MTU and tear it back off. In the first case, a = complicit server endpoint wouldn't even have to ignore a MAC failure, = and could echo back 0, signifying "nobody on path understood this". = (There might be ways to put a nonce here to defend against this, but I'm = not sure what the details would look like). One way to prevent this = being used for large identifier spaces would be to make most such = accumulators use only a few bits, and most of the ones we're thinking of = (delay accumulators, path MTU) have this property. The second case isn't really any different from today: any endpoint can = stick a shim header between TCP and the (TLS-protected) payload if it = knows something on the far end will rip it off, given room under the = path MTU. And if there's no room under the path MTU, then you can't = steal bits from PLUS either. Indeed, if PLUS makes good use of PLPMTUD, = or supported explicit PMTU in a future with PLUS-enabled routers, then = the amount of space available for such shenanigans could be reduced. = There are also countless out-of-band ways to associate user IDs with = flow identifiers that PLUS can't do anything about, either. > * In the proposed approach, will it be possible for a network operator = to require a client to insert a particular kind of metadata into a = stream, e.g., to gain network access? >=20 > * In the proposed approach, will it be possible for a network to offer = a different quality of service to servers that insert specific metadata = into their streams (thereby affecting network neutrality)? I think these are two different shades of the same threat: "tell me = something I want to hear, or I drop your packets", "tell me something I = want to hear, or I'll give you crap service", where "something I want to = hear" is either some secret verifying you've done something the operator = wants you to do (paid money, watched an ad) or information about the = traffic the operator could independently verify but doesn't want to have = to (otherwise, you could just lie). Short answer: I do not think it is possible to prevent this kind of = behavior, even in the current architecture, because it isn't really a = technical problem. But it would be possible with PLUS to make it = transparent (which is the reason I don't see PLUS as enabling this = behavior). Long answer: Here, the threat is above layer 7: the application is = "forced" to hand over a token in order to get connectivity of acceptable = performance. This token might represent information that could currently = be taken through DPI, but can't when that information is protected via = TLS.=20 Sadly, I can see no technical solution to this problem at all. An = operator could today force an to place information in bits under its = control (IPv6 source and destination address, flow label; TCP source = port) for such a thing, or leverage the relative ease of five-tuple = routing plus the ease of standing up HTTPS servers in random bits of the = cloud to use out-of-band mechanisms ("give me your token and your = five-tuple via a TLS-protected API with a server somewhere on a CDN = network that you can't easily tell is Your Friendly Local ISP, and you = get to ride in the fast lane.") So assuming such a mechanism is deployed = without standardization, at least the presence of the keys in the PLUS = header would make this behavior visible to *everyone* on the network. = That alone is IMO a reason it wouldn't be deployed in this way -- the = relatively vigorous opposition to this kind of thing from customers who = care means operators would rather hide it. Thanks, cheers, Brian > See also: http://mnot.github.io/I-D/transport-metadata-impact/ >=20 > Cheers, >=20 >=20 >> On 20 May 2016, at 9:02 PM, Brian Trammell wrote: >>=20 >> Hi, all, >>=20 >> I've heard one concrete charter suggestion so far; the edited draft = charter (changed paragraph 2) is below. If others would like to see = points clarified to answer their questions, please send suggested edits. = :) >>=20 >> I take the fact that we're diving into technical discussion as an = indication that those participating are at least interested in the BoF, = if not (yet ;) ) convinced of the need for a WG at this space? >>=20 >> Thanks, cheers, >>=20 >> Brian >>=20 >>=20 >> Path Layer UDP Substrate (PLUS) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>=20 >> The PLUS working group's goal is to enable the deployment of new, >> encrypted transport protocols, while providing a >> transport-independent method to signal flow semantics under >> transport and application control. >>=20 >> The current Internet protocol stack has no layer for explicit, >> in-band signaling of flow semantics and characteristics to network >> elements in an interdomain context, nor an integrated signaling >> mechanism from network elements to back to endpoints and = applications. >> This layer never evolved within the stack, because middleboxes and >> other devices on path could simply inspect and modify headers and >> payload of unencrypted traffic at every layer. This implicit use of >> information from the transport and application layers is a >> key cause of the ossification that makes it hard or impossible >> to deploy new protocols. >>=20 >> In order to support more ubiquitous deployment of encryption, >> explicit signaling must be added to the stack, and it must be >> transport protocol independent. 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. >> Additionally, 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. >>=20 >> The PLUS working group will specify a new protocol as a Path Layer >> User Substrate (PLUS), to support experimental deployment of >> explicit cooperation between endpoints and devices on path, with the = following goals: >>=20 >> - enable ubiquitous deployment of encrypted higher layer protocols >> by providing exposure of similar semantics to existing protocols = (e.g. >> TCP) to devices on path (e.g. NATs and firewalls) >>=20 >> - allow applications and transport protocols to explicitly provide >> limited information to devices on path >>=20 >> - allow devices on path to provide feedback and information about >> the path to sending endpoints, under sending endpoint control >>=20 >> - allow devices on path to provide information about the path to >> receiving endpoints, with feedback to the sending endpoint, under >> sending endpoint control >>=20 >> Note that 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 at the level of detail that is useful for the network, >> while encrypting everything else. This is important to avoid future >> implicit treatment and the resulting ossification, as well as to >> leverage the principle of least exposure to minimize privacy risks >> presented by explicit cooperation. >>=20 >> Given that the primary goal of PLUS is to enable the deployment of >> arbitrary, fully encrypted transport protocols, 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. >>=20 >> 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 >> these use cases and requirements. The working group will close if >> it is not able to come to consensus on a protocol design to meet >> these requirements. >>=20 >> The working group will additionally aim to identify other working >> groups that could or should 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. >> TLS) which could be used for encryption of transport protocols >> running over PLUS. >>=20 >>=20 >>=20 >>=20 >>> On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) = wrote: >>>=20 >>> My comment is *only* that the sentence "The current Internet = protocol stack has no layer for explicit signaling of flow semantics and = characteristics to network elements" needs to be improved, in my = personal point of view. >>>=20 >>> For instance, for NAT/FW control, there are many existing = out-of-band protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and = SIMCO), COPS, etc., not to mention all the SDN protocols, which are = typically all flow-based. They are all out-of-band but e.g. NSIS would = have been end-to-end. The intention and deployment model of these = protocols may be very different to what SPUD aims for, and none of them = is deployed end-to-end in the Internet. But I think this sentence has to = be slightly more specific how to differentiate e.g. from control plane = solutions. >>>=20 >>> Michael >>>=20 >>>=20 >>> -----Original Message----- >>> From: Toerless Eckert [mailto:eckert@cisco.com] >>> Sent: Thursday, May 19, 2016 8:27 PM >>> To: Tom Herbert >>> Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org >>> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming = follow-on to SPUD BoF >>>=20 >>> Tom, Michael >>>=20 >>> I am reading your positions and i am confused: >>>=20 >>> DSCP is very successfull in enterprise networks. SPUD does not have = to be successfull "on the Internet". To me it would already be a great = success if it would help to improve controlled network services (like = enterprise or 4G/5G networks). And their transit traffic across the = Internet (without changing anything on the Internet itself). >>>=20 >>> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. = Even if we often think about them as per-flow and ould maybe like them = to be restrict to per-flow. At least i don't know any normative = reference that defines them to be per-flow. >>>=20 >>> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the = analysis that all those mechanisms fail to provide an easily deplopyale = framework in the face of middleboxes. Aka: their presence and mostly = non-success should be an argument FOR working on spud. Not against it. >>>=20 >>> If a NAT/FW does support any flow signaling, its most likely inband. = Every NAT/firwall supports flow recognition via the explicit signaling = of flow-based transport protoocols like TCP. They do try to do the same = for UDP and because that has no explicit flow signaling, thats where the = problem starts. NAT/FW do deep packet inspection which has all these = problems we know. SPUD sets out to solve/reduce these NAT/FW issues. >>>=20 >>> Non-support of anything like IP options is IMHO primarily driven by = the absence of unform cross-OS/Dev-language APIs for them. Yes. It may = suck architecturally by designing protocol stacks based on reality like: = applications will only be able to use UDP and TCP, so lets do new work = on top of them, but to me the most important goal is to find the best = deployable solution to a problem. Not the architecturally cleanest one. = If you give me research money to work outside of reality i will happily = take it though and represent a different perspective. >>>=20 >>> Please, i do not want to dismiss your opposition, i just don't = understand how the arguments you make are working out. Maybe you can = explain to me where i am going wrong in my interpretations above. >>>=20 >>> Cheers >>> Toerless >>>=20 >>> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >>>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >>>> wrote: >>>>> Does the sentence ... >>>>>=20 >>>>> The current Internet protocol stack has no layer for explicit = signaling of flow semantics and characteristics to network elements ... >>>>>=20 >>>>> actually wants to say something like >>>>>=20 >>>>> The current Internet protocol stack has no layer for explicit = *in-band* signaling of flow semantics and characteristics ... ? >>>>>=20 >>>>> I may be wrong, but there is no shortage of IETF and non-IETF = protocols that can signal flow semantics and characteristics = out-of-band, either path-coupled or path-decoupled, e.g., in the control = or management plane. As a result, there are protocol "layers" for that = signaling, but they are not in-band. There may also be other ways to fix = this problem (e.g., by adding "end-to-end" or "inter-domain" instead of = "in-band"). >>>>>=20 >>>> Not to mention that TOS and diff-serv are in-band signaling = mechanisms >>>> to the network, ECN is explicitly signaling from the network. Given >>>> that they've been around for many years but have never been widely >>>> deployed on the Internet makes me wonder if any in-band signaling >>>> mechanism will ever catch on. The use of out of band signaling = should >>>> be considered, especially considered that in many cases like NAT = and >>>> firewall the network elements that need signaling are likely in = local >>>> networks of one side of the connection. >>>>=20 >>>> I have a similar concern about the statement that IP options/EH and >>>> extension headers are being left off the table as part of a = solution. >>>> The fact that neither have these caught on in the Internet and that >>>> tells me two things 1) No IP option is needed for the Internet to >>>> operate and be successful which makes me wonder if signaling = between >>>> network and hosts is even required 2) If the extensibility = mechanisms >>>> of IP are chronically not deployable, I wonder why any alternative >>>> that does not yet exist but intends to solve the same problem would = be >>>> any more deployable. >>>>=20 >>>> Tom >>>>=20 >>>>> Michael >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] = On >>>>> Behalf Of Brian Trammell >>>>> Sent: Thursday, May 19, 2016 5:07 PM >>>>> To: stackevo-discuss@iab.org >>>>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to >>>>> SPUD BoF >>>>>=20 >>>>> Greetings, all, >>>>>=20 >>>>> Forwarding this to the correct address for this mailing list = (oops). Please discuss at spud@ietf.org. >>>>>=20 >>>>> Thanks, cheers, >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>> From: Brian Trammell >>>>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>>>> To: spud@ietf.org >>>>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja = Kuehlewind >>>>>> (IETF)" , Spencer Dawkins at IETF >>>>>> >>>>>>=20 >>>>>> Greetings, all, >>>>>>=20 >>>>>> We propose to hold a working-group forming BoF in Berlin as a = follow-on to the SPUD work, to define a common substrate protocol for = encrypted transports based on the requirements derived from = experimentation with the SPUD prototype. >>>>>>=20 >>>>>> First, note that since the acronym "SPUD" refers primarily to the = prototype itself, any follow-on working group should have a different = name. We're using the derived requirements, not starting for the = prototype. The name is a subject for discussion, and suggestions are = welcome. To have something to put in the proposed charter, we'd propose = "Path Layer UDP Substrate" (PLUS) as a starting point. >>>>>>=20 >>>>>> The proposed charter appears below. We're interested in hearing = initial feedback on the proposed charter in preparation for a BoF = proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). = Is there work to do here within the IETF? Is the scope of the proposed = charter appropriate? Is there energy to do this work? >>>>>>=20 >>>>>> Thanks, cheers, >>>>>>=20 >>>>>> Brian and Mirja >>>>>>=20 >>>>>>=20 >>>>>> Path Layer UDP Substrate (PLUS) >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>>>=20 >>>>>> The PLUS working group???s goal is to enable the deployment of = new, >>>>>> encrypted transport protocols, while providing a >>>>>> transport-independent method to signal flow semantics under = transport and application control. >>>>>>=20 >>>>>> The current Internet protocol stack has no layer for explicit >>>>>> signaling of flow semantics and characteristics to network >>>>>> elements, nor an integrated signaling mechanism from network >>>>>> elements to back to endpoints and applications. This layer never >>>>>> evolved within the stack, because middleboxes and other devices = on >>>>>> path could simply inspect and modify headers and payload of >>>>>> unencrypted traffic at every layer. This implicit use of >>>>>> information from the transport and application layers is a key = origin of the ossification that makes it hard or impossible to deploy = new protocols. >>>>>>=20 >>>>>> In order to support more ubiquitous deployment of encryption, >>>>>> explicit signaling must be added to the stack, and it must be >>>>>> transport protocol independent. 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. >>>>>> Additionally, 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. >>>>>>=20 >>>>>> The PLUS working group will specify a new protocol as a Path = Layer >>>>>> User Substrate (PLUS), to support experimental deployment of >>>>>> explicit cooperation between endpoints and devices on path, with = the following goals: >>>>>>=20 >>>>>> - enable ubiquitous deployment of encrypted higher layer = protocols >>>>>> by providing exposure of similar semantics to existing protocols = (e.g. >>>>>> TCP) to devices on path (e.g. NATs and firewalls) >>>>>>=20 >>>>>> - allow applications and transport protocols to explicitly = provide >>>>>> limited information to devices on path >>>>>>=20 >>>>>> - allow devices on path to provide feedback and information about >>>>>> the path to sending endpoints, under sending endpoint control >>>>>>=20 >>>>>> - allow devices on path to provide information about the path to >>>>>> receiving endpoints, with feedback to the sending endpoint, under >>>>>> sending endpoint control >>>>>>=20 >>>>>> Note that 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 at the level of detail that is useful for the network, >>>>>> while encrypting everything else. This is important to avoid = future >>>>>> implicit treatment and the resulting ossification, as well as to >>>>>> leverage the principle of least exposure to minimize privacy = risks presented by explicit cooperation. >>>>>>=20 >>>>>> Given that the primary goal of PLUS is to enable the deployment = of >>>>>> arbitrary, fully encrypted transport protocols, 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. >>>>>>=20 >>>>>> 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 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 >>>>>> these use cases and requirements. The working group will close if >>>>>> it is not able to come to consensus on a protocol design to meet = these requirements. >>>>>>=20 >>>>>> The working group will additionally aim to identify other working >>>>>> groups that could or should 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. >>>>>> TLS) which could be used for encryption of transport protocols = running over PLUS. >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Spud mailing list >>>>> Spud@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spud >>>>=20 >>>> _______________________________________________ >>>> Spud mailing list >>>> Spud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spud >>>=20 >>> -- >>> --- >>> Toerless Eckert, eckert@cisco.com >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Mon May 23 07:03: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 7D53C12D909 for ; Mon, 23 May 2016 07:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 aVvKINgwZi4r for ; Mon, 23 May 2016 07:03:28 -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 6FC1712D8FC for ; Mon, 23 May 2016 07:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2207; q=dns/txt; s=iport; t=1464012208; x=1465221808; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ji6Tzz6OrCjLSlDnspWzoPuGdWu2OMKNOfaE/wrCiY8=; b=ZxQhpvPKNPqLLopb009Ef9ysxuNUXJKghno4SweT3hyHHVL1kC+fp0Cs S+1otwRQLeihtYdKogZ0RXWgEugF53VedxiCsrcFUlu1OsSzSYbRQwrTO snOjOEDsqfhxSQtylQVXwSvNy01lG8frETN9UAsJmi93hNug3T0v9nxiC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAgD2DENX/5hdJa1cgze5RIIPAQ2Bd?= =?us-ascii?q?YYRAoEuOBQBAQEBAQEBZSeEQwEBBDo/EAsOBAYJJQ8FNRSIQsRGAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBHIp0h2uCLgWOWYleiHiFHgqPHI9MHgEBQoIGHIFrHIoDA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.26,356,1459814400"; d="scan'208";a="276003080" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 May 2016 14:03:27 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4NE3Rai027628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2016 14:03:27 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 u4NE3PMv015280; Mon, 23 May 2016 07:03:25 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4NE3Pl2015276; Mon, 23 May 2016 07:03:25 -0700 Date: Mon, 23 May 2016 07:03:25 -0700 From: Toerless Eckert To: Brian Trammell Message-ID: <20160523140325.GC15064@cisco.com> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94911BF5-C313-4816-896B-A90FA630EE5B@mnot.net> 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: Mark Nottingham , "spud@ietf.org" Subject: Re: [Spud] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 14:03:30 -0000 On Mon, May 23, 2016 at 03:43:55PM +0200, Brian Trammell wrote: > > * In the proposed approach, will it be possible for a network to offer a different quality of service to servers that insert specific metadata into their streams (thereby affecting network neutrality)? > > I think these are two different shades of the same threat: "tell me something I want to hear, or I drop your packets", "tell me something I want to hear, or I'll give you crap service", where "something I want to hear" is either some secret verifying you've done something the operator wants you to do (paid money, watched an ad) or information about the traffic the operator could independently verify but doesn't want to have to (otherwise, you could just lie). > > Short answer: I do not think it is possible to prevent this kind of behavior, even in the current architecture, because it isn't really a technical problem. But it would be possible with PLUS to make it transparent (which is the reason I don't see PLUS as enabling this behavior). > > Long answer: Here, the threat is above layer 7: the application is "forced" to hand over a token in order to get connectivity of acceptable performance. This token might represent information that could currently be taken through DPI, but can't when that information is protected via TLS. I like that answer much better than what Mirjan sent in before. But when you are saying "PLUS to make it transparent" - that was exactly what i was trying to get to, and i don't think thats understood so far: How would the application know what it needs to send to get through. Right now it does not know (existing firewalls). So, how in PLUS would an app know what it needs to send to get through ? And then even more importantly: How can we make sure that anything that needs to be exposed to the firewall is known to be exposed only to the "trusted" firewall of eg: your enterprise, but not potentially all along the path to any other observers whom the app does not want to show its credential. Btw: there are good and IMHO easy answers to these questions, i just haven't seen clear evidence whether PLUS intends to provide them. Cheers Toerless From nobody Mon May 23 07:05: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 6FEBF12D906 for ; Mon, 23 May 2016 07:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 gPTVHfmUVh0u for ; Mon, 23 May 2016 07:05: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 EA8D912D8F5 for ; Mon, 23 May 2016 07:05:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 81DB9D9307; Mon, 23 May 2016 16:05: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 jPOq96kmi210; Mon, 23 May 2016 16:05:09 +0200 (MEST) Received: from [172.20.10.5] (ip-109-42-3-54.web.vodafone.de [109.42.3.54]) (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 DCBF3D9304; Mon, 23 May 2016 16:05:08 +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: <20160523134348.GB15064@cisco.com> Date: Mon, 23 May 2016 16:05:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8948F6BD-87AF-41E2-87C0-72B45D9F81B7@tik.ee.ethz.ch> References: <20160523134348.GB15064@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , "spud@ietf.org" Subject: Re: [Spud] What middleboxes are allowed to know (Re: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 14:05:13 -0000 (about to take off; so very short answer) The important word here is =E2=80=9Erequire=E2=80=9C. If the information = is provided by the endpoint that's good; then use it (or not); but I = don=E2=80=99t think there should a mechanism to enforce certain = exposure. So everything is only declarative: here you get some info, use = it or leave it.=20 That=E2=80=99s similar to what we have today. You see a SYN if the = endpoint decides to use TCP. The big different with PLUS is, it's = transport-independent and therefore should make it much easier to deploy = new transports in future (as soon as PLUS is deployed). Mirja > Am 23.05.2016 um 15:43 schrieb Toerless Eckert : >=20 >=20 > Mirja: Your answer below "i don't want the middleboxes to require = anything here" > is letting me totally confused. If PLUS wants to define how talk with = the > middlebox (or however you want to call it "pass info to it, get info = from it"), > then it is clear that the resut of this interaction is that you will = not > achieve desirable outcomes if you do not send specific info to the = middlebox >=20 > Please give me an example how you think PLUS will help firewall = middleboxes > to decide whether or not to less some traffic flow pass. Lets assume = that > same firewall today is using TCP port number policies and/or DPI. What > in your opinion should the firewall do. >=20 >=20 >>> What i really want to see is this: >>>=20 >>> - Allow the application to learn from the network devices what = information >>> it must present in the clear to have its traffic be passed through >>> and/or receive additional treatment by the network. >>>=20 >>> Aka: "Security guard: Sure, you can go through this door if you show = me your else not" >>>=20 >>> Then the app can decide if it wants to show . Otherwise = the >>> apps have to operate like corporate drones, carrying around their = corp-ID >>> in the open all the time hoping that thats the right credential. >>>=20 >>> Or to rephrase: if we do not even attempt to overcome TCP port = numbers as >>> credentials then we're lame and will not be successful. >>=20 >> Okay??? I first of all have to simply say no here. I don???t want the = middleboxes to require anything here, because why would a middlebox not = just say ???either you show me all you content in plain or I don???t = transport you data???. I believe that???s something we all don???t want = and building a mechanism that could lead to this, it the last thing I = want. I know what you intention is here, but we have to be more than = careful here and the way you???ve just phrased it, I can just disagree. = However, I would propose to have this discussion in a separate thread. >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon May 23 07:10: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 0670812D912 for ; Mon, 23 May 2016 07:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 2_Y6qU8pvuFa for ; Mon, 23 May 2016 07:10:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA0612D8C4 for ; Mon, 23 May 2016 07:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3723; q=dns/txt; s=iport; t=1464012653; x=1465222253; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=fb7kWU2I9MOtzjfqQmuRKKqrjNSEeKP0/ZTQiN3e9c4=; b=K1DaXfMrePrvzdt8zBQ0Jlwlhkh0pT7WSuz52ymYk8hjjAuLr6FDSVaM letPGt6Hi9Woran7dKQsDAtbcXtifzyZKW3H8WHhGF2/ttm6OFZaf++QR kcfn8QQ0YLgrptaIWd4je+zPEzBUaaR4eGHftK76gdjAptOprGk5uRT3L g=; X-IronPort-AV: E=Sophos;i="5.26,356,1459814400"; d="scan'208";a="107256461" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 May 2016 14:10:53 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4NEAqpi008391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2016 14:10:53 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 u4NEAqvG015582; Mon, 23 May 2016 07:10:52 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4NEAqFQ015581; Mon, 23 May 2016 07:10:52 -0700 Date: Mon, 23 May 2016 07:10:52 -0700 From: Toerless Eckert To: Mirja@cisco.com, K@cisco.com Message-ID: <20160523141052.GD15064@cisco.com> References: <20160523134348.GB15064@cisco.com> <8948F6BD-87AF-41E2-87C0-72B45D9F81B7@tik.ee.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8948F6BD-87AF-41E2-87C0-72B45D9F81B7@tik.ee.ethz.ch> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Brian Trammell , "spud@ietf.org" Subject: Re: [Spud] What middleboxes are allowed to know (Re: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 14:10:56 -0000 Yeah, today the firewall requires that you use IP packets with protocol TCP and TCP port number 80 ;-)) And the app has no idea if it tries to establish a communication on eg: a different port. I call this "require". So it does exist today. And btw: the "take it or leave it" was rejected by reviewers when we had first rounds of metadata signaling concepts in the IETF: Why send a lot of information thats not needed. Unnecessary exposure. So the question IMHO is how we can expose the firewall policies via PLUS, so the app knows what to send. On Mon, May 23, 2016 at 04:05:20PM +0200, Mirja K?hlewind wrote: > (about to take off; so very short answer) > > The important word here is ???require???. If the information is provided by the endpoint that's good; then use it (or not); but I don???t think there should a mechanism to enforce certain exposure. So everything is only declarative: here you get some info, use it or leave it. > > That???s similar to what we have today. You see a SYN if the endpoint decides to use TCP. The big different with PLUS is, it's transport-independent and therefore should make it much easier to deploy new transports in future (as soon as PLUS is deployed). > > Mirja > > > > Am 23.05.2016 um 15:43 schrieb Toerless Eckert : > > > > > > Mirja: Your answer below "i don't want the middleboxes to require anything here" > > is letting me totally confused. If PLUS wants to define how talk with the > > middlebox (or however you want to call it "pass info to it, get info from it"), > > then it is clear that the resut of this interaction is that you will not > > achieve desirable outcomes if you do not send specific info to the middlebox > > > > Please give me an example how you think PLUS will help firewall middleboxes > > to decide whether or not to less some traffic flow pass. Lets assume that > > same firewall today is using TCP port number policies and/or DPI. What > > in your opinion should the firewall do. > > > > > >>> What i really want to see is this: > >>> > >>> - Allow the application to learn from the network devices what information > >>> it must present in the clear to have its traffic be passed through > >>> and/or receive additional treatment by the network. > >>> > >>> Aka: "Security guard: Sure, you can go through this door if you show me your else not" > >>> > >>> Then the app can decide if it wants to show . Otherwise the > >>> apps have to operate like corporate drones, carrying around their corp-ID > >>> in the open all the time hoping that thats the right credential. > >>> > >>> Or to rephrase: if we do not even attempt to overcome TCP port numbers as > >>> credentials then we're lame and will not be successful. > >> > >> Okay??? I first of all have to simply say no here. I don???t want the middleboxes to require anything here, because why would a middlebox not just say ???either you show me all you content in plain or I don???t transport you data???. I believe that???s something we all don???t want and building a mechanism that could lead to this, it the last thing I want. I know what you intention is here, but we have to be more than careful here and the way you???ve just phrased it, I can just disagree. However, I would propose to have this discussion in a separate thread. > > > > _______________________________________________ > > 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 Mon May 23 07:17: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 5BB0512D92A for ; Mon, 23 May 2016 07:17:46 -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 BJE0aopY0ems for ; Mon, 23 May 2016 07:17:44 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 221BF12D929 for ; Mon, 23 May 2016 07:17:44 -0700 (PDT) Received: from [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0] (unknown [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0]) by trammell.ch (Postfix) with ESMTPSA id 6067D1A01F8; Mon, 23 May 2016 16:17:43 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8C1BC4A4-267E-4823-B45D-3DA2BFECE4BB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <20160523134348.GB15064@cisco.com> Date: Mon, 23 May 2016 16:17:44 +0200 Message-Id: References: <20160523134348.GB15064@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: mirja.kuehlewind@tik.ee.ethz.ch, "spud@ietf.org" Subject: Re: [Spud] What middleboxes are allowed to know (Re: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 14:17:46 -0000 --Apple-Mail=_8C1BC4A4-267E-4823-B45D-3DA2BFECE4BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Toerless, > On 23 May 2016, at 15:43, Toerless Eckert wrote: >=20 >=20 > Mirja: Your answer below "i don't want the middleboxes to require = anything here" > is letting me totally confused. If PLUS wants to define how talk with = the > middlebox (or however you want to call it "pass info to it, get info = from it"), > then it is clear that the resut of this interaction is that you will = not > achieve desirable outcomes if you do not send specific info to the = middlebox >=20 > Please give me an example how you think PLUS will help firewall = middleboxes > to decide whether or not to less some traffic flow pass. Lets assume = that > same firewall today is using TCP port number policies and/or DPI. What > in your opinion should the firewall do. I don't think this is what we're trying to do with PLUS: declarative = information about network traffic *properties* doesn't match well to = policies described in terms of particular fields in headers. Certainly, = port number based firewall rules would still work for applications over = PLUS if PLUS itself doesn't use UDP port numbers to identify itself = (which, IMO, it shouldn't -- I'm a big fan of magic numbers for this). One could certainly ask for an "application ID" as an application to = path key for firewall use, but among indistinguishable applications, = this is simply an invitation to lie, so I'm not optimistic about its = usefulness. Cheers, Brian >=20 >=20 >>> What i really want to see is this: >>>=20 >>> - Allow the application to learn from the network devices what = information >>> it must present in the clear to have its traffic be passed through >>> and/or receive additional treatment by the network. >>>=20 >>> Aka: "Security guard: Sure, you can go through this door if you show = me your else not" >>>=20 >>> Then the app can decide if it wants to show . Otherwise = the >>> apps have to operate like corporate drones, carrying around their = corp-ID >>> in the open all the time hoping that thats the right credential. >>>=20 >>> Or to rephrase: if we do not even attempt to overcome TCP port = numbers as >>> credentials then we're lame and will not be successful. >>=20 >> Okay??? I first of all have to simply say no here. I don???t want the = middleboxes to require anything here, because why would a middlebox not = just say ???either you show me all you content in plain or I don???t = transport you data???. I believe that???s something we all don???t want = and building a mechanism that could lead to this, it the last thing I = want. I know what you intention is here, but we have to be more than = careful here and the way you???ve just phrased it, I can just disagree. = However, I would propose to have this discussion in a separate thread. >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_8C1BC4A4-267E-4823-B45D-3DA2BFECE4BB 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 iQIcBAEBCgAGBQJXQxEIAAoJEIoSt78L6kaj4IUP/1m4pysbJWUa1K8F6M6njYhM sY1MdXaDfMabJVteYFYzCgwv9XVU1aumrUV9GTltLeizWf/UEQNCpQMCCCq93TN1 Nn6rVTzng28Jz4C58JQd40VtSnAZY8KXoo+Z6vy+HwjCloh+4ttpEaG1CycpRlb3 hebiQbVEB0lGoaf7TEdHU/WByU+6SCMcqdUtuRexyFNnqYbTEf3Wr8YPsYFv5UoY pHK3tmj6ONjZvwMAty0bte4NSxzz2xjN4YsyZfxvjUIBjdQt8MwvG5bZZLB3uGwt V7YrcHdpMaHIMA3D1UIa1jZDlWZP77iTDQXXD6PPYdZwxSQW9c+vLw2t1jZLc1CY 71nue/+PTC1Dx7VVlHiaI6aCjfsKGuspP5x9MAgXzgiRALodklr45h/G+NgZsESB xFa7AKWqbBSEH06hTH3ncauarr0c+hWgEQhaKD21RekPCN23EUzZINX1oiVaRiMW 3WxcvCWgPFbkuNVem7s5Oxi7wo0rfyfMonxUhFwTMlPF+c11W6tc275eRdTdPMck kDOEpYBzV01ug4NwchegIO4f0fZpnlRmLLOPWDvyspXRnL8Tyk62r/maGvfMZf4W kD5EDUWIO6ECGLLTnpasic90BjdCJX5rg6OO6TpvcPmPX2sKXj3NmTC6PA09ZiMH 2nE/4U1HIB//G3bL1c9F =c4JY -----END PGP SIGNATURE----- --Apple-Mail=_8C1BC4A4-267E-4823-B45D-3DA2BFECE4BB-- From nobody Mon May 23 07:32: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 E85C812D944 for ; Mon, 23 May 2016 07:32:49 -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 Y7SKc46BReS1 for ; Mon, 23 May 2016 07:32:48 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 03AE812D93C for ; Mon, 23 May 2016 07:32:47 -0700 (PDT) Received: from [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0] (unknown [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0]) by trammell.ch (Postfix) with ESMTPSA id CC5F41A049E; Mon, 23 May 2016 16:32:46 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B47F3C89-A480-4BCF-B961-F376249D3C15"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <655C07320163294895BBADA28372AF5D48861FF5@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Mon, 23 May 2016 16:32:47 +0200 Message-Id: References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48861FF5@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Nokia - DE)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Toerless Eckert \(eckert\)" , Joe Touch , Tom Herbert , "spud@ietf.org" , Christian Huitema , Jana Iyengar Subject: Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-00.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: Mon, 23 May 2016 14:32:50 -0000 --Apple-Mail=_B47F3C89-A480-4BCF-B961-F376249D3C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Michael, On your questions as to the PLUS charter: > On 22 May 2016, at 19:30, Scharf, Michael (Nokia - DE) = wrote: >=20 > Furthermore, I believe that this discussions matters for PLUS/SPUD, = since: >=20 > =C2=B7 If two different, worked-out candidate users of the = common substrate seem to have similar requirements for signaling = information in clear-text, this could be some lessons learnt for what = may be required in the common substrate. This is a good point, and a reason for coordination between the PLUS and = QUIC efforts (should WGs be chartered here). > =C2=B7 Even if this is not the case, the current excessive use = of the term =E2=80=9Cencryption=E2=80=9D in the PLUS/SPUD charter IMHO = has to be reviewed, since at least two potential candidate protocols = actually seems to use information in clear text. Example: =E2=80=9CThe = primary goal of PLUS is to enable the deployment of arbitrary, fully = encrypted transport protocols=E2=80=9D. Well, at least I learn now that = not everything is =E2=80=9Cfully=E2=80=9D encrypted=E2=80=A6 This is imprecise language and should be cleaned up. The point is that = everything above a PLUS shim layer is encrypted, and everything below = open to the path. There should probably be something outlining the broad = architecture here, which would make this more clear. > =C2=B7 Finally, from the current charter I don=E2=80=99t = understand whether PLUS/SPUD would consider the requirements of = middleboxes designed to provide user anonymity (e.g., TOR-like). I=E2=80=99= d personally be fine with flagging their specific requirements as = out-of-scope. But for sure there is a user community of that sort of = infrastructure and it may make sense to discuss early how to deal with = that. I *think* this is orthogonal -- I can't see what in PLUS would break = TOR, or how stuff in PLUS could make TOR work better, without partially = redesigning both... can you say more about what your concerns are here? Cheers, Brian --Apple-Mail=_B47F3C89-A480-4BCF-B961-F376249D3C15 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 iQIcBAEBCgAGBQJXQxSQAAoJEIoSt78L6kajLc0QAIJ89tE7sF4iJJVHlWqaQVW2 //8qRj7Sujq5sH1mZ3seGr+3td1T/ViOVAX5wqFfaKOh83te4QInvLQ/B6X9MvQ9 uu0VErzPdtZvPyBxX7n+0LZ3xfDCpryUWiZV6Zvqq/85f5Jo1tUsHWzj3oXpQzUT 6MHhRMjoPt1hejS1p+WrQaKbOzcE6FnFxBxO75djGMN7cIn2nYlvV8bD5MO4qByq HdARccWGLBbqpJISyVgFHBK2KIBVupL9aP4szA1NJpvxEqPyxTvEQLPnCrxyC5V5 DdAQ6hCUqfmNiE6R8qyu3E7TH/UDAzfwFGPF8Pi5GanCxLT+fS9DNWxHedu+0Owt oALeNqIkOO3dDH81tlTQTamho5aMPD6r7cFEf9ske3U+i2hGJig7sTM1QrjuW6Ro zq3TYtFRRvg0HlYrFSzCmrn90kRn1u1RnPOkdCSbfKBzYNS8ot/ktihnGPhmsPLo pO75ZB8H1/eoVWQZTnhm91nroMarmxLIX2UrBls+5FzGbvqtHWiGeXJ5P5VeysBf aMp5t3aEUmWqbNn+3qh2rq01Z860/jdMWVeM8sewVj2z15H5IQdDMgPbS4L0Ha/+ 1rOvZnKGC/5P0fL9cWJ37+YcIuaVqlkFyTQqKTD5WT9IMxenTk/6TBerQew5yTpk l8QZaQNBjXvtZX18xIb2 =CUk9 -----END PGP SIGNATURE----- --Apple-Mail=_B47F3C89-A480-4BCF-B961-F376249D3C15-- From nobody Mon May 23 07:56: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 A446112D8F9 for ; Mon, 23 May 2016 07:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QJgJnD4hpfFE for ; Mon, 23 May 2016 07:56:36 -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 0AE9312D907 for ; Mon, 23 May 2016 07:56:35 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id EDA5C5D83516A; Mon, 23 May 2016 14:56:29 +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 u4NEuW7t028854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 14:56:32 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NEuMPa004364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 16:56:31 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 23 May 2016 16:56:03 +0200 From: "Scharf, Michael (Nokia - DE)" To: Brian Trammell Thread-Topic: [Spud] New Version Notification for draft-herbert-transports-over-udp-00.txt Thread-Index: AQHRtQACuMRn7B/zHk26aCXl/+8xCJ/Glkvw Date: Mon, 23 May 2016 14:56:02 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48863300@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48861FF5@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Toerless Eckert \(eckert\)" , Joe Touch , Tom Herbert , "spud@ietf.org" , Christian Huitema , Jana Iyengar Subject: Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-00.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: Mon, 23 May 2016 14:56:37 -0000 PiA+IMK3ICAgICAgICAgRmluYWxseSwgZnJvbSB0aGUgY3VycmVudCBjaGFydGVyIEkgZG9u4oCZ dCB1bmRlcnN0YW5kIHdoZXRoZXIgUExVUy9TUFVEIHdvdWxkIGNvbnNpZGVyIHRoZSByZXF1aXJl bWVudHMgb2YgbWlkZGxlYm94ZXMgZGVzaWduZWQgdG8gcHJvdmlkZSB1c2VyIGFub255bWl0eSAo ZS5nLiwgVE9SLWxpa2UpLiBJ4oCZZCBwZXJzb25hbGx5IGJlIGZpbmUgd2l0aCBmbGFnZ2luZyB0 aGVpciBzcGVjaWZpYyByZXF1aXJlbWVudHMgYXMgb3V0LW9mLXNjb3BlLiBCdXQgZm9yIHN1cmUg dGhlcmUgaXMgYSB1c2VyIGNvbW11bml0eSBvZiB0aGF0IHNvcnQgb2YgaW5mcmFzdHJ1Y3R1cmUg YW5kIGl0IG1heSBtYWtlIHNlbnNlIHRvIGRpc2N1c3MgZWFybHkgaG93IHRvIGRlYWwgd2l0aCB0 aGF0Lg0KDQo+IEkgKnRoaW5rKiB0aGlzIGlzIG9ydGhvZ29uYWwgLS0gSSBjYW4ndCBzZWUgd2hh dCBpbiBQTFVTIHdvdWxkIGJyZWFrIFRPUiwgb3IgaG93IHN0dWZmIGluIFBMVVMgY291bGQgbWFr ZSBUT1Igd29yayBiZXR0ZXIsIHdpdGhvdXQgcGFydGlhbGx5IHJlZGVzaWduaW5nIGJvdGguLi4g Y2FuIHlvdSBzYXkgbW9yZSBhYm91dCB3aGF0IHlvdXIgY29uY2VybnMgYXJlIGhlcmU/DQoNCkkg ZG9uJ3QgdGhpbmsgaXQgaXMgb3J0aG9nb25hbCwgYnV0IEkgY291bGQgaW1hZ2luZSBzb21lIHF1 aXRlIGNvbnRyYWRpY3RpbmcgZGVzaWduIG9iamVjdGl2ZXMgb24gdGhlIHJlcXVpcmVkIHNpZ25h bGluZyBlLmcuIGJldHdlZW4gZW5kIHN5c3RlbSBhbmQgVE9SIHByb3hpZXMuIEJ1dCBJIGFtIG5v dCBhIFRPUiBleHBlcnQuDQoNCldoeSBkb24ndCBlLmcuIHRoZSBCb0YgY2hhaXJzIHJlYWNoIG91 dCB0byB0aGUgVE9SIGNvbW11bml0eSB0byBnZXQgZmVlZGJhY2sgYW5kIHRvIGVuc3VyZSBvcGVu bmVzcyBpbiB0aGUgSUVURiBwcm9jZXNzIHJlZ2FyZGluZyBhbGwgcG9zc2libHkgYWZmZWN0ZWQg dXNlcnMgaW4gdGhlIEludGVybmV0Pw0KDQpGb3IgaW5zdGFuY2UsIGlmIHRoZXJlIGlzIG5vIGZl ZWRiYWNrIGZyb20gdGhlIGEgY2VydGFpbiBjb21tdW5pdHksIGl0IHdvdWxkIGJlIGVhc3kgdG8g YXJndWUgdGhhdCBzb21ldGhpbmcgY2FuIGJlIGV4Y2x1ZGVkIGluIHRoZSBjaGFydGVyLg0KDQpN aWNoYWVsDQo= From nobody Mon May 23 08:01: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 199BC12B077 for ; Mon, 23 May 2016 08:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 5Z5FRWMX64MO for ; Mon, 23 May 2016 08:01:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3942112D91A for ; Mon, 23 May 2016 08:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4273; q=dns/txt; s=iport; t=1464015704; x=1465225304; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=q7kn2kuXXWQAJtETKKsA5a/ZCbft2qNy+DkmbrdKMvA=; b=NHmuHGHjDs7MgNIxHmhUn6hqGkoQN3jVYmtpn3gFL3QJnFZScUDcWs3i SXVi6ptCx6eTS58x1rpoZ0aeCI6N5HsjoEkXWcDPsg5fhq5exKThV5Yqc R6KORHwI9twwBw8q0DTwmi03qVAnMZ5cgjt1dmI1TGkubkAF8ZzVzgxk7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgBHGkNX/4QNJK1SCoM3Vn26AAENg?= =?us-ascii?q?XcXC4VvAoEvOBQBAQEBAQEBZSeEQgEBAQMBAQEBNzQLBQsLDgoJGgsPBRM2E4g?= =?us-ascii?q?nCA7EZQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFinSEF4NUgi4FjlmJXo4WCoFph?= =?us-ascii?q?E+IZI9MHgEBQoI4gVUcMolRAQEB?= X-IronPort-AV: E=Sophos;i="5.26,356,1459814400"; d="scan'208";a="105506144" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2016 15:01:43 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4NF1guw023731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2016 15:01:43 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 u4NF1fhr017720; Mon, 23 May 2016 08:01:42 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4NF1fsY017719; Mon, 23 May 2016 08:01:41 -0700 Date: Mon, 23 May 2016 08:01:41 -0700 From: Toerless Eckert To: Brian Trammell Message-ID: <20160523150141.GE15064@cisco.com> References: <20160523134348.GB15064@cisco.com> 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: mirja.kuehlewind@tik.ee.ethz.ch, "spud@ietf.org" Subject: Re: [Spud] What middleboxes are allowed to know (Re: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 15:01:46 -0000 On Mon, May 23, 2016 at 04:17:44PM +0200, Brian Trammell wrote: > > Please give me an example how you think PLUS will help firewall middleboxes > > to decide whether or not to less some traffic flow pass. Lets assume that > > same firewall today is using TCP port number policies and/or DPI. What > > in your opinion should the firewall do. > > I don't think this is what we're trying to do with PLUS: declarative information about network traffic *properties* doesn't match well to policies described in terms of particular fields in headers. Certainly, port number based firewall rules would still work for applications over PLUS if PLUS itself doesn't use UDP port numbers to identify itself (which, IMO, it shouldn't -- I'm a big fan of magic numbers for this). > One could certainly ask for an "application ID" as an application to path key for firewall use, but among indistinguishable applications, this is simply an invitation to lie, so I'm not optimistic about its usefulness. It would really help to get an example of how PLUS would help to get encrypted traffic better through firewall middleboxes. If that goal is out of the window for PLUS lets be very clear with it, because i think this was the starting point of SPUD. Simple unauthenticated app-ids are of course even less trustworthy than TCP ports, so they won't help with firewalls. They would help to do better statistics of course. DPI is often done together with netflow just for statistics gathering in enterprises, no firewalls involved. For the firewalls, i think we need authenticated/secure app-id: AFAIK, every apple/google store binary has some authenticity elements. It's not hard to image how every such app binary could have a cert from the store or app-vendor, and the PLUS signaling is a proof of posession of the Cert, so that the middlebox can authenticate it. Encrypt the proof of posession so that you're not exposing your app-id to anyone by your own enterprise firewall, and IMHO we'd have something highly valuable. Yes, too large to fit into a PLUS header alone, would require to be part of PLUS session setup packets. Of course, such a model has a tail of more security implications like: firewall needs to be able to vet that the endpoint signaling PLUS can be trusted, eg: is administered by the enterprise IT department, so that apps started on it are assumed not to be hacked. And in such an environment it certainly is necessary to do the PLUS signaling from the OS level etc. pp. Cheer Toerless > Cheers, > > Brian > > > > > > >>> What i really want to see is this: > >>> > >>> - Allow the application to learn from the network devices what information > >>> it must present in the clear to have its traffic be passed through > >>> and/or receive additional treatment by the network. > >>> > >>> Aka: "Security guard: Sure, you can go through this door if you show me your else not" > >>> > >>> Then the app can decide if it wants to show . Otherwise the > >>> apps have to operate like corporate drones, carrying around their corp-ID > >>> in the open all the time hoping that thats the right credential. > >>> > >>> Or to rephrase: if we do not even attempt to overcome TCP port numbers as > >>> credentials then we're lame and will not be successful. > >> > >> Okay??? I first of all have to simply say no here. I don???t want the middleboxes to require anything here, because why would a middlebox not just say ???either you show me all you content in plain or I don???t transport you data???. I believe that???s something we all don???t want and building a mechanism that could lead to this, it the last thing I want. I know what you intention is here, but we have to be more than careful here and the way you???ve just phrased it, I can just disagree. However, I would propose to have this discussion in a separate thread. > > > > _______________________________________________ > > 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 Mon May 23 08:35: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 8D85512D967 for ; Mon, 23 May 2016 08:34:58 -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 JtOYA6ic7CHF for ; Mon, 23 May 2016 08:34:55 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 785B612D98C for ; Mon, 23 May 2016 08:34:55 -0700 (PDT) Received: from [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0] (unknown [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0]) by trammell.ch (Postfix) with ESMTPSA id F11C01A03C6; Mon, 23 May 2016 17:34:23 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A027C8B9-D461-4517-94CA-9CA07A1F9795"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <20160523150141.GE15064@cisco.com> Date: Mon, 23 May 2016 17:34:24 +0200 Message-Id: <0FA26CD2-BB4A-47AA-A85F-2DE52315E372@trammell.ch> References: <20160523134348.GB15064@cisco.com> <20160523150141.GE15064@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: mirja.kuehlewind@tik.ee.ethz.ch, "spud@ietf.org" Subject: Re: [Spud] What middleboxes are allowed to know (Re: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 15:34:59 -0000 --Apple-Mail=_A027C8B9-D461-4517-94CA-9CA07A1F9795 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 23 May 2016, at 17:01, Toerless Eckert wrote: >=20 > On Mon, May 23, 2016 at 04:17:44PM +0200, Brian Trammell wrote: >>> Please give me an example how you think PLUS will help firewall = middleboxes >>> to decide whether or not to less some traffic flow pass. Lets assume = that >>> same firewall today is using TCP port number policies and/or DPI. = What >>> in your opinion should the firewall do. >>=20 >> I don't think this is what we're trying to do with PLUS: declarative = information about network traffic *properties* doesn't match well to = policies described in terms of particular fields in headers. Certainly, = port number based firewall rules would still work for applications over = PLUS if PLUS itself doesn't use UDP port numbers to identify itself = (which, IMO, it shouldn't -- I'm a big fan of magic numbers for this). >=20 >> One could certainly ask for an "application ID" as an application to = path key for firewall use, but among indistinguishable applications, = this is simply an invitation to lie, so I'm not optimistic about its = usefulness. >=20 > It would really help to get an example of how PLUS would help to get = encrypted traffic better > through firewall middleboxes. If that goal is out of the window for = PLUS lets be very clear with > it, because i think this was the starting point of SPUD. Ah. Here the answer is simple: by encrypting the transport headers = (necessary to deossify), you take away the SYN/SYNACK/FIN/RST for flow = state management, and you can give it back in a transport-neutral way = with PLUS. Together with UDP port number based rules, and you preserve = the status quo while getting to deploy new transports. This = functionality wasn't meant to make firewalls work better than they do = today, it was meant to keep from breaking them once the transport = headers are encrypted. > Simple unauthenticated app-ids are of course even less trustworthy = than TCP ports, so they > won't help with firewalls. They would help to do better statistics of = course. DPI is often done > together with netflow just for statistics gathering in enterprises, no = firewalls involved. ...as long as you don't actually need those statistics for anything = other than drawing pretty graphs on the wall in the NOC, this is fine. = If you're a content network, you can pretty much trust yourself not to = lie. Of course, your customers might not appreciate you tagging their = encrypted traffic... so there are tradeoffs. > For the firewalls, i think we need authenticated/secure app-id: AFAIK, = every apple/google store binary > has some authenticity elements. It's not hard to image how every such = app binary could have a cert from the store > or app-vendor, and the PLUS signaling is a proof of posession of the = Cert, so that the middlebox > can authenticate it. Encrypt the proof of posession so that you're not = exposing your app-id to anyone > by your own enterprise firewall, and IMHO we'd have something highly = valuable. Yes, too large to fit into > a PLUS header alone, would require to be part of PLUS session setup = packets. >=20 > Of course, such a model has a tail of more security implications like: = firewall needs to be able to > vet that the endpoint signaling PLUS can be trusted, eg: is = administered by the enterprise IT department, > so that apps started on it are assumed not to be hacked. This cuts both ways, of course; as soon as you have an architecture in = which you have an encrypted in-band side channel to a firewall on path, = you also need to be *very, very* careful that the thing you have the = encrypted in-band side channel to is actually the firewall you think you = should (or, rather, according to organization policy, must) trust. > And in such an environment it certainly > is necessary to do the PLUS signaling from the OS level etc. pp. I'd note that is in direct conflict with the requirement to support = application deployability of the PLUS shim, so... I don't see this use = case coexisting well with a PLUS stack "under application control". Cheers, Brian > Cheer > Toerless >=20 >> Cheers, >>=20 >> Brian >>=20 >>>=20 >>>=20 >>>>> What i really want to see is this: >>>>>=20 >>>>> - Allow the application to learn from the network devices what = information >>>>> it must present in the clear to have its traffic be passed through >>>>> and/or receive additional treatment by the network. >>>>>=20 >>>>> Aka: "Security guard: Sure, you can go through this door if you = show me your else not" >>>>>=20 >>>>> Then the app can decide if it wants to show . = Otherwise the >>>>> apps have to operate like corporate drones, carrying around their = corp-ID >>>>> in the open all the time hoping that thats the right credential. >>>>>=20 >>>>> Or to rephrase: if we do not even attempt to overcome TCP port = numbers as >>>>> credentials then we're lame and will not be successful. >>>>=20 >>>> Okay??? I first of all have to simply say no here. I don???t want = the middleboxes to require anything here, because why would a middlebox = not just say ???either you show me all you content in plain or I don???t = transport you data???. I believe that???s something we all don???t want = and building a mechanism that could lead to this, it the last thing I = want. I know what you intention is here, but we have to be more than = careful here and the way you???ve just phrased it, I can just disagree. = However, I would propose to have this discussion in a separate thread. >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>=20 >=20 >=20 >=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >=20 >=20 > -- > --- > Toerless Eckert, eckert@cisco.com >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_A027C8B9-D461-4517-94CA-9CA07A1F9795 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 iQIcBAEBCgAGBQJXQyMBAAoJEIoSt78L6kajjyoQAJ1s/MjcU2xRAjqvXfzRiB5A KLqcFD3YzXsowGz6GWm8BY8Y979bZsbclA11oc/9PekhmVNvWQS9zTj6MVLjSJjl donOuT0E4sfnmKJ+zYlm8oiS6SVmBYsUB0kG39kEt1jck/Y5yCyPvGGNsRM+JAT9 JTfCbGWpPwGjNKSmX1s8sraXIMrtGIv8r8PLvxo/OYYwoKpImTwnKu5HeBA9vbB5 jkiG4g1VIASxxgjB0kIc1+4fOat8X1P6u0ZOZVYzwLSdkgTSd31RWIpmpCn7ZmZP ylIOTdde5W1xj5bmaA8lTPvbve5b0JE7EHa3EOryMEXwO6ff7lBIX80pGAcv+/Ip x098WIcz4rZUpLntbRUCxYez5CG5O7zUP4diAeTJ3TCl0ipn7lJsQGUmwF73mteA oO+OjKiuKISD/O04IwIfpx/CzVXqwtQMQ9H6jmDDifdudLy3d0/xDuZcZ80WdYHP 8C5Zfc7Dx72sAYhqXesXA0UHJAepuV9NQdbTotlzm7a8J8IXBNf82VTvIBOF8z6s aOTA8eRR7N2jzXIbmRfcj/85kA16B1Vlb0/4+y0WL56TL7GaqRoNJHIz71NsblGJ lbnpOnvAfGZWRlUFv2mno9wjyLcsyJ/BY6wizq/pfo0jdjbq7Ziip2XiP4NR1eSH 6SOC8qsg0PsfgG4Bii7/ =bh97 -----END PGP SIGNATURE----- --Apple-Mail=_A027C8B9-D461-4517-94CA-9CA07A1F9795-- From nobody Mon May 23 08:37: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 632A612D967 for ; Mon, 23 May 2016 08:36:54 -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 S2CHtFSvFJCV for ; Mon, 23 May 2016 08:36:46 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 98BBF12D1AD for ; Mon, 23 May 2016 08:36:46 -0700 (PDT) Received: by mail-ig0-x232.google.com with SMTP id l10so26211147igk.0 for ; Mon, 23 May 2016 08:36:46 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=RFC2wcGmUulYT06NMS9A44rmQciIxbboyUVdb83qFjc=; b=vDxzmAanvC1QFx337VkurWniLpuZit/lwAvKoII9tFJ8O6vPARpaJaxiRLsqZ4kUy+ 9W/Dsv5+u3nm2TJ0OISOW9/JcZQC8DfSz15o24Pqw4XO5x2HDIyERju8KRjVK7Gd1oZ9 skZXOWs0Rr1b2p83CDkJJ5ibYe/1EZIwX1IAbpcyM3JPx6T7eFdyA/YVv2tDvNkOQEoL vzugFFqlo2t0kHl64mo+POTJth07uVoq2yz1gAG+NYhsS31EwaUUkP3UUcGlUCrG3yJw QcowyK5FZzk50J0f066lwpJd+IO3LFoPHVUDiLgvwiSYrGrMkkOfHRY7isOWw3FP4w7V cxnA== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=RFC2wcGmUulYT06NMS9A44rmQciIxbboyUVdb83qFjc=; b=Rklp0/FsdTV7j2d+6Wwri0xzTuUzCnuB/GRLHYVa+EpwJzs+Jr6E8GKMp0HJf4DaSD bgO31zp43yYVqKjIhzh1T0UTpDQou6sS71J5qhv/KPr+e43TMeMuwo15WU33EB3nk6Jo zEI0pJrXKTRm2tUCnLf/0/z3emH5EkaWj95/7kMvppiIgEirFQisb8/BrB1vgpQZFlhJ 3yAkLb+y/uCvLOFbLzb9bOkogEtt6tSE9sURXrkISuplMzurGivO4xhWSCY9P1MwkhCv 2BQAZXYIDDsMeWfxnO+zzSalKj4j1dVaQP40cUH06gJvC97zdKqCfq+wz9od3md22eS7 ykjw== X-Gm-Message-State: AOPr4FXvDv6eTqlVMyYvPSP+KJ0M3mRGi/yJu/SbWQ47IYXDcx86I3Z+0STuBo2mLsnWcpOGmiRYxHcgqOc3pw== MIME-Version: 1.0 X-Received: by 10.50.205.8 with SMTP id lc8mr13807326igc.94.1464017804377; Mon, 23 May 2016 08:36:44 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Mon, 23 May 2016 08:36:44 -0700 (PDT) In-Reply-To: References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Mon, 23 May 2016 08:36:44 -0700 Message-ID: From: Tom Herbert To: Ca By Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Toerless Eckert , Michael Welzl , Joe Touch , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" , Jana Iyengar , Christian Huitema Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Mon, 23 May 2016 15:36:54 -0000 On Sun, May 22, 2016 at 1:06 PM, Ca By wrote: > > > On Sunday, May 22, 2016, Michael Welzl wrote: >> >> Hi, >> >> I still didn=E2=80=99t get to read the draft - apologies! I probably li= ke it :-) >> but I hope it allows putting multiple TCP connections under one single U= DP >> 5-tuple. >> Anyway, not speaking pro- or con- this draft, just a comment in line: >> >> >> On 22. mai 2016, at 05.03, Jana Iyengar wrote: >> >> Possibly unsurprisingly, I like this draft. I'd like to argue some of th= e >> choices made in the draft but I'll do that separately. For now, I just >> wanted to articulate a few thoughts as I caught up on this thread: >> >> - The ship has sailed on new native-IP transports. I worked on SCTP for = 6 >> years and tried and watched it get nowhere in terms of deployment over >> native-IP. It wasn't because it was in the kernel, it was primarily beca= use >> of NATs and various middleboxes. Yes this is definitely my opinion, but >> arguing this point is silly. No new native IP transport has seen signifi= cant >> deployment over the internet over the past 20 years, and it's not for la= ck >> of trying. >> >> =E2=80=9CThe ship has sailed=E2=80=9D and =E2=80=9Cit=E2=80=99s not for = lack of trying=E2=80=9D are both wrong >> IMO. How many applications have tried to use SCTP/IP and fallen back to = TCP >> in case it doesn=E2=80=99t work? How many applications do you expect to = change in >> order to get such a change to happen? And why should anyone expect someo= ne >> designing or maintaining a router or middlebox to support native SCTP wh= en >> they never even see the packets and never even hear anyone say =E2=80=9C= my >> application works better elsewhere because of SCTP=E2=80=9D ? >> >> This is what TAPS is trying to address. It=E2=80=99s a very deep archite= ctural >> problem of the Internet - an inability to automate fall-backs, which >> unnecessarily burdens application developers. Rant, rant, rant, make me = stop >> :-) >> >> Now all this being said, I also don=E2=80=99t fully get why some folks h= ave such a >> big problem with running stuff over UDP. I=E2=80=99m not against doing t= hat, if only >> as a temporary solution that would serve to convince people that the >> transport (option, ..) is useful. >> In a TAPS world, it=E2=80=99s just another option to try=E2=80=A6 >> > > The fact that udp is mostly (by volume) internet attack traffic is my > concern with udp. > > If legitimate traffic starts using udp in volume, it will make distiguish= ing > and thwarting voulmetric attacks very difficult at scale. Without current= ly > curbing n * 100g blasts of udp traffic with blanket policers, i would not= be > able to keep my network up... This is a daily issue. For example, my usu= al > udp volume is about 1%. If it goes to 10% suddenly, it is likely smart to > drop 11% and onwards as a 10x increase in udp is 100% certainly not legit= . > > My request to quic and spud is simply use a different transport protocol > number so that their interesting and innovative traffic does not run up > against the many network policers that are required to enforce well known > baselines of good normal udp traffic. The quic folks say that they cannot= do > that since 10 year old cpe only passes udp and tcp, then they rant about > ossified stacks and how we need to put everything on udp to make progess = ... > Seems like they are just choosing to ossify on udp ... And udp is alread= y > considered trash (reflection attacks) ...So we agree to disagree, i guess > Isn't any other protocol besides TCP also considered trash right now? UDP based transport protocols would use well know port numbers. A firewall can allow UDP port X that carries a properly congestion controlled protocols not subject to reflection attacks, but disallow other UDP ports. Tom > https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > > >> Cheers, >> Michael >> > From nobody Mon May 23 08:43: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 A88F712D993 for ; Mon, 23 May 2016 08:43:29 -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 bE3yqufnnERz for ; Mon, 23 May 2016 08:43:26 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6075D12D99D for ; Mon, 23 May 2016 08:43:26 -0700 (PDT) Received: from [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0] (unknown [IPv6:2001:67c:64:49:b0cc:febd:b2ea:c9b0]) by trammell.ch (Postfix) with ESMTPSA id A60B41A0523; Mon, 23 May 2016 17:42:55 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_69973D08-3D08-4EB0-BE1D-5B1BB2F51D02"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <655C07320163294895BBADA28372AF5D48863300@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Mon, 23 May 2016 17:42:57 +0200 Message-Id: <07E0D879-73F8-41A4-9525-4DCE5D592C07@trammell.ch> References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48861FF5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48863300@FR712WXCHMBA15.zeu.alcate l-lucent.com> To: "Scharf, Michael (Nokia - DE)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-00.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: Mon, 23 May 2016 15:43:30 -0000 --Apple-Mail=_69973D08-3D08-4EB0-BE1D-5B1BB2F51D02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Michael, > On 23 May 2016, at 16:56, Scharf, Michael (Nokia - DE) = wrote: >=20 >>> =C2=B7 Finally, from the current charter I don=E2=80=99t = understand whether PLUS/SPUD would consider the requirements of = middleboxes designed to provide user anonymity (e.g., TOR-like). I=E2=80=99= d personally be fine with flagging their specific requirements as = out-of-scope. But for sure there is a user community of that sort of = infrastructure and it may make sense to discuss early how to deal with = that. >=20 >> I *think* this is orthogonal -- I can't see what in PLUS would break = TOR, or how stuff in PLUS could make TOR work better, without partially = redesigning both... can you say more about what your concerns are here? >=20 > I don't think it is orthogonal, but I could imagine some quite = contradicting design objectives on the required signaling e.g. between = end system and TOR proxies. But I am not a TOR expert. >=20 > Why don't e.g. the BoF chairs reach out to the TOR community to get = feedback and to ensure openness in the IETF process regarding all = possibly affected users in the Internet? Thanks for the suggestion; will do. Thanks, cheers, Brian >=20 > For instance, if there is no feedback from the a certain community, it = would be easy to argue that something can be excluded in the charter. >=20 > Michael > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_69973D08-3D08-4EB0-BE1D-5B1BB2F51D02 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 iQIcBAEBCgAGBQJXQyUBAAoJEIoSt78L6kajnjQP/jJ1eQKWpOUlJNX5qJ4SWX10 E5EnlgYtXlY/rLj5ZW40OQ5NSzrEcMTS0slhSFy0umGfIh6g2kskEXvJf0ARKDe7 DGEj7BqfOpUPHvb6Pt/tSDne2GEpprfiE4bzKcIaK5Gx/TKANyV8mDNzwweOOmxS WDbaF9r0Sj4Z1GF0JHr3LQYtG7ad6WiXwAXhewd+mq5UlUeZBbWKRw7ZBBWfNelP McTDtwor7240HCKaZ2T0Jn+EMOKav+I8Jap7y2voHgTdbSn5Ut3J/dad+GW4PE+T ub62J6SRDR2PoeNjBZDH5EcPQd7wspi1akWzAEnqLhKA8y+HUVJAqnBFoySsNnbC EuRnQfPtRsXM3gD6T+/oJAkWqvdgI7Rj8MxUOzdevOOsttYULoS1+66paBJZZSGy +vcFueUtRNGx/X9OlaKmwKZI4YNS87J7/yM2thWmiT7kJ/v3AC1/Ya/phT9WfbMt K7F7I6oBgTCBDK9fcqlq8TC+1n3VaaYRpFDHAucbrL17AbgwlSU2VtIT20HLbpaM UZcJ7dx1GY6TjDwKeeutiTk7N3WOnzNLaKUhxuPTCUr01z9fMJv63k/9KqG9twHb GVJk/wrnsPnMtxeOT4v/3/F9DRQAnOwgDm2ICVwBJDVALna5U0H4xZRaeYOtHroj 87k4s1pzJLWXrmdQ/z6n =1m4l -----END PGP SIGNATURE----- --Apple-Mail=_69973D08-3D08-4EB0-BE1D-5B1BB2F51D02-- From nobody Mon May 23 08:46: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 890B412D127 for ; Mon, 23 May 2016 08:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 J4mwwDqofeMT for ; Mon, 23 May 2016 08:45:58 -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 1CF8712D0EF for ; Mon, 23 May 2016 08:45:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7E446D9314; Mon, 23 May 2016 17:45:56 +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 95c7dZO0XogW; Mon, 23 May 2016 17:45:56 +0200 (MEST) Received: from [172.20.10.5] (ip-109-84-2-6.web.vodafone.de [109.84.2.6]) (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 A7C31D930E; Mon, 23 May 2016 17:45:55 +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, 23 May 2016 16:33:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <677C2E5C-5EE6-49AD-B642-2577E3706F0F@tik.ee.ethz.ch> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 15:46:04 -0000 I don=E2=80=99t think we can deny the existence of stateful network work = devices anymore. Even though your load balancer does not work (well), = there are other things such as firewall which need to keep state for a = good reason. Mirja > Am 23.05.2016 um 15:44 schrieb Brian Trammell : >=20 >> I'm not sure what "path layer" is. Yes every packet takes some path, >> but the Internet is packet-switched not circuit-switched, so not all >> packets for a flow are required to always take the same path. >> Maintaining flow state in intermediate nodes is only best effort. In >> the presence of multi-homing and mobility intermediate devices that >> track flow state will inevitably have it wrong. Anyone who has ever >> tried to build a front-end L4 load balancer understands this problem >> all too well :-) >=20 > Your L4 load balancer is a path layer device. The fact that the = architecture (and operational practice built around it) don't work well = with it is a consequence of the architecture ignoring the existence of = path layer devices. From nobody Mon May 23 08:46: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 4ED3312D0EF for ; Mon, 23 May 2016 08:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 c1i_h3EVgxwd for ; Mon, 23 May 2016 08:46:03 -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 518B512D0BD for ; Mon, 23 May 2016 08:46:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 12E33D9316; Mon, 23 May 2016 17:46:02 +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 6uiD5wRyCbaD; Mon, 23 May 2016 17:46:01 +0200 (MEST) Received: from [172.20.10.5] (ip-109-84-2-6.web.vodafone.de [109.84.2.6]) (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 3B91FD930E; Mon, 23 May 2016 17:46:01 +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: <20160523140325.GC15064@cisco.com> Date: Mon, 23 May 2016 16:47:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4F306D60-0BD8-4425-A5D8-D815DB4EAAA7@tik.ee.ethz.ch> References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94911BF5-C313-4816-896B-A90FA630EE5B@mnot.net> <20160523140325.GC15064@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , Mark Nottingham , "spud@ietf.org" Subject: Re: [Spud] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 15:46:05 -0000 Hi Toerless, see below. > Am 23.05.2016 um 16:03 schrieb Toerless Eckert : >=20 > On Mon, May 23, 2016 at 03:43:55PM +0200, Brian Trammell wrote: >>> * In the proposed approach, will it be possible for a network to = offer a different quality of service to servers that insert specific = metadata into their streams (thereby affecting network neutrality)? >>=20 >> I think these are two different shades of the same threat: "tell me = something I want to hear, or I drop your packets", "tell me something I = want to hear, or I'll give you crap service", where "something I want to = hear" is either some secret verifying you've done something the operator = wants you to do (paid money, watched an ad) or information about the = traffic the operator could independently verify but doesn't want to have = to (otherwise, you could just lie). >>=20 >> Short answer: I do not think it is possible to prevent this kind of = behavior, even in the current architecture, because it isn't really a = technical problem. But it would be possible with PLUS to make it = transparent (which is the reason I don't see PLUS as enabling this = behavior). >>=20 >> Long answer: Here, the threat is above layer 7: the application is = "forced" to hand over a token in order to get connectivity of acceptable = performance. This token might represent information that could currently = be taken through DPI, but can't when that information is protected via = TLS.=20 >=20 > I like that answer much better than what Mirjan sent in before. But = when you are saying > "PLUS to make it transparent" - that was exactly what i was trying to = get to, and > i don't think thats understood so far: How would the application know = what it needs > to send to get through. Right now it does not know (existing = firewalls).=20 >=20 > So, how in PLUS would an app know what it needs to send to get through = ? Okay, that=E2=80=99s a good point. However, from the PLUS point of view = that not the important question for me because if you are willing to = provide certain information because they are not privacy-sensitive and = there simply might be a chance that by sending the information you get = the service that you=E2=80=99d like to get/need, why not just providing = these information=E2=80=A6? Simple example again: don=E2=80=99t really = see a reason to hind the TCP SYN/not expose the first packet of a flow = in PLUS, so just do it. I think , you again have a little bit more the application view here and = there the question is e.g. if you would like to use quic (as an = example): how do I know it works? Here I think you still need some happy = eyeball or fallback mechanism in the transport layer (or higher) (see = taps wg). However, SPUD could help you with a more meaningful error = message why your initial packet was dropped and therefore assist the = higher layer to implement the fallback appropriately e.g. speeding up = the fallback because you don=E2=80=99t have to wait for a timeout. However, I=E2=80=99m not sure if there is really a point in discussing = this at a general level. I think this has to be discussed separately for = each piece of information that we decide to support/provide in PLUS. Mirja >=20 > And then even more importantly: How can we make sure that anything = that needs to be exposed > to the firewall is known to be exposed only to the "trusted" firewall = of eg: your enterprise, > but not potentially all along the path to any other observers whom the = app does not > want to show its credential. >=20 > Btw: there are good and IMHO easy answers to these questions, i just = haven't seen > clear evidence whether PLUS intends to provide them. >=20 > Cheers > Toerless >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon May 23 08:50: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 B478112D128 for ; Mon, 23 May 2016 08:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 lImqHnewjc79 for ; Mon, 23 May 2016 08:50:43 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE7012D9A3 for ; Mon, 23 May 2016 08:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6500; q=dns/txt; s=iport; t=1464018630; x=1465228230; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Rx6KhUbN6/tjuk1iFR8AtzOg9vceQCOzKn+058fMR/Q=; b=HfPqKIHKPdAdKNBZf14MTnqAmazExMvFFvuxVU27o+teaqJ4/pQqXJau ZAWdasNPLR6N63qH3VZv9FyBLPb/zJc6acBTWbB9r+eMrYn/d0Ow+YPWN R+Wb5QtKQJrdaGbTLnH3eGJnctWJNM6aieYAG9sfymawvJAISvaTrL/Il I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgDrJUNX/4sNJK1VCYM3Vn26AQENg?= =?us-ascii?q?XcXC4VvAoExOBQBAQEBAQEBZSeEQgEBAQMBAQEBNzQLEAsOBAYJGgsPBRMiFBO?= =?us-ascii?q?IJwgOxGsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYlxgQOEEAiGAQWOWYleiHiFH?= =?us-ascii?q?gqBaYd7hTiPTB4BAUKCBhwWgVUcMolRAQEB?= X-IronPort-AV: E=Sophos;i="5.26,356,1459814400"; d="scan'208";a="275020712" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2016 15:50:29 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u4NFoSKv019382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2016 15:50:29 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 u4NFoSMb019794; Mon, 23 May 2016 08:50:28 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4NFoR3b019793; Mon, 23 May 2016 08:50:27 -0700 Date: Mon, 23 May 2016 08:50:27 -0700 From: Toerless Eckert To: Brian Trammell Message-ID: <20160523155027.GG15064@cisco.com> References: <20160523134348.GB15064@cisco.com> <20160523150141.GE15064@cisco.com> <0FA26CD2-BB4A-47AA-A85F-2DE52315E372@trammell.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0FA26CD2-BB4A-47AA-A85F-2DE52315E372@trammell.ch> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: mirja.kuehlewind@tik.ee.ethz.ch, "spud@ietf.org" Subject: Re: [Spud] What middleboxes are allowed to know (Re: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 15:50:46 -0000 On Mon, May 23, 2016 at 05:34:24PM +0200, Brian Trammell wrote: > > It would really help to get an example of how PLUS would help to get encrypted traffic better > > through firewall middleboxes. If that goal is out of the window for PLUS lets be very clear with > > it, because i think this was the starting point of SPUD. > > Ah. Here the answer is simple: by encrypting the transport headers (necessary to deossify), you take away the SYN/SYNACK/FIN/RST for flow state management, and you can give it back in a transport-neutral way with PLUS. Together with UDP port number based rules, and you preserve the status quo while getting to deploy new transports. This functionality wasn't meant to make firewalls work better than they do today, it was meant to keep from breaking them once the transport headers are encrypted. Ok. That type of explnaation should really be in the charter text because that makes a lot of things a lot clearer. And provides the best reason why we'd want to encrypt the transport headers. because none of the other explanations for encrypting transport headrs that we regurgitated in the last few days made sense to me. > > Simple unauthenticated app-ids are of course even less trustworthy than TCP ports, so they > > won't help with firewalls. They would help to do better statistics of course. DPI is often done > > together with netflow just for statistics gathering in enterprises, no firewalls involved. > > ...as long as you don't actually need those statistics for anything other than drawing pretty graphs on the wall in the NOC, this is fine. If you're a content network, you can pretty much trust yourself not to lie. Of course, your customers might not appreciate you tagging their encrypted traffic... so there are tradeoffs. Yes, the problem is when you would leak this information to the internet because it will have more information than you may want to signal further. > > For the firewalls, i think we need authenticated/secure app-id: AFAIK, every apple/google store binary > > has some authenticity elements. It's not hard to image how every such app binary could have a cert from the store > > or app-vendor, and the PLUS signaling is a proof of posession of the Cert, so that the middlebox > > can authenticate it. Encrypt the proof of posession so that you're not exposing your app-id to anyone > > by your own enterprise firewall, and IMHO we'd have something highly valuable. Yes, too large to fit into > > a PLUS header alone, would require to be part of PLUS session setup packets. > > > > Of course, such a model has a tail of more security implications like: firewall needs to be able to > > vet that the endpoint signaling PLUS can be trusted, eg: is administered by the enterprise IT department, > > so that apps started on it are assumed not to be hacked. > > This cuts both ways, of course; as soon as you have an architecture in which you have an encrypted in-band side channel to a firewall on path, you also need to be *very, very* careful that the thing you have the encrypted in-band side channel to is actually the firewall you think you should (or, rather, according to organization policy, must) trust. Sure, thats why i said to encrypt it, so only your orgs firewalls can decrypt it. > > And in such an environment it certainly > > is necessary to do the PLUS signaling from the OS level etc. pp. > > I'd note that is in direct conflict with the requirement to support application deployability of the PLUS shim, so... I don't see this use case coexisting well with a PLUS stack "under application control". Well, in my order of priorities, application level implementability is top. Its just that if i read Mirjams responses you folks don't feel too happy about giving it its rightfull place in the charter. And with opposition by folks like Joe that we can't define protocol stacks to make our stuff more implementable, because "it breaks the Internet", i have an idea why you don't want to, although i'll certainly would like to continue trying to persuade folks of the necessity. Wrt to "OS" - If you "apps" are running in a browser, then the "OS" would actually be the browser. You just need some trust-anchor on the client-device that can guarantee you that an application sending authnticated identity can not fake who it is. Cheers Toerless > > Cheers, > > Brian > > > Cheer > > Toerless > > > >> Cheers, > >> > >> Brian > >> > >>> > >>> > >>>>> What i really want to see is this: > >>>>> > >>>>> - Allow the application to learn from the network devices what information > >>>>> it must present in the clear to have its traffic be passed through > >>>>> and/or receive additional treatment by the network. > >>>>> > >>>>> Aka: "Security guard: Sure, you can go through this door if you show me your else not" > >>>>> > >>>>> Then the app can decide if it wants to show . Otherwise the > >>>>> apps have to operate like corporate drones, carrying around their corp-ID > >>>>> in the open all the time hoping that thats the right credential. > >>>>> > >>>>> Or to rephrase: if we do not even attempt to overcome TCP port numbers as > >>>>> credentials then we're lame and will not be successful. > >>>> > >>>> Okay??? I first of all have to simply say no here. I don???t want the middleboxes to require anything here, because why would a middlebox not just say ???either you show me all you content in plain or I don???t transport you data???. I believe that???s something we all don???t want and building a mechanism that could lead to this, it the last thing I want. I know what you intention is here, but we have to be more than careful here and the way you???ve just phrased it, I can just disagree. However, I would propose to have this discussion in a separate thread. > >>> > >>> _______________________________________________ > >>> 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 > -- --- Toerless Eckert, eckert@cisco.com From nobody Mon May 23 08:52: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 B57B012D95A for ; Mon, 23 May 2016 08:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 Zm4-pRvw3Kry for ; Mon, 23 May 2016 08:52:01 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 877CC12D1AD for ; Mon, 23 May 2016 08:52:00 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id b65so139933820oia.1 for ; Mon, 23 May 2016 08:52: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:date:message-id:subject:from:to :cc; bh=w5jGqOaU9APpdPwNYMQafWujd0pxFhnCEoPCbbsf/Xo=; b=WmV9vN6TOSw0EBFv2aCLKJWD844Ase+3h1Qua+CCRYO8V3gkkjV7AweOgnSQdslIC1 6/cKmlk4pp7E+Y3jJUNbRLduRjSvIjp6WpZtTyGZ0j0OUT6RWY7m70okC3ThFJbByoEu oJH7vJ8B8KmjWvg/fYimB6ifpG4r/JHgQaYnGG7KGvo9dZgIeP1G/li/fuU9EycKgpY6 DzkUWuQT7qAk/hxKjHWZHiT2Quu6XlHz4gWsO7ILOxVCIQ2DmkRA1JJ0oQ/G8UdDKaf/ HDQXZCs/nbTpFD7DdYvvkGZdaNKfi/ZF0IcjCYDs8QViPn9CaUldBL72T+71oYK1Ey8L HLZQ== 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:date :message-id:subject:from:to:cc; bh=w5jGqOaU9APpdPwNYMQafWujd0pxFhnCEoPCbbsf/Xo=; b=HnJs3HwOuAg1I2U5jfyt8J1m8Y5s7+IHNW88immP8NYFD9yf/lZUUCFJEkIrSoUk/9 LZSCnv8F4dlFl97LN2L+z9vXjdI2OVC+UbkA8ObWbs/XIWkEQdCUARCjCI0nZT/95Pug MNR5WRt4I+gb/wZtcmN9Q4NueWB2io35PgQSBnqt+9a4vSKmSOweEz72FAeKcBpYXIIW eoRAVqvrcKTRVyS8mczadYcqN1xPqdRJTKB8MlxNG+IV6pS7Jev0y77XQLEah02+ALo7 ffr84Cg6d6yh4ONKyIpWMsKPEpKGiwYVSfdZM+m4vy2pQjgz2J5nTBl11CDjnoUpBWfH rgHA== X-Gm-Message-State: ALyK8tJdDMfetxkh9t4QVkpYU71jU3Z2yte/MyF+KwbpCVB42EyhdjHliZYCB25xVDqunQNO3eN0SKgKLCbGiQ== MIME-Version: 1.0 X-Received: by 10.157.9.100 with SMTP id 91mr2515034otp.142.1464018719910; Mon, 23 May 2016 08:51:59 -0700 (PDT) Received: by 10.157.42.69 with HTTP; Mon, 23 May 2016 08:51:59 -0700 (PDT) In-Reply-To: References: <20160519185943.GM12994@cisco.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Mon, 23 May 2016 08:51:59 -0700 Message-ID: From: Ca By To: Tom Herbert Content-Type: multipart/alternative; boundary=94eb2c04f3fcbebaeb0533846bb8 Archived-At: Cc: Toerless Eckert , Michael Welzl , Joe Touch , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" , Jana Iyengar , Christian Huitema Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Mon, 23 May 2016 15:52:02 -0000 --94eb2c04f3fcbebaeb0533846bb8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, May 23, 2016, Tom Herbert wrote: > On Sun, May 22, 2016 at 1:06 PM, Ca By = > > wrote: > > > > > > On Sunday, May 22, 2016, Michael Welzl > wrote: > >> > >> Hi, > >> > >> I still didn=E2=80=99t get to read the draft - apologies! I probably = like it > :-) > >> but I hope it allows putting multiple TCP connections under one single > UDP > >> 5-tuple. > >> Anyway, not speaking pro- or con- this draft, just a comment in line: > >> > >> > >> On 22. mai 2016, at 05.03, Jana Iyengar = > > wrote: > >> > >> Possibly unsurprisingly, I like this draft. I'd like to argue some of > the > >> choices made in the draft but I'll do that separately. For now, I just > >> wanted to articulate a few thoughts as I caught up on this thread: > >> > >> - The ship has sailed on new native-IP transports. I worked on SCTP fo= r > 6 > >> years and tried and watched it get nowhere in terms of deployment over > >> native-IP. It wasn't because it was in the kernel, it was primarily > because > >> of NATs and various middleboxes. Yes this is definitely my opinion, bu= t > >> arguing this point is silly. No new native IP transport has seen > significant > >> deployment over the internet over the past 20 years, and it's not for > lack > >> of trying. > >> > >> =E2=80=9CThe ship has sailed=E2=80=9D and =E2=80=9Cit=E2=80=99s not fo= r lack of trying=E2=80=9D are both wrong > >> IMO. How many applications have tried to use SCTP/IP and fallen back t= o > TCP > >> in case it doesn=E2=80=99t work? How many applications do you expect t= o change > in > >> order to get such a change to happen? And why should anyone expect > someone > >> designing or maintaining a router or middlebox to support native SCTP > when > >> they never even see the packets and never even hear anyone say =E2=80= =9Cmy > >> application works better elsewhere because of SCTP=E2=80=9D ? > >> > >> This is what TAPS is trying to address. It=E2=80=99s a very deep archi= tectural > >> problem of the Internet - an inability to automate fall-backs, which > >> unnecessarily burdens application developers. Rant, rant, rant, make m= e > stop > >> :-) > >> > >> Now all this being said, I also don=E2=80=99t fully get why some folks= have > such a > >> big problem with running stuff over UDP. I=E2=80=99m not against doing= that, if > only > >> as a temporary solution that would serve to convince people that the > >> transport (option, ..) is useful. > >> In a TAPS world, it=E2=80=99s just another option to try=E2=80=A6 > >> > > > > The fact that udp is mostly (by volume) internet attack traffic is my > > concern with udp. > > > > If legitimate traffic starts using udp in volume, it will make > distiguishing > > and thwarting voulmetric attacks very difficult at scale. Without > currently > > curbing n * 100g blasts of udp traffic with blanket policers, i would > not be > > able to keep my network up... This is a daily issue. For example, my > usual > > udp volume is about 1%. If it goes to 10% suddenly, it is likely smart = to > > drop 11% and onwards as a 10x increase in udp is 100% certainly not > legit. > > > > My request to quic and spud is simply use a different transport protoco= l > > number so that their interesting and innovative traffic does not run up > > against the many network policers that are required to enforce well kno= wn > > baselines of good normal udp traffic. The quic folks say that they > cannot do > > that since 10 year old cpe only passes udp and tcp, then they rant abou= t > > ossified stacks and how we need to put everything on udp to make proges= s > ... > > Seems like they are just choosing to ossify on udp ... And udp is > already > > considered trash (reflection attacks) ...So we agree to disagree, i gue= ss > > > Isn't any other protocol besides TCP also considered trash right now? > > My network only "manages" udp. Ymmv. UDP based transport protocols would use well know port numbers. A firewall can allow UDP port X that carries a > A "firewall" is a enterprise solution that does not scale for large national internet providers in the usa Yes, the bulk of the trash is less than 20 source ports (chargen, ntp, snmp, ntp, dns, ....). But we also get very large bot swarms doing straight packet attacks with udp. Even a novice like me can write to udp sockets in python on any port and stuff data through it. > > properly congestion > controlled protocols not subject to reflection attacks, but disallow > other UDP ports. > > Tom > > > https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > > > > > > >> Cheers, > >> Michael > >> > > > --94eb2c04f3fcbebaeb0533846bb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, May 23, 2016, Tom Herbert <tom@herbertland.com> wrote:
On Sun, May 22, 2016 at 1:06 PM, Ca By <cb.list= 6@gmail.com> wrote:
>
>
> On Sunday, May 22, 2016, Michael Welzl <michawe@i= fi.uio.no> wrote:
>>
>> Hi,
>>
>> I still didn=E2=80=99t get to read the draft - apologies!=C2=A0 I = probably like it=C2=A0 :-)
>> but I hope it allows putting multiple TCP connections under one si= ngle UDP
>> 5-tuple.
>> Anyway, not speaking pro- or con- this draft, just a comment in li= ne:
>>
>>
>> On 22. mai 2016, at 05.03, Jana Iyengar <jri@goog= le.com> wrote:
>>
>> Possibly unsurprisingly, I like this draft. I'd like to argue = some of the
>> choices made in the draft but I'll do that separately. For now= , I just
>> wanted to articulate a few thoughts as I caught up on this thread:=
>>
>> - The ship has sailed on new native-IP transports. I worked on SCT= P for 6
>> years and tried and watched it get nowhere in terms of deployment = over
>> native-IP. It wasn't because it was in the kernel, it was prim= arily because
>> of NATs and various middleboxes. Yes this is definitely my opinion= , but
>> arguing this point is silly. No new native IP transport has seen s= ignificant
>> deployment over the internet over the past 20 years, and it's = not for lack
>> of trying.
>>
>> =E2=80=9CThe ship has sailed=E2=80=9D and =E2=80=9Cit=E2=80=99s no= t for lack of trying=E2=80=9D are both wrong
>> IMO. How many applications have tried to use SCTP/IP and fallen ba= ck to TCP
>> in case it doesn=E2=80=99t work? How many applications do you expe= ct to change in
>> order to get such a change to happen? And why should anyone expect= someone
>> designing or maintaining a router or middlebox to support native S= CTP when
>> they never even see the packets and never even hear anyone say =E2= =80=9Cmy
>> application works better elsewhere because of SCTP=E2=80=9D ?
>>
>> This is what TAPS is trying to address. It=E2=80=99s a very deep a= rchitectural
>> problem of the Internet - an inability to automate fall-backs, whi= ch
>> unnecessarily burdens application developers. Rant, rant, rant, ma= ke me stop
>> :-)
>>
>> Now all this being said, I also don=E2=80=99t fully get why some f= olks have such a
>> big problem with running stuff over UDP. I=E2=80=99m not against d= oing that, if only
>> as a temporary solution that would serve to convince people that t= he
>> transport (option, ..) is useful.
>> In a TAPS world, it=E2=80=99s just another option to try=E2=80=A6<= br> >>
>
> The fact that udp is mostly (by volume) internet attack traffic=C2=A0 = is my
> concern with udp.
>
> If legitimate traffic starts using udp in volume, it will make distigu= ishing
> and thwarting voulmetric attacks very difficult at scale. Without curr= ently
> curbing n * 100g blasts of udp traffic with blanket policers, i would = not be
> able to keep my network up... This is a daily issue.=C2=A0 For example= , my usual
> udp volume is about 1%. If it goes to 10% suddenly, it is likely smart= to
> drop 11% and onwards as a 10x increase in udp is 100% certainly not le= git.
>
> My request to quic and spud is simply use a different transport protoc= ol
> number so that their interesting and innovative traffic does not run u= p
> against the many network policers that are required to enforce well kn= own
> baselines of good normal udp traffic. The quic folks say that they can= not do
> that since 10 year old cpe only passes udp and tcp, then they rant abo= ut
> ossified stacks and how we need to put everything on udp to make proge= ss ...
> Seems like they are just choosing to ossify on udp ...=C2=A0 And udp i= s already
> considered trash (reflection attacks) ...So we agree to disagree, i gu= ess
>
Isn't any other protocol besides TCP also considered trash right now?

My network only "manages" ud= p.=C2=A0=C2=A0Ymmv.=C2=A0

firewall can allow UDP port X that carries a=C2=A0


A "firewall&qu= ot; is a enterprise solution that does not scale for large national interne= t providers in the usa=C2=A0

Yes, the bulk of the = trash is less than 20 source ports (chargen, ntp, snmp, ntp, dns, ....). Bu= t we also get very large bot swarms doing straight packet attacks with udp.= =C2=A0 Even a novice like me can write to udp sockets in python on any port= and stuff data through it.=C2=A0

=C2=A0
=

properly congestion
controlled protocols not subject to reflection attacks, but disallow
other UDP ports.

Tom

> https://tools.ietf.org/html/draft-byrne-opsec-udp-adv= isory-00
>
>
>
>> Cheers,
>> Michael
>>
>
--94eb2c04f3fcbebaeb0533846bb8-- From nobody Mon May 23 08:57: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 0422E12D9A1 for ; Mon, 23 May 2016 08:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 ZvD0Nu-HIgrO for ; Mon, 23 May 2016 08:57:24 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 52AA012D147 for ; Mon, 23 May 2016 08:57:24 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4NFuf7J017112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 May 2016 08:56:43 -0700 (PDT) To: Brian Trammell , Dave Dolson References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Joe Touch Message-ID: <57432839.9020308@isi.edu> Date: Mon, 23 May 2016 08:56:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010501030202090309040301" X-MailScanner-ID: u4NFuf7J017112 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 15:57:34 -0000 This is a multi-part message in MIME format. --------------010501030202090309040301 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit As I've pointed out repeatedly, OS implementation issues should not drive network architecture. Joe On 5/23/2016 6:44 AM, Brian Trammell wrote: >> On 20 May 2016, at 18:17, Dave Dolson wrote: >> >> Brian, >> The text of the proposed charter doesn't mention "UDP"; it's just in the title. >> >> If the intent is to require the use of UDP, it should be spelled out, I'd think. > I think the situation requires the use of UDP... especially, as Toerless says, if we make it clear that userspace implementability is a hard requirement (which IMO it is; longer reply to Toerless' charter comments to follow) in the charter. > > So yes, this should be explicit in the charter. > > Thanks, cheers, > > Brian > > > >> -Dave >> >> >> -----Original Message----- >> From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Brian Trammell >> Sent: Friday, May 20, 2016 7:02 AM >> To: spud@ietf.org >> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF >> >> Hi, all, >> >> I've heard one concrete charter suggestion so far; the edited draft charter (changed paragraph 2) is below. If others would like to see points clarified to answer their questions, please send suggested edits. :) >> >> I take the fact that we're diving into technical discussion as an indication that those participating are at least interested in the BoF, if not (yet ;) ) convinced of the need for a WG at this space? >> >> Thanks, cheers, >> >> Brian >> >> >> Path Layer UDP Substrate (PLUS) >> =============================== >> >> The PLUS working group's goal is to enable the deployment of new, >> encrypted transport protocols, while providing a >> transport-independent method to signal flow semantics under >> transport and application control. >> >> The current Internet protocol stack has no layer for explicit, >> in-band signaling of flow semantics and characteristics to network >> elements in an interdomain context, nor an integrated signaling >> mechanism from network elements to back to endpoints and applications. >> This layer never evolved within the stack, because middleboxes and >> other devices on path could simply inspect and modify headers and >> payload of unencrypted traffic at every layer. This implicit use of >> information from the transport and application layers is a >> key cause of the ossification that makes it hard or impossible >> to deploy new protocols. >> >> In order to support more ubiquitous deployment of encryption, >> explicit signaling must be added to the stack, and it must be >> transport protocol independent. 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. >> Additionally, 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. >> >> The PLUS working group will specify a new protocol as a Path Layer >> User 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 similar semantics to existing protocols (e.g. >> TCP) to devices on path (e.g. NATs and firewalls) >> >> - allow applications and transport protocols to explicitly provide >> limited information to devices on path >> >> - allow devices on path to provide feedback and information about >> the path to sending endpoints, under sending endpoint control >> >> - allow devices on path to provide information about the path to >> receiving endpoints, with feedback to the sending endpoint, under >> sending endpoint control >> >> Note that 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 at the level of detail that is useful for the network, >> while encrypting everything else. This is important to avoid future >> implicit treatment and the resulting ossification, as well as to >> leverage the principle of least exposure to minimize privacy risks >> presented by explicit cooperation. >> >> Given that the primary goal of PLUS is to enable the deployment of >> arbitrary, fully encrypted transport protocols, 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 >> these use cases and requirements. 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 other working >> groups that could or should 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. >> TLS) which could be used for encryption of transport protocols >> running over PLUS. >> >> >> >> >>> On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) wrote: >>> >>> My comment is *only* that the sentence "The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements" needs to be improved, in my personal point of view. >>> >>> For instance, for NAT/FW control, there are many existing out-of-band protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, etc., not to mention all the SDN protocols, which are typically all flow-based. They are all out-of-band but e.g. NSIS would have been end-to-end. The intention and deployment model of these protocols may be very different to what SPUD aims for, and none of them is deployed end-to-end in the Internet. But I think this sentence has to be slightly more specific how to differentiate e.g. from control plane solutions. >>> >>> Michael >>> >>> >>> -----Original Message----- >>> From: Toerless Eckert [mailto:eckert@cisco.com] >>> Sent: Thursday, May 19, 2016 8:27 PM >>> To: Tom Herbert >>> Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org >>> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF >>> >>> Tom, Michael >>> >>> I am reading your positions and i am confused: >>> >>> DSCP is very successfull in enterprise networks. SPUD does not have to be successfull "on the Internet". To me it would already be a great success if it would help to improve controlled network services (like enterprise or 4G/5G networks). And their transit traffic across the Internet (without changing anything on the Internet itself). >>> >>> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if we often think about them as per-flow and ould maybe like them to be restrict to per-flow. At least i don't know any normative reference that defines them to be per-flow. >>> >>> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis that all those mechanisms fail to provide an easily deplopyale framework in the face of middleboxes. Aka: their presence and mostly non-success should be an argument FOR working on spud. Not against it. >>> >>> If a NAT/FW does support any flow signaling, its most likely inband. Every NAT/firwall supports flow recognition via the explicit signaling of flow-based transport protoocols like TCP. They do try to do the same for UDP and because that has no explicit flow signaling, thats where the problem starts. NAT/FW do deep packet inspection which has all these problems we know. SPUD sets out to solve/reduce these NAT/FW issues. >>> >>> Non-support of anything like IP options is IMHO primarily driven by the absence of unform cross-OS/Dev-language APIs for them. Yes. It may suck architecturally by designing protocol stacks based on reality like: applications will only be able to use UDP and TCP, so lets do new work on top of them, but to me the most important goal is to find the best deployable solution to a problem. Not the architecturally cleanest one. If you give me research money to work outside of reality i will happily take it though and represent a different perspective. >>> >>> Please, i do not want to dismiss your opposition, i just don't understand how the arguments you make are working out. Maybe you can explain to me where i am going wrong in my interpretations above. >>> >>> Cheers >>> Toerless >>> >>> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote: >>>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE) >>>> wrote: >>>>> Does the sentence ... >>>>> >>>>> The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements ... >>>>> >>>>> actually wants to say something like >>>>> >>>>> The current Internet protocol stack has no layer for explicit *in-band* signaling of flow semantics and characteristics ... ? >>>>> >>>>> I may be wrong, but there is no shortage of IETF and non-IETF protocols that can signal flow semantics and characteristics out-of-band, either path-coupled or path-decoupled, e.g., in the control or management plane. As a result, there are protocol "layers" for that signaling, but they are not in-band. There may also be other ways to fix this problem (e.g., by adding "end-to-end" or "inter-domain" instead of "in-band"). >>>>> >>>> Not to mention that TOS and diff-serv are in-band signaling mechanisms >>>> to the network, ECN is explicitly signaling from the network. Given >>>> that they've been around for many years but have never been widely >>>> deployed on the Internet makes me wonder if any in-band signaling >>>> mechanism will ever catch on. The use of out of band signaling should >>>> be considered, especially considered that in many cases like NAT and >>>> firewall the network elements that need signaling are likely in local >>>> networks of one side of the connection. >>>> >>>> I have a similar concern about the statement that IP options/EH and >>>> extension headers are being left off the table as part of a solution. >>>> The fact that neither have these caught on in the Internet and that >>>> tells me two things 1) No IP option is needed for the Internet to >>>> operate and be successful which makes me wonder if signaling between >>>> network and hosts is even required 2) If the extensibility mechanisms >>>> of IP are chronically not deployable, I wonder why any alternative >>>> that does not yet exist but intends to solve the same problem would be >>>> any more deployable. >>>> >>>> Tom >>>> >>>>> Michael >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On >>>>> Behalf Of Brian Trammell >>>>> Sent: Thursday, May 19, 2016 5:07 PM >>>>> To: stackevo-discuss@iab.org >>>>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to >>>>> SPUD BoF >>>>> >>>>> Greetings, all, >>>>> >>>>> Forwarding this to the correct address for this mailing list (oops). Please discuss at spud@ietf.org. >>>>> >>>>> Thanks, cheers, >>>>> >>>>> Brian >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> From: Brian Trammell >>>>>> Subject: Possible WG-forming follow-on to SPUD BoF >>>>>> Date: 19 May 2016 at 17:04:50 GMT+2 >>>>>> To: spud@ietf.org >>>>>> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind >>>>>> (IETF)" , Spencer Dawkins at IETF >>>>>> >>>>>> >>>>>> Greetings, all, >>>>>> >>>>>> We propose to hold a working-group forming BoF in Berlin as a follow-on to the SPUD work, to define a common substrate protocol for encrypted transports based on the requirements derived from experimentation with the SPUD prototype. >>>>>> >>>>>> First, note that since the acronym "SPUD" refers primarily to the prototype itself, any follow-on working group should have a different name. We're using the derived requirements, not starting for the prototype. The name is a subject for discussion, and suggestions are welcome. To have something to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (PLUS) as a starting point. >>>>>> >>>>>> The proposed charter appears below. We're interested in hearing initial feedback on the proposed charter in preparation for a BoF proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work to do here within the IETF? Is the scope of the proposed charter appropriate? Is there energy to do this work? >>>>>> >>>>>> Thanks, cheers, >>>>>> >>>>>> Brian and Mirja >>>>>> >>>>>> >>>>>> Path Layer UDP Substrate (PLUS) >>>>>> =============================== >>>>>> >>>>>> The PLUS working group???s goal is to enable the deployment of new, >>>>>> encrypted transport protocols, while providing a >>>>>> transport-independent method to signal flow semantics under transport and application control. >>>>>> >>>>>> The current Internet protocol stack has no layer for explicit >>>>>> signaling of flow semantics and characteristics to network >>>>>> elements, nor an integrated signaling mechanism from network >>>>>> elements to back to endpoints and applications. This layer never >>>>>> evolved within the stack, because middleboxes and other devices on >>>>>> path could simply inspect and modify headers and payload of >>>>>> unencrypted traffic at every layer. This implicit use of >>>>>> information from the transport and application layers is a key origin of the ossification that makes it hard or impossible to deploy new protocols. >>>>>> >>>>>> In order to support more ubiquitous deployment of encryption, >>>>>> explicit signaling must be added to the stack, and it must be >>>>>> transport protocol independent. 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. >>>>>> Additionally, 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. >>>>>> >>>>>> The PLUS working group will specify a new protocol as a Path Layer >>>>>> User 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 similar semantics to existing protocols (e.g. >>>>>> TCP) to devices on path (e.g. NATs and firewalls) >>>>>> >>>>>> - allow applications and transport protocols to explicitly provide >>>>>> limited information to devices on path >>>>>> >>>>>> - allow devices on path to provide feedback and information about >>>>>> the path to sending endpoints, under sending endpoint control >>>>>> >>>>>> - allow devices on path to provide information about the path to >>>>>> receiving endpoints, with feedback to the sending endpoint, under >>>>>> sending endpoint control >>>>>> >>>>>> Note that 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 at the level of detail that is useful for the network, >>>>>> while encrypting everything else. This is important to avoid future >>>>>> implicit treatment and the resulting ossification, as well as to >>>>>> leverage the principle of least exposure to minimize privacy risks presented by explicit cooperation. >>>>>> >>>>>> Given that the primary goal of PLUS is to enable the deployment of >>>>>> arbitrary, fully encrypted transport protocols, 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 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 >>>>>> these use cases and requirements. 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 other working >>>>>> groups that could or should 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. >>>>>> TLS) which could be used for encryption of transport protocols running over 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 >>> -- >>> --- >>> Toerless Eckert, eckert@cisco.com > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --------------010501030202090309040301 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit As I've pointed out repeatedly, OS implementation issues should not drive network architecture.

Joe

On 5/23/2016 6:44 AM, Brian Trammell wrote:

      

        
On 20 May 2016, at 18:17, Dave Dolson <ddolson@sandvine.com> wrote:

Brian,
The text of the proposed charter doesn't mention "UDP"; it's just in the title.

If the intent is to require the use of UDP, it should be spelled out, I'd think.


      

      
I think the situation requires the use of UDP... especially, as Toerless says, if we make it clear that userspace implementability is a hard requirement (which IMO it is; longer reply to Toerless' charter comments to follow) in the charter.

So yes, this should be explicit in the charter.

Thanks, cheers,

Brian





      

        
-Dave


-----Original Message-----
From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Brian Trammell
Sent: Friday, May 20, 2016 7:02 AM
To: spud@ietf.org
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF

Hi, all,

I've heard one concrete charter suggestion so far; the edited draft charter (changed paragraph 2) is below. If others would like to see points clarified to answer their questions, please send suggested edits. :)

I take the fact that we're diving into technical discussion as an indication that those participating are at least interested in the BoF, if not (yet ;) ) convinced of the need for a WG at this space?

Thanks, cheers,

Brian


Path Layer UDP Substrate (PLUS)
===============================

The PLUS working group's goal is to enable the deployment of new,
encrypted transport protocols, while providing a
transport-independent method to signal flow semantics under
transport and application control.

The current Internet protocol stack has no layer for explicit,
in-band signaling of flow semantics and characteristics to network
elements in an interdomain context, nor an integrated signaling
mechanism from network elements to back to endpoints and applications.
This layer never evolved within the stack, because middleboxes and
other devices on path could simply inspect and modify headers and
payload of unencrypted traffic at every layer. This implicit use of
information from the transport and application layers is a
key cause of the ossification that makes it hard or impossible
to deploy new protocols.

In order to support more ubiquitous deployment of encryption,
explicit signaling must be added to the stack, and it must be
transport protocol independent. 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.
Additionally, 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.

The PLUS working group will specify a new protocol as a Path Layer
User 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 similar semantics to existing protocols (e.g.
TCP) to devices on path (e.g. NATs and firewalls)

- allow applications and transport protocols to explicitly provide
limited information to devices on path

- allow devices on path to provide feedback and information about
the path to sending endpoints, under sending endpoint control

- allow devices on path to provide information about the path to
receiving endpoints, with feedback to the sending endpoint, under
sending endpoint control

Note that 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 at the level of detail that is useful for the network,
while encrypting everything else. This is important to avoid future
implicit treatment and the resulting ossification, as well as to
leverage the principle of least exposure to minimize privacy risks
presented by explicit cooperation.

Given that the primary goal of PLUS is to enable the deployment of
arbitrary, fully encrypted transport protocols, 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
these use cases and requirements. 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 other working
groups that could or should 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.
TLS) which could be used for encryption of transport protocols
running over PLUS.






        

          
On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com> wrote:

My comment is *only* that the sentence "The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements" needs to be improved, in my personal point of view.

For instance, for NAT/FW control, there are many existing out-of-band protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, etc., not to mention all the SDN protocols, which are typically all flow-based. They are all out-of-band but e.g. NSIS would have been end-to-end. The intention and deployment model of these protocols may be very different to what SPUD aims for, and none of them is deployed end-to-end in the Internet. But I think this sentence has to be slightly more specific how to differentiate e.g. from control plane solutions.

Michael


-----Original Message-----
From: Toerless Eckert [mailto:eckert@cisco.com]
Sent: Thursday, May 19, 2016 8:27 PM
To: Tom Herbert
Cc: Scharf, Michael (Nokia - DE); Brian Trammell; spud@ietf.org
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF

Tom, Michael

I am reading your positions and i am confused:

DSCP is very successfull in enterprise networks. SPUD does not have to be successfull "on the Internet". To me it would already be a great success if it would help to improve controlled network services (like enterprise or 4G/5G networks). And their transit traffic across the Internet (without changing anything on the Internet itself).

AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if we often think about them as per-flow and ould maybe like them to be restrict to per-flow. At least i don't know any normative reference that defines them to be per-flow.

Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis that all those mechanisms fail to provide an easily deplopyale framework in the face of middleboxes. Aka: their presence and mostly non-success should be an argument FOR working on spud. Not against it.

If a NAT/FW does support any flow signaling, its most likely inband. Every NAT/firwall supports flow recognition via the explicit signaling of flow-based transport protoocols like TCP. They do try to do the same for UDP and because that has no explicit flow signaling, thats where the problem starts. NAT/FW do deep packet inspection which has all these problems we know. SPUD sets out to solve/reduce these NAT/FW issues.

Non-support of anything like IP options is IMHO primarily driven by the absence of unform cross-OS/Dev-language APIs for them. Yes. It may suck architecturally by designing protocol stacks based on reality like: applications will only be able to use UDP and TCP, so lets do new work on top of them, but to me the most important goal is to find the best deployable solution to a problem. Not the architecturally cleanest one. If you give me research money to work outside of reality i will happily take it though and represent a different perspective.

Please, i do not want to dismiss your opposition, i just don't understand how the arguments you make are working out. Maybe you can explain to me where i am going wrong in my interpretations above.

Cheers
 Toerless

On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote:


          

            
On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE)
<michael.scharf@nokia.com> wrote:


            

              
Does the sentence ...

The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements ...

actually wants to say something like

The current Internet protocol stack has no layer for explicit *in-band* signaling of flow semantics and characteristics ... ?

I may be wrong, but there is no shortage of IETF and non-IETF protocols that can signal flow semantics and characteristics out-of-band, either path-coupled or path-decoupled, e.g., in the control or management plane. As a result, there are protocol "layers" for that signaling, but they are not in-band. There may also be other ways to fix this problem (e.g., by adding "end-to-end" or "inter-domain" instead of "in-band").



            

            
Not to mention that TOS and diff-serv are in-band signaling mechanisms
to the network, ECN is explicitly signaling from the network. Given
that they've been around for many years but have never been widely
deployed on the Internet makes me wonder if any in-band signaling
mechanism will ever catch on. The use of out of band signaling should
be considered, especially considered that in many cases like NAT and
firewall the network elements that need signaling are likely in local
networks of one side of the connection.

I have a similar concern about the statement that IP options/EH and
extension headers are being left off the table as part of a solution.
The fact that neither have these caught on in the Internet and that
tells me two things 1) No IP option is needed for the Internet to
operate and be successful which makes me wonder if signaling between
network and hosts is even required 2) If the extensibility mechanisms
of IP are chronically not deployable, I wonder why any alternative
that does not yet exist but intends to solve the same problem would be
any more deployable.

Tom



            

              
Michael


-----Original Message-----
From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On
Behalf Of Brian Trammell
Sent: Thursday, May 19, 2016 5:07 PM
To: stackevo-discuss@iab.org
Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to
SPUD BoF

Greetings, all,

Forwarding this to the correct address for this mailing list (oops). Please discuss at spud@ietf.org.

Thanks, cheers,

Brian



              

                
Begin forwarded message:

From: Brian Trammell <ietf@trammell.ch>
Subject: Possible WG-forming follow-on to SPUD BoF
Date: 19 May 2016 at 17:04:50 GMT+2
To: spud@ietf.org
Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind
(IETF)" <ietf@kuehlewind.net>, Spencer Dawkins at IETF
<spencerdawkins.ietf@gmail.com>

Greetings, all,

We propose to hold a working-group forming BoF in Berlin as a follow-on to the SPUD work, to define a common substrate protocol for encrypted transports based on the requirements derived from experimentation with the SPUD prototype.

First, note that since the acronym "SPUD" refers primarily to the prototype itself, any follow-on working group should have a different name. We're using the derived requirements, not starting for the prototype. The name is a subject for discussion, and suggestions are welcome. To have something to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (PLUS) as a starting point.

The proposed charter appears below. We're interested in hearing initial feedback on the proposed charter in preparation for a BoF proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work to do here within the IETF? Is the scope of the proposed charter appropriate? Is there energy to do this work?

Thanks, cheers,

Brian and Mirja


Path Layer UDP Substrate (PLUS)
===============================

The PLUS working group???s goal is to enable the deployment of new,
encrypted transport protocols, while providing a
transport-independent method to signal flow semantics under transport and application control.

The current Internet protocol stack has no layer for explicit
signaling of flow semantics and characteristics to network
elements, nor an integrated signaling mechanism from network
elements to back to endpoints and applications. This layer never
evolved within the stack, because middleboxes and other devices on
path could simply inspect and modify headers and payload of
unencrypted traffic at every layer. This implicit use of
information from the transport and application layers is a key origin of the ossification that makes it hard or impossible to deploy new protocols.

In order to support more ubiquitous deployment of encryption,
explicit signaling must be added to the stack, and it must be
transport protocol independent. 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.
Additionally, 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.

The PLUS working group will specify a new protocol as a Path Layer
User 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 similar semantics to existing protocols (e.g.
TCP) to devices on path (e.g. NATs and firewalls)

- allow applications and transport protocols to explicitly provide
limited information to devices on path

- allow devices on path to provide feedback and information about
the path to sending endpoints, under sending endpoint control

- allow devices on path to provide information about the path to
receiving endpoints, with feedback to the sending endpoint, under
sending endpoint control

Note that 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 at the level of detail that is useful for the network,
while encrypting everything else. This is important to avoid future
implicit treatment and the resulting ossification, as well as to
leverage the principle of least exposure to minimize privacy risks presented by explicit cooperation.

Given that the primary goal of PLUS is to enable the deployment of
arbitrary, fully encrypted transport protocols, 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 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
these use cases and requirements. 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 other working
groups that could or should 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.
TLS) which could be used for encryption of transport protocols running over 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


          

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


        

        

      

      

      

      

      

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


    

    

  


--------------010501030202090309040301--


From nobody Mon May 23 08:58:31 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 531B012D149 for ; Mon, 23 May 2016 08:58: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 aWI2JxmnR8FY for ; Mon, 23 May 2016 08:58:26 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEFB12D147 for ; Mon, 23 May 2016 08:58:26 -0700 (PDT)
Received: from [IPv6:2001:67c:64:42:78ad:ba35:e29c:f80] (unknown [IPv6:2001:67c:64:42:78ad:ba35:e29c:f80]) by trammell.ch (Postfix) with ESMTPSA id 9ABDC1A0C46; Mon, 23 May 2016 17:57:55 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_F6D58AAB-423E-4567-94FB-F1F7898E27F1"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell 
In-Reply-To: <20160523155027.GG15064@cisco.com>
Date: Mon, 23 May 2016 17:57:56 +0200
Message-Id: <0F82B261-BF42-4155-B003-9DA3C8E77774@trammell.ch>
References: <20160523134348.GB15064@cisco.com>  <20160523150141.GE15064@cisco.com> <0FA26CD2-BB4A-47AA-A85F-2DE52315E372@trammell.ch> <20160523155027.GG15064@cisco.com>
To: Toerless Eckert 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: mirja.kuehlewind@tik.ee.ethz.ch, "spud@ietf.org" 
Subject: Re: [Spud] What middleboxes are allowed to know (Re: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 15:58:30 -0000

--Apple-Mail=_F6D58AAB-423E-4567-94FB-F1F7898E27F1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 23 May 2016, at 17:50, Toerless Eckert  wrote:
>=20
> On Mon, May 23, 2016 at 05:34:24PM +0200, Brian Trammell wrote:
>>> It would really help to get an example of how PLUS would help to get =
encrypted traffic better
>>> through firewall middleboxes. If that goal is out of the window for =
PLUS lets be very clear with
>>> it, because i think this was the starting point of SPUD.
>>=20
>> Ah. Here the answer is simple: by encrypting the transport headers =
(necessary to deossify), you take away the SYN/SYNACK/FIN/RST for flow =
state management, and you can give it back in a transport-neutral way =
with PLUS. Together with UDP port number based rules, and you preserve =
the status quo while getting to deploy new transports. This =
functionality wasn't meant to make firewalls work better than they do =
today, it was meant to keep from breaking them once the transport =
headers are encrypted.
>=20
> Ok. That type of explnaation should really be in the charter text =
because that makes a
> lot of things a lot clearer. And provides the best reason why we'd =
want to encrypt the
> transport headers. because none of the other explanations for =
encrypting transport headrs
> that we regurgitated in the last few days made sense to me.

Will add this to the list of pending charter edits, thanks.

>=20
>>> And in such an environment it certainly
>>> is necessary to do the PLUS signaling from the OS level etc. pp.
>>=20
>> I'd note that is in direct conflict with the requirement to support =
application deployability of the PLUS shim, so... I don't see this use =
case coexisting well with a PLUS stack "under application control".
>=20
> Well, in my order of priorities, application level implementability is =
top. Its
> just that if i read Mirjams responses you folks don't feel too happy =
about giving
> it its rightfull place in the charter.

I wouldn't say that (indeed "mention userspace/application =
implementability explicitly" is issue #2 on the charter edits list now).

Cheers,

Brian

> And with opposition by folks like Joe that
> we can't define protocol stacks to make our stuff more implementable, =
because
> "it breaks the Internet", i have an idea why you don't want to, =
although i'll certainly
> would like to continue trying to persuade folks of the necessity.
>=20
> Wrt to "OS" - If you "apps" are running in a browser, then the "OS" =
would actually be
> the browser. You just need some trust-anchor on the client-device that =
can guarantee
> you that an application sending authnticated identity can not fake who =
it is.
>=20
> Cheers
>   Toerless
>>=20
>> Cheers,
>>=20
>> Brian
>>=20
>>> Cheer
>>>   Toerless
>>>=20
>>>> Cheers,
>>>>=20
>>>> Brian
>>>>=20
>>>>>=20
>>>>>=20
>>>>>>> What i really want to see is this:
>>>>>>>=20
>>>>>>> - Allow the application to learn from the network devices what =
information
>>>>>>> it must present in the clear to have its traffic be passed =
through
>>>>>>> and/or receive additional treatment by the network.
>>>>>>>=20
>>>>>>> Aka: "Security guard: Sure, you can go through this door if you =
show me your  else not"
>>>>>>>=20
>>>>>>> Then the app can decide if it wants to show . =
Otherwise the
>>>>>>> apps have to operate like corporate drones, carrying around =
their corp-ID
>>>>>>> in the open all the time hoping that thats the right credential.
>>>>>>>=20
>>>>>>> Or to rephrase: if we do not even attempt to overcome TCP port =
numbers as
>>>>>>> credentials then we're lame and will not be successful.
>>>>>>=20
>>>>>> Okay??? I first of all have to simply say no here. I don???t want =
the middleboxes to require anything here, because why would a middlebox =
not just say ???either you show me all you content in plain or I don???t =
transport you data???. I believe that???s something we all don???t want =
and building a mechanism that could lead to this, it the last thing I =
want. I know what you intention is here, but we have to be more than =
careful here and the way you???ve just phrased it, I can just disagree. =
However, I would propose to have this discussion in a separate thread.
>>>>>=20
>>>>> _______________________________________________
>>>>> Spud mailing list
>>>>> Spud@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/spud
>>>>=20
>>>=20
>>>=20
>>>=20
>>>> _______________________________________________
>>>> Spud mailing list
>>>> Spud@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/spud
>>>=20
>>>=20
>>> --
>>> ---
>>> Toerless Eckert, eckert@cisco.com
>>>=20
>>> _______________________________________________
>>> Spud mailing list
>>> Spud@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spud
>>=20
>=20
>=20
>=20
> --
> ---
> Toerless Eckert, eckert@cisco.com
>=20
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud


--Apple-Mail=_F6D58AAB-423E-4567-94FB-F1F7898E27F1
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

iQIcBAEBCgAGBQJXQyiEAAoJEIoSt78L6kajSUIP/R+yhpwof9qUHDOqtU6prHNW
actvwMG4Ku0MW5K0vsz2APWGHNOo7r5x3pdQ7dMp+nkVToxAk+fh191CZBfbFQ0Z
bHAHDrczkKRae7BNj4p+3LBDdda1/7lmUtFWysYGXFl7a+KtpmTsT0BbFXChyAd8
CVHdZrzHjfTJAWbL0fnOM+erxGN7C7PgaIu3FimEMtikGD7KJ2afSMXgbwtT9v+Q
wwYaih9ExP0//o+M9750wP0TFoV8YC8WwBsfkkpdGQG+MVviJMG6Hflsr7b7+iwN
tPJ4A6/08vNlDCqfzvsU1+h9AqtK7jJ3sdpDKrbUpHTwGMjJxVtXF1UbY0mBT6ot
Te5GDjSoOT0olLytZCl21Ut2wLUSBxYAjm9J6uwsSvxs/o5SLyJ6u/9wYmlZ0RGn
5P6wfuWfC2PmYRwysDDM9/FxDe2fLhLWZcNDYyusE3QzFKbSdf41iqi698o84+mu
lpCN3LF4tXL/I0AdPGEzsJCn0D41V0WA8QU716Bb/iN7cXyiQovA1pJ3VpgSN5j5
F1gMpZY+iTRiRwNJ8Xhm5BJ0KqSWgk3bFe3vGb8S4UWLslAkF9a/2qr7deUZwb28
gVQ+X+4eIv1uGwrS5wAPUGfd/ePiLGJY5PG+7F07YnqWp1SN1lzscvMhsaAIoziR
RYdaU7lnvacEhNDHUM3B
=+GB2
-----END PGP SIGNATURE-----

--Apple-Mail=_F6D58AAB-423E-4567-94FB-F1F7898E27F1--


From nobody Mon May 23 09:01: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 DACD212D998 for ; Mon, 23 May 2016 09:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level: 
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 78r5SPnrSxoQ for ; Mon, 23 May 2016 09:01:47 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 F000712D995 for ; Mon, 23 May 2016 09:01:46 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4NG0so9017716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 May 2016 09:00:56 -0700 (PDT)
To: Brian Trammell , Tom Herbert 
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>    
From: Joe Touch 
Message-ID: <57432936.4080503@isi.edu>
Date: Mon, 23 May 2016 09:00:54 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; 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-MailScanner-ID: u4NG0so9017716
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 16:01:53 -0000

On 5/23/2016 6:44 AM, Brian Trammell wrote:
>> On 20 May 2016, at 18:03, Tom Herbert  wrote:
>> ...
>> DSCP is properly network-layer. If you believe in a "path layer" (which I'm pretty sure I do), you can argue that ECN is the first path layer protocol.
>>
>> I'm not sure what "path layer" is. Yes every packet takes some path,
>> but the Internet is packet-switched not circuit-switched, so not all
>> packets for a flow are required to always take the same path.
>> Maintaining flow state in intermediate nodes is only best effort. In
>> the presence of multi-homing and mobility intermediate devices that
>> track flow state will inevitably have it wrong. Anyone who has ever
>> tried to build a front-end L4 load balancer understands this problem
>> all too well :-)
> Your L4 load balancer is a path layer device. 

The only notion the Internet has of a path is a flow label.

Transport IDs identify services and connections within an endpoint, and
are not universally available or meaningful except at the endpoints.

All attempts by intermediate devices to rely on those identifiers makes
assumptions about visibility and correlation to desired shared-path
behavior that are baseless.

This is the key reason why MP-TCP is very badly misnamed. It is
multi-endpoint, not multipath, and always has been.

Joe


From nobody Mon May 23 09:03: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 DEF3412D91E for ; Mon, 23 May 2016 09:03:46 -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 lDyaPGgLGAe6 for ; Mon, 23 May 2016 09:03:43 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF1D12D104 for ; Mon, 23 May 2016 09:03:43 -0700 (PDT)
Received: from [IPv6:2001:67c:64:42:78ad:ba35:e29c:f80] (unknown [IPv6:2001:67c:64:42:78ad:ba35:e29c:f80]) by trammell.ch (Postfix) with ESMTPSA id 355B11A0459; Mon, 23 May 2016 18:03:42 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_83E8A75A-D12B-4EF7-950E-4F150E27AA64"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell 
In-Reply-To: <57432839.9020308@isi.edu>
Date: Mon, 23 May 2016 18:03:43 +0200
Message-Id: 
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <57432839.9020308@isi.edu>
To: Joe Touch 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Dave Dolson , "spud@ietf.org" 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 16:03:47 -0000

--Apple-Mail=_83E8A75A-D12B-4EF7-950E-4F150E27AA64
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


> On 23 May 2016, at 17:56, Joe Touch  wrote:
>=20
> As I've pointed out repeatedly, OS implementation issues should not =
drive network architecture.

Indeed.

A very large part of the problem here is the narrowness of the interface =
from the operating system down to TCP; attempts to work around this =
either have to sit on top of it (abstracting away some of the ugliness =
of socket options to provide a closer-to-DWIM interface to the =
programmer), or implement entirely new ways of doing things with little =
interoperability across libraries. You're also quite right in pointing =
out that *this* is not the IETF's problem.

IMO, leveraging the work done in making userspace stacks work fast gives =
us a way to sidestep the API in userspace. But assuming it is... in this =
world, userspace processes do direct DMA off the NIC, but we still need =
a transport header so the kernel knows which process gets to access =
which region of memory. If the transport is TCP, and has semantics that =
are TCP-enough that the network won't choke on them, then this header =
should be a TCP header. If it isn't, then we need a header that won't =
set up an expectation of TCP semantics on the wire; that leaves us with =
UDP if we acknowledge the existence of NATs and the expansion of =
five-tuple forwarding in general.

So it's not OS implementation details that are driving architecture, in =
this case, but the built environment.

Cheers,

Brian

> Joe
>=20
> On 5/23/2016 6:44 AM, Brian Trammell wrote:
>>> On 20 May 2016, at 18:17, Dave Dolson 
>>>  wrote:
>>>=20
>>> Brian,
>>> The text of the proposed charter doesn't mention "UDP"; it's just in =
the title.
>>>=20
>>> If the intent is to require the use of UDP, it should be spelled =
out, I'd think.
>>>=20
>> I think the situation requires the use of UDP... especially, as =
Toerless says, if we make it clear that userspace implementability is a =
hard requirement (which IMO it is; longer reply to Toerless' charter =
comments to follow) in the charter.
>>=20
>> So yes, this should be explicit in the charter.
>>=20
>> Thanks, cheers,
>>=20
>> Brian
>>=20
>>=20
>>=20
>>=20
>>> -Dave
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: Spud [
>>> mailto:spud-bounces@ietf.org
>>> ] On Behalf Of Brian Trammell
>>> Sent: Friday, May 20, 2016 7:02 AM
>>> To:
>>> spud@ietf.org
>>>=20
>>> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming =
follow-on to SPUD BoF
>>>=20
>>> Hi, all,
>>>=20
>>> I've heard one concrete charter suggestion so far; the edited draft =
charter (changed paragraph 2) is below. If others would like to see =
points clarified to answer their questions, please send suggested edits. =
:)
>>>=20
>>> I take the fact that we're diving into technical discussion as an =
indication that those participating are at least interested in the BoF, =
if not (yet ;) ) convinced of the need for a WG at this space?
>>>=20
>>> Thanks, cheers,
>>>=20
>>> Brian
>>>=20
>>>=20
>>> Path Layer UDP Substrate (PLUS)
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>> The PLUS working group's goal is to enable the deployment of new,
>>> encrypted transport protocols, while providing a
>>> transport-independent method to signal flow semantics under
>>> transport and application control.
>>>=20
>>> The current Internet protocol stack has no layer for explicit,
>>> in-band signaling of flow semantics and characteristics to network
>>> elements in an interdomain context, nor an integrated signaling
>>> mechanism from network elements to back to endpoints and =
applications.
>>> This layer never evolved within the stack, because middleboxes and
>>> other devices on path could simply inspect and modify headers and
>>> payload of unencrypted traffic at every layer. This implicit use of
>>> information from the transport and application layers is a
>>> key cause of the ossification that makes it hard or impossible
>>> to deploy new protocols.
>>>=20
>>> In order to support more ubiquitous deployment of encryption,
>>> explicit signaling must be added to the stack, and it must be
>>> transport protocol independent. 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.
>>> Additionally, 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.
>>>=20
>>> The PLUS working group will specify a new protocol as a Path Layer
>>> User Substrate (PLUS), to support experimental deployment of
>>> explicit cooperation between endpoints and devices on path, with the =
following goals:
>>>=20
>>> - enable ubiquitous deployment of encrypted higher layer protocols
>>> by providing exposure of similar semantics to existing protocols =
(e.g.
>>> TCP) to devices on path (e.g. NATs and firewalls)
>>>=20
>>> - allow applications and transport protocols to explicitly provide
>>> limited information to devices on path
>>>=20
>>> - allow devices on path to provide feedback and information about
>>> the path to sending endpoints, under sending endpoint control
>>>=20
>>> - allow devices on path to provide information about the path to
>>> receiving endpoints, with feedback to the sending endpoint, under
>>> sending endpoint control
>>>=20
>>> Note that 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 at the level of detail that is useful for the network,
>>> while encrypting everything else. This is important to avoid future
>>> implicit treatment and the resulting ossification, as well as to
>>> leverage the principle of least exposure to minimize privacy risks
>>> presented by explicit cooperation.
>>>=20
>>> Given that the primary goal of PLUS is to enable the deployment of
>>> arbitrary, fully encrypted transport protocols, 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.
>>>=20
>>> 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
>>> these use cases and requirements. The working group will close if
>>> it is not able to come to consensus on a protocol design to meet
>>> these requirements.
>>>=20
>>> The working group will additionally aim to identify other working
>>> groups that could or should 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.
>>> TLS) which could be used for encryption of transport protocols
>>> running over PLUS.
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) =

>>>>  wrote:
>>>>=20
>>>> My comment is *only* that the sentence "The current Internet =
protocol stack has no layer for explicit signaling of flow semantics and =
characteristics to network elements" needs to be improved, in my =
personal point of view.
>>>>=20
>>>> For instance, for NAT/FW control, there are many existing =
out-of-band protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and =
SIMCO), COPS, etc., not to mention all the SDN protocols, which are =
typically all flow-based. They are all out-of-band but e.g. NSIS would =
have been end-to-end. The intention and deployment model of these =
protocols may be very different to what SPUD aims for, and none of them =
is deployed end-to-end in the Internet. But I think this sentence has to =
be slightly more specific how to differentiate e.g. from control plane =
solutions.
>>>>=20
>>>> Michael
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: Toerless Eckert [
>>>> mailto:eckert@cisco.com
>>>> ]
>>>> Sent: Thursday, May 19, 2016 8:27 PM
>>>> To: Tom Herbert
>>>> Cc: Scharf, Michael (Nokia - DE); Brian Trammell;
>>>> spud@ietf.org
>>>>=20
>>>> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming =
follow-on to SPUD BoF
>>>>=20
>>>> Tom, Michael
>>>>=20
>>>> I am reading your positions and i am confused:
>>>>=20
>>>> DSCP is very successfull in enterprise networks. SPUD does not have =
to be successfull "on the Internet". To me it would already be a great =
success if it would help to improve controlled network services (like =
enterprise or 4G/5G networks). And their transit traffic across the =
Internet (without changing anything on the Internet itself).
>>>>=20
>>>> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. =
Even if we often think about them as per-flow and ould maybe like them =
to be restrict to per-flow. At least i don't know any normative =
reference that defines them to be per-flow.
>>>>=20
>>>> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the =
analysis that all those mechanisms fail to provide an easily deplopyale =
framework in the face of middleboxes. Aka: their presence and mostly =
non-success should be an argument FOR working on spud. Not against it.
>>>>=20
>>>> If a NAT/FW does support any flow signaling, its most likely =
inband. Every NAT/firwall supports flow recognition via the explicit =
signaling of flow-based transport protoocols like TCP. They do try to do =
the same for UDP and because that has no explicit flow signaling, thats =
where the problem starts. NAT/FW do deep packet inspection which has all =
these problems we know. SPUD sets out to solve/reduce these NAT/FW =
issues.
>>>>=20
>>>> Non-support of anything like IP options is IMHO primarily driven by =
the absence of unform cross-OS/Dev-language APIs for them. Yes. It may =
suck architecturally by designing protocol stacks based on reality like: =
applications will only be able to use UDP and TCP, so lets do new work =
on top of them, but to me the most important goal is to find the best =
deployable solution to a problem. Not the architecturally cleanest one. =
If you give me research money to work outside of reality i will happily =
take it though and represent a different perspective.
>>>>=20
>>>> Please, i do not want to dismiss your opposition, i just don't =
understand how the arguments you make are working out. Maybe you can =
explain to me where i am going wrong in my interpretations above.
>>>>=20
>>>> Cheers
>>>>  Toerless
>>>>=20
>>>> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert wrote:
>>>>=20
>>>>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE)
>>>>>=20
>>>>> 
>>>>>  wrote:
>>>>>=20
>>>>>> Does the sentence ...
>>>>>>=20
>>>>>> The current Internet protocol stack has no layer for explicit =
signaling of flow semantics and characteristics to network elements ...
>>>>>>=20
>>>>>> actually wants to say something like
>>>>>>=20
>>>>>> The current Internet protocol stack has no layer for explicit =
*in-band* signaling of flow semantics and characteristics ... ?
>>>>>>=20
>>>>>> I may be wrong, but there is no shortage of IETF and non-IETF =
protocols that can signal flow semantics and characteristics =
out-of-band, either path-coupled or path-decoupled, e.g., in the control =
or management plane. As a result, there are protocol "layers" for that =
signaling, but they are not in-band. There may also be other ways to fix =
this problem (e.g., by adding "end-to-end" or "inter-domain" instead of =
"in-band").
>>>>>>=20
>>>>>>=20
>>>>> Not to mention that TOS and diff-serv are in-band signaling =
mechanisms
>>>>> to the network, ECN is explicitly signaling from the network. =
Given
>>>>> that they've been around for many years but have never been widely
>>>>> deployed on the Internet makes me wonder if any in-band signaling
>>>>> mechanism will ever catch on. The use of out of band signaling =
should
>>>>> be considered, especially considered that in many cases like NAT =
and
>>>>> firewall the network elements that need signaling are likely in =
local
>>>>> networks of one side of the connection.
>>>>>=20
>>>>> I have a similar concern about the statement that IP options/EH =
and
>>>>> extension headers are being left off the table as part of a =
solution.
>>>>> The fact that neither have these caught on in the Internet and =
that
>>>>> tells me two things 1) No IP option is needed for the Internet to
>>>>> operate and be successful which makes me wonder if signaling =
between
>>>>> network and hosts is even required 2) If the extensibility =
mechanisms
>>>>> of IP are chronically not deployable, I wonder why any alternative
>>>>> that does not yet exist but intends to solve the same problem =
would be
>>>>> any more deployable.
>>>>>=20
>>>>> Tom
>>>>>=20
>>>>>=20
>>>>>> Michael
>>>>>>=20
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Stackevo-discuss [
>>>>>> mailto:stackevo-discuss-bounces@iab.org
>>>>>> ] On
>>>>>> Behalf Of Brian Trammell
>>>>>> Sent: Thursday, May 19, 2016 5:07 PM
>>>>>> To:
>>>>>> stackevo-discuss@iab.org
>>>>>>=20
>>>>>> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to
>>>>>> SPUD BoF
>>>>>>=20
>>>>>> Greetings, all,
>>>>>>=20
>>>>>> Forwarding this to the correct address for this mailing list =
(oops). Please discuss at
>>>>>> spud@ietf.org
>>>>>> .
>>>>>>=20
>>>>>> Thanks, cheers,
>>>>>>=20
>>>>>> Brian
>>>>>>=20
>>>>>>=20
>>>>>>> Begin forwarded message:
>>>>>>>=20
>>>>>>> From: Brian Trammell
>>>>>>> 
>>>>>>>=20
>>>>>>> Subject: Possible WG-forming follow-on to SPUD BoF
>>>>>>> Date: 19 May 2016 at 17:04:50 GMT+2
>>>>>>> To:
>>>>>>> spud@ietf.org
>>>>>>>=20
>>>>>>> Cc:
>>>>>>> stackevo-discuss@ietf.org, tsv-area@ietf.org
>>>>>>> , "Mirja Kuehlewind
>>>>>>> (IETF)"
>>>>>>> 
>>>>>>> , Spencer Dawkins at IETF
>>>>>>>=20
>>>>>>> 
>>>>>>>=20
>>>>>>>=20
>>>>>>> Greetings, all,
>>>>>>>=20
>>>>>>> We propose to hold a working-group forming BoF in Berlin as a =
follow-on to the SPUD work, to define a common substrate protocol for =
encrypted transports based on the requirements derived from =
experimentation with the SPUD prototype.
>>>>>>>=20
>>>>>>> First, note that since the acronym "SPUD" refers primarily to =
the prototype itself, any follow-on working group should have a =
different name. We're using the derived requirements, not starting for =
the prototype. The name is a subject for discussion, and suggestions are =
welcome. To have something to put in the proposed charter, we'd propose =
"Path Layer UDP Substrate" (PLUS) as a starting point.
>>>>>>>=20
>>>>>>> The proposed charter appears below. We're interested in hearing =
initial feedback on the proposed charter in preparation for a BoF =
proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). =
Is there work to do here within the IETF? Is the scope of the proposed =
charter appropriate? Is there energy to do this work?
>>>>>>>=20
>>>>>>> Thanks, cheers,
>>>>>>>=20
>>>>>>> Brian and Mirja
>>>>>>>=20
>>>>>>>=20
>>>>>>> Path Layer UDP Substrate (PLUS)
>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>>>=20
>>>>>>> The PLUS working group???s goal is to enable the deployment of =
new,
>>>>>>> encrypted transport protocols, while providing a
>>>>>>> transport-independent method to signal flow semantics under =
transport and application control.
>>>>>>>=20
>>>>>>> The current Internet protocol stack has no layer for explicit
>>>>>>> signaling of flow semantics and characteristics to network
>>>>>>> elements, nor an integrated signaling mechanism from network
>>>>>>> elements to back to endpoints and applications. This layer never
>>>>>>> evolved within the stack, because middleboxes and other devices =
on
>>>>>>> path could simply inspect and modify headers and payload of
>>>>>>> unencrypted traffic at every layer. This implicit use of
>>>>>>> information from the transport and application layers is a key =
origin of the ossification that makes it hard or impossible to deploy =
new protocols.
>>>>>>>=20
>>>>>>> In order to support more ubiquitous deployment of encryption,
>>>>>>> explicit signaling must be added to the stack, and it must be
>>>>>>> transport protocol independent. 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.
>>>>>>> Additionally, 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.
>>>>>>>=20
>>>>>>> The PLUS working group will specify a new protocol as a Path =
Layer
>>>>>>> User Substrate (PLUS), to support experimental deployment of
>>>>>>> explicit cooperation between endpoints and devices on path, with =
the following goals:
>>>>>>>=20
>>>>>>> - enable ubiquitous deployment of encrypted higher layer =
protocols
>>>>>>> by providing exposure of similar semantics to existing protocols =
(e.g.
>>>>>>> TCP) to devices on path (e.g. NATs and firewalls)
>>>>>>>=20
>>>>>>> - allow applications and transport protocols to explicitly =
provide
>>>>>>> limited information to devices on path
>>>>>>>=20
>>>>>>> - allow devices on path to provide feedback and information =
about
>>>>>>> the path to sending endpoints, under sending endpoint control
>>>>>>>=20
>>>>>>> - allow devices on path to provide information about the path to
>>>>>>> receiving endpoints, with feedback to the sending endpoint, =
under
>>>>>>> sending endpoint control
>>>>>>>=20
>>>>>>> Note that 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 at the level of detail that is useful for the network,
>>>>>>> while encrypting everything else. This is important to avoid =
future
>>>>>>> implicit treatment and the resulting ossification, as well as to
>>>>>>> leverage the principle of least exposure to minimize privacy =
risks presented by explicit cooperation.
>>>>>>>=20
>>>>>>> Given that the primary goal of PLUS is to enable the deployment =
of
>>>>>>> arbitrary, fully encrypted transport protocols, 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.
>>>>>>>=20
>>>>>>> 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 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
>>>>>>> these use cases and requirements. The working group will close =
if
>>>>>>> it is not able to come to consensus on a protocol design to meet =
these requirements.
>>>>>>>=20
>>>>>>> The working group will additionally aim to identify other =
working
>>>>>>> groups that could or should 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.
>>>>>>> TLS) which could be used for encryption of transport protocols =
running over PLUS.
>>>>>>>=20
>>>>>>>=20
>>>>>> _______________________________________________
>>>>>> Spud mailing list
>>>>>>=20
>>>>>> Spud@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/spud
>>>>> _______________________________________________
>>>>> Spud mailing list
>>>>>=20
>>>>> Spud@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/spud
>>>> --
>>>> ---
>>>> Toerless Eckert,
>>>> eckert@cisco.com
>>=20
>>=20
>> _______________________________________________
>> Spud mailing list
>>=20
>> Spud@ietf.org
>> https://www.ietf.org/mailman/listinfo/spud
>=20
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud


--Apple-Mail=_83E8A75A-D12B-4EF7-950E-4F150E27AA64
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

iQIcBAEBCgAGBQJXQynfAAoJEIoSt78L6kajnvUP/RTZArgxE/1+QTdXEYSWLAs+
sbdf+LgA2P8AFHe68n04pPiHuheR+cIAhM8WzlSFXPbph0UvgGeqiXlqzlE5rd7v
pRcgbCO/BAa/2LUlkLGQU2LYzK4ZxI/vXTIAIa+7bY+4rwtBvJFewlM8osBu4htA
36+Mjlq+W4yPd9bOvmsis1QGIUwPDELZ7FJTbtgektm/XOE91vufMjvQIJE3Kr+z
xn4v9amr6N+PFvS0yVL1tCpYdFApteml3/qgwDwNmbz2/kivuOfr9udlISfVf+MY
C7d9YiuaTTP2icT+harMcTss4cdgxU5PsO/3wDoyYaXjpP/RkF54OHntUX93gX5I
jlhzhK7DiV0qimgLOTyzitP0C9bSZ9A+f6GArDDTc8YTRqXCDPE0KOdtcHHHKEmI
48mpIAJUYpHYiU11RUL3811q57NcckPM+Lhc2O7k6Yv67Y7kswhT2oqU6Tza+0nS
dfBIVniK9Z20EVzecq7sqhbRGj6fx9Lj0g2vnlOPLHJNPG0nN7iONjqOLuTO9mEn
KrxwQMl1+VU0Y0RsJb0zaf69Js6BoKUWG4dN5d/udAGBULvnHWD9pLK9uNYiR/wQ
N22Np+YydUq+DgO/xqljWC675XEjqvc5lrZmTetddz2kbL2j/L4RaRpQkEkqPISE
4tUt+fZPYtUoT0Gibwqp
=CYnA
-----END PGP SIGNATURE-----

--Apple-Mail=_83E8A75A-D12B-4EF7-950E-4F150E27AA64--


From nobody Mon May 23 09:05: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 2BF5E12B004 for ; Mon, 23 May 2016 09:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.325
X-Spam-Level: 
X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 69V-yEsjaxRs for ; Mon, 23 May 2016 09:05:57 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 2B25E12D97D for ; Mon, 23 May 2016 09:05:54 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4NG5PMW018411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 May 2016 09:05:27 -0700 (PDT)
To: Phillip Hallam-Baker , Toerless Eckert 
References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com>  <20160519185943.GM12994@cisco.com>  <20160519202134.GP12994@cisco.com> 
From: Joe Touch 
Message-ID: <57432A45.7050608@isi.edu>
Date: Mon, 23 May 2016 09:05:25 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040701000401040501070905"
X-MailScanner-ID: u4NG5PMW018411
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: Tom Herbert , spud 
Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.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: Mon, 23 May 2016 16:05:58 -0000

This is a multi-part message in MIME format.
--------------040701000401040501070905
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit



On 5/21/2016 9:21 PM, Phillip Hallam-Baker wrote:
>
>
> On Thu, May 19, 2016 at 4:21 PM, Toerless Eckert  > wrote:
>
>
>     TLS should not be attackable this way. Isn't this fixed in 1.3 ?
>     You don't want
>     to be a baby sitter for TLS. TLS has to be a standalone
>     babysitter. That why we
>     hired it ;-)
>
>
> There is nothing in TLS to stop it being attacked. All TLS can do is
> to prevent certain attacks from succeeding and it is only designed to
> prevent Confidentiality or Integrity attacks.
>
> TLS isn't at all good at stopping denial of service attacks. When an
> attack occurs, there isn't much that can be done apart from closing
> the socket and trying again. 
>
> If you want to add in robustness, you need to be able to detect which
> of your TCP packets were mangled and that really isn't possible in
> user space.

You can detect anything in user space that the OS allows access to,
including link, network, and transport errors.

If you delegate demuxing to the OS and don't have an override, then
*that* is what stands in your way, not any property of the Internet
stack or its protocols.

Joe

--------------040701000401040501070905
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    

    
On 5/21/2016 9:21 PM, Phillip
      Hallam-Baker wrote:

    

    

      


        


          
On Thu, May 19, 2016 at 4:21 PM,
            Toerless Eckert <eckert@cisco.com> wrote:

            


              TLS should not be attackable this way. Isn't this fixed in
              1.3 ? You don't want

              to be a baby sitter for TLS. TLS has to be a standalone
              babysitter. That why we

              hired it ;-)

            


            

            
There is nothing in TLS to stop it being attacked. All
              TLS can do is to prevent certain attacks from succeeding
              and it is only designed to prevent Confidentiality or
              Integrity attacks.

            


            

            
TLS isn't at all good at stopping denial of service
              attacks. When an attack occurs, there isn't much that can
              be done apart from closing the socket and trying again. 

            


            

            
If you want to add in robustness, you need to be able
              to detect which of your TCP packets were mangled and that
              really isn't possible in user space.

            

          

        

      

    

    

    You can detect anything in user space that the OS allows access to,
    including link, network, and transport errors.

    

    If you delegate demuxing to the OS and don't have an override, then
    *that* is what stands in your way, not any property of the Internet
    stack or its protocols.

    

    Joe

  


--------------040701000401040501070905--


From nobody Mon May 23 09:09: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 763E612D9C0 for ; Mon, 23 May 2016 09:09:56 -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 r4nVjpJH0Br3 for ; Mon, 23 May 2016 09:09:54 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 696F512D9BF for ; Mon, 23 May 2016 09:09:54 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id f8so63857091ioe.3 for ; Mon, 23 May 2016 09:09:54 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=oSj7aEBPQ1uINjG/dCv8YQKnyeAjlUssXuoWKlJZlWo=; b=1//h6l2pCuVUn4QXQDImDyrTn87yJWW4O6Y2GpDNQSwsSN9GOoQ8Vxto715+H1Cbiy jMbe0K2y+d9luGl4vyiaWC+A/Vzwqc4sfiOjtP+0juSLmpYZBXyZ1QRAMzEJifjiIXNC KVf6lB40bcewJtzGjcdMufZcTHXFGOYyXh7P3H3cvLe8YCZpRM19D4dlNeS0UHO/ORY7 g1c5yb3LqBS22zg8CDAuvJ9plc5tvym9HYiX21k5d3Z4T/RCp1JD3NKkzbMolzEpXoFn Rs/x1LHZpdTydpMUNOe7sSOvqs83jElW/FDgT3FTDgtiz7I4DsFUK2JOoddfDWPlIHAz Xsig==
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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=oSj7aEBPQ1uINjG/dCv8YQKnyeAjlUssXuoWKlJZlWo=; b=Z+ejAYwjVFRP+eNgg4TD/goT/10Xnj310RZJ+mRypmFErbZ9mBQsXGHVx3LrCIDIIt nirm8CshVkKYEldg8LERVdL8TCJKjn1geZYs0LGKrn/+TKAh2TtXdLqozg8G3DXsixjn J3dhycEpFY3rnHhTlrTaT+v4DbcusqOhM22UZf0sGAJdQZBcak327CoeXnc22BmIFFO3 iGChcCEGw+sqZ5KujQJkScj58dSzgE7y3VyiTNiY0ZaDWI02btRqaAih+Tvxo/GzSinV N5VhCQo219J3kiaU8v1KDh1iL6LEIfWKpGAF7nFNCGNibBFHjCGjxiwtQPs4qwA8S1Q+ Ph6Q==
X-Gm-Message-State: ALyK8tLKZdkmx+yAE+lbNu3wNYFwN5N1HjRKsNMVWBdl7juYsEz7t197K//b3MC+4u++I4zUidByJ35tZm6uwA==
MIME-Version: 1.0
X-Received: by 10.107.162.131 with SMTP id l125mr4106819ioe.84.1464019793481;  Mon, 23 May 2016 09:09:53 -0700 (PDT)
Received: by 10.107.56.67 with HTTP; Mon, 23 May 2016 09:09:53 -0700 (PDT)
In-Reply-To: 
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>    
Date: Mon, 23 May 2016 09:09:53 -0700
Message-ID: 
From: Tom Herbert 
To: Brian Trammell 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 16:09:56 -0000

On Mon, May 23, 2016 at 6:44 AM, Brian Trammell  wrote:
>
>> On 20 May 2016, at 18:03, Tom Herbert  wrote:
>>
>> On Fri, May 20, 2016 at 3:08 AM, Brian Trammell  wrote=
:
>>> hi Tom,
>>>
>>>> On 19 May 2016, at 19:50, Tom Herbert  wrote:
>>>>
>>>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE)
>>>>  wrote:
>>>>> Does the sentence ...
>>>>>
>>>>> The current Internet protocol stack has no layer for explicit signali=
ng of flow semantics and characteristics to network elements ...
>>>>>
>>>>> actually wants to say something like
>>>>>
>>>>> The current Internet protocol stack has no layer for explicit *in-ban=
d* signaling of flow semantics and characteristics ... ?
>>>>>
>>>>> I may be wrong, but there is no shortage of IETF and non-IETF protoco=
ls that can signal flow semantics and characteristics out-of-band, either p=
ath-coupled or path-decoupled, e.g., in the control or management plane. As=
 a result, there are protocol "layers" for that signaling, but they are not=
 in-band. There may also be other ways to fix this problem (e.g., by adding=
 "end-to-end" or "inter-domain" instead of "in-band").
>>>>>
>>>> Not to mention that TOS and diff-serv are in-band signaling mechanisms
>>>> to the network, ECN is explicitly signaling from the network.
>>>
>>> DSCP is properly network-layer. If you believe in a "path layer" (which=
 I'm pretty sure I do), you can argue that ECN is the first path layer prot=
ocol.
>>>
>> I'm not sure what "path layer" is. Yes every packet takes some path,
>> but the Internet is packet-switched not circuit-switched, so not all
>> packets for a flow are required to always take the same path.
>> Maintaining flow state in intermediate nodes is only best effort. In
>> the presence of multi-homing and mobility intermediate devices that
>> track flow state will inevitably have it wrong. Anyone who has ever
>> tried to build a front-end L4 load balancer understands this problem
>> all too well :-)
>
> Your L4 load balancer is a path layer device. The fact that the architect=
ure (and operational practice built around it) don't work well with it is a=
 consequence of the architecture ignoring the existence of path layer devic=
es.
>

But the architecture here is that of the Internet which is inherently
packet-switched not circuit switched. I don't see how "path layer"
fits into that architecture, and we can't change the core Internet
protocols to accommodate it. Any intermediate device that creates
state presumes that flows follow a persistent and invariant path will
eventually, at some point, be wrong about the state. This is why
signaling connection state can only ever be considered best effort, in
the network we cannot operational rely on it to always be available or
correct. For instance, consider in PLUS a FIN is defined for end of
flow. Now suppose that some connection followed five different paths
during its lifetime. That means when the FIN is sent only the devices
on one of those paths will see it and know to destroy flow state.
State in devices on the other four paths is left hanging indefinitely
so they still need to implement some state eviction method like
timeout.

We solve this problem in out L4 load balancers by having them
cooperate with each other to perform identical consistent hashing or
out of band sharing of flow information. I don't believe such
cooperative methods can be used in the Internet between arbitrary
third party devices.

> In short (and I need a better definition than this), the "path layer" is =
a virtual layer in the stack comprised of those behaviors of on-path device=
s that keep state derived from the data plane of the network layer and/or u=
se transport layer information (and therefore have to keep state to operate=
 properly, as the transport layer maintains end-to-end state beyond the net=
work interface at each endpoint).
>
>>>> Given
>>>> that they've been around for many years but have never been widely
>>>> deployed on the Internet
>>>
>>> DCSP was defined in such a way that it makes little sense in an interdo=
main context, and its widespread intradomain deployment means that it will =
never deploy across domains in the general case.
>>>
>> Sure, but can you give a specific example of information exposure that
>> is useful in interdomain context, does not diminish end user security,
>> and does have any detrimental effects if the information is
>> fabricated?
>
> SYN/FIN/RST, with higher probability than TCP affords that the thing that=
 sent the FIN or RST is at least on path.
>
> Very limited information about the transport protocol's tolerances: loss =
and reordering tolerance come to mind.
>
Don't we already have diff-serv for such things?

> I'm a fan of timestamps with echoes (as with TSOPT, but with some way to =
indicate local delta) for diagnostics, but given that clock drift provides =
a few bits of fingerprint entropy, they might not meet the "does not dimini=
sh end user security" requirement if your attacker model includes people tr=
ying to track you via fingerprinting.
>
> Note that all of these are things you get on-path with TLS over TCP, that=
 you won't get with transport protocols that encrypt their headers, so thes=
e are examples of the "giving back" of information taken away when transpor=
t headers are encrypted, and/or the transport isn't TCP.
>
> 
>
>> Considering that there's already talk of sunsetting IPv4 I think it's
>> less of a concern-- IPv6 is the future of the Internet. In fact,
>> optimizing SPUD for IPv6 seems perfectly inline with encouraging
>> adoption wider adoption of IPv6.
>
> I'm extremely sympathetic to this approach. "Optimize for v6" can't mean =
"v6 only", though, unless we don't think it will deploy until v4 is on the =
way out anyway.
>
>>>> The fact that neither have these caught on in the Internet and that
>>>> tells me two things 1) No IP option is needed for the Internet to
>>>> operate and be successful which makes me wonder if signaling between
>>>> network and hosts is even required 2) If the extensibility mechanisms
>>>> of IP are chronically not deployable, I wonder why any alternative
>>>> that does not yet exist but intends to solve the same problem would be
>>>> any more deployable.
>>>
>>> I'd assert that encapsulating things in UDP is certainly much more depl=
oyable *at the endpoints*. The open question is about adoption by on-path d=
evices.
>>>
>> I'm not sure in this specific case that UDP necessarily make things
>> more deployable. For instance, there's the pesky problem of
>> fragmentation. If L3 information is put into UDP and that packet is
>> fragmented, only the first fragment contains the L3 information the
>> others don't. Either the application needs to pick some minimal MTU
>> and hope that packets make it through, or needs to implement PMTU
>> discovery (rather or not ICMP PTB is delivered to the application is
>> another story, in Linux it is at least). IPv6 nicely great here since
>> minimum MTU is 1280, IPv4 might be harder to nail down.
>
> Agreed. One of the things that works really well in an all-PLUS world is =
you can actually have native signaling of path MTU. Until then, PLPMTUD is =
your friend, and can live in the PLUS shim.
>
We already have PMTU discovery (RFC1191). The fact that it's
considered unusable because many network devices don't implement it is
is not a good rationale to create a new mechanism that provides the
same information but requires other new implementation in those same
devices.

Tom

> Cheers,
>
> Brian
>>
>


From nobody Mon May 23 09:15: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 AD15712D9D0 for ; Mon, 23 May 2016 09:15:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level: 
X-Spam-Status: No, score=-15.947 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.426, 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 yJy_OQtQ-EeY for ; Mon, 23 May 2016 09:15:22 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D0012D9CD for ; Mon, 23 May 2016 09:15:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4626; q=dns/txt; s=iport; t=1464020121; x=1465229721; h=from:date:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=D3E7pxWZYBTo1zP7nIKTZQRmkwq6LiW1uHgARBoXdzU=; b=GnNaBp/gETC9SbNOCFK/0qtEWeYujXaBNBUosEyBtGXTbzIlspj4o6/+ C1NSZks9jzZd7aMnEzjH7vNxlIVvUUyt9cjyW/xTBqg+CeSCGKEnVIc2J 20m0O4cbauPwxELkNj/IVD7aKI4qzVVr44uJO6/gx1x+3vcCyAyGIb6jF A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BZBQBQLENX/4sNJK1dgzdWfboPgXcXC?= =?us-ascii?q?4VvAoExORMBAQEBAQEBZSeEQwEBBAEBATc0CxALEgYJJQ8FEyIniC8OxF4BAQE?= =?us-ascii?q?BAQEBAQIBAQEBAQEBAQEBGAWKdIoZBY5ZiV6IeIUeCo8ciVeFdSIBP4IGHIFrH?= =?us-ascii?q?DKJUQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.26,356,1459814400"; d="scan'208";a="107300242"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2016 16:15:09 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u4NGF84Z006091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2016 16:15:09 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 u4NGF8pf027032; Mon, 23 May 2016 09:15:08 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4NGF74w027031; Mon, 23 May 2016 09:15:07 -0700
From: Toerless Eckert 
Date: Mon, 23 May 2016 09:15:07 -0700
To: mirja.kuehlewind@tik.ee.ethz.ch
Message-ID: <20160523161507.GH15064@cisco.com>
References: <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <94911BF5-C313-4816-896B-A90FA630EE5B@mnot.net>  <20160523140325.GC15064@cisco.com> <4F306D60-0BD8-4425-A5D8-D815DB4EAAA7@tik.ee.ethz.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F306D60-0BD8-4425-A5D8-D815DB4EAAA7@tik.ee.ethz.ch>
User-Agent: Mutt/1.4.2.2i
Archived-At: 
Cc: Brian Trammell , Mark Nottingham , "spud@ietf.org" 
Subject: Re: [Spud] Fwd:  Possible WG-forming follow-on to SPUD 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, 23 May 2016 16:15:24 -0000

Mirja:

I am sure privacy advocats will rightfully argue that anything beyond whats
necessary is bad to disclose.

What i wouldlike to have is the ability of PLUS to mange whats signaled:
As an app, i'd be happy to signal relevant data up to the point (eg: firewall)
where it leaves my local trust-domain. To do this, i'd either need to encrypt
the info so if it leaks beyond that trust edge, its useless, or PLUS should be
abble to remove the info, and in any case, the sender would need a mechanism
to figure out if three will be a trust-edge removing the info before the
flow enters the untrusted Internet.

Cheers
    Toerless

On Mon, May 23, 2016 at 04:47:51PM +0200, Mirja K?hlewind wrote:
> Hi Toerless,
> 
> see below.
> 
> > Am 23.05.2016 um 16:03 schrieb Toerless Eckert :
> > 
> > On Mon, May 23, 2016 at 03:43:55PM +0200, Brian Trammell wrote:
> >>> * In the proposed approach, will it be possible for a network to offer a different quality of service to servers that insert specific metadata into their streams (thereby affecting network neutrality)?
> >> 
> >> I think these are two different shades of the same threat: "tell me something I want to hear, or I drop your packets", "tell me something I want to hear, or I'll give you crap service", where "something I want to hear" is either some secret verifying you've done something the operator wants you to do (paid money, watched an ad) or information about the traffic the operator could independently verify but doesn't want to have to (otherwise, you could just lie).
> >> 
> >> Short answer: I do not think it is possible to prevent this kind of behavior, even in the current architecture, because it isn't really a technical problem. But it would be possible with PLUS to make it transparent (which is the reason I don't see PLUS as enabling this behavior).
> >> 
> >> Long answer: Here, the threat is above layer 7: the application is "forced" to hand over a token in order to get connectivity of acceptable performance. This token might represent information that could currently be taken through DPI, but can't when that information is protected via TLS. 
> > 
> > I like that answer much better than what Mirjan sent in before. But when you are saying
> > "PLUS to make it transparent" - that was exactly  what i was trying to get to, and
> > i don't think thats understood so far: How would the application know what it needs
> > to send to get through. Right now it does not know (existing firewalls). 
> > 
> > So, how in PLUS would an app know what it needs to send to get through ?
> 
> Okay, that???s a good point. However, from the PLUS point of view that not the important question for me because if you are willing to provide certain information because they are not privacy-sensitive and there simply might be a chance that by sending the information you get the service that you???d like to get/need, why not just providing these information???? Simple example again: don???t really see a reason to hind the TCP SYN/not expose the first packet of a flow in PLUS, so just do it.
> 
> I think , you again have a little bit more the application view here and there the question is e.g. if you would like to use quic (as an example): how do I know it works? Here I think you still need some happy eyeball or fallback mechanism in the transport layer (or higher) (see taps wg). However, SPUD could help you with a more meaningful error message why your initial packet was dropped and therefore assist the higher layer to implement the fallback appropriately e.g. speeding up the fallback because you don???t have to wait for a timeout.
> 
> However, I???m not sure if there is really a point in discussing this at a general level. I think this has to be discussed separately for each piece of information that we decide to support/provide in PLUS.
> 
> Mirja
> 
> 
> > 
> > And then even more importantly: How can we make sure that anything that needs to be exposed
> > to the firewall is known to be exposed only to the "trusted" firewall of eg: your enterprise,
> > but not potentially all along the path to any other observers whom the app does not
> > want to show its credential.
> > 
> > Btw: there are good and IMHO easy answers to these questions, i just haven't seen
> > clear evidence whether PLUS intends to provide them.
> > 
> > Cheers
> >    Toerless
> > 
> > _______________________________________________
> > Spud mailing list
> > Spud@ietf.org
> > https://www.ietf.org/mailman/listinfo/spud
> 

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


From nobody Mon May 23 09:16: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 46D5512D9D1 for ; Mon, 23 May 2016 09:16:17 -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 gznhhBTJq10X for ; Mon, 23 May 2016 09:16:15 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id B0EFD12D9D2 for ; Mon, 23 May 2016 09:16:11 -0700 (PDT)
Received: from [IPv6:2001:67c:64:42:d60:875c:3816:c219] (unknown [IPv6:2001:67c:64:42:d60:875c:3816:c219]) by trammell.ch (Postfix) with ESMTPSA id E11901A03C6; Mon, 23 May 2016 18:15:40 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_E015B4EE-4898-4AEF-BA3F-172385FC8275"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell 
In-Reply-To: <57432936.4080503@isi.edu>
Date: Mon, 23 May 2016 18:15:39 +0200
Message-Id: 
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>     <57432936.4080503@isi.edu>
To: Joe Touch 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "spud@ietf.org" 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 16:16:17 -0000

--Apple-Mail=_E015B4EE-4898-4AEF-BA3F-172385FC8275
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


> On 23 May 2016, at 18:00, Joe Touch  wrote:
>=20
>=20
>=20
> On 5/23/2016 6:44 AM, Brian Trammell wrote:
>>> On 20 May 2016, at 18:03, Tom Herbert  wrote:
>>> ...
>>> DSCP is properly network-layer. If you believe in a "path layer" =
(which I'm pretty sure I do), you can argue that ECN is the first path =
layer protocol.
>>>=20
>>> I'm not sure what "path layer" is. Yes every packet takes some path,
>>> but the Internet is packet-switched not circuit-switched, so not all
>>> packets for a flow are required to always take the same path.
>>> Maintaining flow state in intermediate nodes is only best effort. In
>>> the presence of multi-homing and mobility intermediate devices that
>>> track flow state will inevitably have it wrong. Anyone who has ever
>>> tried to build a front-end L4 load balancer understands this problem
>>> all too well :-)
>> Your L4 load balancer is a path layer device.
>=20
> The only notion the Internet has of a path is a flow label.
>=20
> Transport IDs identify services and connections within an endpoint, =
and
> are not universally available or meaningful except at the endpoints.
>=20
> All attempts by intermediate devices to rely on those identifiers =
makes
> assumptions about visibility and correlation to desired shared-path
> behavior that are baseless.

But those intermediate devices *do indeed* route those packets based an =
N-tuple, where N is generally 5. One can ignore this fact and be =
surprised by what the network does, or resign oneself to it and leverage =
it.

> This is the key reason why MP-TCP is very badly misnamed. It is
> multi-endpoint, not multipath, and always has been.

You're quite right, but the current routing architecture gives us no way =
to influence paths except by choosing endpoints. And even then, we can =
know very little about how the endpoint identifiers map to paths.

Cheers,

Brian

--Apple-Mail=_E015B4EE-4898-4AEF-BA3F-172385FC8275
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

iQIcBAEBCgAGBQJXQyysAAoJEIoSt78L6kajOWoQAKpfN8I0tC4lfXlJhEQqrlj9
ie5lbLtnQHdCNLrqV/bSIlJ4CbsFVB1iIhhyrtrR539oUD02CLmj8r6zLwyovq6r
WXlQ3pnuo32dyZkR+B4ViIyfo3MG/MFsRvyL0i4BReTg+M8A6rnUIhWYDT0jXsB1
ZmUuM7ZBlAT8bZyfi9fBD3D1r0TBLcOA8SkRPnHfW24yI+Padl3Bq/isJCv2tlDd
cBgIcslvz7ORQyAZh/RLGABZtyFXHWcnVKhXnOQSUKJDJ+t+ax+EA6z7m9UNJHRM
ZaXh9dfrWxplHYo9MW+SSBgyU5GTeTpHD+rx8nF2n1R2oA8bxz7h/ligK/5RbVxn
JcSSMgrRRFdyLl9S+1qoqhLjVUd5erxDme47YDiH0Xo+6uePK3ScbSKLOyQKeSvn
AIr+T+ohIkN60qVJ0d+++bFYi6vbDVYRKsVuPmwQIAffrVBIV40CnrQu5Sty1/Ay
rPsNPvx+H6wNO/Qki1V/BztmAn2FngqgSP2eLqcuNCQbqkpmCjqcdHDqMovLT2nT
ZvG2/K5XHjQlq2csIzpaWjWpExxcUP2wGpqW63Xvl/G5edu8SXoJvHLrdPNlC3Y4
Qt9ys6yl/JHMvLN39/fkXxgVzvBhhx3i2KlRcUF8UQlHlzORpTAogKUvZg3soVQ6
hcC9EApzAWgLC7l8/lsE
=UKlA
-----END PGP SIGNATURE-----

--Apple-Mail=_E015B4EE-4898-4AEF-BA3F-172385FC8275--


From nobody Mon May 23 09:17: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 472F112D818 for ; Mon, 23 May 2016 09:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level: 
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 HeTLKKFyNaan for ; Mon, 23 May 2016 09:17:50 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 6217412D9E2 for ; Mon, 23 May 2016 09:17:44 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4NGHKbW020009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 May 2016 09:17:21 -0700 (PDT)
To: Brian Trammell 
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <57432839.9020308@isi.edu> 
From: Joe Touch 
Message-ID: <57432D10.4070506@isi.edu>
Date: Mon, 23 May 2016 09:17:20 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; 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-MailScanner-ID: u4NGHKbW020009
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: Dave Dolson , "spud@ietf.org" 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 16:17:53 -0000

On 5/23/2016 9:03 AM, Brian Trammell wrote:
>> On 23 May 2016, at 17:56, Joe Touch  wrote:
>>
>> As I've pointed out repeatedly, OS implementation issues should not drive network architecture.
> Indeed.
>
> A very large part of the problem here is the narrowness of the interface from the operating system down to TCP; attempts to work around this either have to sit on top of it (abstracting away some of the ugliness of socket options to provide a closer-to-DWIM interface to the programmer), or implement entirely new ways of doing things with little interoperability across libraries. You're also quite right in pointing out that *this* is not the IETF's problem.
>
> IMO, leveraging the work done in making userspace stacks work fast gives us a way to sidestep the API in userspace. But assuming it is... in this world, userspace processes do direct DMA off the NIC, but we still need a transport header so the kernel knows which process gets to access which region of memory. If the transport is TCP, and has semantics that are TCP-enough that the network won't choke on them, then this header should be a TCP header. If it isn't, then we need a header that won't set up an expectation of TCP semantics on the wire; that leaves us with UDP if we acknowledge the existence of NATs and the expansion of five-tuple forwarding in general.

You need a transport header to define multiple protocol machines inside
an endpoint, period. The rest is an OS implementation issue.

However, once you accept that header as a demux point, the payload has
to be sufficiently complete. TCP in UDP isn't.

Joe



From nobody Mon May 23 09:19:46 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 38C6412D9E0 for ; Mon, 23 May 2016 09:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.325
X-Spam-Level: 
X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 MLz_jSrd5McH for ; Mon, 23 May 2016 09:19:44 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 1EFA912D9D6 for ; Mon, 23 May 2016 09:19:44 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4NGJ33a020100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 May 2016 09:19:05 -0700 (PDT)
To: Brian Trammell 
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>     <57432936.4080503@isi.edu> 
From: Joe Touch 
Message-ID: <57432D77.1030401@isi.edu>
Date: Mon, 23 May 2016 09:19:03 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000905090306020800010206"
X-MailScanner-ID: u4NGJ33a020100
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: "spud@ietf.org" 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 16:19:45 -0000

This is a multi-part message in MIME format.
--------------000905090306020800010206
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit



On 5/23/2016 9:15 AM, Brian Trammell wrote:
>> All attempts by intermediate devices to rely on those identifiers makes
>> > assumptions about visibility and correlation to desired shared-path
>> > behavior that are baseless.
> But those intermediate devices *do indeed* route those packets based an N-tuple, where N is generally 5. One can ignore this fact and be surprised by what the network does, or resign oneself to it and leverage it.

Or we can encrypt the transport and disable the network's ability to do
this altogether.

>> > This is the key reason why MP-TCP is very badly misnamed. It is
>> > multi-endpoint, not multipath, and always has been.
> You're quite right, but the current routing architecture gives us no way to influence paths except by choosing endpoints.
We have routing headers for *exactly* this purpose.

>  And even then, we can know very little about how the endpoint identifiers map to paths.
Yes; that's why we have routing headers.

Joe

--------------000905090306020800010206
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    

    
On 5/23/2016 9:15 AM, Brian Trammell
      wrote:

    

    

      

        
All attempts by intermediate devices to rely on those identifiers makes
> assumptions about visibility and correlation to desired shared-path
> behavior that are baseless.


      

      
But those intermediate devices *do indeed* route those packets based an N-tuple, where N is generally 5. One can ignore this fact and be surprised by what the network does, or resign oneself to it and leverage it.

    

    

    Or we can encrypt the transport and disable the network's ability to
    do this altogether.

    

    

      

        
> This is the key reason why MP-TCP is very badly misnamed. It is
> multi-endpoint, not multipath, and always has been.


      

      
You're quite right, but the current routing architecture gives us no way to influence paths except by choosing endpoints.

    

    We have routing headers for *exactly* this purpose.

    

    

      
 And even then, we can know very little about how the endpoint identifiers map to paths.

    

    Yes; that's why we have routing headers.

    

    Joe

  


--------------000905090306020800010206--


From nobody Mon May 23 09: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 37CE512D9CB for ; Mon, 23 May 2016 09:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 N-zxb2VmXMr3 for ; Mon, 23 May 2016 09:20:31 -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 B8BA312D9E5 for ; Mon, 23 May 2016 09:20:27 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id z123so27893645itg.0 for ; Mon, 23 May 2016 09:20:27 -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:date:message-id:subject:from:to :cc; bh=NGsDJjVXOXGWBSeZILJ2Wfs9IWfUYx4AcujXnZR3jkk=; b=r2bZq8nCHWgMzLaK7F0CkU3s8mApW8HNPMpMInlVUBUpK0cVGO89upTu9yeWysho2y 8TrU7Vrc9NajJxTA7N3fCwKZPDNjQ5wW/AZ3UvupC7M3TVguS0+E3sajTcBsNFLXJsqk 63Kosr7nIcICBU+Tw1Ir+kuN0PeSSNNWjaMJl8SXp4J0lBjKVRSkhb3LnjPep3ucvvOg ou7zyb2cJgMAospnmsPjOjhCps7YAMEIADN18feRuMfBrH1bJVp7BX7rbVx4HxCpyc0p WECH1pMr1ns0KAQYpO9CzHPR6BP6BihK1KTjoufLp0GG5dYrpFezxWJDwVOWNM6/72IC tyIA==
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:date :message-id:subject:from:to:cc; bh=NGsDJjVXOXGWBSeZILJ2Wfs9IWfUYx4AcujXnZR3jkk=; b=PLyHK6ShVDsCVgshSxKfuehKUM1XGOZMLpFUeDiHyudxek1ig5LNe3S/iMdd5d5r2P yfambTn2sLmn8ldsorYOSuxGWmVu3ckKNoq160TcPt1jCiesxI/9Bdtrd/jE8CDhlF+y wLRoVZYNf6LhYl53yj2rMXR6uncWEEV3rWiNZ2dsHplr86uH/aRK6ISWCV/sziWKfi9z D2lTVbvHSMvXpcUkgb30RLKXMrJAlaL1LhN0MVUsdpKHfAMuXUJ3id6jOUKekyeTH08z cfChKq+HnmIMk1FgaRRxnTiA1V469qnauhafunyedARI+tLSvD+J7Q38QwhNqEf3RRUs 1M4Q==
X-Gm-Message-State: ALyK8tIUJHOIBnSr4dWUj9Uk8J+UfpDfi0KB4OH1neuToCpabLR6A6rTbbdcDUuvd6N8VgErUVmJpT8OkY7yKg==
MIME-Version: 1.0
X-Received: by 10.36.33.1 with SMTP id e1mr4553213ita.37.1464020426968; Mon, 23 May 2016 09:20:26 -0700 (PDT)
Received: by 10.107.56.67 with HTTP; Mon, 23 May 2016 09:20:26 -0700 (PDT)
In-Reply-To: 
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>     <57432936.4080503@isi.edu> 
Date: Mon, 23 May 2016 09:20:26 -0700
Message-ID: 
From: Tom Herbert 
To: Brian Trammell 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "spud@ietf.org" , Joe Touch 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 16:20:33 -0000

On Mon, May 23, 2016 at 9:15 AM, Brian Trammell  wrote:
>
>> On 23 May 2016, at 18:00, Joe Touch  wrote:
>>
>>
>>
>> On 5/23/2016 6:44 AM, Brian Trammell wrote:
>>>> On 20 May 2016, at 18:03, Tom Herbert  wrote:
>>>> ...
>>>> DSCP is properly network-layer. If you believe in a "path layer" (which I'm pretty sure I do), you can argue that ECN is the first path layer protocol.
>>>>
>>>> I'm not sure what "path layer" is. Yes every packet takes some path,
>>>> but the Internet is packet-switched not circuit-switched, so not all
>>>> packets for a flow are required to always take the same path.
>>>> Maintaining flow state in intermediate nodes is only best effort. In
>>>> the presence of multi-homing and mobility intermediate devices that
>>>> track flow state will inevitably have it wrong. Anyone who has ever
>>>> tried to build a front-end L4 load balancer understands this problem
>>>> all too well :-)
>>> Your L4 load balancer is a path layer device.
>>
>> The only notion the Internet has of a path is a flow label.
>>
>> Transport IDs identify services and connections within an endpoint, and
>> are not universally available or meaningful except at the endpoints.
>>
>> All attempts by intermediate devices to rely on those identifiers makes
>> assumptions about visibility and correlation to desired shared-path
>> behavior that are baseless.
>
> But those intermediate devices *do indeed* route those packets based an N-tuple, where N is generally 5. One can ignore this fact and be surprised by what the network does, or resign oneself to it and leverage it.
>
If you're referring to ECMP that does not require state to be created
it operates fine being stateless. Stateful devices are not required to
route packets.

Tom


>> This is the key reason why MP-TCP is very badly misnamed. It is
>> multi-endpoint, not multipath, and always has been.
>
> You're quite right, but the current routing architecture gives us no way to influence paths except by choosing endpoints. And even then, we can know very little about how the endpoint identifiers map to paths.
>
> Cheers,
>
> Brian
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>


From nobody Mon May 23 10:17: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 5A2E912D0CC for ; Mon, 23 May 2016 10:17:07 -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 nbgi2IvWDbZR for ; Mon, 23 May 2016 10:17:03 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 389A712D107 for ; Mon, 23 May 2016 10:17:03 -0700 (PDT)
Received: by mail-ig0-x229.google.com with SMTP id l10so27870839igk.0 for ; Mon, 23 May 2016 10:17:03 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=d5nsPT+gX+AwA3k35OonXwwt3yXOlCHC1m9eiQuW6mI=; b=yPWysjgG8wveXhlxZDxViWtnJnWm1srTTIqqkz3HrebJlit+HLvGP2GpgKm5gZWGdJ /5SU30L0I4hHYmsZmeEPCkSGgHJsnPXp3cDFLDZzQAnLeRIU3MOo8K2AMd2XXHX/9BDg K/7ojgrGE1gIQoDXpNBE/vhDo4talDiCIzk0M3uiHu8+XZPZgGlPOjyyf7ZBtkKzr0/H pO02+Ki0M0xDpfV8h0YrB46+D5n0OxhdBPI2XCNbPf+HH/7pcxDqmTjJMqb7WsT4p/yX 84sF6v7HO9kjPwF1FsI3+5+nJCAmq6Qo1Qn/m9PX2yOzIXqQ29pPFDpNGtST0jKsVELA C4ZA==
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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=d5nsPT+gX+AwA3k35OonXwwt3yXOlCHC1m9eiQuW6mI=; b=anbumpG9Dg+1vjo2dv/NV4eZgx5PyA59HDuIUqlpU7/Ua+ucBkCre1zjpFq6UqKe6q nuWa38WHr+17Ct9GzI6jca5XOHVCvOfp97jSU7VpNaKD7L3PEfHSdnsevMVcoqcm+tt3 zK3/m9KPhhPRYJhDPgDCTxbg/PP+C81VAMwlFAbkWXLDWBJx/ZdP1OGaSnuk/msMQHpW fXnatX8x9AAjUdHB1v1ON0a65KEuAj4n5llop67bXZt1fStPhLbHRpp4HIhQWbgczyEf ckfyhBGeGMBibTFnNg4IB8YC6z9egvvY92NeGY2COVnAgq+ArRusn7mX3T0z/ScAfpLr +ldQ==
X-Gm-Message-State: AOPr4FW43xPjqH/ooYZbempYVAPTpQSHhMFOMuSWR1PfnDei6lctuIZLPzehpeOONFHba1zis8motEbce6W8/Q==
MIME-Version: 1.0
X-Received: by 10.50.13.106 with SMTP id g10mr14194042igc.65.1464023822437; Mon, 23 May 2016 10:17:02 -0700 (PDT)
Received: by 10.107.56.67 with HTTP; Mon, 23 May 2016 10:17:02 -0700 (PDT)
In-Reply-To: <677C2E5C-5EE6-49AD-B642-2577E3706F0F@tik.ee.ethz.ch>
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>     <677C2E5C-5EE6-49AD-B642-2577E3706F0F@tik.ee.ethz.ch>
Date: Mon, 23 May 2016 10:17:02 -0700
Message-ID: 
From: Tom Herbert 
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 , "spud@ietf.org" 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 23 May 2016 17:17:08 -0000

On Mon, May 23, 2016 at 7:33 AM, Mirja K=C3=BChlewind
 wrote:
> I don=E2=80=99t think we can deny the existence of stateful network work =
devices anymore. Even though your load balancer does not work (well), there=
 are other things such as firewall which need to keep state for a good reas=
on.
>
Mirja,

There was a great presentation in Buenos Aires on UDP usability
(https://www.ietf.org/proceedings/95/slides/slides-95-maprg-3.pdf).
Unless I'm reading it incorrectly, the conclusion is that UDP is
mostly usable on the Internet as is, stateful devices can already deal
with it even though UDP has no concept of explicit signaling for
connection creation/tear down. Also, judging from the comments from
network operators that block UDP, it seems they are more inclined to
assume all UDP is bad and I don't think we've seen any indication that
adding explicit state signaling would change that view.

I suppose it's a natural inclination to try to mimic TCP semantics
because of its pervasiveness, but if things already work well enough
then I don't see what problem it solves. The addition of such
signaling increases the complexity of the protocols, the networking
stack, network devices, and creates yet another opportunity for
ossification. So, yes, we can acknowledge firewalls and other stateful
devices do exist, but if existing protocols already work I'm not
seeing why we have to do anything differently.

Tom

> Mirja
>
>
>> Am 23.05.2016 um 15:44 schrieb Brian Trammell :
>>
>>> I'm not sure what "path layer" is. Yes every packet takes some path,
>>> but the Internet is packet-switched not circuit-switched, so not all
>>> packets for a flow are required to always take the same path.
>>> Maintaining flow state in intermediate nodes is only best effort. In
>>> the presence of multi-homing and mobility intermediate devices that
>>> track flow state will inevitably have it wrong. Anyone who has ever
>>> tried to build a front-end L4 load balancer understands this problem
>>> all too well :-)
>>
>> Your L4 load balancer is a path layer device. The fact that the architec=
ture (and operational practice built around it) don't work well with it is =
a consequence of the architecture ignoring the existence of path layer devi=
ces.
>


From nobody Mon May 23 18:00: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 DDB0512D0A5 for ; Mon, 23 May 2016 18:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7yMdE2xXgIeK for ; Mon, 23 May 2016 18:00:02 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 5D2C812DC0D for ; Mon, 23 May 2016 18:00:02 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6578322E253; Mon, 23 May 2016 20:59:57 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Tue, 24 May 2016 10:59:55 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <62F21423-3239-4696-BEE0-B86754AA299B@mnot.net>
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <94911BF5-C313-4816-896B-A90FA630EE5B@mnot.net> 
To: Brian Trammell 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "spud@ietf.org" 
Subject: Re: [Spud] Possible WG-forming follow-on to SPUD 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: Tue, 24 May 2016 01:00:05 -0000

Hi Brian,

>> * In the proposed approach, will it be possible for a network =
operator to use PLUS mechanisms to insert arbitrary metadata (e.g., a =
user identifier) in the server-bound stream of a client-server protocol? =
=20
>=20
> Short answer: No.
>=20
> Detailed answer: The "under endpoint control" language in the spud-req =
and PLUS charters is meant to describe something like the following:
>=20
> A sending endpoint (here, the client) controls the type and content of =
information exposed to the path (as TLV, CBOR, whatever; conceptually, =
it's a key-value mapping). Each of the keys in this mapping has a =
meaning. Some of the keys are "application-to-path" keys, and are set by =
the sender and protected by a MAC using a secret derived from the =
superstrate session key. Some of the keys are "path-to-application" =
keys, or requests for information from the path to be sent to the far =
endpoint (which can then echo them back, encrypted, in a subsequent =
packet). These are set by the sender to a fixed-length array of 0x00 =
bytes, to be filled in by anything along the path which understands =
them. The presence of the key and the length of its data are protected =
by the MAC, but *not* the content.=20
>=20
> In this case, if everyone is following the protocol, the client has to =
create a key ("path-to-application-user-id") to let the access network =
put its user ID in it. As Mirja points out, I doubt that an IETF =
following a restrictive key allocation policy would standardize such a =
thing, given BCP 188. And if so, a client could simply fail to create =
this key, and there would be no space in the PLUS header for the user =
ID. (To answer your what I suspect your next question would be, "what if =
the access network requires me to put the user ID path-to-app key in my =
packets", see the answer to the questions below).=20

That sounds good, as long as something (ideally, a forwarding node, but =
at least the receiving endpoint) breaks in a fairly ugly fashion when =
the MAC isn't correct. This needs to be specified behaviour, and =
actually implemented by at least a sizeable population, so that it =
sticks.

Question: is application-to-path information exposed to the other =
endpoint, and if so, is its delivery there guaranteed by the protocol?=20=


In other words, if my phone inserts metadata to the path, can the Web =
site on the other end reliably detect its presence?

=46rom your answer below, it sounds like that's the case, just wanted to =
be sure.


> Of course, MUSTS and SHOULDS are nice, but what if an access network =
gateway abuses the header? Two possibilities here: it could co-opt an =
existing path-to-application key, or wedge new information into the =
header underneath the MTU and tear it back off. In the first case, a =
complicit server endpoint wouldn't even have to ignore a MAC failure, =
and could echo back 0, signifying "nobody on path understood this". =
(There might be ways to put a nonce here to defend against this, but I'm =
not sure what the details would look like). One way to prevent this =
being used for large identifier spaces would be to make most such =
accumulators use only a few bits, and most of the ones we're thinking of =
(delay accumulators, path MTU) have this property.

That sounds like the start of text for security considerations + =
registry requirements...


> The second case isn't really any different from today: any endpoint =
can stick a shim header between TCP and the (TLS-protected) payload if =
it knows something on the far end will rip it off, given room under the =
path MTU. And if there's no room under the path MTU, then you can't =
steal bits from PLUS either. Indeed, if PLUS makes good use of PLPMTUD, =
or supported explicit PMTU in a future with PLUS-enabled routers, then =
the amount of space available for such shenanigans could be reduced. =
There are also countless out-of-band ways to associate user IDs with =
flow identifiers that PLUS can't do anything about, either.

*nod*


>> * In the proposed approach, will it be possible for a network =
operator to require a client to insert a particular kind of metadata =
into a stream, e.g., to gain network access?
>>=20
>> * In the proposed approach, will it be possible for a network to =
offer a different quality of service to servers that insert specific =
metadata into their streams (thereby affecting network neutrality)?
>=20
> I think these are two different shades of the same threat: "tell me =
something I want to hear, or I drop your packets", "tell me something I =
want to hear, or I'll give you crap service", where "something I want to =
hear" is either some secret verifying you've done something the operator =
wants you to do (paid money, watched an ad) or information about the =
traffic the operator could independently verify but doesn't want to have =
to (otherwise, you could just lie).
>=20
> Short answer: I do not think it is possible to prevent this kind of =
behavior, even in the current architecture, because it isn't really a =
technical problem. But it would be possible with PLUS to make it =
transparent (which is the reason I don't see PLUS as enabling this =
behavior).
>=20
> Long answer: Here, the threat is above layer 7: the application is =
"forced" to hand over a token in order to get connectivity of acceptable =
performance. This token might represent information that could currently =
be taken through DPI, but can't when that information is protected via =
TLS.=20
>=20
> Sadly, I can see no technical solution to this problem at all. An =
operator could today force an to place information in bits under its =
control (IPv6 source and destination address, flow label; TCP source =
port) for such a thing, or leverage the relative ease of five-tuple =
routing plus the ease of standing up HTTPS servers in random bits of the =
cloud to use out-of-band mechanisms ("give me your token and your =
five-tuple via a TLS-protected API with a server somewhere on a CDN =
network that you can't easily tell is Your Friendly Local ISP, and you =
get to ride in the fast lane.") So assuming such a mechanism is deployed =
without standardization, at least the presence of the keys in the PLUS =
header would make this behavior visible to *everyone* on the network. =
That alone is IMO a reason it wouldn't be deployed in this way -- the =
relatively vigorous opposition to this kind of thing from customers who =
care means operators would rather hide it.

I don't disagree on any particular point. What concerns me are =
situations where people are asked to install a particular piece of =
software, or configure their machines a particular way, to be able to =
access the Internet; it's already a problem with things like browser =
extensions and CA certs, and adding more surface area doesn't seem like =
a good direction to go in.

Thanks!

--
Mark Nottingham   https://www.mnot.net/


From nobody Tue May 24 00:36: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 7BDFA12D137 for ; Tue, 24 May 2016 00:36:20 -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 Vq1W0gxaUblK for ; Tue, 24 May 2016 00:36:18 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id B6E3512D531 for ; Tue, 24 May 2016 00:36:17 -0700 (PDT)
Received: from [IPv6:2001:67c:64:42:552e:8a9f:18db:58c6] (unknown [IPv6:2001:67c:64:42:552e:8a9f:18db:58c6]) by trammell.ch (Postfix) with ESMTPSA id 0C9F71A1438; Tue, 24 May 2016 09:35:46 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_73871886-7758-42C7-A769-6DC16EDFEB42"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell 
In-Reply-To: <62F21423-3239-4696-BEE0-B86754AA299B@mnot.net>
Date: Tue, 24 May 2016 09:35:43 +0200
Message-Id: 
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <94911BF5-C313-4816-896B-A90FA630EE5B@mnot.net>  <62F21423-3239-4696-BEE0-B86754AA299B@mnot.net>
To: Mark Nottingham 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "spud@ietf.org" 
Subject: Re: [Spud] Possible WG-forming follow-on to SPUD 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: Tue, 24 May 2016 07:36:20 -0000

--Apple-Mail=_73871886-7758-42C7-A769-6DC16EDFEB42
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 24 May 2016, at 02:59, Mark Nottingham  wrote:
>=20
> Hi Brian,
>=20
>>> * In the proposed approach, will it be possible for a network =
operator to use PLUS mechanisms to insert arbitrary metadata (e.g., a =
user identifier) in the server-bound stream of a client-server protocol?
>>=20
>> Short answer: No.
>>=20
>> Detailed answer: The "under endpoint control" language in the =
spud-req and PLUS charters is meant to describe something like the =
following:
>>=20
>> A sending endpoint (here, the client) controls the type and content =
of information exposed to the path (as TLV, CBOR, whatever; =
conceptually, it's a key-value mapping). Each of the keys in this =
mapping has a meaning. Some of the keys are "application-to-path" keys, =
and are set by the sender and protected by a MAC using a secret derived =
from the superstrate session key. Some of the keys are =
"path-to-application" keys, or requests for information from the path to =
be sent to the far endpoint (which can then echo them back, encrypted, =
in a subsequent packet). These are set by the sender to a fixed-length =
array of 0x00 bytes, to be filled in by anything along the path which =
understands them. The presence of the key and the length of its data are =
protected by the MAC, but *not* the content.
>>=20
>> In this case, if everyone is following the protocol, the client has =
to create a key ("path-to-application-user-id") to let the access =
network put its user ID in it. As Mirja points out, I doubt that an IETF =
following a restrictive key allocation policy would standardize such a =
thing, given BCP 188. And if so, a client could simply fail to create =
this key, and there would be no space in the PLUS header for the user =
ID. (To answer your what I suspect your next question would be, "what if =
the access network requires me to put the user ID path-to-app key in my =
packets", see the answer to the questions below).
>=20
> That sounds good, as long as something (ideally, a forwarding node, =
but at least the receiving endpoint)

Receiving endpoint is trivially easy. Forwarding node is more difficult =
and requires more overhead, but possible. But I think the details of =
this requirement and the specification are IMO post-BoF work.

> breaks in a fairly ugly fashion when the MAC isn't correct.

Yep, this would be a rage quit: regardless of whether a forwarding node =
assists in detection, the PLUS layer on the receiving endpoint tells the =
superstrate transport that the association is hard reset.

> This needs to be specified behaviour, and actually implemented by at =
least a sizeable population, so that it sticks.

Agree completely.

>=20
> Question: is application-to-path information exposed to the other =
endpoint, and if so, is its delivery there guaranteed by the protocol?

Yes, with a caveat on "guaranteed": if the packet gets delivered to the =
other endpoint (subject to the reliability requirements and mechanisms =
of the superstrate), then *all* the information

One major change in our thinking from what's in the SPUD prototype, =
which came from experience with it, is that a2p and p2a data aren't =
really all that different from an API standpoint. There's simply =
information bound to a tube whose content is integrity protected, and =
which on-path devices must not modify or drop, and information bound to =
a tube whose presence and length are integrity protected, and which =
on-path devices may modify. This is a property of the information =
element's identifier, and the identifier itself is probably encoded in a =
way that the integrity code and easily generate and verify MACs without =
doing a bunch of registry lookups. The sending endpoint has complete =
control over the information elements it sends and their content, and =
the receiving endpoint has access to all of them.

(There's an API requirement hiding in there.)

> In other words, if my phone inserts metadata to the path, can the Web =
site on the other end reliably detect its presence?

In the absence of misbehavior of the second case, below, yes.

> =46rom your answer below, it sounds like that's the case, just wanted =
to be sure.
>=20
>=20
>> Of course, MUSTS and SHOULDS are nice, but what if an access network =
gateway abuses the header? Two possibilities here: it could co-opt an =
existing path-to-application key, or wedge new information into the =
header underneath the MTU and tear it back off. In the first case, a =
complicit server endpoint wouldn't even have to ignore a MAC failure, =
and could echo back 0, signifying "nobody on path understood this". =
(There might be ways to put a nonce here to defend against this, but I'm =
not sure what the details would look like). One way to prevent this =
being used for large identifier spaces would be to make most such =
accumulators use only a few bits, and most of the ones we're thinking of =
(delay accumulators, path MTU) have this property.
>=20
> That sounds like the start of text for security considerations + =
registry requirements...

yep. thanks for asking the question. :)

>=20
>> The second case isn't really any different from today: any endpoint =
can stick a shim header between TCP and the (TLS-protected) payload if =
it knows something on the far end will rip it off, given room under the =
path MTU. And if there's no room under the path MTU, then you can't =
steal bits from PLUS either. Indeed, if PLUS makes good use of PLPMTUD, =
or supported explicit PMTU in a future with PLUS-enabled routers, then =
the amount of space available for such shenanigans could be reduced. =
There are also countless out-of-band ways to associate user IDs with =
flow identifiers that PLUS can't do anything about, either.
>=20
> *nod*
>=20
>=20
>>> * In the proposed approach, will it be possible for a network =
operator to require a client to insert a particular kind of metadata =
into a stream, e.g., to gain network access?
>>>=20
>>> * In the proposed approach, will it be possible for a network to =
offer a different quality of service to servers that insert specific =
metadata into their streams (thereby affecting network neutrality)?
>>=20
>> I think these are two different shades of the same threat: "tell me =
something I want to hear, or I drop your packets", "tell me something I =
want to hear, or I'll give you crap service", where "something I want to =
hear" is either some secret verifying you've done something the operator =
wants you to do (paid money, watched an ad) or information about the =
traffic the operator could independently verify but doesn't want to have =
to (otherwise, you could just lie).
>>=20
>> Short answer: I do not think it is possible to prevent this kind of =
behavior, even in the current architecture, because it isn't really a =
technical problem. But it would be possible with PLUS to make it =
transparent (which is the reason I don't see PLUS as enabling this =
behavior).
>>=20
>> Long answer: Here, the threat is above layer 7: the application is =
"forced" to hand over a token in order to get connectivity of acceptable =
performance. This token might represent information that could currently =
be taken through DPI, but can't when that information is protected via =
TLS.
>>=20
>> Sadly, I can see no technical solution to this problem at all. An =
operator could today force an to place information in bits under its =
control (IPv6 source and destination address, flow label; TCP source =
port) for such a thing, or leverage the relative ease of five-tuple =
routing plus the ease of standing up HTTPS servers in random bits of the =
cloud to use out-of-band mechanisms ("give me your token and your =
five-tuple via a TLS-protected API with a server somewhere on a CDN =
network that you can't easily tell is Your Friendly Local ISP, and you =
get to ride in the fast lane.") So assuming such a mechanism is deployed =
without standardization, at least the presence of the keys in the PLUS =
header would make this behavior visible to *everyone* on the network. =
That alone is IMO a reason it wouldn't be deployed in this way -- the =
relatively vigorous opposition to this kind of thing from customers who =
care means operators would rather hide it.
>=20
> I don't disagree on any particular point. What concerns me are =
situations where people are asked to install a particular piece of =
software, or configure their machines a particular way, to be able to =
access the Internet; it's already a problem with things like browser =
extensions and CA certs, and adding more surface area doesn't seem like =
a good direction to go in.

I share this concern. I think we have different estimations of how much =
additional surface area PLUS practically presents.

Thanks, cheers,

Brian

>=20
> Thanks!
>=20
> --
> Mark Nottingham   https://www.mnot.net/
>=20
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud


--Apple-Mail=_73871886-7758-42C7-A769-6DC16EDFEB42
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

iQIcBAEBCgAGBQJXRARQAAoJEIoSt78L6kaju8sP/0Ifgd9493818yi3v9fJBgWb
XvVRDrIfdV86NAogeJPYcwBnGjHY3j7l4xMpBnxYhzI0p8TztvUKvPUoVQWRRlJy
vxtPV7pKoYwVDJPm4nhZkcv/MRD5z7n+2iNIMybsOTBd99nnL5lLg/B9FwEIygBD
7K38giF1uSkLO/m1tHzK6Wxg1BGAovOJDcoHmuU8kS0Jchl03LVrJ01Wa2E4ceq4
JBbH3xQ1IRhNSpAYif4sYFB68mFlyTwm5fbuGvj8ae3UjNUNRx3wiZrT7bmVOCao
MNSgo8SKsP0RYWoj5HO23hrJqx+Ng8efg/2oz3rqEGuj0nmBv/kfNGBkgi7K7u0S
HeoeS1jOG2JG6tOAq5X/7kVDMsadbk5MaooZdSOukSHQxIJMNZ1nUWAJbIhTMe65
v0ZS3QsENTygvia5IlGTx9KvmLl4QdVCej7KUgG9VEC3qyeHrnpqW/5MWfG9R9NE
r2BIM4OdhvGhj5n7Xitw+psJkYOjZasruGDSJrD38QzWbRgG/d+uiYJ/fIF1Nj1w
i1HjTMrPdGRkGyz7S4wJn19YqbesEvrwwDSMONw9HLUQB61Cd1n9pWpWMIu489Fm
u+fDj2qkwz57UFXMt/Y/GhCnj2+YYi72Ebkm8zrSY24+9D8Xi4PoCP1FZurRjA4q
xK95YxAPebOlrc2yBKxi
=DGkl
-----END PGP SIGNATURE-----

--Apple-Mail=_73871886-7758-42C7-A769-6DC16EDFEB42--


From nobody Tue May 24 00:40: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 A07E012D901 for ; Tue, 24 May 2016 00:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 C4PV--ZXin19 for ; Tue, 24 May 2016 00:40:44 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 583C212DC84 for ; Tue, 24 May 2016 00:40:30 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A1F2422E1FA; Tue, 24 May 2016 03:40:28 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Tue, 24 May 2016 17:40:25 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D8EE3FC-54E5-4045-86A2-75C7FB3310CD@mnot.net>
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <20160519182701.GL12994@cisco.com> <655C07320163294895BBADA28372AF5D4885D2CB@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <94911BF5-C313-4816-896B-A90FA630EE5B@mnot.net>  <62F21423-3239-4696-BEE0-B86754AA299B@mnot.net> 
To: Brian Trammell 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "spud@ietf.org" 
Subject: Re: [Spud] Possible WG-forming follow-on to SPUD 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: Tue, 24 May 2016 07:40:46 -0000

> On 24 May 2016, at 5:35 PM, Brian Trammell  wrote:
>=20
> I share this concern. I think we have different estimations of how =
much additional surface area PLUS practically presents.

I don't have an estimation yet. :)

Thanks for taking the time to give detailed answers!

Cheers,

--
Mark Nottingham   https://www.mnot.net/


From nobody Tue May 24 00:57: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 2658A12D137 for ; Tue, 24 May 2016 00:57:56 -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 kJKikj11HzA8 for ; Tue, 24 May 2016 00:57:54 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 10CEB12D107 for ; Tue, 24 May 2016 00:57:54 -0700 (PDT)
Received: from [IPv6:2001:67c:64:42:552e:8a9f:18db:58c6] (unknown [IPv6:2001:67c:64:42:552e:8a9f:18db:58c6]) by trammell.ch (Postfix) with ESMTPSA id 427421A153B; Tue, 24 May 2016 09:57:23 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_882227F5-2E37-4543-B2F0-A9F122756A19"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell 
In-Reply-To: 
Date: Tue, 24 May 2016 09:57:22 +0200
Message-Id: <2F492BAF-908C-45BD-B7B8-32701AA2CB41@trammell.ch>
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>     <677C2E5C-5EE6-49AD-B642-2577E3706F0F@tik.ee.ethz.ch> 
To: Tom Herbert 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , "spud@ietf.org" 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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: Tue, 24 May 2016 07:57:56 -0000

--Apple-Mail=_882227F5-2E37-4543-B2F0-A9F122756A19
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

hi Tom,

> On 23 May 2016, at 19:17, Tom Herbert  wrote:
>=20
> On Mon, May 23, 2016 at 7:33 AM, Mirja K=C3=BChlewind
>  wrote:
>> I don=E2=80=99t think we can deny the existence of stateful network =
work devices anymore. Even though your load balancer does not work =
(well), there are other things such as firewall which need to keep state =
for a good reason.
>>=20
> Mirja,
>=20
> There was a great presentation in Buenos Aires on UDP usability
> (https://www.ietf.org/proceedings/95/slides/slides-95-maprg-3.pdf).
> Unless I'm reading it incorrectly, the conclusion is that UDP is
> mostly usable on the Internet as is, stateful devices can already deal
> with it even though UDP has no concept of explicit signaling for
> connection creation/tear down.

Speaking as the presenter of that talk, this wasn't what we measured. =
Abusing UDP traceroute on the RIPE Atlas probes supports only a basic =
connectivity test - "does the first packet make it through, and how much =
slower/faster is it than TCP?" is the question we asked.

Measuring the state timeout spectrum, and differences for UDP and TCP, =
is near-future work. It's not something we can leverage Atlas for, so =
getting access to a whole lot of access networks will be hard. We =
presume that it's still a problem.

> Also, judging from the comments from
> network operators that block UDP, it seems they are more inclined to
> assume all UDP is bad and I don't think we've seen any indication that
> adding explicit state signaling would change that view.

Adding explicit state signaling won't change that view. Adding =
productive, well-behaved, congestion-controlled traffic with an IP =
protocol number of 17 to the Internet (i.e. QUIC, PLUS, WebRTC) will.

"Block/rate limit UDP" is not, as far as I can tell, a universally =
accepted and applied policy in the Internet. Gaming, for instance, seems =
to work in the Internet. Networks that don't have a lot of gamers on =
them (enterprises, mobiles in many markets) can afford to use heuristics =
to limit harmful UDP traffic. Other networks can't, unless they want all =
their gamers to go find other providers.

> I suppose it's a natural inclination to try to mimic TCP semantics
> because of its pervasiveness, but if things already work well enough
> then I don't see what problem it solves. The addition of such
> signaling increases the complexity of the protocols, the networking
> stack, network devices, and creates yet another opportunity for
> ossification. So, yes, we can acknowledge firewalls and other stateful
> devices do exist, but if existing protocols already work I'm not
> seeing why we have to do anything differently.

If it just works, I agree. I don't think that's the case, though. Data, =
hopefully, to follow.

Cheers,

Brian

>=20
> Tom
>=20
>> Mirja
>>=20
>>=20
>>> Am 23.05.2016 um 15:44 schrieb Brian Trammell :
>>>=20
>>>> I'm not sure what "path layer" is. Yes every packet takes some =
path,
>>>> but the Internet is packet-switched not circuit-switched, so not =
all
>>>> packets for a flow are required to always take the same path.
>>>> Maintaining flow state in intermediate nodes is only best effort. =
In
>>>> the presence of multi-homing and mobility intermediate devices that
>>>> track flow state will inevitably have it wrong. Anyone who has ever
>>>> tried to build a front-end L4 load balancer understands this =
problem
>>>> all too well :-)
>>>=20
>>> Your L4 load balancer is a path layer device. The fact that the =
architecture (and operational practice built around it) don't work well =
with it is a consequence of the architecture ignoring the existence of =
path layer devices.
>>=20


--Apple-Mail=_882227F5-2E37-4543-B2F0-A9F122756A19
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

iQIcBAEBCgAGBQJXRAliAAoJEIoSt78L6kajRMcQAJKt3UkiIm4O/4Gbb85+HLFP
8wnXWwN8i8mcTkkmMbOcFhpr60kgL/pJg8im3uu2N+NNN4950IQs71e0NBhoTdXY
G/XJIgBh6GAuf7sg+Pl9QU3WQLSyl0KZ4M4rVqx1PAUhK0kbeWqxhybSOKZqmJwp
jfpm9wROOugpLZt5jARbg4Fc0YrMZTVSfkXDyVPUjNmo158akdfNtLHhrEYCjcbh
28/rEYRPAT8qkXB7m4Pl11ArYqxNqNn2I+6hjPCJ69jwC7L5nAe+Q5QI7hCuh1EN
1fI/rd4jVguy2GpcNW2MxFC1hWaOds5q0Vl45u1h+ekX7k4WXqot2Ge1LxmrEBp2
j4HLnPV7lv4pQejFiHPRYt7TSbtEWMhQG2KWGu88AILT58j05a0KybrLV06+VrKv
qULSQ68YmhiWZsdlU/yNkcQWg2ul1wlL+ha5dN+U3jzaXHqRAub+OSOQdeCyEuCK
5IWQ9AXBpv6yCCQLxkBZNoGOPk1V3HmiMpjxS/lkXgirm8u4e/ql5xCxMw99YJ2H
BlT43JsVJkXshFrWPXunq/GiaUgTSK5pl8Jtfvx5efjsSMmsVIYuzfwI89z6ig9E
+H1HsIjjOgwhYo4ib4fTB27GEKWGbgtkKtX3L6hlay2Woz5tL2mPmOVj356+hqv9
IAw7AFZCsmXceHeGVRrc
=wEij
-----END PGP SIGNATURE-----

--Apple-Mail=_882227F5-2E37-4543-B2F0-A9F122756A19--


From nobody Tue May 24 01:13: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 4EDEB12DB69 for ; Tue, 24 May 2016 01:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 ZjXecpQtKSQ4 for ; Tue, 24 May 2016 01:13:33 -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 5CE7912D137 for ; Tue, 24 May 2016 01:13:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 92945D9304; Tue, 24 May 2016 10:13:31 +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 pfDgH9KPNIGO; Tue, 24 May 2016 10:13:31 +0200 (MEST)
Received: from [172.30.172.138] (unknown [91.143.127.69]) (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 36F35D9303; Tue, 24 May 2016 10:13:31 +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: <2F492BAF-908C-45BD-B7B8-32701AA2CB41@trammell.ch>
Date: Tue, 24 May 2016 10:13:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B12E853-F164-46A9-BB1E-754DC969D07F@tik.ee.ethz.ch>
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>     <677C2E5C-5EE6-49AD-B642-2577E3706F0F@tik.ee.ethz.ch>  <2F492BAF-908C-45BD-B7B8-32701AA2CB41@trammell.ch>
To: Tom Herbert 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Brian Trammell , "spud@ietf.org" 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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: Tue, 24 May 2016 08:13:35 -0000

Hi Tom,

> Am 24.05.2016 um 09:57 schrieb Brian Trammell :
>=20
>> I suppose it's a natural inclination to try to mimic TCP semantics
>> because of its pervasiveness, but if things already work well enough
>> then I don't see what problem it solves. The addition of such
>> signaling increases the complexity of the protocols, the networking
>> stack, network devices, and creates yet another opportunity for
>> ossification.

The problem is it only works for what we have right now. It works less =
well for new things which is a pity=E2=80=A6 it=E2=80=99s ossified. Yes, =
adding more stuff will make it more complex; I guess that=E2=80=99s a =
general case but I don=E2=80=99t think is an argument to stop trying to =
solve the problem. And also yes, it might get ossified again, but if we =
do it right this time, I want it to get ossified and settle as a common =
base for new protocols to get (more quickly and at all) deployed.

Mirja




From nobody Tue May 24 01:45: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 9AA4A12D1B9 for ; Tue, 24 May 2016 01:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 VTlaQtIjiiPi for ; Tue, 24 May 2016 01:44: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 9909612D09D for ; Tue, 24 May 2016 01:44:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 52010D930B; Tue, 24 May 2016 10:44: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 DEZCvmD8HV1u; Tue, 24 May 2016 10:44:55 +0200 (MEST)
Received: from [172.30.172.138] (unknown [91.143.127.69]) (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 E65CCD9309; Tue, 24 May 2016 10:44: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: <20160523155027.GG15064@cisco.com>
Date: Tue, 24 May 2016 10:44:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160523134348.GB15064@cisco.com>  <20160523150141.GE15064@cisco.com> <0FA26CD2-BB4A-47AA-A85F-2DE52315E372@trammell.ch> <20160523155027.GG15064@cisco.com>
To: Toerless Eckert 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Brian Trammell , "spud@ietf.org" 
Subject: Re: [Spud] What middleboxes are allowed to know (Re: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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: Tue, 24 May 2016 08:44:59 -0000

Two comments inline.

> Am 23.05.2016 um 17:50 schrieb Toerless Eckert :
>=20
> On Mon, May 23, 2016 at 05:34:24PM +0200, Brian Trammell wrote:
>>> It would really help to get an example of how PLUS would help to get =
encrypted traffic better
>>> through firewall middleboxes. If that goal is out of the window for =
PLUS lets be very clear with
>>> it, because i think this was the starting point of SPUD.
>>=20
>> Ah. Here the answer is simple: by encrypting the transport headers =
(necessary to deossify), you take away the SYN/SYNACK/FIN/RST for flow =
state management, and you can give it back in a transport-neutral way =
with PLUS. Together with UDP port number based rules, and you preserve =
the status quo while getting to deploy new transports. This =
functionality wasn't meant to make firewalls work better than they do =
today, it was meant to keep from breaking them once the transport =
headers are encrypted.
>=20
> Ok. That type of explnaation should really be in the charter text =
because that makes a
> lot of things a lot clearer. And provides the best reason why we'd =
want to encrypt the
> transport headers. because none of the other explanations for =
encrypting transport headrs
> that we regurgitated in the last few days made sense to me.

That=E2=80=99s our primary use case in draft-kuehlewind-spud-use-cases. =
We thought about spelling it out in the charter but didn=E2=80=99t to =
keep the charter short and at the point. This argument didn=E2=80=99t =
come up early in the discussion because we were assuming that people =
already have this simple first step in mind. Maybe we should add a short =
note in the charter=E2=80=A6

>=20
>>> Simple unauthenticated app-ids are of course even less trustworthy =
than TCP ports, so they
>>> won't help with firewalls. They would help to do better statistics =
of course. DPI is often done
>>> together with netflow just for statistics gathering in enterprises, =
no firewalls involved.
>>=20
>> ...as long as you don't actually need those statistics for anything =
other than drawing pretty graphs on the wall in the NOC, this is fine. =
If you're a content network, you can pretty much trust yourself not to =
lie. Of course, your customers might not appreciate you tagging their =
encrypted traffic... so there are tradeoffs.
>=20
> Yes, the problem is when you would leak this information to the =
internet because it will have
> more information than you may want to signal further.
>=20
>>> For the firewalls, i think we need authenticated/secure app-id: =
AFAIK, every apple/google store binary
>>> has some authenticity elements. It's not hard to image how every =
such app binary could have a cert from the store
>>> or app-vendor, and the PLUS signaling is a proof of posession of the =
Cert, so that the middlebox
>>> can authenticate it. Encrypt the proof of posession so that you're =
not exposing your app-id to anyone
>>> by your own enterprise firewall, and IMHO we'd have something highly =
valuable. Yes, too large to fit into
>>> a PLUS header alone, would require to be part of PLUS session setup =
packets.
>>>=20
>>> Of course, such a model has a tail of more security implications =
like: firewall needs to be able to
>>> vet that the endpoint signaling PLUS can be trusted, eg: is =
administered by the enterprise IT department,
>>> so that apps started on it are assumed not to be hacked.
>>=20
>> This cuts both ways, of course; as soon as you have an architecture =
in which you have an encrypted in-band side channel to a firewall on =
path, you also need to be *very, very* careful that the thing you have =
the encrypted in-band side channel to is actually the firewall you think =
you should (or, rather, according to organization policy, must) trust.
>=20
> Sure, thats why i said to encrypt it, so only your orgs firewalls can =
decrypt it.
>=20
>>> And in such an environment it certainly
>>> is necessary to do the PLUS signaling from the OS level etc. pp.
>>=20
>> I'd note that is in direct conflict with the requirement to support =
application deployability of the PLUS shim, so... I don't see this use =
case coexisting well with a PLUS stack "under application control".
>=20
> Well, in my order of priorities, application level implementability is =
top. Its
> just that if i read Mirjams responses you folks don't feel too happy =
about giving
> it its rightfull place in the charter.

Just want to say that I support this goal and I=E2=80=99m pretty sure =
that we can support it with what every we get to with PLUS. However, I =
guess I agree with Joe that this goal should not primarily drive our =
architecture and therefore it simply does not belong in the charter for =
me. It=E2=80=99s in the requirements doc, section 7.3 =
(draft-trammels-spud-req).

Mirja


> And with opposition by folks like Joe that
> we can't define protocol stacks to make our stuff more implementable, =
because
> "it breaks the Internet", i have an idea why you don't want to, =
although i'll certainly
> would like to continue trying to persuade folks of the necessity.
>=20
> Wrt to "OS" - If you "apps" are running in a browser, then the "OS" =
would actually be
> the browser. You just need some trust-anchor on the client-device that =
can guarantee
> you that an application sending authnticated identity can not fake who =
it is.
>=20
> Cheers
>   Toerless
>>=20
>> Cheers,
>>=20
>> Brian
>>=20
>>> Cheer
>>>   Toerless
>>>=20
>>>> Cheers,
>>>>=20
>>>> Brian
>>>>=20
>>>>>=20
>>>>>=20
>>>>>>> What i really want to see is this:
>>>>>>>=20
>>>>>>> - Allow the application to learn from the network devices what =
information
>>>>>>> it must present in the clear to have its traffic be passed =
through
>>>>>>> and/or receive additional treatment by the network.
>>>>>>>=20
>>>>>>> Aka: "Security guard: Sure, you can go through this door if you =
show me your  else not"
>>>>>>>=20
>>>>>>> Then the app can decide if it wants to show . =
Otherwise the
>>>>>>> apps have to operate like corporate drones, carrying around =
their corp-ID
>>>>>>> in the open all the time hoping that thats the right credential.
>>>>>>>=20
>>>>>>> Or to rephrase: if we do not even attempt to overcome TCP port =
numbers as
>>>>>>> credentials then we're lame and will not be successful.
>>>>>>=20
>>>>>> Okay??? I first of all have to simply say no here. I don???t want =
the middleboxes to require anything here, because why would a middlebox =
not just say ???either you show me all you content in plain or I don???t =
transport you data???. I believe that???s something we all don???t want =
and building a mechanism that could lead to this, it the last thing I =
want. I know what you intention is here, but we have to be more than =
careful here and the way you???ve just phrased it, I can just disagree. =
However, I would propose to have this discussion in a separate thread.
>>>>>=20
>>>>> _______________________________________________
>>>>> Spud mailing list
>>>>> Spud@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/spud
>>>>=20
>>>=20
>>>=20
>>>=20
>>>> _______________________________________________
>>>> Spud mailing list
>>>> Spud@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/spud
>>>=20
>>>=20
>>> --
>>> ---
>>> Toerless Eckert, eckert@cisco.com
>>>=20
>>> _______________________________________________
>>> Spud mailing list
>>> Spud@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spud
>>=20
>=20
>=20
>=20
> --=20
> ---
> Toerless Eckert, eckert@cisco.com


From nobody Tue May 24 01:47: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 AB4FF12D0BA for ; Tue, 24 May 2016 01:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 a5JieQ8Qm78h for ; Tue, 24 May 2016 01:47:33 -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 9C95712D09D for ; Tue, 24 May 2016 01:47:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4B3C7D930B; Tue, 24 May 2016 10:47:32 +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 N3bEwukww8Wm; Tue, 24 May 2016 10:47:32 +0200 (MEST)
Received: from [172.30.172.138] (unknown [91.143.127.69]) (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 2D1E8D9304; Tue, 24 May 2016 10:47:31 +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: Tue, 24 May 2016 10:47:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <888B9681-9466-4B78-A3D5-CC2EAF5EE64C@tik.ee.ethz.ch>
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>     
To: Tom Herbert 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Brian Trammell , "Scharf, Michael \(Nokia - DE\)" , "spud@ietf.org" 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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: Tue, 24 May 2016 08:47:35 -0000

One quick comment below.

> Am 23.05.2016 um 18:09 schrieb Tom Herbert :
>=20
> On Mon, May 23, 2016 at 6:44 AM, Brian Trammell  =
wrote:
>>=20
>>> On 20 May 2016, at 18:03, Tom Herbert  wrote:
>>>=20
>>> On Fri, May 20, 2016 at 3:08 AM, Brian Trammell  =
wrote:
>>>> hi Tom,
>>>>=20
>>>>> On 19 May 2016, at 19:50, Tom Herbert  wrote:
>>>>>=20
>>>>> On Thu, May 19, 2016 at 10:12 AM, Scharf, Michael (Nokia - DE)
>>>>>  wrote:
>>>>>> Does the sentence ...
>>>>>>=20
>>>>>> The current Internet protocol stack has no layer for explicit =
signaling of flow semantics and characteristics to network elements ...
>>>>>>=20
>>>>>> actually wants to say something like
>>>>>>=20
>>>>>> The current Internet protocol stack has no layer for explicit =
*in-band* signaling of flow semantics and characteristics ... ?
>>>>>>=20
>>>>>> I may be wrong, but there is no shortage of IETF and non-IETF =
protocols that can signal flow semantics and characteristics =
out-of-band, either path-coupled or path-decoupled, e.g., in the control =
or management plane. As a result, there are protocol "layers" for that =
signaling, but they are not in-band. There may also be other ways to fix =
this problem (e.g., by adding "end-to-end" or "inter-domain" instead of =
"in-band").
>>>>>>=20
>>>>> Not to mention that TOS and diff-serv are in-band signaling =
mechanisms
>>>>> to the network, ECN is explicitly signaling from the network.
>>>>=20
>>>> DSCP is properly network-layer. If you believe in a "path layer" =
(which I'm pretty sure I do), you can argue that ECN is the first path =
layer protocol.
>>>>=20
>>> I'm not sure what "path layer" is. Yes every packet takes some path,
>>> but the Internet is packet-switched not circuit-switched, so not all
>>> packets for a flow are required to always take the same path.
>>> Maintaining flow state in intermediate nodes is only best effort. In
>>> the presence of multi-homing and mobility intermediate devices that
>>> track flow state will inevitably have it wrong. Anyone who has ever
>>> tried to build a front-end L4 load balancer understands this problem
>>> all too well :-)
>>=20
>> Your L4 load balancer is a path layer device. The fact that the =
architecture (and operational practice built around it) don't work well =
with it is a consequence of the architecture ignoring the existence of =
path layer devices.
>>=20
>=20
> But the architecture here is that of the Internet which is inherently
> packet-switched not circuit switched. I don't see how "path layer"
> fits into that architecture, and we can't change the core Internet
> protocols to accommodate it. Any intermediate device that creates
> state presumes that flows follow a persistent and invariant path will
> eventually, at some point, be wrong about the state. This is why
> signaling connection state can only ever be considered best effort, in
> the network we cannot operational rely on it to always be available or
> correct. For instance, consider in PLUS a FIN is defined for end of
> flow. Now suppose that some connection followed five different paths
> during its lifetime. That means when the FIN is sent only the devices
> on one of those paths will see it and know to destroy flow state.
> State in devices on the other four paths is left hanging indefinitely
> so they still need to implement some state eviction method like
> timeout.

Yes, that=E2=80=99s a very valid agreement. I don=E2=80=99t think we can =
get fully rid of these mechanisms, also not all traffic will support =
PLUS. However, if it is supported and you get the information is can =
help you to make the write decision earlier. And the more PLUS =
deployment we see, the more it will actually free memory and computation =
resources...=20

>=20
> We solve this problem in out L4 load balancers by having them
> cooperate with each other to perform identical consistent hashing or
> out of band sharing of flow information. I don't believe such
> cooperative methods can be used in the Internet between arbitrary
> third party devices.
>=20
>> In short (and I need a better definition than this), the "path layer" =
is a virtual layer in the stack comprised of those behaviors of on-path =
devices that keep state derived from the data plane of the network layer =
and/or use transport layer information (and therefore have to keep state =
to operate properly, as the transport layer maintains end-to-end state =
beyond the network interface at each endpoint).
>>=20
>>>>> Given
>>>>> that they've been around for many years but have never been widely
>>>>> deployed on the Internet
>>>>=20
>>>> DCSP was defined in such a way that it makes little sense in an =
interdomain context, and its widespread intradomain deployment means =
that it will never deploy across domains in the general case.
>>>>=20
>>> Sure, but can you give a specific example of information exposure =
that
>>> is useful in interdomain context, does not diminish end user =
security,
>>> and does have any detrimental effects if the information is
>>> fabricated?
>>=20
>> SYN/FIN/RST, with higher probability than TCP affords that the thing =
that sent the FIN or RST is at least on path.
>>=20
>> Very limited information about the transport protocol's tolerances: =
loss and reordering tolerance come to mind.
>>=20
> Don't we already have diff-serv for such things?
>=20
>> I'm a fan of timestamps with echoes (as with TSOPT, but with some way =
to indicate local delta) for diagnostics, but given that clock drift =
provides a few bits of fingerprint entropy, they might not meet the =
"does not diminish end user security" requirement if your attacker model =
includes people trying to track you via fingerprinting.
>>=20
>> Note that all of these are things you get on-path with TLS over TCP, =
that you won't get with transport protocols that encrypt their headers, =
so these are examples of the "giving back" of information taken away =
when transport headers are encrypted, and/or the transport isn't TCP.
>>=20
>> 
>>=20
>>> Considering that there's already talk of sunsetting IPv4 I think =
it's
>>> less of a concern-- IPv6 is the future of the Internet. In fact,
>>> optimizing SPUD for IPv6 seems perfectly inline with encouraging
>>> adoption wider adoption of IPv6.
>>=20
>> I'm extremely sympathetic to this approach. "Optimize for v6" can't =
mean "v6 only", though, unless we don't think it will deploy until v4 is =
on the way out anyway.
>>=20
>>>>> The fact that neither have these caught on in the Internet and =
that
>>>>> tells me two things 1) No IP option is needed for the Internet to
>>>>> operate and be successful which makes me wonder if signaling =
between
>>>>> network and hosts is even required 2) If the extensibility =
mechanisms
>>>>> of IP are chronically not deployable, I wonder why any alternative
>>>>> that does not yet exist but intends to solve the same problem =
would be
>>>>> any more deployable.
>>>>=20
>>>> I'd assert that encapsulating things in UDP is certainly much more =
deployable *at the endpoints*. The open question is about adoption by =
on-path devices.
>>>>=20
>>> I'm not sure in this specific case that UDP necessarily make things
>>> more deployable. For instance, there's the pesky problem of
>>> fragmentation. If L3 information is put into UDP and that packet is
>>> fragmented, only the first fragment contains the L3 information the
>>> others don't. Either the application needs to pick some minimal MTU
>>> and hope that packets make it through, or needs to implement PMTU
>>> discovery (rather or not ICMP PTB is delivered to the application is
>>> another story, in Linux it is at least). IPv6 nicely great here =
since
>>> minimum MTU is 1280, IPv4 might be harder to nail down.
>>=20
>> Agreed. One of the things that works really well in an all-PLUS world =
is you can actually have native signaling of path MTU. Until then, =
PLPMTUD is your friend, and can live in the PLUS shim.
>>=20
> We already have PMTU discovery (RFC1191). The fact that it's
> considered unusable because many network devices don't implement it is
> is not a good rationale to create a new mechanism that provides the
> same information but requires other new implementation in those same
> devices.
>=20
> Tom
>=20
>> Cheers,
>>=20
>> Brian
>>>=20
>>=20
>=20
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud


From nobody Tue May 24 02:14: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 B410112D5B5 for ; Tue, 24 May 2016 02:14:51 -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 qTUD94t5PkUt for ; Tue, 24 May 2016 02:14:49 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0988B12D50E for ; Tue, 24 May 2016 02:14:49 -0700 (PDT)
Received: from [IPv6:2001:67c:64:42:2c53:6307:dcc9:5f34] (unknown [IPv6:2001:67c:64:42:2c53:6307:dcc9:5f34]) by trammell.ch (Postfix) with ESMTPSA id 5D8ED1A03C3 for ; Tue, 24 May 2016 11:14:48 +0200 (CEST)
From: Brian Trammell 
X-Pgp-Agent: GPGMail 2.6b2
Content-Type: multipart/signed; boundary="Apple-Mail=_F50BB211-15E1-4A4B-BE66-28C86053B869"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Tue, 24 May 2016 11:14:47 +0200
References: 
To: spud 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [Spud] on NAT timers in UDP (Fwd: [Maprg] Is UDP a trash heap?)
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, 24 May 2016 09:14:52 -0000

--Apple-Mail=_F50BB211-15E1-4A4B-BE66-28C86053B869
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Greetings, all,

For those of you not on maprg@irtf.org, here's an IMC paper on a =
laboratory experiment on captive middleboxes (from 2010): one datapoint =
on the need for TCP-like state management in PLUS.

Cheers,

Brian

> Begin forwarded message:
>=20
> From: "Eggert, Lars" 
> Subject: Re: [Maprg] Is UDP a trash heap?
> Date: 24 May 2016 at 10:58:01 GMT+2
> To: Brian Trammell 
> Cc: Aaron Falk , "maprg@irtf.org" =

>=20
> On 2016-05-24, at 10:50, Brian Trammell  wrote:
>> As noted over on the spud@ietf.org list, there are other questions =
about UDP vs TCP treatment that we need answers to as well: distribution =
of NAT timers on UDP NAT, prevalence and distribution of UDP rate =
limiting. (The second question is of course hard to answer with active =
measurement unless you're willing to run DoS attacks.)
>=20
> There is some (now old) data on this in our IMC paper: =
http://conferences.sigcomm.org/imc/2010/papers/p260.pdf
>=20
> NAT timers are shorter, and rate limiting more prevalent.
>=20
> Lars


--Apple-Mail=_F50BB211-15E1-4A4B-BE66-28C86053B869
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

iQIcBAEBCgAGBQJXRBuHAAoJEIoSt78L6kajwzEQAKLtrZiuzK9m+HQqjOQaHv/c
OsbClsPO660ufmgZcuWjIw2ixM3UScT6RYB3OG7NZ+KfZamCPuCNsV2URTTF9hdh
ZnguZ+YjdvvuKV2cRWPjnLwDyRWeW59TRDJKSHruz0YlP/zeKeEBMJ5Tws1tZ9J+
xTM0TIG4YFvw+8D6UNa6xW3n2OOxKwUMbPZdu54ZHsv+Oeicukjxts6pJ5/aZwJV
t6Hd5XnvLkOD4Ct4/ydKft1gZCavXFKDp+IYwQbzW2vvkSIsFU4vd5iEjgcMLWgW
558HsY65zbRiC7QuMNsLPP9h40/mNWRqxiPXck5YOxe2+5cumVsSx7FXT+Pzz8ua
hv5ifOKTXq7QAJd0hyP3J0V+jNMJI0nL4L8JAxL8jj8d0POiQ5syF7WgzZcqync/
Yk9jy2ZkZV66zNwVCSTk2229PEslm0zRswGPA3UPquEG6C00MNV1c2KXcKRR6X8l
OiasMngRg3vIwOWosWh36pzgI9HVP+S1TCwC0/rkeVYi11CuVU3AOCoFymLBjJSM
NGj+ALEShxFibyYIMAEGyymv61SxnawjfZoUdSRZuMDNvzOI4EGTRdvA+Nn+3CQb
Gp1fT3xk40pKNrjj8qgmo33Fu1wIvzlLiH9wuL8Fg1dxL5+VrcgbXi+XRUmjEKI8
qou5Op+HpsoE7hNVEtGX
=TENI
-----END PGP SIGNATURE-----

--Apple-Mail=_F50BB211-15E1-4A4B-BE66-28C86053B869--


From nobody Tue May 24 03:08: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 517EF12D65C for ; Tue, 24 May 2016 03:08:33 -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 NIFZ3i1LfjKO for ; Tue, 24 May 2016 03:08:31 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2C812B02D for ; Tue, 24 May 2016 03:08:30 -0700 (PDT)
Received: from [IPv6:2001:67c:64:49:f960:f4a2:6702:8e83] (unknown [IPv6:2001:67c:64:49:f960:f4a2:6702:8e83]) by trammell.ch (Postfix) with ESMTPSA id 988F01A167F for ; Tue, 24 May 2016 12:08:29 +0200 (CEST)
From: Brian Trammell 
X-Pgp-Agent: GPGMail 2.6b2
Content-Type: multipart/signed; boundary="Apple-Mail=_9314F6F9-A956-433C-87A3-6E70EEC45919"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Tue, 24 May 2016 12:08:28 +0200
Message-Id: 
To: spud 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [Spud] updated PLUS charter
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, 24 May 2016 10:08:33 -0000

--Apple-Mail=_9314F6F9-A956-433C-87A3-6E70EEC45919
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Greetings, all,

Consolidating edits from yesterday, here's the present state of the =
charter (working copy at https://github.com/ietf-plus/charter).

Thanks, cheers,

Brian

Path Layer UDP Substrate (PLUS)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

The PLUS working group's goal is to enable the deployment of new, =
encrypted
transport protocols, while providing a transport-independent method to =
signal
flow semantics under transport and application control. The approach =
from
which the working group will start is a shim layer based on the User =
Datagram
Protocol (UDP), which provides compatibility with existing middleboxes =
in the
Internet as well as ubiquitous support in endpoints, and provides for
userspace implementation.

The current Internet protocol stack does not provide explicit, =
transport-
independent signaling of flow characteristics to on-path network =
devices. This
has led to the deployment of devices which perform implicit discovery of =
these
characteristics, through inspection of protocol headers all they way up =
to the
application layer, a practice made possible because these headers are =
sent in
the clear. Inspection and modification of unencrypted protocol headers =
is a
key cause of the ossification that makes it hard or impossible to deploy =
new
protocols.

In order to support more ubiquitous deployment of encryption, and the
encryption of transport headers to allow deployment of new transport
protocols, explicit signaling must be added to the stack, and it must be
transport protocol independent. 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. Additionally, 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.

The PLUS working group will specify a new protocol as a Path Layer
User 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 in cleartext to devices on path

- allow devices on path to provide feedback and information about
  the path in cleartext to sending endpoints, under sending endpoint
  control

- allow devices on path to provide information about the path in =
cleartext
  to receiving endpoints, with feedback to the sending endpoint, under
  sending endpoint control

Note that 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 at the level of detail that is useful for the network,
while encrypting everything else. This is important to avoid future
implicit treatment and the resulting ossification, as well as to
leverage the principle of least exposure to minimize privacy risks
presented by explicit cooperation.

Given that the primary goal of PLUS is to enable the deployment of =
arbitrary
transport protocols, encrypting transport protocol 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
these use cases and requirements. 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 other working
groups that could or should 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.
TLS) which could be used for encryption of transport protocols
running over PLUS.


--Apple-Mail=_9314F6F9-A956-433C-87A3-6E70EEC45919
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

iQIcBAEBCgAGBQJXRCgdAAoJEIoSt78L6kajOwcP/A3z84j0A20lLtoyODHZ0Juj
6nKbljpxSatzdENpDx61v4AeyooRbV+eCLbzHLvUrIqBru3p2JH0/XPPSYBTVHk2
r5EtxQZhyumbMaBCtdcfr/FCwpGyC2paE1JFI/NHk7FbtFUw1c3mUnY9elDAA2KX
xWR3M2mP3SpZGMNonHsULRo8BI4Bp2zxIHO9c8ufmC443U3A1haDL34ntiSsPhXt
WWyrb+GfppMC/7E79WjIpCeU1gVzZs0vY9r0pUK2hbDwJcDr/DlGOS488QCGhft9
wJkM/v8uWADG5jyLzm1VAjmomG6jlrsxLXK3N8DKCI3KoqcbTTFMTp6bsYOxLSYf
TgBTawSn22g94JSekeR28V0hHcwP6qsMSNSGnTEXV80e5YC8a2UG2Q1kezQ7Xpy3
YBTREgtFFg14sk0DlyQd+B3+zFU2C3sVTiA4o814LJOJ1B3VnoDxTHPH7kPNG4G4
/5pi+IbgANU3g8Ji0WRfxhQM8bKr3mIRiyRLtcLFQlDhUeRXJUqLSX46ayKQNIBH
rrjyrYKs7tBNeOztYhIgEEb6Z+Z+t7d4iw/8Q85rcXKQtIGciv4Ucb2Wf2hxdRJl
usxMWIvf5MDwMOQG8mwqzsDa9/BfDVMqan4EBOtSlk+si8QjdX2PzOJg67cJPlfP
BQ+FhBaypLKOo5aOYWc6
=FsRh
-----END PGP SIGNATURE-----

--Apple-Mail=_9314F6F9-A956-433C-87A3-6E70EEC45919--


From nobody Wed May 25 04:34: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 F192512DAE9 for ; Wed, 25 May 2016 04:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.025
X-Spam-Level: 
X-Spam-Status: No, score=-4.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 q46Rm7fu9alT for ; Wed, 25 May 2016 04:34:38 -0700 (PDT)
Received: from n9-41.mail.139.com (n9-41.mail.139.com [221.176.9.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4584A12DAE5 for ; Wed, 25 May 2016 04:34:38 -0700 (PDT)
X-RM-SPAM-FLAG: 00000000
Received: from peng.fan@139.com ( [61.135.169.79] ) by ajax-webmail-rmapp-22-11022 (Richmail) with HTTP; Wed, 25 May 2016 19:34:36 +0800 (CST)
Date: Wed, 25 May 2016 19:34:36 +0800 (CST)
From: "Fan, Peng" 
To: spud , ietf 
Message-ID: <2b0e574586dd955-00039.Richmail.00049889758880203458@139.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_509495_1939342187.1464176076167"
X-Priority: 3
X-RM-TRANSID: 2b0e574586dd955-00039
X-RM-OA-ENC-TYPE: 0
X-CLIENT-INFO: X-TIMING=0&X-MASSSENT=0&X-SENSITIVE=0
X-Mailer: Richmail_Webapp(V1.8.30)A001
Archived-At: 
Subject: Re: [Spud] Possible WG-forming follow-on to SPUD 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, 25 May 2016 11:34:48 -0000

------=_Part_509495_1939342187.1464176076167
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

Are we ready to answer the network neutrality concern that was also mentioned in previous SPUD efforts?

Best regards,
Peng



------=_Part_509495_1939342187.1464176076167
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

Are we ready to answer the network neutrality concern that was also mentioned in previous SPUD efforts?

Best regards,
Peng

------=_Part_509495_1939342187.1464176076167--


From nobody Wed May 25 05:33: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 038C712D677 for ; Wed, 25 May 2016 05:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.347
X-Spam-Level: 
X-Spam-Status: No, score=-8.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 n9eCDVw67kEh for ; Wed, 25 May 2016 05:33:45 -0700 (PDT)
Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8869A12D66C for ; Wed, 25 May 2016 05:33:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.26,364,1459839600";  d="asc'?scan'208";a="118401924"
Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx144-out.netapp.com with ESMTP; 25 May 2016 05:33:08 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 25 May 2016 05:33:02 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::7db0:a96:265e:db5e%21]) with mapi id 15.00.1156.000; Wed, 25 May 2016 05:33:02 -0700
From: "Eggert, Lars" 
To: Brian Trammell 
Thread-Topic: [Spud] updated PLUS charter
Thread-Index: AQHRtaQ8vI1+oSWPj0m1cNB0lCaa5p/KDTmA
Date: Wed, 25 May 2016 12:33:01 +0000
Message-ID: 
References: 
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.122.56.79]
Content-Type: multipart/signed; boundary="Apple-Mail=_416B9066-A643-4429-A653-B6BA891EA03D"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: 
Cc: spud 
Subject: Re: [Spud] updated PLUS charter
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, 25 May 2016 12:33:47 -0000

--Apple-Mail=_416B9066-A643-4429-A653-B6BA891EA03D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

a few comments:

On 2016-05-24, at 12:08, Brian Trammell  wrote:
> Path Layer UDP Substrate (PLUS)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>=20
> The PLUS working group's goal is to enable the deployment of new, =
encrypted
> transport protocols, while providing a transport-independent method to =
signal
> flow semantics under transport and application control.

Using the plural here ("new, encrypted transport protocols") sounds =
awfully broad. At the end of the charter, the text says "an experimental =
protocol specification" is the deliverable, which is much more =
constrained. Suggest to use similar wording here also.

> The approach from
> which the working group will start is a shim layer based on the User =
Datagram
> Protocol (UDP), which provides compatibility with existing middleboxes =
in the
> Internet as well as ubiquitous support in endpoints, and provides for
> userspace implementation.
>=20
> The current Internet protocol stack does not provide explicit, =
transport-
> independent signaling of flow characteristics to on-path network =
devices.

I think it's been pointed out that this broad statement is incorrect in =
several ways, since we have many explicit, transport-independent =
signaling protocols (RSVP, NSIS, etc.) They are neither in-band (which I =
think you want here) nor are they generally deployed or deployable =
(which is also what I think you want here), so I suggest that this text =
be tightened, so that folks like me don't overreact :-)

> This
> has led to the deployment of devices which perform implicit discovery =
of these
> characteristics, through inspection of protocol headers all they way =
up to the
> application layer, a practice made possible because these headers are =
sent in
> the clear.

Another reason for DPI is that the network can't really in general trust =
what is signaled by the end points, and so it is attractive to try and =
obtain "the truth" by DPI (whether that is possible or not in all =
cases.) I'd like to raise that any new endpoint signaling method - i.e., =
the work proposed here - will have similar issues. It would be good to =
have some argument as to why PLUS will be different.

> Inspection and modification of unencrypted protocol headers is a
> key cause of the ossification that makes it hard or impossible to =
deploy new
> protocols.
>=20
> In order to support more ubiquitous deployment of encryption, and the
> encryption of transport headers to allow deployment of new transport
> protocols, explicit signaling must be added to the stack, and it must =
be
> transport protocol independent.

I again think you mean "in-band" signaling, since we have out-of-band =
signaling - well, at least many specs for it :-)

> 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. Additionally, 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.
>=20
> The PLUS working group will specify a new protocol as a Path Layer
> User Substrate (PLUS), to support experimental deployment of
> explicit cooperation between endpoints and devices on path, with the =
following goals:
>=20
> - 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).
>=20
> - allow applications and transport protocols to explicitly provide
>  limited information in cleartext to devices on path
>=20
> - allow devices on path to provide feedback and information about
>  the path in cleartext to sending endpoints, under sending endpoint
>  control
>=20
> - allow devices on path to provide information about the path in =
cleartext
>  to receiving endpoints, with feedback to the sending endpoint, under
>  sending endpoint control

Can we find a better word than "cleartext"? At least my mind immediately =
jumps to think about unstructured ASCII data in protocol headers. Maybe =
"unencrypted" or "not integrity-protected"?

> Note that 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 at the level of detail that is useful for the network,
> while encrypting everything else.

It would be good to add a half-sentence on how PLUS can achieve that =
goal (i.e., how can it limit what an app decides to signal)...

> This is important to avoid future
> implicit treatment and the resulting ossification, as well as to
> leverage the principle of least exposure to minimize privacy risks
> presented by explicit cooperation.

...because as you say that is important.

> Given that the primary goal of PLUS is to enable the deployment of =
arbitrary
> transport protocols, encrypting transport protocol 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.
>=20
> 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
> these use cases and requirements. The working group will close if
> it is not able to come to consensus on a protocol design to meet
> these requirements.
>=20
> The working group will additionally aim to identify other working
> groups that could or should 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.
> TLS) which could be used for encryption of transport protocols
> running over PLUS.

Lars

--Apple-Mail=_416B9066-A643-4429-A653-B6BA891EA03D
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-----

iQIcBAEBCAAGBQJXRZuAAAoJEFS1wwm/cMFXWssP/1EI7mKdwseXdmLmyyutlYo1
hRGsyRBuoVryTMjGQKOnmcFP/pCVWxGpIc2Y713YvuSUHSqaCmKZL92VTJpLZ/ZH
Wx0NpRiPjrrhlr+tNStOPJcKIquYT9HLjIKx3LxFGtP1wL99KLui/aoO+b2cHpWi
XYO1btuQvghidpsC2koSWWmT8hXxZey/EMQ247BpYLuloV7BmFSqbb5ONYHmPNra
gQRrJJbtqyMkuwPqqwbgqRqRR1ZW+cbRRMB5voI0LnrUn8Xwhv7BXiTcdppN7d+D
5ziTjXdE036RX7+UpnzCjd/+jjnGF/O3DK0MbKPPcxcOs+j/E4mf2np0FaUDUjHp
XQ4CSeWNq+Ws6bYtbXpcKvd2PL15uxKRd/MnbML/JkpI3xrMHnSyIgiy1H7M+o0F
LKm58lOAIm9Q+myFEkwH4h+pghrV5o2LzOuU52Z2xs4VBi8G5HPUrkWVTy22a6o8
uolM0w0SnznXQavDKbQVtxYPZ+Trco/acXJRs1/06u3vWmKzXaxlEJqMAUFLBVmc
KJa7OwqGmz0UHOY4G/zWPeFEtSkLX/xRG4Q3jDdI/rF9s28urrrm4Lg2gHM9R+nL
erbHDyLc8/cbygTNKjZA65Jm0z//5N9hrcbXE6CQ4GfAGPVzIbxt7yIz0RMIz31E
QAkZFD0QeTCJ6ReEJhkN
=73Kp
-----END PGP SIGNATURE-----

--Apple-Mail=_416B9066-A643-4429-A653-B6BA891EA03D--


From nobody Wed May 25 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 E016A12D097 for ; Wed, 25 May 2016 07:41:59 -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 JaUSWhHnb9Mx for ; Wed, 25 May 2016 07:41:57 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 D97C112D776 for ; Wed, 25 May 2016 07:41:45 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id k1so11761458vka.3 for ; Wed, 25 May 2016 07:41:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3L210ZbvHS9bvK2rZUIIB+cMrHQUSF9OS0iI+Klh0fo=; b=lA92J8K1jvzqjXTeUNbxzo2mWIjh1NMjxdRfLnOSPXuiIBVRuL95GOCmqYewgSD8Kf WKo3EWZW+9P1oqxP05UUWyiN/fj7swXdy8PMd06HE+IaLBOOmPxJEl9iOfDDfbzNpMgq dbxOqu9S+CybP2p+534pfAtwAPQ2q2azlIB2fPJKpfh0vir/g5THJXrjraWzQBMjffJi rx5H2fX2l16BT2WMK6XF9EBjZRu6lKIIDocavlwt/LtycBDCIFtylEeRrA/SNNjTdCKe SZxC+G6IXWftfhpAn3TdGuBlZwbM8FUoRg9eOvQR5Ppes3U5czvtknUs6c6fDIdXG3cW lPbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3L210ZbvHS9bvK2rZUIIB+cMrHQUSF9OS0iI+Klh0fo=; b=X0R3QS+8CQwvwcacbVyphLIb3OD2QzkdqYmKxThB0FCUUSheGd9OPKj21ef5Pj0Isd T3OqqWrJq34oNLinBF+EtmeElpnWEYc1MgnnacCCLtilatZrnNI6lmoQPYjYslrzmrj3 0ROJxWXWbUWsnkhtbaqXc4gFHgz8Z6nK5yYuAYRgelzGbPQnWuvua8b388u24B+N2m53 Q+XG7pf3xIQuPSVSoS70HBe4C1V8PZqaQDG8QjY4xO9nPBhmsTHzp8KYJTS9bKK0yaE3 R7ahWm2XEmNIRlI6TsXcz9FnsJCwH3vNZs5qDgRE3UchsDZ8bpWhCTM0ubJcz5wbagh3 krlw==
X-Gm-Message-State: ALyK8tLRRKltykAt41YgRuXErgsP8V3yKmrEOwvnabbcBMQqBb9QBZyxdZmgjcDz/mk+X8395+Vu5FoD0GbZFg==
X-Received: by 10.176.69.248 with SMTP id u111mr2566775uau.138.1464187304840;  Wed, 25 May 2016 07:41:44 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Aaron Falk 
Date: Wed, 25 May 2016 14:41:30 +0000
Message-ID: 
To: "Eggert, Lars" , Brian Trammell 
Content-Type: multipart/alternative; boundary=94eb2c0482b03094e30533abac2c
Archived-At: 
Cc: spud 
Subject: Re: [Spud] updated PLUS charter
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, 25 May 2016 14:42:00 -0000

--94eb2c0482b03094e30533abac2c
Content-Type: text/plain; charset=UTF-8

There's a fair bit of redundancy which encourages nitpicking.  Suggest
cutting the 1st three paragraphs.  Start with "The PLUS working group will
specify a new protocol as a Path Layer User Substrate (PLUS)..."

--aaron

On Wed, May 25, 2016 at 8:33 AM Eggert, Lars  wrote:

> Hi,
>
> a few comments:
>
> On 2016-05-24, at 12:08, Brian Trammell  wrote:
> > Path Layer UDP Substrate (PLUS)
> > ===============================
> >
> > The PLUS working group's goal is to enable the deployment of new,
> encrypted
> > transport protocols, while providing a transport-independent method to
> signal
> > flow semantics under transport and application control.
>
> Using the plural here ("new, encrypted transport protocols") sounds
> awfully broad. At the end of the charter, the text says "an experimental
> protocol specification" is the deliverable, which is much more constrained.
> Suggest to use similar wording here also.
>
> > The approach from
> > which the working group will start is a shim layer based on the User
> Datagram
> > Protocol (UDP), which provides compatibility with existing middleboxes
> in the
> > Internet as well as ubiquitous support in endpoints, and provides for
> > userspace implementation.
> >
> > The current Internet protocol stack does not provide explicit, transport-
> > independent signaling of flow characteristics to on-path network devices.
>
> I think it's been pointed out that this broad statement is incorrect in
> several ways, since we have many explicit, transport-independent signaling
> protocols (RSVP, NSIS, etc.) They are neither in-band (which I think you
> want here) nor are they generally deployed or deployable (which is also
> what I think you want here), so I suggest that this text be tightened, so
> that folks like me don't overreact :-)
>
> > This
> > has led to the deployment of devices which perform implicit discovery of
> these
> > characteristics, through inspection of protocol headers all they way up
> to the
> > application layer, a practice made possible because these headers are
> sent in
> > the clear.
>
> Another reason for DPI is that the network can't really in general trust
> what is signaled by the end points, and so it is attractive to try and
> obtain "the truth" by DPI (whether that is possible or not in all cases.)
> I'd like to raise that any new endpoint signaling method - i.e., the work
> proposed here - will have similar issues. It would be good to have some
> argument as to why PLUS will be different.
>
> > Inspection and modification of unencrypted protocol headers is a
> > key cause of the ossification that makes it hard or impossible to deploy
> new
> > protocols.
> >
> > In order to support more ubiquitous deployment of encryption, and the
> > encryption of transport headers to allow deployment of new transport
> > protocols, explicit signaling must be added to the stack, and it must be
> > transport protocol independent.
>
> I again think you mean "in-band" signaling, since we have out-of-band
> signaling - well, at least many specs for it :-)
>
> > 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. Additionally, 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.
> >
> > The PLUS working group will specify a new protocol as a Path Layer
> > User 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 in cleartext to devices on path
> >
> > - allow devices on path to provide feedback and information about
> >  the path in cleartext to sending endpoints, under sending endpoint
> >  control
> >
> > - allow devices on path to provide information about the path in
> cleartext
> >  to receiving endpoints, with feedback to the sending endpoint, under
> >  sending endpoint control
>
> Can we find a better word than "cleartext"? At least my mind immediately
> jumps to think about unstructured ASCII data in protocol headers. Maybe
> "unencrypted" or "not integrity-protected"?
>
> > Note that 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 at the level of detail that is useful for the network,
> > while encrypting everything else.
>
> It would be good to add a half-sentence on how PLUS can achieve that goal
> (i.e., how can it limit what an app decides to signal)...
>
> > This is important to avoid future
> > implicit treatment and the resulting ossification, as well as to
> > leverage the principle of least exposure to minimize privacy risks
> > presented by explicit cooperation.
>
> ...because as you say that is important.
>
> > Given that the primary goal of PLUS is to enable the deployment of
> arbitrary
> > transport protocols, encrypting transport protocol 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
> > these use cases and requirements. 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 other working
> > groups that could or should 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.
> > TLS) which could be used for encryption of transport protocols
> > running over PLUS.
>
> Lars
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>

--94eb2c0482b03094e30533abac2c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


There's a fair bit of redundancy which encourages nitp=
icking.=C2=A0 Suggest cutting the 1st three paragraphs.=C2=A0 Start with &q=
uot;The PLUS working group will specify a new prot=
ocol as a Path Layer=C2=A0User Substrate (P=
LUS)..." =C2=A0

--aaron

On Wed, May 25, 2016 at 8:33 AM Egge=
rt, Lars <lars@netapp.com> wro=
te:
Hi,



a few comments:



On 2016-05-24, at 12:08, Brian Trammell <ietf@trammell.ch> wrote:

> Path Layer UDP Substrate (PLUS)

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D

>

> The PLUS working group's goal is to enable the deployment of new, =
encrypted

> transport protocols, while providing a transport-independent method to=
 signal

> flow semantics under transport and application control.



Using the plural here ("new, encrypted transport protocols") soun=
ds awfully broad. At the end of the charter, the text says "an experim=
ental protocol specification" is the deliverable, which is much more c=
onstrained. Suggest to use similar wording here also.



> The approach from

> which the working group will start is a shim layer based on the User D=
atagram

> Protocol (UDP), which provides compatibility with existing middleboxes=
 in the

> Internet as well as ubiquitous support in endpoints, and provides for<=
br>
> userspace implementation.

>

> The current Internet protocol stack does not provide explicit, transpo=
rt-

> independent signaling of flow characteristics to on-path network devic=
es.



I think it's been pointed out that this broad statement is incorrect in=
 several ways, since we have many explicit, transport-independent signaling=
 protocols (RSVP, NSIS, etc.) They are neither in-band (which I think you w=
ant here) nor are they generally deployed or deployable (which is also what=
 I think you want here), so I suggest that this text be tightened, so that =
folks like me don't overreact :-)



> This

> has led to the deployment of devices which perform implicit discovery =
of these

> characteristics, through inspection of protocol headers all they way u=
p to the

> application layer, a practice made possible because these headers are =
sent in

> the clear.



Another reason for DPI is that the network can't really in general trus=
t what is signaled by the end points, and so it is attractive to try and ob=
tain "the truth" by DPI (whether that is possible or not in all c=
ases.) I'd like to raise that any new endpoint signaling method - i.e.,=
 the work proposed here - will have similar issues. It would be good to hav=
e some argument as to why PLUS will be different.



> Inspection and modification of unencrypted protocol headers is a

> key cause of the ossification that makes it hard or impossible to depl=
oy new

> protocols.

>

> In order to support more ubiquitous deployment of encryption, and the<=
br>
> encryption of transport headers to allow deployment of new transport
> protocols, explicit signaling must be added to the stack, and it must =
be

> transport protocol independent.



I again think you mean "in-band" signaling, since we have out-of-=
band signaling - well, at least many specs for it :-)



> While IP would seem to be the natural home for

> this facility, both IPv4 and IPv6 options and extensions have deployme=
nt

> problems on their own, which makes it hard to include any additional
> information in these protocols. Additionally, 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 expl=
icit

> cooperation approach.

>

> The PLUS working group will specify a new protocol as a Path Layer

> User Substrate (PLUS), to support experimental deployment of

> explicit cooperation between endpoints and devices on path, with the f=
ollowing goals:

>

> - enable ubiquitous deployment of encrypted higher layer protocols

>=C2=A0 by providing exposure of basic TCP-like semantics (e.g. SYN, FIN=
,

>=C2=A0 RST flags) to devices on path (e.g. NATs and firewalls).

>

> - allow applications and transport protocols to explicitly provide

>=C2=A0 limited information in cleartext to devices on path

>

> - allow devices on path to provide feedback and information about

>=C2=A0 the path in cleartext to sending endpoints, under sending endpoi=
nt

>=C2=A0 control

>

> - allow devices on path to provide information about the path in clear=
text

>=C2=A0 to receiving endpoints, with feedback to the sending endpoint, u=
nder

>=C2=A0 sending endpoint control



Can we find a better word than "cleartext"? At least my mind imme=
diately jumps to think about unstructured ASCII data in protocol headers. M=
aybe "unencrypted" or "not integrity-protected"?



> Note that 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 at the level of detail that is useful for the network,

> while encrypting everything else.



It would be good to add a half-sentence on how PLUS can achieve that goal (=
i.e., how can it limit what an app decides to signal)...



> This is important to avoid future

> implicit treatment and the resulting ossification, as well as to

> leverage the principle of least exposure to minimize privacy risks

> presented by explicit cooperation.



...because as you say that is important.



> Given that the primary goal of PLUS is to enable the deployment of arb=
itrary

> transport protocols, encrypting transport protocol headers, we assume =
that

> the higher-layer protocol can provide an encryption context that can b=
e used by

> PLUS to provide authentication, integrity, and encryption where needed=
. The

> primary threat model to defend against will be modification or deletio=
n of

> exposed information by middleboxes and other devices on path, by allow=
ing 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

> these use cases and requirements. 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 other working

> groups that could or should 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.
> TLS) which could be used for encryption of transport protocols

> running over PLUS.



Lars

_______________________________________________

Spud mailing list

Spud@ietf.org

https://www.ietf.org/mailman/listinfo/spud




--94eb2c0482b03094e30533abac2c--


From nobody Wed May 25 07:46: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 452F112D124 for ; Wed, 25 May 2016 07:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 8M7UIHz8mMsE for ; Wed, 25 May 2016 07:46:40 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 CB76012D6FC for ; Wed, 25 May 2016 07:46:40 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id l63so33339756ita.1 for ; Wed, 25 May 2016 07:46:40 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=o3La1diwM2BXi9YpmE8YMZqL6KybwLrs0/fBQyDgt3c=; b=SHAjoLKwTEnhxU17bdPWHaVyhB3g3TsjI9sRf+pU3y0HSsOk+/kUWRqpxoHAKnFGUy mC7lttRNFUXbAhCGlNrrCoBKEuZiJDWRL5gNLwv1dJ7yxjI6Q/pBZ4267zop09HqqafR fcUb2Py/YgUTDaQSmHrAMdo8b9tr7/sbjNAGJfKfkDrN/xeedSWDTTA8LgFZqfVxKRVT X3rl5vVZXvl4xXY9h3IPaBqv2MYjprxHHDHFDQ6XTa0KPydPe3iauXhnGEeSZqEMbC4b 5t9e6TgYmOmrULFKXqMgj3bNSjlo7KGgMYQaWPZowY8Td5gf3JG5rWIKo+QYtBAs8axZ sanQ==
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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=o3La1diwM2BXi9YpmE8YMZqL6KybwLrs0/fBQyDgt3c=; b=TXU3N6SxT8E9Zs4iZFf712BPfoo6UAMxcdALFCxm2PscFihuheKsP4awHEdrO2lQ9I wIWcLX5+Jfp5kE/bfV2kcB/4WgvSIQqg0OGjLu/zR48WKZ8ePVX5DOqXv2WO0AAYTPey rf+nw2eLeF4GQOi/ZOF8j/oBnVho43kMR9TLGeLXOPYNZkERK8Op6hXSC8ffpOpxBkhz TKyNGrXhx7zOYimf/1F1tUsspqhClwXyaDF1rxzEvTK9tmOycReGNd9BQVCE9YHTYlTu G9nJyqhdFvNjFFeIdLe2XsC7G2xBQ65ARtOTT8vUdkskjXoHlUt1pUc/r2K4X61yPX41 XscQ==
X-Gm-Message-State: AOPr4FXiCr/4QlRCdjV5F7d1kl42CBQ9mUaWWBzw6+dqf5jv7AP9WSU0AmFJD7ZMHRuEEWJSd8laFxIywqjJ/g==
MIME-Version: 1.0
X-Received: by 10.36.96.14 with SMTP id i14mr23527541itc.91.1464187600024; Wed, 25 May 2016 07:46:40 -0700 (PDT)
Received: by 10.107.56.67 with HTTP; Wed, 25 May 2016 07:46:39 -0700 (PDT)
In-Reply-To: <7B12E853-F164-46A9-BB1E-754DC969D07F@tik.ee.ethz.ch>
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com>     <677C2E5C-5EE6-49AD-B642-2577E3706F0F@tik.ee.ethz.ch>  <2F492BAF-908C-45BD-B7B8-32701AA2CB41@trammell.ch> <7B12E853-F164-46A9-BB1E-754DC969D07F@tik.ee.ethz.ch>
Date: Wed, 25 May 2016 07:46:39 -0700
Message-ID: 
From: Tom Herbert 
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 , "spud@ietf.org" 
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD 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, 25 May 2016 14:46:42 -0000

On Tue, May 24, 2016 at 1:13 AM, Mirja K=C3=BChlewind
 wrote:
> Hi Tom,
>
>> Am 24.05.2016 um 09:57 schrieb Brian Trammell :
>>
>>> I suppose it's a natural inclination to try to mimic TCP semantics
>>> because of its pervasiveness, but if things already work well enough
>>> then I don't see what problem it solves. The addition of such
>>> signaling increases the complexity of the protocols, the networking
>>> stack, network devices, and creates yet another opportunity for
>>> ossification.
>
> The problem is it only works for what we have right now. It works less we=
ll for new things which is a pity=E2=80=A6 it=E2=80=99s ossified. Yes, addi=
ng more stuff will make it more complex; I guess that=E2=80=99s a general c=
ase but I don=E2=80=99t think is an argument to stop trying to solve the pr=
oblem. And also yes, it might get ossified again, but if we do it right thi=
s time, I want it to get ossified and settle as a common base for new proto=
cols to get (more quickly and at all) deployed.
>

Mirja,

I will argue that what we have does not work right now. If a NAT state
is evicted in a network device then that means we lose the TCP
connection often without any notification. This has forced widespread
use of NAT keepalives which are basically junk packets sent into the
Internet that serve no other purpose than keep NAT state fresh. This
is a real problem especially on mobile devices where we waking up a
transmitter to send a keepalives is drain on the battery.

A proposed solution to this is what I'm calling "disassociated
location" (described in draft-herbert-transports-over-udp-00 and
borrowed from QUIC). The idea is that the endpoints do not use the IP
addresses and port numbers to identify a connection, they instead use
connection identifiers that are negotiated between the two endpoints
to be unique the other connections in the nodes. With this method, I
believe that connections can survive a NAT eviction. So if a
connection goes idle we no longer have to worry about maintaining NAT
state (presuming the client is the one that initiates requests). And
when an idle client wakes up it can assume that the NAT state has
timed so it may as well use new port numbers and new flow identifiers;
to the network this looks like a completely new flow (good for
security), but to the transport endpoints it is a continuation of an
established connection.

Similarly this should resolve the multi-homing/mobility issue.
Currently, if the path of a connection changes and packets are routed
through a different NAT device we lose the connection. With a
transport over UDP and disassociated location the connection remains
viable in that scenario.

This model only assumes typical UDP-NAT behavior in the network (like
in RFC4787) and does not require any new "path layer" protocol. I
don't see how exposing connection state can help here, and honestly I
wouldn't even know how to set it-- during the lifetime of one
connection it would be seen by the network to be different flows at
different times and (hopefully) would be unable deduce that these
refer to the same transport layer connection.

Tom

> Mirja
>
>
>


From nobody Wed May 25 07:51: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 4E88412D720 for ; Wed, 25 May 2016 07:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 oSdz3eLwXpOZ for ; Wed, 25 May 2016 07:51:13 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 0C27412D75C for ; Wed, 25 May 2016 07:50:48 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id v125so6870892itc.0 for ; Wed, 25 May 2016 07:50:48 -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:date:message-id:subject:from:to :cc; bh=xQt8IK8PCwEE8fsjr7ys96tLNmPEhOyjtlTrScsh+EE=; b=i7WRAtF/5RkhcFOCsYnU1bJgMHVPP6yIuwzRYsMIW0W9RQq5/chCyZlU2uhEV4XHZl iPIqZFkWgoRon1b8DFH9fNz5Nf8ObPDeDRdVxH9on5PDoJW6CwQKVP0JRUmi+wtm0/0p zvbjInQaQtgk/CeMpToLG9AlqFb5Py+zrUcfzsflWxbyy7iTluni2zI+FgjsUVggthz6 0D4KCQYwpUpRoqsMtCMSWDHqBRgoq5/U9FM0iAxsBxzOAWYkW3Oa79nx4m9jJJxanXv5 1neJmGMYDJzZd76o3b+VAGF3lF/NPfPmGv5UJmgDzpVI8I/LQtWRyY5XBk4KxnWiwLXd uk7Q==
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:date :message-id:subject:from:to:cc; bh=xQt8IK8PCwEE8fsjr7ys96tLNmPEhOyjtlTrScsh+EE=; b=OZeLMYFUtfKMVJPwBxs1vfh6vk7pZWwoQ7NklnQiUzmdslbusaCBIU2TZwQsD97Ucc WI5qgHRwslS13wiIYWsS3PYbW7+qjsZ5dvajLwqmh4vPya7RQN677oOl8s0DmI5iF/TO 3Sd24syLtbhTj+6IBkVeG9o+JbQ8x3vLNMRESHKGqFBsQ2AmFYzJ8bOpMULJBu8dDjzL JcqxwtqiHbhCvtxeG1Rfj5cMHid4x4sF0Bwf5V+w7tYSooldpoxwfE6qpr522gPe0Nbk WesETk7C+C3hhZNQyF08u+jzg63DC3KOxUbsMr2fBVycALzLLQIENWt7tKoj+8t1WSue PKEA==
X-Gm-Message-State: AOPr4FVG2X6XYoQKnN0XxGSUUN/i9A1D+VwFRGuJMHjMzR9CZJ38XMkB+fYYyMI1idChNbqhJ+LasjvApGJhTQ==
MIME-Version: 1.0
X-Received: by 10.36.96.14 with SMTP id i14mr23545580itc.91.1464187847352; Wed, 25 May 2016 07:50:47 -0700 (PDT)
Received: by 10.107.56.67 with HTTP; Wed, 25 May 2016 07:50:47 -0700 (PDT)
In-Reply-To: <2b0e574586dd955-00039.Richmail.00049889758880203458@139.com>
References: <2b0e574586dd955-00039.Richmail.00049889758880203458@139.com>
Date: Wed, 25 May 2016 07:50:47 -0700
Message-ID: 
From: Tom Herbert 
To: "Fan, Peng" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: ietf , spud 
Subject: Re: [Spud] Possible WG-forming follow-on to SPUD 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, 25 May 2016 14:51:17 -0000

On Wed, May 25, 2016 at 4:34 AM, Fan, Peng  wrote:
> Hi,
>
> Are we ready to answer the network neutrality concern that was also
> mentioned in previous SPUD efforts?
>
I think the security and net neutrality concern is that if you create
an open ended mechanism that allows applications to signal arbitrary
data to the network, some network operators, government, or other
"authorized" personnel can and will require the use of that mechanism
to provide private data about users and their communications. Of
course such demands will be made anyway, but I don't believe IETF
should standardize protocols that facilitate this.

Tom


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


From nobody Wed May 25 08:20: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 104AF12D7EB for ; Wed, 25 May 2016 08:20:09 -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 JgMYLUnY4tYp for ; Wed, 25 May 2016 08:20:07 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3444012DD10 for ; Wed, 25 May 2016 08:17:41 -0700 (PDT)
Received: from [IPv6:2001:67c:64:49:f929:8fc8:52b5:294a] (unknown [IPv6:2001:67c:64:49:f929:8fc8:52b5:294a]) by trammell.ch (Postfix) with ESMTPSA id 7619C1A0F8A; Wed, 25 May 2016 17:17:10 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_1D4C8671-0E2A-43F2-968A-10F757CF505C"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell 
X-Priority: 3
In-Reply-To: <2b0e574586dd955-00039.Richmail.00049889758880203458@139.com>
Date: Wed, 25 May 2016 17:17:15 +0200
Message-Id: <0DA26621-C4AA-4E25-A18A-C5CF7555AD3E@trammell.ch>
References: <2b0e574586dd955-00039.Richmail.00049889758880203458@139.com>
To: "Fan, Peng" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: spud 
Subject: Re: [Spud] Possible WG-forming follow-on to SPUD 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, 25 May 2016 15:20:09 -0000

--Apple-Mail=_1D4C8671-0E2A-43F2-968A-10F757CF505C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

hi Peng,

I believe so. Please see my answers to Mark's questions (and follow-on =
discussion) starting with =
http://www.ietf.org/mail-archive/web/spud/current/msg00446.html.

Are there other questions you have that that thread doesn't cover?

Thanks, cheers,

Brian

> On 25 May 2016, at 13:34, Fan, Peng  wrote:
>=20
> Hi,
>=20
> Are we ready to answer the network neutrality concern that was also =
mentioned in previous SPUD efforts?
>=20
> Best regards,
> Peng


--Apple-Mail=_1D4C8671-0E2A-43F2-968A-10F757CF505C
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

iQIcBAEBCgAGBQJXRcH7AAoJEIoSt78L6kajkK0P/RntoI1b1c/WYZN6bzH0kXda
H3TObZzIzay5EeyOiqTKdn9b5/39XWmbyn/PcOjfozpbx2eSU/hIpNBBlL4YD9j5
nvjNfzcfITq9npoesM46W9aepas8fQfunFRWE+zEpZ8butfIQ9xVnqjz9X8Z/y3t
o4z0002ZY7oFD51HYKIv6t/d48W3FZMUChVnhZ8kIRbKb6XX/8Zvw7egK/0PGvVP
M+JLTFogZ+wVZ3/qEa2ygYrYo5lI5KwsRbaK9HOHR9zVFjhPiRQVzxG9dcfkBVvS
uhnYiY+SIhpoBNdnuzsFTVOcE4/snNeCOq0A5jygrJZdZjX3uAyXfxTfWrhzotHh
9Gg4Ddd8I/NJQlrTxm+obZqj3FZN6Y1/AKtU0jBHNeIxsHfd9UWFJ1tyu70pYAWJ
oBnORnh4In80Q90Mi2pb8+thEgevYJ6fIhb44cZqmfTEezfLFV5+cbDEyKk+vBGC
bycpjpyNZrCP1ywVeOwJqtyzz/Eb22LNt84bF9W8naCGiVfgcKKcdc/ymW7zl0ur
pw+23QYsdjtbStZhNDhgkfEAT1zzIKdUJCGso3C6q4uyso8zAsjiwg+UmIxF1Jtj
3z1rGN0WiIeRBM4QvgoAPIkgErrRv+6OfMtwPWpUTATRiQScDdOh3etCqiPnZ4oa
YiT+LrHhKhgpAeVrqOew
=TI82
-----END PGP SIGNATURE-----

--Apple-Mail=_1D4C8671-0E2A-43F2-968A-10F757CF505C--


From nobody Wed May 25 08:50: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 C789912D654 for ; Wed, 25 May 2016 08:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level: 
X-Spam-Status: No, score=-15.947 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.426, 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 8Gbj_sHRvzZ7 for ; Wed, 25 May 2016 08:50:48 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2C412B015 for ; Wed, 25 May 2016 08:50:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6459; q=dns/txt; s=iport; t=1464191447; x=1465401047; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=aCpQjrlqlhLyN7zjmtH+c52nNWoPC5C96ZATINaHx4U=; b=FxA6fapZ+1E32OSwpr+D9fk+XWA6OFP+QHxKkT4Z5wqFxQoz1L1rIdBG 93eL2sy4ILJYSUGFdEoHGXSNdCVlUnLD65i2dl4F1ig42x5rozK65ycia sFygZ2FLX5x0rKp4utkwFegJY6vtWpTdEkg0GP09q1zadQNmOsTQzZ/Cp g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxBQDMyEVX/4cNJK1SBAaDN1Z9ugWBd?= =?us-ascii?q?xcLhW8CgUE5EwEBAQEBAQFlJ4RDAQEBAwEBAQE3NAsFCwsYCSUPBRM2ExuIDAg?= =?us-ascii?q?OxCEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYlwgQOEFwUVhWgFjlmJXo4WCo8cj?= =?us-ascii?q?0wiAj6CBhyBaxwyiEqBPQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208";a="106343482"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 May 2016 15:50:46 +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 u4PFokOb030285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 May 2016 15:50:46 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 u4PFoj0K005213; Wed, 25 May 2016 08:50:45 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u4PFojTX005211; Wed, 25 May 2016 08:50:45 -0700
Date: Wed, 25 May 2016 08:50:45 -0700
From: Toerless Eckert 
To: "Eggert, Lars" 
Message-ID: <20160525155045.GG15064@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: Brian Trammell , spud 
Subject: Re: [Spud] Lars:  updated PLUS charter
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, 25 May 2016 15:50:50 -0000

On Wed, May 25, 2016 at 12:33:01PM +0000, Eggert, Lars wrote:
> > The PLUS working group's goal is to enable the deployment of new, encrypted
> > transport protocols, while providing a transport-independent method to signal
> > flow semantics under transport and application control.
> 
> Using the plural here ("new, encrypted transport protocols") sounds awfully broad. At the end of the charter, the text says "an experimental protocol specification" is the deliverable, which is much more constrained. Suggest to use similar wording here also.

The goal should not be as as constrained as the deliverables. The
goal of the PLUS working group is to enable broad followup work 
leveraging PLUS without that work necessarily having to happen in PLUS.

"NEW" is actually a big constraint. IMHO, it acknowledges that as far as IETF semantics
is concerned, that even taking TCP and trying to put it in PLUS would constitute
a NEW protocol and should not be seen as simply a different encap method of
TCP because of the current tie in's between TCP and IP (pseudoheader) that
would have to be reviewed and potentially require modifications to
the transport protocols semantic (see Joe's comments).

"Encrypted" is also a big constraint.

What in this thinking do you not agree to ? What text would you propose ?

> > This
> > has led to the deployment of devices which perform implicit discovery of these
> > characteristics, through inspection of protocol headers all they way up to the
> > application layer, a practice made possible because these headers are sent in
> > the clear.
> 
> Another reason for DPI is that the network can't really in general trust what is signaled by the end points, and so it is attractive to try and obtain "the truth" by DPI (whether that is possible or not in all cases.) I'd like to raise that any new endpoint signaling method - i.e., the work proposed here - will have similar issues. It would be good to have some argument as to why PLUS will be different.

Well, the strategy is "change even current TCP traffic to TCP-NG over PLUS. With TCP-NG
headers encrypted, the middlebox is forced to use PLUS signaling for session
detection". Once thats in in middleboxes, we can also do SCTP-NG over PLUS and
ACMETP over PLUS without the middlebox having any chance to do anything against this,
because it wouldn't be able to see the difference, it only sees PLUS headers/signaling.
(*-NG being acks to the NEW transport considerations from above)

Obviously, this strategy is based on getting some really busines critical
traffic on top of PLUS in the first place to make middleboxes start implementing
PLUS based filtering. Thats the industry dependency we have with a lot of
IETF work outcome, so not unusual. And given how nobody has stood up with a
better plan to achieve the goal defined by PLUS, thats why we should give it
a try. At least i can't see that any of the past IETF work did try this strategy,
so PLUS IMHO can't be shot down by the often heard "IETF been here, done that" mantra.

Not sure about the best way to make this strategy textually more crystal clear in the
charter.

Wrt to trusting the signaling from PLUS in middleboxes, the safe fallback
position seems to be "dear middlebox, just use the UDP port number space for filtering,
you've been doiong that crap with TCP port numbrers for decades, and we couldn't
stop you, so justs continue". Thats safe and pragmatic.

I too would like to see also more than just that to happen in PLUS,
eg: cryptographic authentication mechanisms of PLUS headers with middleboxes.
Alas, i've done a bit of research into this myself, and its quite tricky, so
if i was trying to go for WG chair in PLUS like Brian and Mirja are doing, then
i'd certainly would not want to have this on a first round of deliverables. If
PLUS manages to deliver the pragmatic solution, maybe we can put that onto a
charter for round 2.

> > - allow devices on path to provide information about the path in cleartext
> >  to receiving endpoints, with feedback to the sending endpoint, under
> >  sending endpoint control
> 
> Can we find a better word than "cleartext"? At least my mind immediately jumps to think about unstructured ASCII data in protocol headers. Maybe "unencrypted" or "not integrity-protected"?

"Not integrity-protected" would be wrong. Some form of integrity protection
for either signaling in PLUS might actually be a first step towards (see above)
setting it further apart from prior technologies (Ok, admittedly RSVP
did explore it as well).

"unencrypted" +1 

> > Note that 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 at the level of detail that is useful for the network,
> > while encrypting everything else.
> 
> It would be good to add a half-sentence on how PLUS can achieve that goal (i.e., how can it limit what an app decides to signal)...

"Every PLUS attribute will be subject to IETF privacy inquisition waterboarding".

Oops, sorry. PC version: PLUS attributes will be subject to a privacy review
mechanism (to be defined). 

I would like to see as described in other emails mechanisms to allow
filtering of attributes when PLUS signaling leaves a trusted
controled (eg: home) network as well. Didn't see anyone picking up on that.

Toerless

> > specification, together with an initial registry of types of

> > information that can be exposed using PLUS, clearly aligned to
> > these use cases and requirements. 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 other working
> > groups that could or should 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.
> > TLS) which could be used for encryption of transport protocols
> > running over PLUS.
> 
> Lars



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


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


From nobody Wed May 25 09:27:40 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 419EC12D862 for ; Wed, 25 May 2016 09:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 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] 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 tiOy6g3AU5oE for ; Wed, 25 May 2016 09:27:37 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182FB12D84C for ; Wed, 25 May 2016 09:27:36 -0700 (PDT)
X-AuditID: c1b4fb30-f79486d0000069d0-97-5745d2773717
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D2.55.27088.772D5475; Wed, 25 May 2016 18:27:35 +0200 (CEST)
Received: from ESESSMB303.ericsson.se ([169.254.3.153]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0294.000; Wed, 25 May 2016 18:27:34 +0200
From: Szilveszter Nadas 
To: spud 
Thread-Topic: [Spud] Possible WG-forming follow-on to SPUD BoF
Thread-Index: AQHRtnlqOXzJTGLhXEipvO9ff0Zg+5/JmyqAgAAoIsA=
Date: Wed, 25 May 2016 16:27:34 +0000
Message-ID: 
References: <2b0e574586dd955-00039.Richmail.00049889758880203458@139.com> 
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.149]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7pW75Jddwg0W9whaLLjxldGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpvuJawFe8Uqln9uZW9gnCPUxcjJISFgIvFz2kpWCFtM4sK9 9WxdjFwcQgJHGCWeHfgO5SxhlFi/9T4LSBWbgIVEw8rNbCC2iICERNOZs2DdwgK2Evd/TWKG iNtJXFy0nR3CtpLYdvAoI4jNIqAqceZ2A9gcXgFfiZ/9l8BqhAQmMEp86gzvYuTg4BQIlPh8 MA0kzAh00PdTa5hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf1APKEmsPbydBaJeR2LB7k9s ELa2xLKFr5kh1gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhFi1OLk3LTjYz0Uosyk4uL 8/P08lJLNjECY+Lglt8GOxhfPnc8xCjAwajEw/vgnEu4EGtiWXFl7iFGCQ5mJRHejouu4UK8 KYmVValF+fFFpTmpxYcYpTlYlMR5/V8qhgsJpCeWpGanphakFsFkmTg4pRoY/b9Oirkkrym8 /nd/aLmdsf2HvJ06ajemxbUFudnJGgcW8VjqzDi/MF47ecel1NlJXBOffzad4ZhT+k+kqlL4 a98Ki3db5X6k7b50JWmp+4vc/34LZQQr66cy+f7bYuaz/3hnu69z0QuZZ5NsXte0C5+dn11d 3RddMH9VVrvR+5+zDgksOvVQiaU4I9FQi7moOBEAMW6vmYUCAAA=
Archived-At: 
Subject: Re: [Spud] Possible WG-forming follow-on to SPUD 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, 25 May 2016 16:27:39 -0000

Hi,

I read the charter and most of the discussion on the list and I am wonderin=
g about a few questions.

-scope of PLUS declarations. There was quite an amount of discussion 1) abo=
ut trusted domain firewalls. Also 2) about all middleboxes in the e2e path.=
 So 1) or 2) or both?=20

-"allow applications and transport protocols to explicitly provide limited =
information in cleartext to devices on path" vs. "sending endpoint", "recei=
ving endpoints". The terminology is not 100% clear to me. What is the diffe=
rence between "applications and transport protocols" and "endpoints" here?=
=20

-What do we gain by limited vocabulary ("limited information")? Is not any =
set of declarations too much for some users/countries/whatever and too few =
for others? Is not it forcing the WG participant's ethics by protocol desig=
n?=20

-There was a comment "PLUS header would make this behavior visible to *ever=
yone* on the network. That alone is IMO a reason it wouldn't be deployed in=
 this way". I agree with this, PLUS would/shall make every non-e2e conversa=
tion as explicit as possible. Is that protection enough? Is it possible to =
make this explicitness as transparent as possible? Is it necessary to have =
further protection as e.g. limited vocabulary?

-PLUS as supercookie layer. I think it is pretty easy to insert supercookie=
s to TCP/UDP/QUIC flows already today (see e.g. https://rd.orbit.com/rd/fre=
e/RD623051.pdf ). Of course the receiving end might be able to detect some =
irregularities. One can also imagine a supercookie removal box, but it is q=
uestionable, whether such a general box can be created (unless it acts in a=
 higher and integrity protected layer like TP or APP).

-trust in applications. Who decides what can be communicated over PLUS? Is =
it possible to have PlusBlock (~AdBlock-like function for declarations)? Is=
 that an OS function or a browser function? Shall the device owner be able =
decide to clear or alter declarations? Shall the OS be able to add/remove/p=
olice/alter/sign declarations? Why (for all questions:) )?=20

-The charter still says "goal is to enable the deployment of new, encrypted=
 transport protocols". I think that whether to encrypt or not is the decisi=
on of the TP, and while I agree that encryption really helps there by avoid=
ing further ossification, I think it shall not be the scope/decision of PLU=
S.=20

-From list "This functionality wasn't meant to make firewalls work better t=
han they do today, it was meant to keep from breaking them once the transpo=
rt headers are encrypted." - Why is it a problem if they work better? If so=
me functions are quite broken in them today, why not provide something bett=
er assuming that is acceptable for the endpoints? (Or define "work better" =
better.:) )

Cheers,
Szilveszter




From nobody Thu May 26 01:06: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 AF6EC12D63C for ; Thu, 26 May 2016 01:06:24 -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 dql8RY2tDx-B for ; Thu, 26 May 2016 01:06:21 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 89AFB12D644 for ; Thu, 26 May 2016 01:06:21 -0700 (PDT)
Received: from [IPv6:2001:67c:64:42:5846:5e08:bb92:e693] (unknown [IPv6:2001:67c:64:42:5846:5e08:bb92:e693]) by trammell.ch (Postfix) with ESMTPSA id 43E141A0C1D; Thu, 26 May 2016 10:06:20 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_C95386BB-2725-49F1-9F20-1BAFBD26CB06"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell 
In-Reply-To: 
Date: Thu, 26 May 2016 10:06:27 +0200
Message-Id: 
References:  
To: "Eggert, Lars" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: spud 
Subject: Re: [Spud] updated PLUS charter
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, 26 May 2016 08:06:25 -0000

--Apple-Mail=_C95386BB-2725-49F1-9F20-1BAFBD26CB06
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi, Lars,

Thanks for the comments! Comment-comments inline, language mentioned has =
been added to the working copy of the draft charter.

> On 25 May 2016, at 14:33, Eggert, Lars  wrote:
>=20
> Hi,
>=20
> a few comments:
>=20
> On 2016-05-24, at 12:08, Brian Trammell  wrote:
>> Path Layer UDP Substrate (PLUS)
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>>=20
>> The PLUS working group's goal is to enable the deployment of new, =
encrypted
>> transport protocols, while providing a transport-independent method =
to signal
>> flow semantics under transport and application control.
>=20
> Using the plural here ("new, encrypted transport protocols") sounds =
awfully broad. At the end of the charter, the text says "an experimental =
protocol specification" is the deliverable, which is much more =
constrained. Suggest to use similar wording here also.

Hm; I see the point, it does set up the expectation that we're going to =
have lots of new transport protocols, as opposed to only the common =
substrate. How about:

The PLUS working group's goal is to define a common substrate protocol =
for
transport-independent of flow semantics under application and transport =
layer
control and encryption of transport layer headers, therefore enabling =
the
deployment of new transports in the Internet.

>> The approach from
>> which the working group will start is a shim layer based on the User =
Datagram
>> Protocol (UDP), which provides compatibility with existing =
middleboxes in the
>> Internet as well as ubiquitous support in endpoints, and provides for
>> userspace implementation.
>>=20
>> The current Internet protocol stack does not provide explicit, =
transport-
>> independent signaling of flow characteristics to on-path network =
devices.
>=20
> I think it's been pointed out that this broad statement is incorrect =
in several ways, since we have many explicit, transport-independent =
signaling protocols (RSVP, NSIS, etc.) They are neither in-band (which I =
think you want here) nor are they generally deployed or deployable =
(which is also what I think you want here), so I suggest that this text =
be tightened, so that folks like me don't overreact :-)

Ah, oops... "in-band" fell back out here after the last rewrite of this =
paragraph. :/

>> This
>> has led to the deployment of devices which perform implicit discovery =
of these
>> characteristics, through inspection of protocol headers all they way =
up to the
>> application layer, a practice made possible because these headers are =
sent in
>> the clear.
>=20
> Another reason for DPI is that the network can't really in general =
trust what is signaled by the end points, and so it is attractive to try =
and obtain "the truth" by DPI (whether that is possible or not in all =
cases.) I'd like to raise that any new endpoint signaling method - i.e., =
the work proposed here - will have similar issues. It would be good to =
have some argument as to why PLUS will be different.

Yep. So this becomes two paragraphs now IMO; how about:

The current Internet protocol stack does not provide explicit, in-band,
transport-independent signaling of transport semantics and flow =
characteristics
to on-path network devices. This has led to the deployment of devices =
which
perform implicit discovery of these characteristics, through inspection =
of
protocol headers all they way up to the application layer, a practice =
made
possible because these headers are sent in the clear.

Current signaling approaches are not generally deployable across =
administrative
domains, as they rely on out-of-band enforcement of honesty. There is no
incentive to believe and act on an imperative signal sent by an =
untrusted
endpoint or middlebox. By relying on a small signaling vocabulary in =
terms
of declarations of intentions, tolerances, and explicit tradeoffs, PLUS =
aims
to improve on this situation.

>=20
>> Inspection and modification of unencrypted protocol headers is a
>> key cause of the ossification that makes it hard or impossible to =
deploy new
>> protocols.
>>=20
>> In order to support more ubiquitous deployment of encryption, and the
>> encryption of transport headers to allow deployment of new transport
>> protocols, explicit signaling must be added to the stack, and it must =
be
>> transport protocol independent.
>=20
> I again think you mean "in-band" signaling, since we have out-of-band =
signaling - well, at least many specs for it :-)

Yep; will s/explicit signaling/explicit, in-band signaling/

>> 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. Additionally, 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.
>>=20
>> The PLUS working group will specify a new protocol as a Path Layer
>> User Substrate (PLUS), to support experimental deployment of
>> explicit cooperation between endpoints and devices on path, with the =
following goals:
>>=20
>> - 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).
>>=20
>> - allow applications and transport protocols to explicitly provide
>> limited information in cleartext to devices on path
>>=20
>> - allow devices on path to provide feedback and information about
>> the path in cleartext to sending endpoints, under sending endpoint
>> control
>>=20
>> - allow devices on path to provide information about the path in =
cleartext
>> to receiving endpoints, with feedback to the sending endpoint, under
>> sending endpoint control
>=20
> Can we find a better word than "cleartext"? At least my mind =
immediately jumps to think about unstructured ASCII data in protocol =
headers. Maybe "unencrypted" or "not integrity-protected"?

Yep. Technically, it's "and", and we don't talk about integrity =
protection yet, so the last three become:

- 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

>> Note that 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 at the level of detail that is useful for the network,
>> while encrypting everything else.
>=20
> It would be good to add a half-sentence on how PLUS can achieve that =
goal (i.e., how can it limit what an app decides to signal)...
>=20
>> This is important to avoid future
>> implicit treatment and the resulting ossification, as well as to
>> leverage the principle of least exposure to minimize privacy risks
>> presented by explicit cooperation.
>=20
> ...because as you say that is important.

Yep. So adding a sentence and tweaking the para slightly, how about:

Note that 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.

Thanks, cheers,

Brian

>> Given that the primary goal of PLUS is to enable the deployment of =
arbitrary
>> transport protocols, encrypting transport protocol 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.
>>=20
>> 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
>> these use cases and requirements. The working group will close if
>> it is not able to come to consensus on a protocol design to meet
>> these requirements.
>>=20
>> The working group will additionally aim to identify other working
>> groups that could or should 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.
>> TLS) which could be used for encryption of transport protocols
>> running over PLUS.
>=20
> Lars


--Apple-Mail=_C95386BB-2725-49F1-9F20-1BAFBD26CB06
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

iQIcBAEBCgAGBQJXRq6DAAoJEIoSt78L6kaj9RIP/3DyVpB7vBl2rzt+bPSqeUF8
NY5FpOLFTi6dZocLi/THiDBPL30z/4AEUDcNwqdhyIjCHDUAWj9lTKyjs1OvzcRe
ZNVeIALj2K4D2T4mv95N5MfOU1HqXY9N3nkL+2EQVNYBh37I0FLAIAq38efShXNO
UpBij15CDma0D72WMnDjY3Oyam0XOK0nPPVd/MRarxpg8/Rdi+WopBQIt82iucl4
UgkgqfOM5QdQMocAcdSsqkBWbnbk32yD73Z6cS0a0jgeNzRJgM4PYh8qLy1QUJp0
Vcl1/nzgLVcSxHEqXZGg5aj6F0pzk49Q4TSPMOmwGTrJYw1I49cQufd+RwIIschK
9Fn1xOjv+GraZTppg7jO6rHRjNgMBIKDVbunBZQTPOiiMCc+H6gk5fM6bHEct2p3
4aCNAU5fwXVprEUk+MRwuXIWl4UZIv+FD4TCm287H+yLorHsub0yiobt5DfpQprq
VBhVv3xxjA81ZcSfcLZklW2YJG30yK22gE8zLsCGXTLftBgmB1Uano5O9KxTuCfg
zp0sP4l0gW5uN9IKqkO3eFGnNVy+x8t/JgxiU7MYgVBk0C/mZz8sRaCUeycPPRad
5vt4MxXqocQFiZt5g1O7mRDBa22ZdoMXPZnlLPLoENljcumjm57Qw+LopBOHcSxG
BxPKjInJd+KUWHWWfp5J
=n8Dt
-----END PGP SIGNATURE-----

--Apple-Mail=_C95386BB-2725-49F1-9F20-1BAFBD26CB06--


From nobody Tue May 31 01:29:31 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 27B6712D136 for ; Tue, 31 May 2016 01:29:29 -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 H55D1QCkTqHF for ; Tue, 31 May 2016 01:29:26 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7A16A12B02C for ; Tue, 31 May 2016 01:29:26 -0700 (PDT)
Received: from [IPv6:2001:67c:10ec:52c7:8000::41b] (unknown [IPv6:2001:67c:10ec:52c7:8000::41b]) by trammell.ch (Postfix) with ESMTPSA id 758C11A0CD2; Tue, 31 May 2016 10:28:54 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_AAD6EDD8-238F-420C-BFD7-EF35FD101C21"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell 
In-Reply-To: 
Date: Tue, 31 May 2016 10:29:24 +0200
Message-Id: 
References: <2b0e574586dd955-00039.Richmail.00049889758880203458@139.com>  
To: Szilveszter Nadas 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: spud 
Subject: Re: [Spud] Possible WG-forming follow-on to SPUD 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: Tue, 31 May 2016 08:29:29 -0000

--Apple-Mail=_AAD6EDD8-238F-420C-BFD7-EF35FD101C21
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

hi Szilveszter,

Thanks for the review and the questions; answers to a few of these =
inline below...

> On 25 May 2016, at 18:27, Szilveszter Nadas =
 wrote:
>=20
> Hi,
>=20
> I read the charter and most of the discussion on the list and I am =
wondering about a few questions.
>=20
> -scope of PLUS declarations. There was quite an amount of discussion =
1) about trusted domain firewalls. Also 2) about all middleboxes in the =
e2e path. So 1) or 2) or both?

The design implied by the current requirements is about signaling to all =
middleboxes on the end to end path. It might be interesting to be able =
to target information at a specific middlebox on path (or a =
middlebox-role) if you have an existing cryptographic relationship with =
it (which I think is a superset of your case 1) -- in this case, the =
content would be accessible to the targeted middlebox and the remote =
endpoint, and integrity protected for verification by both the targeted =
middlebox and the endpoint.

We've thought about this use case for a while. The crypto bits are not =
easy to get right IMO, but then, I'm not a crypto guy. I'll note that =
this is something that can probably run on top of a generic signaling =
framework (where you get end-to-end integrity protection of everything, =
plus possibly end-to-middle confidentiality and authenticity of certain =
information elements using a different crypto context), so might be a =
good candidate for an extension that runs over PLUS.

One of the discussions I'd like to see happen at the BoF (...should it =
be approved...) is whether this use case is in scope.

> -"allow applications and transport protocols to explicitly provide =
limited information in cleartext to devices on path" vs. "sending =
endpoint", "receiving endpoints". The terminology is not 100% clear to =
me. What is the difference between "applications and transport =
protocols" and "endpoints" here?

Some information to be exposed (e.g. expected constant data rate) might =
come from the application layer, and some information (e.g. transport =
reordering tolerance, measurement headers that look something like those =
in the PDM DO header the IPPM WG is currently working on) comes from the =
transport layer. In this case, the transport should always allow the =
application to know what is being sent, and to have control over whether =
it is sent, but may keep the application from changing the values =
exposed. This is up to the transport/app API.

> -What do we gain by limited vocabulary ("limited information")? Is not =
any set of declarations too much for some users/countries/whatever and =
too few for others? Is not it forcing the WG participant's ethics by =
protocol design?

A few things; mostly, we gain some control at the process level against =
subversion of endpoint control.

> -There was a comment "PLUS header would make this behavior visible to =
*everyone* on the network. That alone is IMO a reason it wouldn't be =
deployed in this way". I agree with this, PLUS would/shall make every =
non-e2e conversation as explicit as possible. Is that protection enough? =
Is it possible to make this explicitness as transparent as possible? Is =
it necessary to have further protection as e.g. limited vocabulary?

WRT "limited vocabulary", the thing it's hard to defend against here is =
someone defining their own declaration, the meaning of which is secret =
and the name obfuscated. If I see that an app is radiating something to =
the path over PLUS, but I can't understand it, well, I do know that app =
may be up to no good, but I don't know what *kind* of no good. It's not =
clear to me whether that's enough to qualify as "transparent".

> -PLUS as supercookie layer.

First of all, in draft-trammell-spud-req, which assumes a tube ID for =
packet grouping and protocol binding as well as proof of on-path-ness =
for direct feedback, the tube ID is always scoped to 5-tuple and must be =
random. It's explicitly not a supercookie, and I'd assume that this =
requirement holds for PLUS as well. So the built-in signaling that makes =
PLUS work wouldn't be usable as a supercookie here. The size of the tube =
ID should be selected to be sparse enough that possession of a tube ID =
is a probable indication of on-path-ness, but not so sparse that it =
makes sense to ignore the MUST on randomness, and try to stuff a =
"Internet-wide flow ID" into it.

> I think it is pretty easy to insert supercookies to TCP/UDP/QUIC flows =
already today (see e.g. https://rd.orbit.com/rd/free/RD623051.pdf ). Of =
course the receiving end might be able to detect some irregularities. =
One can also imagine a supercookie removal box, but it is questionable, =
whether such a general box can be created (unless it acts in a higher =
and integrity protected layer like TP or APP).

I'll note that if there was a "app-to-path-cleartext-supercookie" =
information element in PLUS (which I don't think would be a useful one =
to have, nor would it meet any goal we have), it would *not* be =
removable by a middlebox, since it would be integrity protected =
end-to-end. A supercookie mitigation box in PLUS would have to notice =
the existence of the supercookie, drop the packet, and send back a =
direct feedback message that said "I'm sorry, I don't permit =
supercookies, please reset the superstrate transport session and try =
again without the supercookie."

> -trust in applications. Who decides what can be communicated over =
PLUS? Is it possible to have PlusBlock (~AdBlock-like function for =
declarations)? Is that an OS function or a browser function? Shall the =
device owner be able decide to clear or alter declarations? Shall the OS =
be able to add/remove/police/alter/sign declarations? Why (for all =
questions:) )?

All good questions, all largely to be handled within the endpoint. =
End-user alteration of the content would probably be an advanced =
administrative/configuration function, but I would suspect there would =
be a checkbox on a privacy preferences tab somewhere for disabling PLUS =
signaling (aside from transport layer semantics) completely.

> -The charter still says "goal is to enable the deployment of new, =
encrypted transport protocols". I think that whether to encrypt or not =
is the decision of the TP, and while I agree that encryption really =
helps there by avoiding further ossification, I think it shall not be =
the scope/decision of PLUS.

Yes, but: in order for integrity protection of declared information to =
work, PLUS needs a mechanism to share a secret between endpoints, so it =
either needs its own keying or it needs to borrow a key generated from =
the superstrate's session key. And if we are to meet the requirement to =
prevent future ossification of the transport layer (or rather, to =
re-ossify around the path layer provided by PLUS), then we need to =
encrypt the transport layer headers. So IMO this is very much in scope.

> -=46rom list "This functionality wasn't meant to make firewalls work =
better than they do today, it was meant to keep from breaking them once =
the transport headers are encrypted." - Why is it a problem if they work =
better?

Unbreaking firewalls in the face of transport encryption is a necessary =
first step. What you do after that is a separate question.

Cheers,

Brian

--Apple-Mail=_AAD6EDD8-238F-420C-BFD7-EF35FD101C21
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

iQIcBAEBCgAGBQJXTUtlAAoJEIoSt78L6kajloYP/R5EQz6MHgzpRF3HXwQANZHd
qGHTKFgkDpcklhJFcuuPJI/WkDjBCTGtnfeOG83n17LfAob9KK5CwvAyhZSrheIm
95kl9OyS5kSAu13TpQC9F/182BpDmXDFTgDEDEB6qB5s2JfJxw6tdaSD6vJ1yTOS
LVqTJ6q8iVOgJUkT7iNkaabld61Hlbrog5c2wFUWsgpMGV0pshi/c04MQFudHGJd
ZzkVtgtiYJZp0aPUz1yirp7UGrnwMFOh15MBK5Hn6nlGboB5ekPKgtd/PGTyQ2Zg
ePy7CavcWYEONGeOFQbqg1gNJFQqDi5NU6O6uK4eeB3YvxYOJ3HFYOdheuDkLdYn
Vy4viS4fpzyqDRcgX7mNUnXIGywR07fiBsAdsKBskHujIFSD0qrtOMjRq6Ot4WOz
GHFynI01X/wRtPdyvxuzWV6pHSpWzKJdteis1RIaVROMuWKHh4oYr4M3oOtbfEOw
5VYEi0x/8I3NRhtnlW7/6+2BEZwG6iSnzPSkxQZsJSzMD236OLbXMAcSe03DecqS
BiGIUTfSre1ncxLYKfiuPs05D7lQ6YdElMfOVZNJu/kVZZYzfO1ZnxvM5IDHiVdO
UCwwArC+G0sCjoVC0UQv00W936nV3WwJqzM1Ew4RaffE+3KBfNxXKThxd/kvEy6e
f8J9T9aJdPuPSOhaUXBU
=vHY+
-----END PGP SIGNATURE-----

--Apple-Mail=_AAD6EDD8-238F-420C-BFD7-EF35FD101C21--


From nobody Tue May 31 09:55: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 001B912D629 for ; Tue, 31 May 2016 09:55:48 -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 m4Qs7C9o9evK for ; Tue, 31 May 2016 09:55:46 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 4EC2E12D624 for ; Tue, 31 May 2016 09:55:46 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id p64so98884219ioi.2 for ; Tue, 31 May 2016 09:55:46 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=M/WFRX35TybmBwgPd1KtJM6pMX1+8KiVGuwAWZPHYvI=; b=NmB971Z7I3QcS0P2V/ttlQKWvQNbAQ2KrIanPEMen+3OU0wVwyKf4RcpGFTC6V9bNs NXiz2Jwb59Cjebq6Niuu+HSIqZ6FCbJXkPVRvTcu0TaT3cbMmulr4nOdMX2gAXbokgFQ iZxdx2S6olCp39TwlkmlOnmaqZabLOZat68pckWYgRP+/mF0Zu8wg/ktu1+AFVyFumLA 318jLO7vtgDZTCaDOF0fvB93qEx+xXGIiai/6YT6haW0PHhYurStLbVmWkbYQt0XXxbK mBvTYDAbg1I1SlEAQGwY7px4U4W8/QM2bBRQMGbnsiLXB0BpEdEY9HUdwbLLmItHq1tg a+FA==
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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=M/WFRX35TybmBwgPd1KtJM6pMX1+8KiVGuwAWZPHYvI=; b=F4lBLBUyXMh0NsfQkufNW8duCgMl515Q76rfUd9axrQtm3yoSitXQthPFpwSN9jIvs W/0naTfUBF4ylWrRQRqshlZQqduOLnFvp3FSLaYnpxcFeAdCLujkg84bn9sVuSLIMx2H Z/1LPRQ7vSWlGYuoA/hzUFbNPnUVMey7fnwBI2e6cyRoCD7sdzxJdUxkfM7GrYdEPDGW uQK+CoCjhtpoE6OQHaFmIoOA/sJ28e8d1YZuL5+MBv5VpXuOXqxt3chXFaY2GCeUDcg/ jn01FCkEwpv2jXWF+Qgk/pHJ1HhvOuv76swwVUJsGYeWzYzW8Z7tj/Fo0cgXwrqSJSv8 bx1w==
X-Gm-Message-State: ALyK8tIdA+gTN2njoueAj17O53g0mxo6JTLYh9PpRoG8VirdNvZLfzTDHbGcdEgbWS4KzO53SpOqqd1+Jaq54w==
MIME-Version: 1.0
X-Received: by 10.107.162.131 with SMTP id l125mr28451233ioe.84.1464713745156;  Tue, 31 May 2016 09:55:45 -0700 (PDT)
Received: by 10.107.44.203 with HTTP; Tue, 31 May 2016 09:55:44 -0700 (PDT)
In-Reply-To: 
References: <2b0e574586dd955-00039.Richmail.00049889758880203458@139.com>   
Date: Tue, 31 May 2016 09:55:44 -0700
Message-ID: 
From: Tom Herbert 
To: Brian Trammell 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Szilveszter Nadas , spud 
Subject: Re: [Spud] Possible WG-forming follow-on to SPUD 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: Tue, 31 May 2016 16:55:49 -0000

On Tue, May 31, 2016 at 1:29 AM, Brian Trammell  wrote:
> hi Szilveszter,
>
> Thanks for the review and the questions; answers to a few of these inline=
 below...
>
>> On 25 May 2016, at 18:27, Szilveszter Nadas  wrote:
>>
>> Hi,
>>
>> I read the charter and most of the discussion on the list and I am wonde=
ring about a few questions.
>>
>> -scope of PLUS declarations. There was quite an amount of discussion 1) =
about trusted domain firewalls. Also 2) about all middleboxes in the e2e pa=
th. So 1) or 2) or both?
>
> The design implied by the current requirements is about signaling to all =
middleboxes on the end to end path. It might be interesting to be able to t=
arget information at a specific middlebox on path (or a middlebox-role) if =
you have an existing cryptographic relationship with it (which I think is a=
 superset of your case 1) -- in this case, the content would be accessible =
to the targeted middlebox and the remote endpoint, and integrity protected =
for verification by both the targeted middlebox and the endpoint.
>
> We've thought about this use case for a while. The crypto bits are not ea=
sy to get right IMO, but then, I'm not a crypto guy. I'll note that this is=
 something that can probably run on top of a generic signaling framework (w=
here you get end-to-end integrity protection of everything, plus possibly e=
nd-to-middle confidentiality and authenticity of certain information elemen=
ts using a different crypto context), so might be a good candidate for an e=
xtension that runs over PLUS.
>
> One of the discussions I'd like to see happen at the BoF (...should it be=
 approved...) is whether this use case is in scope.
>
>> -"allow applications and transport protocols to explicitly provide limit=
ed information in cleartext to devices on path" vs. "sending endpoint", "re=
ceiving endpoints". The terminology is not 100% clear to me. What is the di=
fference between "applications and transport protocols" and "endpoints" her=
e?
>
> Some information to be exposed (e.g. expected constant data rate) might c=
ome from the application layer, and some information (e.g. transport reorde=
ring tolerance, measurement headers that look something like those in the P=
DM DO header the IPPM WG is currently working on) comes from the transport =
layer. In this case, the transport should always allow the application to k=
now what is being sent, and to have control over whether it is sent, but ma=
y keep the application from changing the values exposed. This is up to the =
transport/app API.
>
>> -What do we gain by limited vocabulary ("limited information")? Is not a=
ny set of declarations too much for some users/countries/whatever and too f=
ew for others? Is not it forcing the WG participant's ethics by protocol de=
sign?
>
> A few things; mostly, we gain some control at the process level against s=
ubversion of endpoint control.
>
>> -There was a comment "PLUS header would make this behavior visible to *e=
veryone* on the network. That alone is IMO a reason it wouldn't be deployed=
 in this way". I agree with this, PLUS would/shall make every non-e2e conve=
rsation as explicit as possible. Is that protection enough? Is it possible =
to make this explicitness as transparent as possible? Is it necessary to ha=
ve further protection as e.g. limited vocabulary?
>
> WRT "limited vocabulary", the thing it's hard to defend against here is s=
omeone defining their own declaration, the meaning of which is secret and t=
he name obfuscated. If I see that an app is radiating something to the path=
 over PLUS, but I can't understand it, well, I do know that app may be up t=
o no good, but I don't know what *kind* of no good. It's not clear to me wh=
ether that's enough to qualify as "transparent".
>
>> -PLUS as supercookie layer.
>
> First of all, in draft-trammell-spud-req, which assumes a tube ID for pac=
ket grouping and protocol binding as well as proof of on-path-ness for dire=
ct feedback, the tube ID is always scoped to 5-tuple and must be random. It=
's explicitly not a supercookie, and I'd assume that this requirement holds=
 for PLUS as well. So the built-in signaling that makes PLUS work wouldn't =
be usable as a supercookie here. The size of the tube ID should be selected=
 to be sparse enough that possession of a tube ID is a probable indication =
of on-path-ness, but not so sparse that it makes sense to ignore the MUST o=
n randomness, and try to stuff a "Internet-wide flow ID" into it.
>
>> I think it is pretty easy to insert supercookies to TCP/UDP/QUIC flows a=
lready today (see e.g. https://rd.orbit.com/rd/free/RD623051.pdf ). Of cour=
se the receiving end might be able to detect some irregularities. One can a=
lso imagine a supercookie removal box, but it is questionable, whether such=
 a general box can be created (unless it acts in a higher and integrity pro=
tected layer like TP or APP).
>
> I'll note that if there was a "app-to-path-cleartext-supercookie" informa=
tion element in PLUS (which I don't think would be a useful one to have, no=
r would it meet any goal we have), it would *not* be removable by a middleb=
ox, since it would be integrity protected end-to-end. A supercookie mitigat=
ion box in PLUS would have to notice the existence of the supercookie, drop=
 the packet, and send back a direct feedback message that said "I'm sorry, =
I don't permit supercookies, please reset the superstrate transport session=
 and try again without the supercookie."
>
>> -trust in applications. Who decides what can be communicated over PLUS? =
Is it possible to have PlusBlock (~AdBlock-like function for declarations)?=
 Is that an OS function or a browser function? Shall the device owner be ab=
le decide to clear or alter declarations? Shall the OS be able to add/remov=
e/police/alter/sign declarations? Why (for all questions:) )?
>
> All good questions, all largely to be handled within the endpoint. End-us=
er alteration of the content would probably be an advanced administrative/c=
onfiguration function, but I would suspect there would be a checkbox on a p=
rivacy preferences tab somewhere for disabling PLUS signaling (aside from t=
ransport layer semantics) completely.
>
>> -The charter still says "goal is to enable the deployment of new, encryp=
ted transport protocols". I think that whether to encrypt or not is the dec=
ision of the TP, and while I agree that encryption really helps there by av=
oiding further ossification, I think it shall not be the scope/decision of =
PLUS.
>
> Yes, but: in order for integrity protection of declared information to wo=
rk, PLUS needs a mechanism to share a secret between endpoints, so it eithe=
r needs its own keying or it needs to borrow a key generated from the super=
strate's session key. And if we are to meet the requirement to prevent futu=
re ossification of the transport layer (or rather, to re-ossify around the =
path layer provided by PLUS), then we need to encrypt the transport layer h=
eaders. So IMO this is very much in scope.
>
>> -From list "This functionality wasn't meant to make firewalls work bette=
r than they do today, it was meant to keep from breaking them once the tran=
sport headers are encrypted." - Why is it a problem if they work better?
>
> Unbreaking firewalls in the face of transport encryption is a necessary f=
irst step. What you do after that is a separate question.
>
Brian,

Like Szilveszter mentions the choice to encrypt must be up to the
application or TP. Applications should not have to ask for permission
from the network to use encryption, nor can deployment of encryption
be gated on middleboxes being updated with PLUS (it's unrealistic to
think we are going to wait N years for PLUS deployment in middleboxes
before starting to encrypt transport headers).

As for "Unbreaking firewalls in the face of transport encryption is a
necessary first step" can you elaborate exactly how firewalls are
broken in this regard? I don't see a good description of this problem
in RFC7663 and your UDP data as well as the fact that QUIC is
currently being deployed don't seem to be illustrating a widespread
reachability issue using UDP in the Internet.

Thanks,
Tom

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