From nobody Wed Jun 1 00:04: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 6B7B212D0F8 for ; Wed, 1 Jun 2016 00:04:28 -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 mPkRVu0fWNBJ for ; Wed, 1 Jun 2016 00:04:26 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id C4D94128E19 for ; Wed, 1 Jun 2016 00:04:20 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id 502BC1A0F1F; Wed, 1 Jun 2016 09:04:18 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4BE909AB-D578-4C8A-AAFF-0915C124765D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Wed, 1 Jun 2016 09:04:16 +0200 Message-Id: <409F4136-9596-4195-88AD-569567979218@trammell.ch> References: <2b0e574586dd955-00039.Richmail.00049889758880203458@139.com> To: Tom Herbert X-Mailer: Apple Mail (2.3124) 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: Wed, 01 Jun 2016 07:04:28 -0000 --Apple-Mail=_4BE909AB-D578-4C8A-AAFF-0915C124765D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Tom, snipping a bunch of the message; replies inline... >> Unbreaking firewalls in the face of transport encryption is a = necessary first step. What you do after that is a separate question. >>=20 > Brian, >=20 > 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, Of course not. > 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). And of course not. I'm having a hard time seeing where anyone has = proposed otherwise in this thread. Since the protocol bounded by draft-trammell-spud-req relies on the = superstrate to provide secrets for integrity protection, we presume = encryption of the superstrate by default. Indeed, one could envision = PLUS' selective exposure and transport state exposure mechanisms being = implemented as extensions to DTLS, since it already provides most of the = pieces we'd need. The difficulty we see in PLUS is what happens when an = application/transport chooses *not* to encrypt; when the superstrate = doesn't provide exchange of secrets, you get no integrity protection for = the PLUS information either. Indeed, in this case the *only* benefit = PLUS provides is a common framing and data model for information exposed = to middleboxes, which as you note is rather useless in the initial = phases of deployment. And this might be an acceptable corner case = anyway: a decision not to encrypt can at this point be taken as an = explicit statement that the endpoint is unconcerned about its packets = being thoroughly inspected and mangled by the network. > 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. Two issues: blocking and state maintenance. On the former: QUIC falls back to TCP 6%-9% of the time; our RIPE Atlas = numbers, which undercount enterprise access networks, point to 3.3% to = 3.6% of measured networks blocking outbound UDP (on ports other than = 53). These are acceptable numbers if you always have a fallback (which = QUIC does built-in, since H2 runs acceptably over TCP, and where = something like TAPS comes in for other applications). But it seems to me = we can do better than that. Providing firewall vendors and = administrators with an incentive to unblock would help here, and = exposure of state information so that new transports over UDP can be = managed like TCP is, I think, a good one. On the latter: have a look at the spectrum of NAT timeouts between TCP = and UDP in the paper Lars sent to maprg (in the "Is UDP a trash heap?" = thread): population median (and mode) UDP timeout for tested devices on = flows that look like QUIC was 3 minutes (figures 4,5), versus 60 minutes = for TCP (figure 6). See also Jim's slide on NAT unbinding from tsvarea = in Vancouver = (https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf): = this test is, I believe, roughly equivalent to the one shown in figure 3 = in Lars' paper, with equivalent results: median is about 1.5 min. Both = datasets suggest a simple heuristic for keepalives: send a useless = packet every thirty seconds if you care about keeping the connection up = and don't have anything to say. The reason these timeouts are longer for TCP is that TCP exposes state = maintenance information to the path. If there is a common mechanism for = UDP-based transport protocols for exposing equivalent information, with = an equivalent level of trust as we can place in TCP flags (formally = zero), then the timeouts can tend over time to be longer, reducing the = need for unproductive keepalive traffic. Cheers, Brian > Thanks, > Tom >=20 >> Cheers, >>=20 >> Brian >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >>=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_4BE909AB-D578-4C8A-AAFF-0915C124765D 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 iQIcBAEBCgAGBQJXTojxAAoJEIoSt78L6kajLA4QALNBDyhn5/++XAstMcVyOzT9 Xugmgpn/U6I6YixwYswK1VcDUXBlviPXRFw7E0OejAZR2qbFBVTKqUUGgZNQ9bAx HfZB3tm3/qxRpUTuE7+0T78dKrfAEQcFgkLi57GaCi/Y74NfnnXrQR1ATjMcHqQJ 85TYyDyWCzjsrDI2MoCLOpGJxtPadIl8AalhoCtOZ1smraQjJKn7EBIZ1vBHrj0s yQYeyaw+EnO/iSH2z9PFaHScrm2s6BR/hQC6GuHrsvZtHMO4i79lkSy1o1L6Vffd Uu5VvUNal7RuZHqZk8aQWnBQs+WhbzyWEdM8Nu+SnvUOEzeAJ4C/9OIxC8KJDqoo nJzqr02anOkDDzFaNa2p+TlR8kukJ3VdafLp/wlfWdeRZbCqUBptzCD8zHWdY4II 48xC2dmkjLMOyo0Te5cWRRlkai6Y0IcGM2LU8PhmTeqCs+NX0kLkOCMagV4pIXIY GMToaZEFbrbFdUV7Ud/LRXFHk/Y6KPUBa+lp9Seu9znMniTjAQH/K1QXxefsmZ31 HLM4joJ0FHasfrBTP1vPg99hfxbLRBhUdj9l1IFwNUK88rAxP/GI2GgoU6Rg4LMS Hsz8u8fYFPb1V22+eQ1K1PW0niIxAcQotQyWPtLWDqDYBVHyGov4BTtroGkNkCgM 7tcEJedtn4+ecKKc/pdv =a0wL -----END PGP SIGNATURE----- --Apple-Mail=_4BE909AB-D578-4C8A-AAFF-0915C124765D-- From nobody Wed Jun 1 03:44: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 5F0CD12B059 for ; Wed, 1 Jun 2016 03:44:53 -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 JgfVtaaswiCk for ; Wed, 1 Jun 2016 03:44:51 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 98ACC12B027 for ; Wed, 1 Jun 2016 03:44:49 -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 9AC241A04E8 for ; Wed, 1 Jun 2016 12:44:48 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_8BE5DFB4-25A0-43C9-A59A-69815B0A2EE0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 1 Jun 2016 12:44:47 +0200 Message-Id: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> To: spud Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 10:44:53 -0000 --Apple-Mail=_8BE5DFB4-25A0-43C9-A59A-69815B0A2EE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've taken another editing pass to tighten the charter; results inline = below at on GitHub (https://github.com/ietf-plus/charter). We think this = is getting close to something it would be useful to discuss and = wordsmith at a BoF. Further comments welcome. 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 define a common shim layer atop the = User Datagram Protocol (UDP) to provide a transport-independent method to = signal flow semantics under transport and application control, necessary to = enable the deployment of new, encrypted transport protocols within the existing Internet. UDP provides compatibility with currently deployed middleboxes = as well as ubiquitous support in endpoints, and supports userspace = implementation of new transport protocols. The working group will not specify any new transport protocols. The current Internet protocol stack does not provide explicit, in-band, transport-independent signaling to on-path network devices. This has led = to the deployment of devices which perform implicit discovery of transport semantics and traffic characteristics via inspection of protocol headers = and payload, a practice made possible when these are sent in the clear. In order to support more ubiquitous deployment of encryption, and the encryption of transport headers to allow deployment of new transport protocols, explicit in-band signaling must be added to the stack. This signaling must be transport protocol independent, and the types of = information signaled must be based on characteristics that can be independently = verified by devices on path, or that can be usefully applied without requiring a = trust relationship between endpoints and the path. Further, a feedback channel = that provides information from on-path devices back to endpoints and = applications, e.g. for error handling, is essential for the deployment and success of = an explicit cooperation approach. While IP would seem to be the natural home for this facility, both IPv4 = and IPv6 options and extensions have deployment problems on their own, which = makes it hard to include any additional information in these protocols. The PLUS working group will specify a new protocol as a Path Layer UDP Substrate (PLUS), to support experimental deployment of explicit cooperation between endpoints and devices on path, with the = following goals: - enable ubiquitous deployment of encrypted higher layer protocols by providing exposure of basic TCP-like semantics (e.g. SYN, FIN, RST flags) to devices on path (e.g. NATs and firewalls). - allow applications and transport protocols to explicitly provide limited information with integrity protection to devices on path - allow devices on path to provide unencrypted feedback and information about the path directly to sending endpoints, under sending endpoint control - allow devices on path to provide unencrypted information about the path to receiving endpoints, with encrypted feedback to the sending endpoint, under sending endpoint control This approach explicitly gives the control of information exposure back = the application and/or transport layer protocol on the end host. It is the = goal of PLUS to minimize the information exposed, to make information exposure transparent, and to limit the level of detail to that useful for network treatment, while encrypting everything else. Endpoint verification of signaling integrity, careful design of minimal data structures, and restrictive policies for registration of signals can help to meet this = goal. This is important to avoid future implicit treatment and resulting ossification, as well as to minimize the privacy risks presented by = explicit cooperation. Given that the primary goal of PLUS is to enable the deployment of = transport protocols with encrypted headers, we assume that the higher-layer = protocol can provide an encryption context that can be used by PLUS to provide authentication, integrity, and encryption where needed. The primary = threat model to defend against will be modification or deletion of exposed information by middleboxes and other devices on path, by allowing a = remote endpoint to detect modifications. The working group will start with an initial set of use cases (see = draft- kuehlewind-spud-use-cases) and requirements (see = draft-trammell-spud-req), taken from experience with the Substrate Protocol for User Datagrams = (SPUD) prototype. The working group's main output will be an experimental = protocol specification, together with an initial registry of types of information = that can be exposed using PLUS, clearly aligned to the use cases determined = by the working group. The working group will close if it is not able to come to consensus on a protocol design to meet these requirements. The working group will additionally aim to identify and work with other working groups that could address parts of these requirements within = existing protocols, e.g. by specifying new protocol extensions, or as input for = on- going standardization work. It will aim to work with working groups = defining encryption protocols (e.g. DTLS) which could be used for encryption of transport protocols running over PLUS. --Apple-Mail=_8BE5DFB4-25A0-43C9-A59A-69815B0A2EE0 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 iQIcBAEBCgAGBQJXTrygAAoJEIoSt78L6kajaEoP/2lhFx1Kgg0QyoHVoGWL8R1J ckBz/v4HyganFxXBFDkbf5VCTNYuOUEPho6Tz6EmcdH0r6S6ep5SNvD19xevDRs0 CSHeMgyulLY6MYPe9bgQGzZ+qMUzJ2CYvNYCzQqOA2KMDt5MTmpuB15qdOAZoqtF Tb+00JqOx2upBFaTyERrHk0sJMPDDOCYYA94vbbAxPUGm9ZN0kPRjMN+3OwjoOgm ZyEk+LHtPi50NIbaPVVzr16pnWEV2SMpu0sGp06zcdxokaNWs93BGpG+1UwMtBb8 vhx0om/FN2jRTsMYo8hUFwjuF6FLnlYwisbKc95QTxyb83ytyG54DPII1FOTPc+P 0+tgA+op+D/eaY75EKW5pNsAuKqHjA950aXMom0mMxcbT8wKc3gBJXhPL6HZU9qC i9YorQCD8VK1dzQ2hT0r1jN7lLT0ItGwGt7iqdb6+40LrH0Cwg36EJHQEdY0VDsT KkdTSL9K2yO7tZR4KNL5ldOWoKzXUa1Bvk9jGd294F6sjwuRpBlc22/E4TV7bmhp 9S0gw2l7/Q5miVJE3OM/C00CUJeGAE5VL8LOhkj5q34WKPGh9sWDMx8U8dm41j/F sB5uNUeiacTX0aKRt3y8jWxcqt24SeKI2d3dtUt2KluPNF1VGnuJVJXCH1cz/pET LyVHe0JeEyea3iJI1+nc =xrCa -----END PGP SIGNATURE----- --Apple-Mail=_8BE5DFB4-25A0-43C9-A59A-69815B0A2EE0-- From nobody Wed Jun 1 09:02:42 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141AF12D5C7 for ; Wed, 1 Jun 2016 09:02:41 -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 7HH_vURUbiP8 for ; Wed, 1 Jun 2016 09:02:38 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E434112D5CD for ; Wed, 1 Jun 2016 09:02:27 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-d8-574f0712b757 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C0.00.18043.2170F475; Wed, 1 Jun 2016 18:02:26 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.158]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0294.000; Wed, 1 Jun 2016 18:02:25 +0200 From: Szilveszter Nadas To: Brian Trammell Thread-Topic: [Spud] Possible WG-forming follow-on to SPUD BoF Thread-Index: AQHRtnlqOXzJTGLhXEipvO9ff0Zg+5/JmyqAgAAoIsCACNtMAIACLM+w Date: Wed, 1 Jun 2016 16:02:25 +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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbHdQFeI3T/cYPdBIYuNLe/YLBZdeMro wOSxZMlPJo8n+2eyBDBFcdmkpOZklqUW6dslcGWse9XLVvBLreLg9tlsDYw98l2MnBwSAiYS r059YYOwxSQu3FsPZHNxCAkcYZSYe+AAO4SzmFGid+NkFpAqNgELiYaVm8E6RARUJbobL7GD 2MwCEhKLJn1iArGFBWwl7v+axAxRYydxcdF2dgjbTeL/xC2MIDaLgIrE2strwWbyCvhK7Pl9 gxliWSeTxOHVs8ASnAL2EuefLwNbxgh03vdTa5gglolL3HoynwnibAGJJXvOM0PYohIvH/9j hbAVJdqfNjBC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUV o2hxanFxbrqRkV5qUWZycXF+nl5easkmRmAMHdzy22oH48HnjocYBTgYlXh4Ezj9woVYE8uK K3MPMUpwMCuJ8Dqy+IcL8aYkVlalFuXHF5XmpBYfYpTmYFES5/V/qRguJJCeWJKanZpakFoE k2Xi4JRqYLSY90HExDZ3zRPlXfLnj1wtqZpVcIDhtLTEtvSe5DMSx1v3V7m3qhXe13MLizu6 /EDT0gd3PLWZPki8/DO79Y6ZnVoUn6bzghkvjE0Y3eWftHzI3FSuqafpZsYXZa23VPCy284H shV/SnZ22S5RYNj64reHNP/eqZ7VZTriiQ9m/J0quTLLRImlOCPRUIu5qDgRAFIQzrOdAgAA 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, 01 Jun 2016 16:02:41 -0000 Hi Brian, Thanks. Some further comments inside. Cheers, Sz. > > -"allow applications and transport protocols to explicitly provide limi= ted > information in cleartext to devices on path" vs. "sending endpoint", "rec= eiving > endpoints". The terminology is not 100% clear to me. What is the differen= ce > between "applications and transport protocols" and "endpoints" here? >=20 > 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 appl= ication > 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. I see. And now I can ask my real question: is it intentional to limit decla= rations to "applications" and "transport protocols" in the "endpoint"? What= about other entities like a middleware? Or an OS level function which acts= on behalf of the user's interest vs. the applications being maybe too self= ish?=20 (I refer to Fig. 1. of https://www.iab.org/wp-content/IAB-uploads/2015/08/M= aRNEW_1_paper_16.pdf ) > > -What do we gain by limited vocabulary ("limited information")? Is not = any > set of declarations too much for some users/countries/whatever and too fe= w > for others? Is not it forcing the WG participant's ethics by protocol des= ign? >=20 > A few things; mostly, we gain some control at the process level against > subversion of endpoint control. Please elaborate it more. I do not get it. > > -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 po= ssible to > make this explicitness as transparent as possible? Is it necessary to hav= e further > protection as e.g. limited vocabulary? >=20 > WRT "limited vocabulary", the thing it's hard to defend against here is > someone defining their own declaration, the meaning of which is secret an= d > the name obfuscated. If I see that an app is radiating something to the p= ath > 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 wheth= er > that's enough to qualify as "transparent". Another way to implement it in the long run is to delegate the task of decl= arations to a trusted piece of software (again like in the marnew paper). T= hen this trusted piece could decide whether to send any data, and to encryp= t it also. Of course it is hard to prevent steganography in both cases. > 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, nor w= ould > it meet any goal we have), it would *not* be removable by a middlebox, si= nce > 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 pack= et, > and send back a direct feedback message that said "I'm sorry, I don't per= mit > supercookies, please reset the superstrate transport session and try agai= n > without the supercookie." This makes inserting any middlebox declaration to the packet impossible. Th= at was discussed before, is it not in scope anymore?=20 > > -The charter still says "goal is to enable the deployment of new, encry= pted > transport protocols". I think that whether to encrypt or not is the decis= ion 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. >=20 > 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 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 preve= nt > future ossification of the transport layer (or rather, to re-ossify aroun= d the > path layer provided by PLUS), then we need to encrypt the transport layer > headers. So IMO this is very much in scope. This definitely makes sense. I am not sure whether this is the best comprom= ise though.=20 The requirement is to be able to provide some kind of integrity protection = and encryption capabilities in PLUS, in a lightweight way. Reusing TP secur= ity context is definitely a solution, there might be issues with that, not = sure. From nobody Wed Jun 1 09:17: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 3F32812D533 for ; Wed, 1 Jun 2016 09:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 vPY7kGOc1yUY for ; Wed, 1 Jun 2016 09:17:24 -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 48D0812D0DD for ; Wed, 1 Jun 2016 09:17:24 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-d5-574f0a92e23e Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8A.BF.27088.29A0F475; Wed, 1 Jun 2016 18:17:22 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.158]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Wed, 1 Jun 2016 18:17:22 +0200 From: Szilveszter Nadas To: spud Thread-Topic: Minor comment to draft-trammell-spud-req-04 Thread-Index: AdG8H7VsWuoEeGVmRyqe85TK4+oeTg== Date: Wed, 1 Jun 2016 16:17:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE240FDC85ESESSMB303erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7qO4kLv9wg7sbtSwWXXjK6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEf75jEXNEhWTDn6mq2BcZZYFyMnh4SAicSaRS2MELaYxIV7 69m6GLk4hASOMEq8+9/JAuEsZpT43L2cGaSKTcBComHlZjYQW0RAQqLpzFlWEFtYwFTiZ/sX doi4lcSu/j9MXYwcQLaexMUZRSBhFgEViYuTr4G18gr4Spz5uxmslRFo8fdTa5hAbGYBcYlb T+YzQRwkILFkz3lmCFtU4uXjf6wQtqJE+9MGRoj6fIm7n6+xQMwUlDg58wnLBEahWUhGzUJS NgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWpyUm25kpJdalJlcXJyfp5eX WrKJERgTB7f8NtjB+PK54yFGAQ5GJR7eBE6/cCHWxLLiytxDjBIczEoivJ85/MOFeFMSK6tS i/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MDLlMK+6yvUrJSbN/fMS oZORp21lW8R28R4siDbPXpbyce45rYIg1/z97r/4zRb9POLOmXRukjxb3w2TiKo/YSotRQJR xxqjF8aVCtzSlfjyPCrvtXXQ3ElxvA3dth3TD12SfC4wk1tCfWpfT52FinLz0Y9bi3701Vik PvkXZb6iKuXA0jOLlFiKMxINtZiLihMBAwwmXYUCAAA= Archived-At: Subject: [Spud] Minor comment to draft-trammell-spud-req-04 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, 01 Jun 2016 16:17:26 -0000 --_000_EA4C43BE752A194597B002779DF69BAE240FDC85ESESSMB303erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, -shall not one of the "superstrate"s be "substrate" in this part? "7.1. Middlebox Traversal SPUD, including all path-to-endpoint and endpoint-to-path signaling as well as superstrate and superstrate payload" Sz. --_000_EA4C43BE752A194597B002779DF69BAE240FDC85ESESSMB303erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

-shall not one of the “superstrate”s be = “substrate” in this part?

“7.1.  Middlebox Traversal

   SPUD, including all path-to-endpoint = and endpoint-to-path signaling

   as well as superstrate and superstrat= e payload”

Sz.

--_000_EA4C43BE752A194597B002779DF69BAE240FDC85ESESSMB303erics_-- From nobody Thu Jun 2 03:12:14 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BE812D6CC; Thu, 2 Jun 2016 03:12:13 -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 afgUNFLibfq7; Thu, 2 Jun 2016 03:12:11 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id E272412D6C8; Thu, 2 Jun 2016 03:12:10 -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 47B951A0B37; Thu, 2 Jun 2016 12:11:40 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E2BE0042-0198-4C1F-9748-FB7454C09868"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> Date: Thu, 2 Jun 2016 12:11:40 +0200 Message-Id: <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-tsvwg-rfc5405bis@ietf.org, quic@ietf.org, tsvwg-chairs@ietf.org, spud , tsvwg WG Subject: Re: [Spud] Last Call: (UDP Usage Guidelines) to Best Current Practice 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, 02 Jun 2016 10:12:13 -0000 --Apple-Mail=_E2BE0042-0198-4C1F-9748-FB7454C09868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Apologies for the late last call comment; I have only one, relatively = minor. I hope it's still useful. I understand that Section 3 was written to encourage application = developers not to roll their own transports ("trust us when we say this = is hard, this document is a list of reasons why") but as written it = would seem to discourage transport innovation atop UDP (e.g. QUIC, the = RTCWEB data channel, anything-over-PLUS), which I very much hope was not = the intent. The problematic recommendation is in the second paragraph: These mechanisms are difficult to implement correctly. For most applications, the use of one of the existing IETF transport protocols is the simplest method of acquiring the required mechanisms. Doing so also avoids issues that protocols using a new IP protocol number face when being deployed over the Internet, where middleboxes that only support TCP and UDP are not rare. Consequently, the RECOMMENDED alternative to the UDP usage described in the remainder of this section is the use of an IETF transport protocol such as TCP [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram Congestion Control Protocol (DCCP) [RFC4340] with its different congestion control types [RFC4341][RFC4342][RFC5622]. First, this paragraph ignores potential deployment issues with any of = these other than TCP, which risks seeming out of touch, but this is a = minor point and probably not worth a late edit. Second, I'm concerned = this recommendation could be taken as broader than intended, against the = definition of any new transport protocol encapsulated within UDP that = performs substantially the same function as the listed protocols. I think this can be made clearer by simply adding to the list of = examples: NEW: These mechanisms are difficult to implement correctly. For most applications, the use of one of the existing IETF transport protocols is the simplest method of acquiring the required mechanisms. Doing so also avoids issues that protocols using a new IP protocol number face when being deployed over the Internet, where middleboxes that only support TCP and UDP are not rare. Consequently, the RECOMMENDED alternative to the UDP usage described in the remainder of this section is the use of an IETF transport protocol such as TCP [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram Congestion Control Protocol (DCCP) [RFC4340] with its different congestion control types [RFC4341][RFC4342][RFC5622], or transport protocols specified by the IETF in the future. and removing the examples from the summary in section 7: OLD: | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | NEW: | SHOULD use a full-featured transport | | Thanks, cheers, Brian > On 18 May 2016, at 02:17, The IESG wrote: >=20 >=20 > The IESG has received a request from the Transport Area Working Group = WG > (tsvwg) to consider the following document: > - 'UDP Usage Guidelines' > as Best Current Practice >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > The User Datagram Protocol (UDP) provides a minimal message-passing > transport that has no inherent congestion control mechanisms. This > document provides guidelines on the use of UDP for the designers of > applications, tunnels and other protocols that use UDP. Congestion > control guidelines are a primary focus, but the document also > provides guidance on other topics, including message sizes, > reliability, checksums, middlebox traversal, the use of ECN, DSCPs, > and ports. >=20 > Because congestion control is critical to the stable operation of = the > Internet, applications and other protocols that choose to use UDP as > an Internet transport must employ mechanisms to prevent congestion > collapse and to establish some degree of fairness with concurrent > traffic. They may also need to implement additional mechanisms, > depending on how they use UDP. >=20 > Some guidance is also applicable to the design of other protocols > (e.g., protocols layered directly on IP or via IP-based tunnels), > especially when these protocols do not themselves provide congestion > control. >=20 > This document obsoletes RFC5405 and adds guidelines for multicast = UDP > usage. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 --Apple-Mail=_E2BE0042-0198-4C1F-9748-FB7454C09868 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 iQIcBAEBCgAGBQJXUAZcAAoJEIoSt78L6kajg0sP/05YYUgj6zyRY90XlrwTCYhF uLYouDERANLIRVa+Mwx1Ipk0D/tCrBj/jeuWmlxqakzW7wPm9NfF97UTweqpRwaW KjmOEEMm5QVIuRmnTOZUyKvF0s66xxiMpkhlpS4qxmLmL1R/Ff8Pd+v9UdEenZR7 ZYRdo8hGRacQt22Fhgr5G88lmuRrDwEcDNHpuSNYkcE1LQRgKZuSrp70J78aaHQV Hclxaejz8IzIj4HJt2+jNB512mELM455EfogH3Lcc3ue7lkgBT8Z4+d9A5lAyjjk SjwsvnOdKlRpi6An7KfPOttyg34OBX3WhrGmjbdrJyrIGWDPTjzdINgNd0cBNF3B Bl5wtNOYSz6I0cwtUX1zNxYzR/RRadgA1Wp8mWu6dItCf8yTYHWbTVXQMbt0vBYf 1B6WkvqjH1uLyNV2iXRpyruMol/Uq/C8T7R3c9gY7zEqVd44PRBO+QkjVMokLJLA bUyDGGMcX1OxRKII2ChSKm3zF4q3PnW5XYUofAVSFB8TJkvkI6NB4XWCbY4thFf+ HT9mFih0SEi3vc3bBw42UsIOjVX8O6zNiR9T1yForJJDBfQQHmcl9xq3lGDWGPuD ZnlHol0rOcxO5DF8q4b/+8KpuTgzx12/lHs7eGsMjMNJuzFg33nQJ0eafWS15Wls KgJrXNhdnlUY4WNZm6Lx =FJ3i -----END PGP SIGNATURE----- --Apple-Mail=_E2BE0042-0198-4C1F-9748-FB7454C09868-- From nobody Thu Jun 2 09:29: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 73E3D12D105 for ; Thu, 2 Jun 2016 09:29: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 efXsGtBP_gJx for ; Thu, 2 Jun 2016 09:29:40 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2CD12B05A for ; Thu, 2 Jun 2016 09:29:38 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id e62so130580366ita.1 for ; Thu, 02 Jun 2016 09:29:38 -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=ciZEzIXgg78nIRoMP5Jon8fFwlvcozIwbkXk/h14dL8=; b=WgtgwIwkiokP/PXAyGoh6Bw3HRHdrK9UxrG2mpQqTq++tyX+qVPUzYYa8fwglztvSz G3ETjiyP8ILizBaVaqanZxQR0+bQE3fbCmt3Gq3hqt8mw5abYT/1TBr5Bqr3OXh9V08C jlGibjQmCR4RqvOc9VxuMtXMTKhzfnSz+ouoWDwm4AaISR7hV6acui2SDBdWxPnjzfyr DKvgIe3dFEN5cc7wxTl80pYI93YEHUOj64Ti4HosCuEqyJJzVhOqV+biD33RDX4vx/Ut Mx/EkLfU6RW6GEPosTGskH669FeRrKaCNoNOpT7f1gQqf1Gv2UWJ/v+F8chCPePg5FQT 4ctg== 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=ciZEzIXgg78nIRoMP5Jon8fFwlvcozIwbkXk/h14dL8=; b=QmGe5aSuKG7FOutNrZ4D1+ResetiHXVfpos8Fg8xMEG28N4wl6rT3KyRndnLyFjQiQ fWvfzLS02LiCq7gdfcp889pz5eV5fc58QEUm2ZK4aEl2ePbx3h17Q6AJuMH938OC+kE2 OjY1WJP/hkn2H0VYkJbkKUuiQGI/GFVPpkQz7oJWqikTXSth5PIvWcAkbvK7+JJGVIPo NfpiGCWEOASjfr9zjDRcvzf+OF06pCrkFFjwnoAAStvkirzvmlrZR2HA0G2B/qvseYYs no1UKTV8Xr1LFiNyJ8t3eq82/dNO1rI5QKgEQSyLRbVtiqPcUGdGJ2C9mb5QhvaXeC/i aVbg== X-Gm-Message-State: ALyK8tIU31/4+GLN2rC6JJRuHnJ2B5ESFcYzuJVu5ynW02+5TSp1+nabt+K0nymR+P6KY9/mbwK2zpQ5793Rlg== MIME-Version: 1.0 X-Received: by 10.36.80.4 with SMTP id m4mr4788070itb.37.1464884977506; Thu, 02 Jun 2016 09:29:37 -0700 (PDT) Received: by 10.107.44.203 with HTTP; Thu, 2 Jun 2016 09:29:37 -0700 (PDT) In-Reply-To: <409F4136-9596-4195-88AD-569567979218@trammell.ch> References: <2b0e574586dd955-00039.Richmail.00049889758880203458@139.com> <409F4136-9596-4195-88AD-569567979218@trammell.ch> Date: Thu, 2 Jun 2016 09:29:37 -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: Thu, 02 Jun 2016 16:29:42 -0000 On Wed, Jun 1, 2016 at 12:04 AM, Brian Trammell wrote: > hi Tom, > > snipping a bunch of the message; replies inline... > >>> Unbreaking firewalls in the face of transport encryption is a necessary= first 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, > > Of course not. > >> 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). > > And of course not. I'm having a hard time seeing where anyone has propose= d otherwise in this thread. > Brian, >From the proposed charter: "In order to support more ubiquitous deployment of encryption, and the encryption of transport headers to allow deployment of new transport protocols, explicit in-band signaling must be added to the stack." It's the word "must" here that is problematic, that implies a requirement for deployment of encryption and new transport protocols. I think there are two mostly orthogonal goals being expressed in the proposal: 1) Encryption of transport layers 2) An extensible signaling mechanism between hosts and networks. There seems to be general agreement that encrypting the transport layer is a solution to protocol ossification and provides better security for users. But implementing this is non-trivial and will require new specifications. We can't just encapsulate TCP, SCTP, etc. packets within UDP and expect it to work-- the presence of NAT makes this a hard problem. For instance, I already posted draft-herbert-transports-over-udp which generally attempts to describe host to encapsulate existing protocols within UDP (encapsulation of TCP is detailed). So my question per the proposed WG is: are development and specifications to encapsulate and encrypt specific existing transport protocols within UDP is within the scope? For instance would a first milestone be an RFC that describes how to encapsulate TCP within UDP (or within DTLS)? Thanks, Tom > Since the protocol bounded by draft-trammell-spud-req relies on the super= strate to provide secrets for integrity protection, we presume encryption o= f the superstrate by default. Indeed, one could envision PLUS' selective ex= posure and transport state exposure mechanisms being implemented as extensi= ons to DTLS, since it already provides most of the pieces we'd need. > > The difficulty we see in PLUS is what happens when an application/transpo= rt chooses *not* to encrypt; when the superstrate doesn't provide exchange = of secrets, you get no integrity protection for the PLUS information either= . Indeed, in this case the *only* benefit PLUS provides is a common framing= and data model for information exposed to middleboxes, which as you note i= s rather useless in the initial phases of deployment. And this might be an = acceptable corner case anyway: a decision not to encrypt can at this point = be taken as an explicit statement that the endpoint is unconcerned about it= s packets being thoroughly inspected and mangled by the network. > >> 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. > > Two issues: blocking and state maintenance. > > On the former: QUIC falls back to TCP 6%-9% of the time; our RIPE Atlas n= umbers, which undercount enterprise access networks, point to 3.3% to 3.6% = of measured networks blocking outbound UDP (on ports other than 53). These = are acceptable numbers if you always have a fallback (which QUIC does built= -in, since H2 runs acceptably over TCP, and where something like TAPS comes= in for other applications). But it seems to me we can do better than that.= Providing firewall vendors and administrators with an incentive to unblock= would help here, and exposure of state information so that new transports = over UDP can be managed like TCP is, I think, a good one. > > On the latter: have a look at the spectrum of NAT timeouts between TCP an= d UDP in the paper Lars sent to maprg (in the "Is UDP a trash heap?" thread= ): population median (and mode) UDP timeout for tested devices on flows tha= t look like QUIC was 3 minutes (figures 4,5), versus 60 minutes for TCP (fi= gure 6). See also Jim's slide on NAT unbinding from tsvarea in Vancouver (h= ttps://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf): this t= est is, I believe, roughly equivalent to the one shown in figure 3 in Lars'= paper, with equivalent results: median is about 1.5 min. Both datasets sug= gest a simple heuristic for keepalives: send a useless packet every thirty = seconds if you care about keeping the connection up and don't have anything= to say. > > The reason these timeouts are longer for TCP is that TCP exposes state ma= intenance information to the path. If there is a common mechanism for UDP-b= ased transport protocols for exposing equivalent information, with an equiv= alent level of trust as we can place in TCP flags (formally zero), then the= timeouts can tend over time to be longer, reducing the need for unproducti= ve keepalive traffic. > > Cheers, > > Brian > >> Thanks, >> Tom >> >>> Cheers, >>> >>> Brian >>> >>> _______________________________________________ >>> 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 Jun 3 08:15: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 B7C6012D555; Fri, 3 Jun 2016 08:15:39 -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 hLxetBeWhNaA; Fri, 3 Jun 2016 08:15:35 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 BD98C12D1C7; Fri, 3 Jun 2016 08:15:34 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id n184so706673wmn.1; Fri, 03 Jun 2016 08:15:34 -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=DsKBy/rkNOl9/IhJfvmjz+gnhN/+rL8EgdGzi4TOAMk=; b=KVW6TXCpd1y399d/T9rxXm6De6xNJNi/Oq489yzicEwLpEuN+OKGikRAznK5xoDfot +5R/P6TaFB2hBiHvQA7AA8q7yOAeB3EA9BPIB7S+Bx3X3ItYGbAdZ09QGap68lBQi6Ua sO9MaFr5ob1NJgUbRtEapV1CHuS1+69O1BEEmJlY2529N2tFfFAmpJWyJKgz32YSt+/h N/so35JmfmAMOQC7uHDnp3JEjXzsBKYjCJbiaR7Fsy0xPg66rKuqosMESQ54Xw9oCBfK EMHGH3Lgumlv0Zk+yvBQKb5bzUMQzbxVoC2bDCMO0xu7gHUor5M6jcFMP/vDH3TPPZY2 cpwg== 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=DsKBy/rkNOl9/IhJfvmjz+gnhN/+rL8EgdGzi4TOAMk=; b=Cv+edS36S4gpZPw8chODlSgH+3yGUczftFdFkerpnIjkRJJKrsBfm6Rasvzn5SgmA8 ddCVghYoKtBdvA2mNuqUOHDZNT0ybBMZWzAvJ22bZGIcV/AylZlwxmcx5JNd/WrrBtKK QvxLpJtXbNO+bQAIO6N5BGTXPiG5aB7/anyCYmeDM1uRGWt6tohvy/YxU2buxSQEs+4F W3LltnRoVHP/oM0wXSZRptmnfZmJCHUxq/eU73ZdCNsndgQ7q5TWAvO8A7nzaLvC9EY2 wYbLUWbdt8F6bWx61GLI0UZpkFLF7RK0S8sRqhnWegcadHgZxOHc5JC0Jw3bjoxvygIW cEGQ== X-Gm-Message-State: ALyK8tJWQdk86VlXnmn9xr484fMCXwyRkjIDcElDM/Ij+W9NYlJM7+chIfUdjEwL4833ZiRrKUZRunGvYW10mQ== MIME-Version: 1.0 X-Received: by 10.28.25.129 with SMTP id 123mr84041wmz.10.1464966933220; Fri, 03 Jun 2016 08:15:33 -0700 (PDT) Received: by 10.28.234.13 with HTTP; Fri, 3 Jun 2016 08:15:33 -0700 (PDT) In-Reply-To: <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> Date: Fri, 3 Jun 2016 08:15:33 -0700 Message-ID: From: Ca By To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114d3ceea9a1010534613197 Archived-At: Cc: tsvwg WG , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , "quic@ietf.org" , "ietf@ietf.org" Subject: Re: [Spud] [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice 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, 03 Jun 2016 15:15:40 -0000 --001a114d3ceea9a1010534613197 Content-Type: text/plain; charset=UTF-8 On Thursday, June 2, 2016, Brian Trammell wrote: > Greetings, all, > > Apologies for the late last call comment; I have only one, relatively > minor. I hope it's still useful. > > I understand that Section 3 was written to encourage application > developers not to roll their own transports ("trust us when we say this is > hard, this document is a list of reasons why") but as written it would seem > to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data > channel, anything-over-PLUS), which I very much hope was not the intent. > The problematic recommendation is in the second paragraph: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622]. > > First, this paragraph ignores potential deployment issues with any of > these other than TCP, which risks seeming out of touch, but this is a minor > point and probably not worth a late edit. Second, I'm concerned this > recommendation could be taken as broader than intended, against the > definition of any new transport protocol encapsulated within UDP that > performs substantially the same function as the listed protocols. > > I think this can be made clearer by simply adding to the list of examples: > > NEW: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622], or transport > protocols specified by the IETF in the future. > > and removing the examples from the summary in section 7: > > OLD: > > | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | > > NEW: > > | SHOULD use a full-featured transport | | > > Thanks, cheers, > > Brian > > > > On 18 May 2016, at 02:17, The IESG > wrote: > > > > > > The IESG has received a request from the Transport Area Working Group WG > > (tsvwg) to consider the following document: > > - 'UDP Usage Guidelines' > > as Best Current Practice > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2016-05-31. > Exceptionally, comments may be > > sent to iesg@ietf.org instead. In either case, please > retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > The User Datagram Protocol (UDP) provides a minimal message-passing > > transport that has no inherent congestion control mechanisms. This > > document provides guidelines on the use of UDP for the designers of > > applications, tunnels and other protocols that use UDP. Congestion > > control guidelines are a primary focus, but the document also > > provides guidance on other topics, including message sizes, > > reliability, checksums, middlebox traversal, the use of ECN, DSCPs, > > and ports. > > > > Because congestion control is critical to the stable operation of the > > Internet, applications and other protocols that choose to use UDP as > > an Internet transport must employ mechanisms to prevent congestion > > collapse and to establish some degree of fairness with concurrent > > traffic. They may also need to implement additional mechanisms, > > depending on how they use UDP. > > > > Some guidance is also applicable to the design of other protocols > > (e.g., protocols layered directly on IP or via IP-based tunnels), > > especially when these protocols do not themselves provide congestion > > control. > > > > This document obsoletes RFC5405 and adds guidelines for multicast UDP > > usage. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > I disagree. The text as-is is best and represents a prudent period of review in the WG. As suggested many times to both spud and quic, extending udp is not recommended. We have multiple L4 transport protocols for a reason, you should innovative in that space without UDP. CB --001a114d3ceea9a1010534613197 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, June 2, 2016, Brian Trammell <ietf@trammell.ch> wrote:
Greetings, all,

Apologies for the late last call comment; I have only one, relatively minor= . I hope it's still useful.

I understand that Section 3 was written to encourage application developers= not to roll their own transports ("trust us when we say this is hard,= this document is a list of reasons why") but as written it would seem= to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data ch= annel, anything-over-PLUS), which I very much hope was not the intent. The = problematic recommendation is in the second paragraph:

=C2=A0 =C2=A0These mechanisms are difficult to implement correctly.=C2=A0 F= or most
=C2=A0 =C2=A0applications, the use of one of the existing IETF transport pr= otocols
=C2=A0 =C2=A0is the simplest method of acquiring the required mechanisms.= =C2=A0 Doing
=C2=A0 =C2=A0so also avoids issues that protocols using a new IP protocol n= umber
=C2=A0 =C2=A0face when being deployed over the Internet, where middleboxes = that
=C2=A0 =C2=A0only support TCP and UDP are not rare.=C2=A0 Consequently, the= RECOMMENDED
=C2=A0 =C2=A0alternative to the UDP usage described in the remainder of thi= s
=C2=A0 =C2=A0section is the use of an IETF transport protocol such as TCP =C2=A0 =C2=A0[RFC0793], Stream Control Transmission Protocol (SCTP) [RFC496= 0], and
=C2=A0 =C2=A0SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Dat= agram
=C2=A0 =C2=A0Congestion Control Protocol (DCCP) [RFC4340] with its differen= t
=C2=A0 =C2=A0congestion control types [RFC4341][RFC4342][RFC5622].

First, this paragraph ignores potential deployment issues with any of these= other than TCP, which risks seeming out of touch, but this is a minor poin= t and probably not worth a late edit. Second, I'm concerned this recomm= endation could be taken as broader than intended, against the definition of= any new transport protocol encapsulated within UDP that performs substanti= ally the same function as the listed protocols.

I think this can be made clearer by simply adding to the list of examples:<= br>
NEW:

=C2=A0 =C2=A0These mechanisms are difficult to implement correctly.=C2=A0 F= or most
=C2=A0 =C2=A0applications, the use of one of the existing IETF transport pr= otocols
=C2=A0 =C2=A0is the simplest method of acquiring the required mechanisms.= =C2=A0 Doing
=C2=A0 =C2=A0so also avoids issues that protocols using a new IP protocol n= umber
=C2=A0 =C2=A0face when being deployed over the Internet, where middleboxes = that
=C2=A0 =C2=A0only support TCP and UDP are not rare.=C2=A0 Consequently, the= RECOMMENDED
=C2=A0 =C2=A0alternative to the UDP usage described in the remainder of thi= s
=C2=A0 =C2=A0section is the use of an IETF transport protocol such as TCP =C2=A0 =C2=A0[RFC0793], Stream Control Transmission Protocol (SCTP) [RFC496= 0], and
=C2=A0 =C2=A0SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Dat= agram
=C2=A0 =C2=A0Congestion Control Protocol (DCCP) [RFC4340] with its differen= t
=C2=A0 =C2=A0congestion control types [RFC4341][RFC4342][RFC5622], or trans= port
=C2=A0 =C2=A0protocols specified by the IETF in the future.

and removing the examples from the summary in section 7:

OLD:

=C2=A0 =C2=A0| SHOULD use a full-featured transport (TCP, SCTP, DCCP)=C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

NEW:

=C2=A0 =C2=A0| SHOULD use a full-featured transport=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|

Thanks, cheers,

Brian


> On 18 May 2016, at 02:17, The IESG <iesg-sec= retary@ietf.org> wrote:
>
>
> The IESG has received a request from the Transport Area Working Group = WG
> (tsvwg) to consider the following document:
> - 'UDP Usage Guidelines'
>=C2=A0 <draft-ietf-tsvwg-rfc5405bis-13.txt> as Best Current Pract= ice
>
> The IESG plans to make a decision in the next few weeks, and solicits<= br> > final comments on this action. Please send substantive comments to the=
> ietf@ietf.org mailing lists by 2016-05-31. Exceptiona= lly, comments may be
> sent to iesg@ietf.org instead. In either case, please= retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>=C2=A0 =C2=A0The User Datagram Protocol (UDP) provides a minimal messag= e-passing
>=C2=A0 =C2=A0transport that has no inherent congestion control mechanis= ms.=C2=A0 This
>=C2=A0 =C2=A0document provides guidelines on the use of UDP for the des= igners of
>=C2=A0 =C2=A0applications, tunnels and other protocols that use UDP.=C2= =A0 Congestion
>=C2=A0 =C2=A0control guidelines are a primary focus, but the document a= lso
>=C2=A0 =C2=A0provides guidance on other topics, including message sizes= ,
>=C2=A0 =C2=A0reliability, checksums, middlebox traversal, the use of EC= N, DSCPs,
>=C2=A0 =C2=A0and ports.
>
>=C2=A0 =C2=A0Because congestion control is critical to the stable opera= tion of the
>=C2=A0 =C2=A0Internet, applications and other protocols that choose to = use UDP as
>=C2=A0 =C2=A0an Internet transport must employ mechanisms to prevent co= ngestion
>=C2=A0 =C2=A0collapse and to establish some degree of fairness with con= current
>=C2=A0 =C2=A0traffic.=C2=A0 They may also need to implement additional = mechanisms,
>=C2=A0 =C2=A0depending on how they use UDP.
>
>=C2=A0 =C2=A0Some guidance is also applicable to the design of other pr= otocols
>=C2=A0 =C2=A0(e.g., protocols layered directly on IP or via IP-based tu= nnels),
>=C2=A0 =C2=A0especially when these protocols do not themselves provide = congestion
>=C2=A0 =C2=A0control.
>
>=C2=A0 =C2=A0This document obsoletes RFC5405 and adds guidelines for mu= lticast UDP
>=C2=A0 =C2=A0usage.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc= 5405bis/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-ts= vwg-rfc5405bis/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>

I disagree.=C2=A0 The text as-is is=C2= =A0best and represents a prudent period of review in the WG.=C2=A0=C2=A0As = suggested many times to both spud and quic, extending udp is not recommende= d. We have multiple=C2=A0L4 transport protocols for a reason, you should in= novative in that space without UDP.=C2=A0

CB
--001a114d3ceea9a1010534613197-- From nobody Fri Jun 3 08:28: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 6CAD612D1BD; Fri, 3 Jun 2016 08:28:23 -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 52pLwdu_uaHa; Fri, 3 Jun 2016 08:28:20 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFB712D6D4; Fri, 3 Jun 2016 08:28:20 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id B75A41B00259; Fri, 3 Jun 2016 16:40:30 +0100 (BST) Message-ID: <5751A209.70601@erg.abdn.ac.uk> Date: Fri, 03 Jun 2016 16:28:09 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ca By References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ietf@ietf.org" , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , Brian Trammell , "quic@ietf.org" , tsvwg WG Subject: Re: [Spud] [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:28:23 -0000 It is certainly not too late, many thanks - to both Brian and you! We have various pending comments to look through, and will make sure all comments are also taken into consideration, - next week we'll be resolving the conflicts between comments and seeing how best to accommodate these in updated text, comments then may be late! Gorry On 03/06/2016 16:15, Ca By wrote: > > > On Thursday, June 2, 2016, Brian Trammell > wrote: > > Greetings, all, > > Apologies for the late last call comment; I have only one, > relatively minor. I hope it's still useful. > > I understand that Section 3 was written to encourage application > developers not to roll their own transports ("trust us when we say > this is hard, this document is a list of reasons why") but as > written it would seem to discourage transport innovation atop UDP > (e.g. QUIC, the RTCWEB data channel, anything-over-PLUS), which I > very much hope was not the intent. The problematic recommendation > is in the second paragraph: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport > protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the > RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) > [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622]. > > First, this paragraph ignores potential deployment issues with any > of these other than TCP, which risks seeming out of touch, but > this is a minor point and probably not worth a late edit. Second, > I'm concerned this recommendation could be taken as broader than > intended, against the definition of any new transport protocol > encapsulated within UDP that performs substantially the same > function as the listed protocols. > > I think this can be made clearer by simply adding to the list of > examples: > > NEW: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport > protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the > RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) > [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622], or transport > protocols specified by the IETF in the future. > > and removing the examples from the summary in section 7: > > OLD: > > | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | > | > > NEW: > > | SHOULD use a full-featured transport | > | > > Thanks, cheers, > > Brian > > > > On 18 May 2016, at 02:17, The IESG > wrote: > > > > > > The IESG has received a request from the Transport Area Working > Group WG > > (tsvwg) to consider the following document: > > - 'UDP Usage Guidelines' > > as Best Current Practice > > > > The IESG plans to make a decision in the next few weeks, and > solicits > > final comments on this action. Please send substantive comments > to the > > ietf@ietf.org mailing lists by 2016-05-31. > Exceptionally, comments may be > > sent to iesg@ietf.org instead. In either case, > please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > The User Datagram Protocol (UDP) provides a minimal > message-passing > > transport that has no inherent congestion control mechanisms. > This > > document provides guidelines on the use of UDP for the > designers of > > applications, tunnels and other protocols that use UDP. > Congestion > > control guidelines are a primary focus, but the document also > > provides guidance on other topics, including message sizes, > > reliability, checksums, middlebox traversal, the use of ECN, > DSCPs, > > and ports. > > > > Because congestion control is critical to the stable operation > of the > > Internet, applications and other protocols that choose to use > UDP as > > an Internet transport must employ mechanisms to prevent congestion > > collapse and to establish some degree of fairness with concurrent > > traffic. They may also need to implement additional mechanisms, > > depending on how they use UDP. > > > > Some guidance is also applicable to the design of other protocols > > (e.g., protocols layered directly on IP or via IP-based tunnels), > > especially when these protocols do not themselves provide > congestion > > control. > > > > This document obsoletes RFC5405 and adds guidelines for > multicast UDP > > usage. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > I disagree. The text as-is is best and represents a prudent period of > review in the WG. As suggested many times to both spud and quic, > extending udp is not recommended. We have multiple L4 transport > protocols for a reason, you should innovative in that space without UDP. > > CB From nobody Sat Jun 4 17:25: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 8879B12B040 for ; Sat, 4 Jun 2016 17:25: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 wgDX6PV1ti84 for ; Sat, 4 Jun 2016 17:25:40 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCB112B01B for ; Sat, 4 Jun 2016 17:25:40 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id f67so17531517ith.1 for ; Sat, 04 Jun 2016 17:25: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=Tr9nltT73o9INI2kp840W1290VmBxSOBrHWqjzzCmZE=; b=JbafQv+6RcTTveWpgFwnlmWjldtJijYi6YOkNX5czrV8ePdOx3GKDicjj7hJf9bQKI OBBeH+Hjiy/z82gRL1s3x0q1oBbn8dbk0TLoSBvRWJdRy7kvrM/15tbfZL1VbRBO02GF +LlKPvo20g2VRTr9uoJU36k5Uxfb8Aaj348w5W5GJFPNlTJQ2F+b35dfkDybA9JfQT/P fyrM4P4K7xss3JSfZflk1dqYaVdRCxVOmT0stuMdSmwTSgV158cGKCcQnb8hg6+mgzmi Q4IY8YG256gyLU2ZklcGlN0NqzrHFfb7SmBpOhe30YrpBljlIb99iZMGYXEOhQ9eFOa0 K51w== 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=Tr9nltT73o9INI2kp840W1290VmBxSOBrHWqjzzCmZE=; b=T6HAQlrKAKtLQaS0YhoiC2r1xliQvIaF8bs8sDeQZ0mNQr8oZwsLWYczVicswp0DBz ROuwM2/gdCLbDZPpGwNNjQ919NGaYcq1JnZIFee0GmjuvmYRykACVFJctyv/luuhmRkU SzQh2bkMzdGRe2OJZSwLEYJnpKJ4jHdzareMrBRCGXRD+H6lGWePMPPaGX54p8uyJnDN bXmBBPZBlQ+cNlBFa05zI+Dy7obk5HaL9bYh1ALG1DovEgWIN429HNwrBKqzGbGlYpIn Q5rg4bKfNbTfc3vaUI0MdztrW19LyVT054O29xO4JSGomLMYsuox4yW0laLMEXZ6MKDV G56w== X-Gm-Message-State: ALyK8tK7ZPShYuPdmL9XY72F2Pxcon5o6DL9Dlq4ocP3A95dUZhONgTJl1WBh8mKVBSvp7Mj5/v1C5xdzjkDsA== MIME-Version: 1.0 X-Received: by 10.36.73.219 with SMTP id e88mr656270itd.88.1465086339582; Sat, 04 Jun 2016 17:25:39 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Sat, 4 Jun 2016 17:25:39 -0700 (PDT) In-Reply-To: <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> Date: Sat, 4 Jun 2016 17:25:39 -0700 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tsvwg WG , draft-ietf-tsvwg-rfc5405bis@ietf.org, tsvwg-chairs@ietf.org, spud , quic@ietf.org, ietf@ietf.org Subject: Re: [Spud] Last Call: (UDP Usage Guidelines) to Best Current Practice 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, 05 Jun 2016 00:25:42 -0000 On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell wrote: > Greetings, all, > > Apologies for the late last call comment; I have only one, relatively min= or. I hope it's still useful. > > I understand that Section 3 was written to encourage application develope= rs not to roll their own transports ("trust us when we say this is hard, th= is document is a list of reasons why") but as written it would seem to disc= ourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data channel, a= nything-over-PLUS), which I very much hope was not the intent. The problema= tic recommendation is in the second paragraph: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622]. > > First, this paragraph ignores potential deployment issues with any of the= se other than TCP, which risks seeming out of touch, but this is a minor po= int and probably not worth a late edit. Second, I'm concerned this recommen= dation could be taken as broader than intended, against the definition of a= ny new transport protocol encapsulated within UDP that performs substantial= ly the same function as the listed protocols. > I would agree, this paragraph also seems a little self contradictory.There is an acknowledgment that "middleboxes that only support TCP and UDP are not rare", but then the next sentence recommends the use of several other protocols besides UDP and TCP. If I put these two together, the only congested controlled protocol that is recommended and expected to work on the Internet is TCP. Tom > I think this can be made clearer by simply adding to the list of examples= : > > NEW: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622], or transport > protocols specified by the IETF in the future. > > and removing the examples from the summary in section 7: > > OLD: > > | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | > > NEW: > > | SHOULD use a full-featured transport | | > > Thanks, cheers, > > Brian > > >> On 18 May 2016, at 02:17, The IESG wrote: >> >> >> The IESG has received a request from the Transport Area Working Group WG >> (tsvwg) to consider the following document: >> - 'UDP Usage Guidelines' >> as Best Current Practice >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The User Datagram Protocol (UDP) provides a minimal message-passing >> transport that has no inherent congestion control mechanisms. This >> document provides guidelines on the use of UDP for the designers of >> applications, tunnels and other protocols that use UDP. Congestion >> control guidelines are a primary focus, but the document also >> provides guidance on other topics, including message sizes, >> reliability, checksums, middlebox traversal, the use of ECN, DSCPs, >> and ports. >> >> Because congestion control is critical to the stable operation of the >> Internet, applications and other protocols that choose to use UDP as >> an Internet transport must employ mechanisms to prevent congestion >> collapse and to establish some degree of fairness with concurrent >> traffic. They may also need to implement additional mechanisms, >> depending on how they use UDP. >> >> Some guidance is also applicable to the design of other protocols >> (e.g., protocols layered directly on IP or via IP-based tunnels), >> especially when these protocols do not themselves provide congestion >> control. >> >> This document obsoletes RFC5405 and adds guidelines for multicast UDP >> usage. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Sun Jun 5 22:18: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 E273312D1D2; Sun, 5 Jun 2016 22:18:21 -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 aGD7uAuWsAlo; Sun, 5 Jun 2016 22:18:19 -0700 (PDT) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109AD12D0BD; Sun, 5 Jun 2016 22:18:19 -0700 (PDT) Received: by mail-qk0-x241.google.com with SMTP id i187so6596029qkd.1; Sun, 05 Jun 2016 22:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=E9HUlQcDLaTPNu8n7gqY4Ei8O/K2BMxLCMiJSMC4HGg=; b=V8em/3XD5KukG1RhnW+prCbL4ht7tPb7w/oALvCBhl1WFBTluGY5WV++kC10dAHx+r oqYNt8MbalRqNOXlEHQHbBKTwYoJvdVBht+yZpgSI/Cd+wxgbSNjUFna4KQu4LWW0SXq q6WOPyJO+q/ZODJKLu4k9imJ5hWMwR9hYLqsmzR453lHDvgEYg6/EqyfeJobnGoqBbib UOQOVtrsTsN+UqrX4SojcNjP/Fn5z8VnKff1LJ4y9038ZPOkhts5Ne3nc7qM+HENSkFw Udv8d+q0Y1EylNHRJznLYCKi7ArkHikE6h4W4jQtWgxQR56XIHwgt/xDOBz+2b3yiJJv V8fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=E9HUlQcDLaTPNu8n7gqY4Ei8O/K2BMxLCMiJSMC4HGg=; b=AGt6LBUf+1UZzXqyB4dWhWtXBwsMPCkmlxzOrPHfUtiESrlhv8Gx5Ytcm/Kr/d4zsk k4CvkoezubejIyxLx1ASSfyYuB25Y11mR8VGOBDgeOX+akK2K5Y9M9Svx5LaBEtG+0jm yavcYNkemMezOwohoKN8M5AgfT56jeQTXuw+9V7ZEchP4Tjt8sHWniWoiplzN0+FnAiD KsAYbq50LPA5nJe60gcYTKMZHLsCsYNumQOqugMvKtZj7wertX+wQAK8l+zLrQqJrvFg thuK/qtU2Rn89AirMiBY/FFsxmhZRb86yki6hVpL9gjiytX9VfXpvyswj9FszDGNUi0L qjwg== X-Gm-Message-State: ALyK8tIgxKWFckrXWmIt3diJ9p9//Jwyw5SQuKUUP+G8GaMiavRRlxYP6i5TK6RY/pVUqumvSKZIk5WEQ/P7JA== X-Received: by 10.55.170.75 with SMTP id t72mr14461835qke.100.1465190298163; Sun, 05 Jun 2016 22:18:18 -0700 (PDT) MIME-Version: 1.0 Sender: jim.roskind@gmail.com Received: by 10.237.33.186 with HTTP; Sun, 5 Jun 2016 22:18:17 -0700 (PDT) In-Reply-To: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> From: Jim Roskind Date: Sun, 5 Jun 2016 22:18:17 -0700 X-Google-Sender-Auth: 5lF5b1hzSIq4fWy-bWzA7Kde6fs Message-ID: To: Tom Herbert Content-Type: multipart/alternative; boundary=001a114d8a20402fb30534953324 Archived-At: Cc: tsvwg WG , draft-ietf-tsvwg-rfc5405bis@ietf.org, tsvwg-chairs@ietf.org, spud , Brian Trammell , quic@ietf.org, ietf@ietf.org Subject: Re: [Spud] [QUIC] Last Call: (UDP Usage Guidelines) to Best Current Practice 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, 06 Jun 2016 05:18:22 -0000 --001a114d8a20402fb30534953324 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert wrote: > On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell wrote: > > Greetings, all, > > > > Apologies for the late last call comment; I have only one, relatively > minor. I hope it's still useful. > > > > I understand that Section 3 was written to encourage application > developers not to roll their own transports ("trust us when we say this is > hard, this document is a list of reasons why") but as written it would seem > to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data > channel, anything-over-PLUS), which I very much hope was not the intent. > The problematic recommendation is in the second paragraph: > > > > These mechanisms are difficult to implement correctly. For most > > applications, the use of one of the existing IETF transport protocols > > is the simplest method of acquiring the required mechanisms. Doing > > so also avoids issues that protocols using a new IP protocol number > > face when being deployed over the Internet, where middleboxes that > > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > > alternative to the UDP usage described in the remainder of this > > section is the use of an IETF transport protocol such as TCP > > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > > Congestion Control Protocol (DCCP) [RFC4340] with its different > > congestion control types [RFC4341][RFC4342][RFC5622]. > > > > First, this paragraph ignores potential deployment issues with any of > these other than TCP, which risks seeming out of touch, but this is a minor > point and probably not worth a late edit. Second, I'm concerned this > recommendation could be taken as broader than intended, against the > definition of any new transport protocol encapsulated within UDP that > performs substantially the same function as the listed protocols. > > > I would agree, this paragraph also seems a little self > contradictory.There is an acknowledgment that "middleboxes that only > support TCP and UDP are not rare", but then the next sentence > recommends the use of several other protocols besides UDP and TCP. If > I put these two together, the only congested controlled protocol that > is recommended and expected to work on the Internet is TCP. > +1 TCP (implemented in kernel space) can't possibly evolve congestion avoidance as fast as the Internet has changed, or will change (example: good handling of middle boxes that use "policers" rather than some flavor of buffer-size based packet-drop). The rationale for using UDP for QUIC was indeed that a new IP number would never make it through the Internet (other protocol deployment attempts have commonly verified this). It turns out that even UDP is partially blocked (as recently as 2011) by paths to 5-7% of all chrome clients, which lead to the "automated fallback" elements of QUIC, Hopefully the benefits that QUIC is bringing to the Internet will not be outlawed (precluded by such commentary). Jim > > Tom > > > I think this can be made clearer by simply adding to the list of > examples: > > > > NEW: > > > > These mechanisms are difficult to implement correctly. For most > > applications, the use of one of the existing IETF transport protocols > > is the simplest method of acquiring the required mechanisms. Doing > > so also avoids issues that protocols using a new IP protocol number > > face when being deployed over the Internet, where middleboxes that > > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > > alternative to the UDP usage described in the remainder of this > > section is the use of an IETF transport protocol such as TCP > > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > > Congestion Control Protocol (DCCP) [RFC4340] with its different > > congestion control types [RFC4341][RFC4342][RFC5622], or transport > > protocols specified by the IETF in the future. > > > > and removing the examples from the summary in section 7: > > > > OLD: > > > > | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | > > > > NEW: > > > > | SHOULD use a full-featured transport | | > > > > Thanks, cheers, > > > > Brian > > > > > >> On 18 May 2016, at 02:17, The IESG wrote: > >> > >> > >> The IESG has received a request from the Transport Area Working Group WG > >> (tsvwg) to consider the following document: > >> - 'UDP Usage Guidelines' > >> as Best Current Practice > >> > >> The IESG plans to make a decision in the next few weeks, and solicits > >> final comments on this action. Please send substantive comments to the > >> ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, comments may > be > >> sent to iesg@ietf.org instead. In either case, please retain the > >> beginning of the Subject line to allow automated sorting. > >> > >> Abstract > >> > >> > >> The User Datagram Protocol (UDP) provides a minimal message-passing > >> transport that has no inherent congestion control mechanisms. This > >> document provides guidelines on the use of UDP for the designers of > >> applications, tunnels and other protocols that use UDP. Congestion > >> control guidelines are a primary focus, but the document also > >> provides guidance on other topics, including message sizes, > >> reliability, checksums, middlebox traversal, the use of ECN, DSCPs, > >> and ports. > >> > >> Because congestion control is critical to the stable operation of the > >> Internet, applications and other protocols that choose to use UDP as > >> an Internet transport must employ mechanisms to prevent congestion > >> collapse and to establish some degree of fairness with concurrent > >> traffic. They may also need to implement additional mechanisms, > >> depending on how they use UDP. > >> > >> Some guidance is also applicable to the design of other protocols > >> (e.g., protocols layered directly on IP or via IP-based tunnels), > >> especially when these protocols do not themselves provide congestion > >> control. > >> > >> This document obsoletes RFC5405 and adds guidelines for multicast UDP > >> usage. > >> > >> > >> > >> > >> The file can be obtained via > >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ > >> > >> IESG discussion can be tracked via > >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> > >> > > > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud > > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a114d8a20402fb30534953324 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert <tom@herbertland.com= > wrote:
On Thu, Jun 2, 2016= at 3:11 AM, Brian Trammell <ietf@tr= ammell.ch> wrote:
> Greetings, all,
>
> Apologies for the late last call comment; I have only one, relatively = minor. I hope it's still useful.
>
> I understand that Section 3 was written to encourage application devel= opers not to roll their own transports ("trust us when we say this is = hard, this document is a list of reasons why") but as written it would= seem to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB da= ta channel, anything-over-PLUS), which I very much hope was not the intent.= The problematic recommendation is in the second paragraph:
>
>=C2=A0 =C2=A0 These mechanisms are difficult to implement correctly.=C2= =A0 For most
>=C2=A0 =C2=A0 applications, the use of one of the existing IETF transpo= rt protocols
>=C2=A0 =C2=A0 is the simplest method of acquiring the required mechanis= ms.=C2=A0 Doing
>=C2=A0 =C2=A0 so also avoids issues that protocols using a new IP proto= col number
>=C2=A0 =C2=A0 face when being deployed over the Internet, where middleb= oxes that
>=C2=A0 =C2=A0 only support TCP and UDP are not rare.=C2=A0 Consequently= , the RECOMMENDED
>=C2=A0 =C2=A0 alternative to the UDP usage described in the remainder o= f this
>=C2=A0 =C2=A0 section is the use of an IETF transport protocol such as = TCP
>=C2=A0 =C2=A0 [RFC0793], Stream Control Transmission Protocol (SCTP) [R= FC4960], and
>=C2=A0 =C2=A0 SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], o= r Datagram
>=C2=A0 =C2=A0 Congestion Control Protocol (DCCP) [RFC4340] with its dif= ferent
>=C2=A0 =C2=A0 congestion control types [RFC4341][RFC4342][RFC5622].
>
> First, this paragraph ignores potential deployment issues with any of = these other than TCP, which risks seeming out of touch, but this is a minor= point and probably not worth a late edit. Second, I'm concerned this r= ecommendation could be taken as broader than intended, against the definiti= on of any new transport protocol encapsulated within UDP that performs subs= tantially the same function as the listed protocols.
>
I would agree, this paragraph also seems a little self
contradictory.There is an acknowledgment that "middleboxes that only support TCP and UDP are not rare", but then the next sentence
recommends the use of several other protocols besides UDP and TCP. If
I put these two together, the only congested controlled protocol that
is recommended and expected to work on the Internet is TCP.

+1 =C2=A0 TCP (implemented in kernel space) can't = possibly evolve congestion avoidance as fast as the Internet has changed, o= r will change (example: good handling of middle boxes that use "police= rs" rather than some flavor of buffer-size based packet-drop).=C2=A0
The rationale for using UDP for QUIC was indeed that a new IP numb= er would never make it through the Internet (other protocol deployment atte= mpts have commonly verified this).=C2=A0 It turns out that even UDP is part= ially blocked (as recently as 2011) by paths to 5-7% of all chrome clients,= which lead to the "automated fallback" elements of QUIC, =C2=A0= =C2=A0

Hopefully the benefits that QUIC is bringin= g to the Internet will not be outlawed (precluded by such commentary).

Jim
=C2=A0

Tom

> I think this can be made clearer by simply adding to the list of examp= les:
>
> NEW:
>
>=C2=A0 =C2=A0 These mechanisms are difficult to implement correctly.=C2= =A0 For most
>=C2=A0 =C2=A0 applications, the use of one of the existing IETF transpo= rt protocols
>=C2=A0 =C2=A0 is the simplest method of acquiring the required mechanis= ms.=C2=A0 Doing
>=C2=A0 =C2=A0 so also avoids issues that protocols using a new IP proto= col number
>=C2=A0 =C2=A0 face when being deployed over the Internet, where middleb= oxes that
>=C2=A0 =C2=A0 only support TCP and UDP are not rare.=C2=A0 Consequently= , the RECOMMENDED
>=C2=A0 =C2=A0 alternative to the UDP usage described in the remainder o= f this
>=C2=A0 =C2=A0 section is the use of an IETF transport protocol such as = TCP
>=C2=A0 =C2=A0 [RFC0793], Stream Control Transmission Protocol (SCTP) [R= FC4960], and
>=C2=A0 =C2=A0 SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], o= r Datagram
>=C2=A0 =C2=A0 Congestion Control Protocol (DCCP) [RFC4340] with its dif= ferent
>=C2=A0 =C2=A0 congestion control types [RFC4341][RFC4342][RFC5622], or = transport
>=C2=A0 =C2=A0 protocols specified by the IETF in the future.
>
> and removing the examples from the summary in section 7:
>
> OLD:
>
>=C2=A0 =C2=A0 | SHOULD use a full-featured transport (TCP, SCTP, DCCP)= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>
> NEW:
>
>=C2=A0 =C2=A0 | SHOULD use a full-featured transport=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
>
> Thanks, cheers,
>
> Brian
>
>
>> On 18 May 2016, at 02:17, The IESG <iesg-secretary@ietf.org> wrote:
>>
>>
>> The IESG has received a request from the Transport Area Working Gr= oup WG
>> (tsvwg) to consider the following document:
>> - 'UDP Usage Guidelines'
>>=C2=A0 <draft-ietf-tsvwg-rfc5405bis-13.txt> as Best Current P= ractice
>>
>> The IESG plans to make a decision in the next few weeks, and solic= its
>> final comments on this action. Please send substantive comments to= the
>> ietf@ietf.org mailing lists b= y 2016-05-31. Exceptionally, comments may be
>> sent to iesg@ietf.org instead= . In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>=C2=A0 =C2=A0The User Datagram Protocol (UDP) provides a minimal me= ssage-passing
>>=C2=A0 =C2=A0transport that has no inherent congestion control mech= anisms.=C2=A0 This
>>=C2=A0 =C2=A0document provides guidelines on the use of UDP for the= designers of
>>=C2=A0 =C2=A0applications, tunnels and other protocols that use UDP= .=C2=A0 Congestion
>>=C2=A0 =C2=A0control guidelines are a primary focus, but the docume= nt also
>>=C2=A0 =C2=A0provides guidance on other topics, including message s= izes,
>>=C2=A0 =C2=A0reliability, checksums, middlebox traversal, the use o= f ECN, DSCPs,
>>=C2=A0 =C2=A0and ports.
>>
>>=C2=A0 =C2=A0Because congestion control is critical to the stable o= peration of the
>>=C2=A0 =C2=A0Internet, applications and other protocols that choose= to use UDP as
>>=C2=A0 =C2=A0an Internet transport must employ mechanisms to preven= t congestion
>>=C2=A0 =C2=A0collapse and to establish some degree of fairness with= concurrent
>>=C2=A0 =C2=A0traffic.=C2=A0 They may also need to implement additio= nal mechanisms,
>>=C2=A0 =C2=A0depending on how they use UDP.
>>
>>=C2=A0 =C2=A0Some guidance is also applicable to the design of othe= r protocols
>>=C2=A0 =C2=A0(e.g., protocols layered directly on IP or via IP-base= d tunnels),
>>=C2=A0 =C2=A0especially when these protocols do not themselves prov= ide congestion
>>=C2=A0 =C2=A0control.
>>
>>=C2=A0 =C2=A0This document obsoletes RFC5405 and adds guidelines fo= r multicast UDP
>>=C2=A0 =C2=A0usage.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/d= oc/draft-ietf-tsvwg-rfc5405bis/
>>
>> IESG discussion can be tracked via
>> https://datatracker.iet= f.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--001a114d8a20402fb30534953324-- From nobody Tue Jun 7 10: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 F148012D185 for ; Tue, 7 Jun 2016 10:40:26 -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 U9Pdf6fCNdsl for ; Tue, 7 Jun 2016 10:40:24 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 942F212D5A2 for ; Tue, 7 Jun 2016 10:40:24 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id c66so99361614vkb.3 for ; Tue, 07 Jun 2016 10:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=8Suc9k8OWOqx9n4WVwqD/feEy4palXYGMcx9du4Ckdo=; b=Ils4oZilbYa+NJ2KzTJO/RIRM9qyEjOieuin/4i2UpsE9vrEFv8lePcBuI+Y/SX47/ yUQy7BOdI5XtkVczEthOQCBilysAztyoITlDwGFzP+RzY+mjeepYVODMk64CVc547PgC MBXzaH+j6SN6D7DH+gRoR/YFuGh1LWtfPjlrzsnAihF3if8/8GPBfUUOiNbDVGryCf60 8qmoFfq28PjEwgK8Gh4sVmQG2C2lUH4YQ1iLgOmuPAwpgEZer4z2aPRZbaqr3gNPnUuo h1OHSINHSVG0x53sUFIu8izqG6p3YHji1SFKCRxNwZL8kHhz5I8NoBXv5yh7ijeRjnHp fevw== 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; bh=8Suc9k8OWOqx9n4WVwqD/feEy4palXYGMcx9du4Ckdo=; b=GsUSj7iUX4zTa19oeOz9Jfbjkt0EyY+pUdlMYE45eQFV/uEHenpEXi4vKmkPGv+sky C0RZnM86Yfd1kifjZmDQDJLpvgBoTnfjLpY8OmN9dDCNNe7NE7jYFJzDzKJI98LGiJ/E 05M7Gx3Afi+iGsa1R06TyjY78E0aTFHdgOdvBPOuW1iHDtf0NoX9/1qUPRQDI0F1RoXP KLvLC1iyw8dzKmBW11SjLuqPWklEAjZoebuFg3JlSV4/rXkJHLt0eIGhNGOBMNzNUMMe KtYHczC39nzwA/ylv4HzdhM/UBB742Uv59zsTlAuHwm3oP6twbSLlwWxlah8QdB17lmM HjcA== X-Gm-Message-State: ALyK8tJToYWoBdqFEZP5ESZm3k6sqr4ZLaEcyt4y2BnGiEy/H66n1t8IYUUUnO903zEO+jLIu+C23Bs6Awg2DQ== X-Received: by 10.159.36.174 with SMTP id 43mr308401uar.134.1465321223513; Tue, 07 Jun 2016 10:40:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.150 with HTTP; Tue, 7 Jun 2016 10:40:22 -0700 (PDT) In-Reply-To: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> From: Aaron Falk Date: Tue, 7 Jun 2016 13:40:22 -0400 Message-ID: To: Brian Trammell , spud Content-Type: multipart/alternative; boundary=001a1142f1d0026d310534b3af3f Archived-At: Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 17:40:27 -0000 --001a1142f1d0026d310534b3af3f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Apologies for being behind on the list and maybe repeating points that have been made. A few comments based on my review of the BoF proposal & charter= : - 1st para of the charter says =E2=80=9CThe working group will not speci= fy any new transport protocols.=E2=80=9D and the 5th para says =E2=80=9CThe PLU= S working group will specify a new protocol=E2=80=9D. I think the latter statement is c= orrect. - I=E2=80=99d like to see a comment on PLUS re-enabling ICMP functionali= ty - There=E2=80=99s the obvious & unaddressed question about the relation = to QUIC - The PLUS Bof description should start something like =E2=80=9CThis BoF= is to discuss the proposed PLUS working group. The wg=E2=80=99s goal is to=E2= =80=A6=E2=80=9D - No discussion of wg anti-goals. I had heard some interest in ruling middlebox to middlebox signaling as out of scope. - (To ADs:) Would like to see the QUIC and PLUS BoFs scheduled back-to-back. While I think the topics are mostly separable, if the discussion gets out of sync it will be a headache. HTH, --aaron On Wed, Jun 1, 2016 at 6:45 AM Brian Trammell wrote: > Greetings, all, > > We've taken another editing pass to tighten the charter; results inline > below at on GitHub (https://github.com/ietf-plus/charter). We think this > is getting close to something it would be useful to discuss and wordsmith > at a BoF. > > Further comments welcome. > > 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 define a common shim layer atop the > User > Datagram Protocol (UDP) to provide a transport-independent method to sign= al > flow semantics under transport and application control, necessary to enab= le > the deployment of new, encrypted transport protocols within the existing > Internet. UDP provides compatibility with currently deployed middleboxes = as > well as ubiquitous support in endpoints, and supports userspace > implementation > of new transport protocols. The working group will not specify any new > transport protocols. > > The current Internet protocol stack does not provide explicit, in-band, > transport-independent signaling to on-path network devices. This has led = to > the deployment of devices which perform implicit discovery of transport > semantics and traffic characteristics via inspection of protocol headers > and > payload, a practice made possible when these are sent in the clear. > > In order to support more ubiquitous deployment of encryption, and the > encryption of transport headers to allow deployment of new transport > protocols, explicit in-band signaling must be added to the stack. This > signaling must be transport protocol independent, and the types of > information > signaled must be based on characteristics that can be independently > verified > by devices on path, or that can be usefully applied without requiring a > trust > relationship between endpoints and the path. Further, a feedback channel > that > provides information from on-path devices back to endpoints and > applications, > e.g. for error handling, is essential for the deployment and success of a= n > explicit cooperation approach. > > While IP would seem to be the natural home for this facility, both IPv4 a= nd > IPv6 options and extensions have deployment problems on their own, which > makes > it hard to include any additional information in these protocols. > > The PLUS working group will specify a new protocol as a Path Layer > UDP Substrate (PLUS), to support experimental deployment of > explicit cooperation between endpoints and devices on path, with the > following goals: > > - enable ubiquitous deployment of encrypted higher layer protocols > by providing exposure of basic TCP-like semantics (e.g. SYN, FIN, > RST flags) to devices on path (e.g. NATs and firewalls). > > - allow applications and transport protocols to explicitly provide > limited information with integrity protection to devices on path > > - allow devices on path to provide unencrypted feedback and information > about the path directly to sending endpoints, under sending endpoint > control > > - allow devices on path to provide unencrypted information about the > path to receiving endpoints, with encrypted feedback to the > sending endpoint, under sending endpoint control > > This approach explicitly gives the control of information exposure back t= he > application and/or transport layer protocol on the end host. It is the > goal of > PLUS to minimize the information exposed, to make information exposure > transparent, and to limit the level of detail to that useful for network > treatment, while encrypting everything else. Endpoint verification of > signaling integrity, careful design of minimal data structures, and > restrictive policies for registration of signals can help to meet this > goal. > This is important to avoid future implicit treatment and resulting > ossification, as well as to minimize the privacy risks presented by > explicit > cooperation. > > Given that the primary goal of PLUS is to enable the deployment of > transport > protocols with encrypted headers, we assume that the higher-layer protoco= l > can > provide an encryption context that can be used by PLUS to provide > authentication, integrity, and encryption where needed. The primary threa= t > model to defend against will be modification or deletion of exposed > information by middleboxes and other devices on path, by allowing a remot= e > 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 (SPU= D) > prototype. The working group's main output will be an experimental protoc= ol > specification, together with an initial registry of types of information > that > can be exposed using PLUS, clearly aligned to the use cases determined by > the > working group. The working group will close if it is not able to come to > consensus on a protocol design to meet these requirements. > > The working group will additionally aim to identify and work with other > working groups that could address parts of these requirements within > existing > protocols, e.g. by specifying new protocol extensions, or as input for on= - > going standardization work. It will aim to work with working groups > defining > encryption protocols (e.g. DTLS) which could be used for encryption of > transport protocols running over PLUS. > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --001a1142f1d0026d310534b3af3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologies for being behind on the list and maybe repeating= points that have been made.=C2=A0 A few comments based on my review of the= BoF proposal & charter:

  • 1st para of the cha= rter says =E2=80=9CThe working group will not specify any new transport pro= tocols.=E2=80=9D and the 5th para says =E2=80=9CThe PLUS working group will= specify a new protocol=E2=80=9D.=C2=A0 I think the latter statement is cor= rect.
  • I=E2=80=99d like to see a comment on PLUS re-enabling ICM= P functionality
  • There=E2=80=99s the obvious & unaddressed q= uestion about the relation to QUIC
  • The PLUS Bof description sho= uld start something like =E2=80=9CThis BoF is to discuss the proposed PLUS = working group.=C2=A0 The wg=E2=80=99s goal is to=E2=80=A6=E2=80=9D
    • =
  • No discussion of wg anti-goals.=C2=A0 I had heard some interest in ruli= ng middlebox to middlebox signaling as out of scope.
  • (To ADs:) = Would like to see the QUIC and PLUS BoFs scheduled back-to-back.=C2=A0 Whil= e I think the topics are mostly separable, if the discussion gets out of sy= nc it will be a headache.
HTH,

--aaron


On Wed, Jun 1, 2016 at 6:45 AM Brian Trammell <ietf@trammell.ch> wrote:
Greetings, all,

We've taken another editing pass to tighten the charter; results inline= below at on GitHub (https://github.com/ietf-plus/charter)= . We think this is getting close to something it would be useful to discuss= and wordsmith at a BoF.

Further comments welcome.

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 define a common shim layer atop the= User
Datagram Protocol (UDP) to provide a transport-independent method to signal=
flow semantics under transport and application control, necessary to enable=
the deployment of new, encrypted transport protocols within the existing Internet. UDP provides compatibility with currently deployed middleboxes as=
well as ubiquitous support in endpoints, and supports userspace implementat= ion
of new transport protocols. The working group will not specify any new
transport protocols.

The current Internet protocol stack does not provide explicit, in-band,
transport-independent signaling to on-path network devices. This has led to=
the deployment of devices which perform implicit discovery of transport
semantics and traffic characteristics via inspection of protocol headers an= d
payload, a practice made possible when these are sent in the clear.

In order to support more ubiquitous deployment of encryption, and the
encryption of transport headers to allow deployment of new transport
protocols, explicit in-band signaling must be added to the stack. This
signaling must be transport protocol independent, and the types of informat= ion
signaled must be based on characteristics that can be independently verifie= d
by devices on path, or that can be usefully applied without requiring a tru= st
relationship between endpoints and the path. Further, a feedback channel th= at
provides information from on-path devices back to endpoints and application= s,
e.g. for error handling, is essential for the deployment and success of an<= br> explicit cooperation approach.

While IP would seem to be the natural home for this facility, both IPv4 and=
IPv6 options and extensions have deployment problems on their own, which ma= kes
it hard to include any additional information in these protocols.

The PLUS working group will specify a new protocol as a Path Layer
UDP Substrate (PLUS), to support experimental deployment of
explicit cooperation between endpoints and devices on path, with the follow= ing 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 with integrity protection to devices on path

- allow devices on path to provide unencrypted feedback and information
=C2=A0 about the path directly to sending endpoints, under sending endpoint=
=C2=A0 control

- allow devices on path to provide unencrypted information about the
=C2=A0 path to receiving endpoints, with encrypted feedback to the
=C2=A0 sending endpoint, under sending endpoint control

This approach explicitly gives the control of information exposure back the=
application and/or transport layer protocol on the end host. It is the goal= of
PLUS to minimize the information exposed, to make information exposure
transparent, and to limit the level of detail to that useful for network treatment, while encrypting everything else. Endpoint verification of
signaling integrity, careful design of minimal data structures, and
restrictive policies for registration of signals can help to meet this goal= .
This is important to avoid future implicit treatment and resulting
ossification, as well as to minimize the privacy risks presented by explici= t
cooperation.

Given that the primary goal of PLUS is to enable the deployment of transpor= t
protocols with encrypted headers, we assume that the higher-layer protocol = can
provide an encryption context that can be used by PLUS to provide
authentication, integrity, and encryption where needed. The primary threat<= br> model to defend against will be modification or deletion of exposed
information by middleboxes and other devices on path, by allowing a remote<= br> 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),<= br> taken from experience with the Substrate Protocol for User Datagrams (SPUD)=
prototype. The working group's main output will be an experimental prot= ocol
specification, together with an initial registry of types of information th= at
can be exposed using PLUS, clearly aligned to the use cases determined by t= he
working group. The working group will close if it is not able to come to consensus on a protocol design to meet these requirements.

The working group will additionally aim to identify and work with other
working groups that could address parts of these requirements within existi= ng
protocols, e.g. by specifying new protocol extensions, or as input for on-<= br> going standardization work. It will aim to work with working groups definin= g
encryption protocols (e.g. DTLS) 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
--001a1142f1d0026d310534b3af3f-- From nobody Tue Jun 7 10:44:33 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386FC12D191 for ; Tue, 7 Jun 2016 10:44:32 -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 uBu7a6GzdBXC for ; Tue, 7 Jun 2016 10:44:29 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 8193B12B00B for ; Tue, 7 Jun 2016 10:44:29 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id c66so99515092vkb.3 for ; Tue, 07 Jun 2016 10:44:29 -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; bh=jVH/gAoR5GPHiEK292Z35UCkQzrkxjZwVFLJsczCNNE=; b=bawFksyslb18Cn3yHCL1fCjtft7jSchbMGeRlXnkyCz1jqCjDIZ95pbcYhbh2aaKub SZjWVse2zQVMqKJUHg0hqS99vivUuwWFH+nZn7v8UM9uXK2oF5XniNeSMhAsVw89Poll XKtydSsz63nokvAowkIs401wmV2DybwNTXTQCIaq23rzBprQHqRQFlVzwPANcBs23Pbo HnTM3vuJIbUxsTdECKOjt6kJCGa3pPhavUkodFVpd01zNjbNgCG2KgMoeCXllrtAZOoH n0qncQ9o5fbUrCnVkLUIbQaUvAzrvvJvLHW35IdRIPuAuugsSdq6T3BETf9ptn8KKGQd 7NUA== 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; bh=jVH/gAoR5GPHiEK292Z35UCkQzrkxjZwVFLJsczCNNE=; b=bVG1gANy62yo5dB3fLzw5A51FQ6iwJsP7WVDJBzlxIa1WDKC5Bv6JIVEIsxZFEqyT8 cleRl5fzZAqL/c36Uy7r4r/Vs0bvL2Jwc5wwW9xaWfHVQcwPyLQQcoElJcoGmos3Qq0z WBzLx285C/D09Bfwz/JE/rrlIKn4NAYb+0OcAOadxPrlP57y3a4YvzViG2ktZ/LWmcAc a3N/KfFQtjBeIQSXSTL6z+ZuJ8ymmlzrjwbVNeQSzGsb8HA/ywaI0bWIFAzJfRsPDwT6 SEL4kGZ4Wm/G3Jl+bXp6l7dsS6csy7VkGSP0PQ6t7DeG1/om660+84AS3Bnc36iq8un7 qxxA== X-Gm-Message-State: ALyK8tIVZzmngqXStjA4O5OvCY48yTzmodIWxlfQgbeYCyLV0GPpiIOb0gSsGbCGO7eYrekHZ5i07loXbwG5sw== X-Received: by 10.159.36.108 with SMTP id 99mr318527uaq.110.1465321468608; Tue, 07 Jun 2016 10:44:28 -0700 (PDT) MIME-Version: 1.0 References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> In-Reply-To: From: Aaron Falk Date: Tue, 07 Jun 2016 17:44:19 +0000 Message-ID: To: Brian Trammell , spud Content-Type: multipart/alternative; boundary=001a113d12689e48be0534b3bde2 Archived-At: Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 17:44:32 -0000 --001a113d12689e48be0534b3bde2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oh, and there should be some draft deliverables so we can have a fight about the realism of the associated dates. On Tue, Jun 7, 2016 at 1:40 PM Aaron Falk wrote: > Apologies for being behind on the list and maybe repeating points that > have been made. A few comments based on my review of the BoF proposal & > charter: > > > - 1st para of the charter says =E2=80=9CThe working group will not spe= cify any > new transport protocols.=E2=80=9D and the 5th para says =E2=80=9CThe P= LUS working group > will specify a new protocol=E2=80=9D. I think the latter statement is= correct. > - I=E2=80=99d like to see a comment on PLUS re-enabling ICMP functiona= lity > - There=E2=80=99s the obvious & unaddressed question about the relatio= n to QUIC > - The PLUS Bof description should start something like =E2=80=9CThis B= oF is to > discuss the proposed PLUS working group. The wg=E2=80=99s goal is to= =E2=80=A6=E2=80=9D > - No discussion of wg anti-goals. I had heard some interest in ruling > middlebox to middlebox signaling as out of scope. > - (To ADs:) Would like to see the QUIC and PLUS BoFs scheduled > back-to-back. While I think the topics are mostly separable, if the > discussion gets out of sync it will be a headache. > > HTH, > > --aaron > > > On Wed, Jun 1, 2016 at 6:45 AM Brian Trammell wrote: > >> Greetings, all, >> >> We've taken another editing pass to tighten the charter; results inline >> below at on GitHub (https://github.com/ietf-plus/charter). We think this >> is getting close to something it would be useful to discuss and wordsmit= h >> at a BoF. >> >> Further comments welcome. >> >> 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 define a common shim layer atop the >> User >> Datagram Protocol (UDP) to provide a transport-independent method to >> signal >> flow semantics under transport and application control, necessary to >> enable >> the deployment of new, encrypted transport protocols within the existing >> Internet. UDP provides compatibility with currently deployed middleboxes >> as >> well as ubiquitous support in endpoints, and supports userspace >> implementation >> of new transport protocols. The working group will not specify any new >> transport protocols. >> >> The current Internet protocol stack does not provide explicit, in-band, >> transport-independent signaling to on-path network devices. This has led >> to >> the deployment of devices which perform implicit discovery of transport >> semantics and traffic characteristics via inspection of protocol headers >> and >> payload, a practice made possible when these are sent in the clear. >> >> In order to support more ubiquitous deployment of encryption, and the >> encryption of transport headers to allow deployment of new transport >> protocols, explicit in-band signaling must be added to the stack. This >> signaling must be transport protocol independent, and the types of >> information >> signaled must be based on characteristics that can be independently >> verified >> by devices on path, or that can be usefully applied without requiring a >> trust >> relationship between endpoints and the path. Further, a feedback channel >> that >> provides information from on-path devices back to endpoints and >> applications, >> e.g. for error handling, is essential for the deployment and success of = an >> explicit cooperation approach. >> >> While IP would seem to be the natural home for this facility, both IPv4 >> and >> IPv6 options and extensions have deployment problems on their own, which >> makes >> it hard to include any additional information in these protocols. >> >> The PLUS working group will specify a new protocol as a Path Layer >> UDP Substrate (PLUS), to support experimental deployment of >> explicit cooperation between endpoints and devices on path, with the >> following goals: >> >> - enable ubiquitous deployment of encrypted higher layer protocols >> by providing exposure of basic TCP-like semantics (e.g. SYN, FIN, >> RST flags) to devices on path (e.g. NATs and firewalls). >> >> - allow applications and transport protocols to explicitly provide >> limited information with integrity protection to devices on path >> >> - allow devices on path to provide unencrypted feedback and information >> about the path directly to sending endpoints, under sending endpoint >> control >> >> - allow devices on path to provide unencrypted information about the >> path to receiving endpoints, with encrypted feedback to the >> sending endpoint, under sending endpoint control >> >> This approach explicitly gives the control of information exposure back >> the >> application and/or transport layer protocol on the end host. It is the >> goal of >> PLUS to minimize the information exposed, to make information exposure >> transparent, and to limit the level of detail to that useful for network >> treatment, while encrypting everything else. Endpoint verification of >> signaling integrity, careful design of minimal data structures, and >> restrictive policies for registration of signals can help to meet this >> goal. >> This is important to avoid future implicit treatment and resulting >> ossification, as well as to minimize the privacy risks presented by >> explicit >> cooperation. >> >> Given that the primary goal of PLUS is to enable the deployment of >> transport >> protocols with encrypted headers, we assume that the higher-layer >> protocol can >> provide an encryption context that can be used by PLUS to provide >> authentication, integrity, and encryption where needed. The primary thre= at >> model to defend against will be modification or deletion of exposed >> information by middleboxes and other devices on path, by allowing a remo= te >> endpoint to detect modifications. >> >> The working group will start with an initial set of use cases (see draft= - >> kuehlewind-spud-use-cases) and requirements (see draft-trammell-spud-req= ), >> taken from experience with the Substrate Protocol for User Datagrams >> (SPUD) >> prototype. The working group's main output will be an experimental >> protocol >> specification, together with an initial registry of types of information >> that >> can be exposed using PLUS, clearly aligned to the use cases determined b= y >> the >> working group. The working group will close if it is not able to come to >> consensus on a protocol design to meet these requirements. >> >> The working group will additionally aim to identify and work with other >> working groups that could address parts of these requirements within >> existing >> protocols, e.g. by specifying new protocol extensions, or as input for o= n- >> going standardization work. It will aim to work with working groups >> defining >> encryption protocols (e.g. DTLS) which could be used for encryption of >> transport protocols running over PLUS. >> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >> > -- --aaron =3D=3D=3D=3D=3DShort message from my phone=3D=3D=3D=3D=3D --001a113d12689e48be0534b3bde2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh, and there should be some draft deliverables so we can = have a fight about the realism of the associated dates.

On Tue, Jun 7, 2016 at 1:40 PM Aaron Falk= <aaron.falk@gmail.com> w= rote:
Apologies fo= r being behind on the list and maybe repeating points that have been made.= =C2=A0 A few comments based on my review of the BoF proposal & charter:=

  • 1st para of the charter says =E2=80=9CThe worki= ng group will not specify any new transport protocols.=E2=80=9D and the 5th= para says =E2=80=9CThe PLUS working group will specify a new protocol=E2= =80=9D.=C2=A0 I think the latter statement is correct.
  • I=E2=80= =99d like to see a comment on PLUS re-enabling ICMP functionality
    • <= li>There=E2=80=99s the obvious & unaddressed question about the relatio= n to QUIC
  • The PLUS Bof description should start something like = =E2=80=9CThis BoF is to discuss the proposed PLUS working group.=C2=A0 The = wg=E2=80=99s goal is to=E2=80=A6=E2=80=9D
  • No discussion of wg a= nti-goals.=C2=A0 I had heard some interest in ruling middlebox to middlebox= signaling as out of scope.
  • (To ADs:) Would like to see the QUI= C and PLUS BoFs scheduled back-to-back.=C2=A0 While I think the topics are = mostly separable, if the discussion gets out of sync it will be a headache.=
HTH,

--aaron


= On Wed, Jun 1, 2016 at 6:45 AM Brian Trammell <ietf@trammell.ch> wrote:
Greetings, all,

We've taken another editing pass to tighten the charter; results inline= below at on GitHub (https://github.com/ietf-plus/charter)= . We think this is getting close to something it would be useful to discuss= and wordsmith at a BoF.

Further comments welcome.

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 define a common shim layer atop the= User
Datagram Protocol (UDP) to provide a transport-independent method to signal=
flow semantics under transport and application control, necessary to enable=
the deployment of new, encrypted transport protocols within the existing Internet. UDP provides compatibility with currently deployed middleboxes as=
well as ubiquitous support in endpoints, and supports userspace implementat= ion
of new transport protocols. The working group will not specify any new
transport protocols.

The current Internet protocol stack does not provide explicit, in-band,
transport-independent signaling to on-path network devices. This has led to=
the deployment of devices which perform implicit discovery of transport
semantics and traffic characteristics via inspection of protocol headers an= d
payload, a practice made possible when these are sent in the clear.

In order to support more ubiquitous deployment of encryption, and the
encryption of transport headers to allow deployment of new transport
protocols, explicit in-band signaling must be added to the stack. This
signaling must be transport protocol independent, and the types of informat= ion
signaled must be based on characteristics that can be independently verifie= d
by devices on path, or that can be usefully applied without requiring a tru= st
relationship between endpoints and the path. Further, a feedback channel th= at
provides information from on-path devices back to endpoints and application= s,
e.g. for error handling, is essential for the deployment and success of an<= br> explicit cooperation approach.

While IP would seem to be the natural home for this facility, both IPv4 and=
IPv6 options and extensions have deployment problems on their own, which ma= kes
it hard to include any additional information in these protocols.

The PLUS working group will specify a new protocol as a Path Layer
UDP Substrate (PLUS), to support experimental deployment of
explicit cooperation between endpoints and devices on path, with the follow= ing 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 with integrity protection to devices on path

- allow devices on path to provide unencrypted feedback and information
=C2=A0 about the path directly to sending endpoints, under sending endpoint=
=C2=A0 control

- allow devices on path to provide unencrypted information about the
=C2=A0 path to receiving endpoints, with encrypted feedback to the
=C2=A0 sending endpoint, under sending endpoint control

This approach explicitly gives the control of information exposure back the=
application and/or transport layer protocol on the end host. It is the goal= of
PLUS to minimize the information exposed, to make information exposure
transparent, and to limit the level of detail to that useful for network treatment, while encrypting everything else. Endpoint verification of
signaling integrity, careful design of minimal data structures, and
restrictive policies for registration of signals can help to meet this goal= .
This is important to avoid future implicit treatment and resulting
ossification, as well as to minimize the privacy risks presented by explici= t
cooperation.

Given that the primary goal of PLUS is to enable the deployment of transpor= t
protocols with encrypted headers, we assume that the higher-layer protocol = can
provide an encryption context that can be used by PLUS to provide
authentication, integrity, and encryption where needed. The primary threat<= br> model to defend against will be modification or deletion of exposed
information by middleboxes and other devices on path, by allowing a remote<= br> 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),<= br> taken from experience with the Substrate Protocol for User Datagrams (SPUD)=
prototype. The working group's main output will be an experimental prot= ocol
specification, together with an initial registry of types of information th= at
can be exposed using PLUS, clearly aligned to the use cases determined by t= he
working group. The working group will close if it is not able to come to consensus on a protocol design to meet these requirements.

The working group will additionally aim to identify and work with other
working groups that could address parts of these requirements within existi= ng
protocols, e.g. by specifying new protocol extensions, or as input for on-<= br> going standardization work. It will aim to work with working groups definin= g
encryption protocols (e.g. DTLS) 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
--
<= div data-smartmail=3D"gmail_signature">
--aaron

=3D= =3D=3D=3D=3DShort message from my phone=3D=3D=3D=3D=3D
--001a113d12689e48be0534b3bde2-- From nobody Tue Jun 7 12:32: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 48A7612D594 for ; Tue, 7 Jun 2016 12:32:38 -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 4fhAJSnB2mIs for ; Tue, 7 Jun 2016 12:32:36 -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 C393F12D14D for ; Tue, 7 Jun 2016 12:32:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A5860D9303; Tue, 7 Jun 2016 21:32:29 +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 VIqyGkn6HNiE; Tue, 7 Jun 2016 21:32:29 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2B24.dip0.t-ipconnect.de [93.236.43.36]) (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 526F2D9302; Tue, 7 Jun 2016 21:32: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: Date: Tue, 7 Jun 2016 21:32:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> To: Aaron Falk X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 19:32:38 -0000 Hi Aaron, a few comments/answers mostly as proponent (if not indicated = differently) in line.=20 > Am 07.06.2016 um 19:44 schrieb Aaron Falk : >=20 > Oh, and there should be some draft deliverables so we can have a fight = about the realism of the associated dates. As AD, I find this less important then the rest of the text. As = proponent, I think the milestones/deliverables are more important than = the dates... And there are actually a few open questions here, that I = would like to discuss in BoF. But I guess we can start this discussion = on the list before the meeting. >=20 > On Tue, Jun 7, 2016 at 1:40 PM Aaron Falk = wrote: > Apologies for being behind on the list and maybe repeating points that = have been made. A few comments based on my review of the BoF proposal & = charter: >=20 > =E2=80=A2 1st para of the charter says =E2=80=9CThe working = group will not specify any new transport protocols.=E2=80=9D and the 5th = para says =E2=80=9CThe PLUS working group will specify a new = protocol=E2=80=9D. I think the latter statement is correct. No both is correct. Yes, we want to specify a new protocol, but I = wouldn=E2=80=99t call it a transport protocol, because it=E2=80=99s = =E2=80=9Aonly=E2=80=98 a signal shim layer, which does not have any of = the other typical transport feature because there always has to be a = =E2=80=9Areal=E2=80=98 transport protocol on top. With this first = sentences we wanted to make that clear; maybe it=E2=80=99s still not = clear enough. > =E2=80=A2 I=E2=80=99d like to see a comment on PLUS re-enabling = ICMP functionality Yes, that=E2=80=99s a very good use case and clearly in scope. However, = there are other good use cases as well, see the use case draft, and we = decided to not explicitly outline one (of a subset of them) in the = charter. > =E2=80=A2 There=E2=80=99s the obvious & unaddressed question = about the relation to QUIC I also think that this does not really belong in the charter. It=E2=80=99s= for sure important to make this clear in the BoF and that why we have = the agenda item on 'Relationship to other work in the IETF=E2=80=98. > =E2=80=A2 The PLUS Bof description should start something like = =E2=80=9CThis BoF is to discuss the proposed PLUS working group. The = wg=E2=80=99s goal is to=E2=80=A6=E2=80=9D Don=E2=80=99t know; isn=E2=80=99t that implicit for a working group = forming BoF=E2=80=A6? > =E2=80=A2 No discussion of wg anti-goals. I had heard some = interest in ruling middlebox to middlebox signaling as out of scope. That=E2=80=99s a good point. I believe that=E2=80=99s out of scope and = would be willing to add that. > =E2=80=A2 (To ADs:) Would like to see the QUIC and PLUS BoFs = scheduled back-to-back. While I think the topics are mostly separable, = if the discussion gets out of sync it will be a headache. As AD, we already discussed that we would like to see the QUIC BoF first = because at least I believe otherwise there is a high risk to have the = QUIC BoF in the SPUD BoF. However, I don=E2=80=99t think back to back is = a good idea (to have some cooling down phase in the mean time). And = given that both BoFs look for a 2.5h slots, they probably will be in two = morning slots on different days. Mirja > HTH, >=20 > --aaron >=20 >=20 > On Wed, Jun 1, 2016 at 6:45 AM Brian Trammell = wrote: > Greetings, all, >=20 > We've taken another editing pass to tighten the charter; results = inline below at on GitHub (https://github.com/ietf-plus/charter). We = think this is getting close to something it would be useful to discuss = and wordsmith at a BoF. >=20 > Further comments welcome. >=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 define a common shim layer atop = the User > Datagram Protocol (UDP) to provide a transport-independent method to = signal > flow semantics under transport and application control, necessary to = enable > the deployment of new, encrypted transport protocols within the = existing > Internet. UDP provides compatibility with currently deployed = middleboxes as > well as ubiquitous support in endpoints, and supports userspace = implementation > of new transport protocols. The working group will not specify any new > transport protocols. >=20 > The current Internet protocol stack does not provide explicit, = in-band, > transport-independent signaling to on-path network devices. This has = led to > the deployment of devices which perform implicit discovery of = transport > semantics and traffic characteristics via inspection of protocol = headers and > payload, a practice made possible when these are sent in the clear. >=20 > In order to support more ubiquitous deployment of encryption, and the > encryption of transport headers to allow deployment of new transport > protocols, explicit in-band signaling must be added to the stack. This > signaling must be transport protocol independent, and the types of = information > signaled must be based on characteristics that can be independently = verified > by devices on path, or that can be usefully applied without requiring = a trust > relationship between endpoints and the path. Further, a feedback = channel that > provides information from on-path devices back to endpoints and = applications, > e.g. for error handling, is essential for the deployment and success = of an > explicit cooperation approach. >=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 > The PLUS working group will specify a new protocol as a Path Layer > UDP Substrate (PLUS), to support experimental deployment of > explicit cooperation between endpoints and devices on path, with the = following goals: >=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 with integrity protection to devices on path >=20 > - allow devices on path to provide unencrypted feedback and = information > about the path directly to sending endpoints, under sending endpoint > control >=20 > - 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 >=20 > 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. >=20 > Given that the primary goal of PLUS is to enable the deployment of = transport > protocols with encrypted headers, we assume that the higher-layer = protocol can > provide an encryption context that can be used by PLUS to provide > authentication, integrity, and encryption where needed. The primary = threat > model to defend against will be modification or deletion of exposed > information by middleboxes and other devices on path, by allowing a = remote > endpoint to detect modifications. >=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 the use cases determined = by the > working group. 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 and work with = other > working groups that could address parts of these requirements within = existing > protocols, e.g. by specifying new protocol extensions, or as input for = on- > going standardization work. It will aim to work with working groups = defining > encryption protocols (e.g. DTLS) which could be used for encryption of > transport protocols running over PLUS. >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --=20 > --aaron >=20 > =3D=3D=3D=3D=3DShort message from my phone=3D=3D=3D=3D=3D > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Tue Jun 7 12:54: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 DF81812D1E7 for ; Tue, 7 Jun 2016 12:54:01 -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 vRtbvccNuvku for ; Tue, 7 Jun 2016 12:53:54 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3254012D528 for ; Tue, 7 Jun 2016 12:53:54 -0700 (PDT) Received: by mail-qg0-x22f.google.com with SMTP id 93so64060191qgx.2 for ; Tue, 07 Jun 2016 12:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=WGqp6gsSX1Li7UWy3s+Ag4oQVtyM5j22FpOk94WVpMo=; b=cRB1Ru0/dEMxeP8OWQvQYkopKe+xTF0RTg97MHATr79gpYNz5fC9XwUDF8LeZi/EeE xYmYA3ylGTOf6lgZeJiS5Yn6h0ePkwjGtBhXvnq8pkhqeGZmstPIqeGeeGLnZ6SzHmEq n1+SRXOy6eQllG1rkx9VpjO7mFI3DUsFsaWq7VDsJsqYHy9wCJOKM9sQeJT6N8xAtIbg YrBcKZAk14+gyFIw1GW+sFqY27uuxl7K/mttdzygqHhlw796Ash4LqkpSzieLI2Vp9xd fLDm38hYh7UFKHDDzahn+tXDMG7Z9DgYDhrvWVauEtuOFkozbncMhTkfWWP0MGKU0vBh qlrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=WGqp6gsSX1Li7UWy3s+Ag4oQVtyM5j22FpOk94WVpMo=; b=i8CrhHzH/NQa3BT3hmuoJXwnlGpW2YLvdVxl/m5yXzFPxehpqKL1XzBw+fBeFLRm8o zb9W0LphJtW1HPRw4wUOkKZhC8ebp0j7MXbmeGrXuWeaDI/qtUdH7SSVMs9kyW1SvnXZ xBeSgIwCljnlxsJeJgF1vQJTp+Vn2ZUb8ZldI8Hb09I1watC7/VNH39EK75HvFJPJeKk 3Wk8rlJHo2AhgwtTjJWz/NG96JosiWUV9JMHpwpa2Uk0Sa28YT6xLWTbRowFeKNG1YZU dAAT0HRZZudQD0Ka2awitG4kTibk3h58ZsIY+++LiyIf46jEo4OPfShbiXr88/wjVO8i 3UIQ== X-Gm-Message-State: ALyK8tJY0h45ymZSAPgxsUearxG9vAVaJP5+o8pIdfC6YGC8GsgSwsQLYGXD+IGoHYHsng== X-Received: by 10.140.29.201 with SMTP id b67mr1219320qgb.77.1465329233103; Tue, 07 Jun 2016 12:53:53 -0700 (PDT) Received: from ?IPv6:2001:4878:8000:60:5c45:d337:3549:3650? ([2001:4878:8000:60:5c45:d337:3549:3650]) by smtp.gmail.com with ESMTPSA id z15sm7027162qkb.15.2016.06.07.12.53.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Jun 2016 12:53:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DA40B6EF-78BF-47A1-9C97-D17B7BF93FDF" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Aaron Falk In-Reply-To: <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> Date: Tue, 7 Jun 2016 15:53:50 -0400 Message-Id: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 19:54:02 -0000 --Apple-Mail=_DA40B6EF-78BF-47A1-9C97-D17B7BF93FDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mirja! > On Jun 7, 2016, at 3:32 PM, Mirja K=C3=BChlewind = wrote: >=20 > Hi Aaron, >=20 > a few comments/answers mostly as proponent (if not indicated = differently) in line.=20 >=20 >> Am 07.06.2016 um 19:44 schrieb Aaron Falk >: >>=20 >> Oh, and there should be some draft deliverables so we can have a = fight about the realism of the associated dates. >=20 > As AD, I find this less important then the rest of the text. As = proponent, I think the milestones/deliverables are more important than = the dates... And there are actually a few open questions here, that I = would like to discuss in BoF. But I guess we can start this discussion = on the list before the meeting. I was joking about the argument re: dates. But I think we are in = agreement that there should be discussion about what the deliverables = should be. This would be helped with a strawman in advance. > On Tue, Jun 7, 2016 at 1:40 PM Aaron Falk > wrote: >> Apologies for being behind on the list and maybe repeating points = that have been made. A few comments based on my review of the BoF = proposal & charter: >>=20 >> =E2=80=A2 1st para of the charter says =E2=80=9CThe working = group will not specify any new transport protocols.=E2=80=9D and the 5th = para says =E2=80=9CThe PLUS working group will specify a new = protocol=E2=80=9D. I think the latter statement is correct. >=20 > No both is correct. Yes, we want to specify a new protocol, but I = wouldn=E2=80=99t call it a transport protocol, because it=E2=80=99s = =E2=80=9Aonly=E2=80=98 a signal shim layer, which does not have any of = the other typical transport feature because there always has to be a = =E2=80=9Areal=E2=80=98 transport protocol on top. With this first = sentences we wanted to make that clear; maybe it=E2=80=99s still not = clear enough. I am unclear. Maybe others are not. Are you inventing a new = =E2=80=99thing=E2=80=99 by not calling it a "shim that is not a = transport protocol"? Is there some reason to do so? =20 >=20 >> =E2=80=A2 I=E2=80=99d like to see a comment on PLUS re-enabling = ICMP functionality >=20 > Yes, that=E2=80=99s a very good use case and clearly in scope. = However, there are other good use cases as well, see the use case draft, = and we decided to not explicitly outline one (of a subset of them) in = the charter. Fair point but I think the charter would benefit from at least a brief = listing of the benefits that come from light weight, in-band signaling. = Besides their important role as scoping documents for working groups, = charters (IMO) should help someone figure out what problems you are = solving. This can of course be done at length in a use-case doc but I = believe providing a clue for the curious outsider as to whether the work = is relevant. YMMV. >=20 >> =E2=80=A2 There=E2=80=99s the obvious & unaddressed question = about the relation to QUIC >=20 > I also think that this does not really belong in the charter. It=E2=80=99= s for sure important to make this clear in the BoF and that why we have = the agenda item on 'Relationship to other work in the IETF=E2=80=99. OK. I probably should have figured that out by who was presenting. >=20 >> =E2=80=A2 The PLUS Bof description should start something like = =E2=80=9CThis BoF is to discuss the proposed PLUS working group. The = wg=E2=80=99s goal is to=E2=80=A6=E2=80=9D >=20 > Don=E2=80=99t know; isn=E2=80=99t that implicit for a working group = forming BoF=E2=80=A6? Meh, I disagree. Clearly a nit. >=20 >> =E2=80=A2 No discussion of wg anti-goals. I had heard some = interest in ruling middlebox to middlebox signaling as out of scope. >=20 > That=E2=80=99s a good point. I believe that=E2=80=99s out of scope and = would be willing to add that. Are there other anti-goals? >=20 >> =E2=80=A2 (To ADs:) Would like to see the QUIC and PLUS BoFs = scheduled back-to-back. While I think the topics are mostly separable, = if the discussion gets out of sync it will be a headache. >=20 > As AD, we already discussed that we would like to see the QUIC BoF = first because at least I believe otherwise there is a high risk to have = the QUIC BoF in the SPUD BoF. However, I don=E2=80=99t think back to = back is a good idea (to have some cooling down phase in the mean time). = And given that both BoFs look for a 2.5h slots, they probably will be in = two morning slots on different days. Fair enough. My feelings about back-to-back are not strong and I am = glad you=E2=80=99ve given it thought. =E2=80=94aaron= --Apple-Mail=_DA40B6EF-78BF-47A1-9C97-D17B7BF93FDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Mirja!

On Jun 7, 2016, at 3:32 PM, = Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:

Hi Aaron,

a few comments/answers mostly as proponent (if = not indicated differently) in line. 

Am 07.06.2016 um 19:44 schrieb Aaron Falk <aaron.falk@gmail.com>:

Oh, = and there should be some draft deliverables so we can have a fight about = the realism of the associated dates.

As AD, I find this = less important then the rest of the text. As proponent, I think the = milestones/deliverables are more important than the dates... And there = are actually a few open questions here, that I would like to discuss in = BoF. But I guess we can start this discussion on the list before the = meeting.

I was = joking about the argument re: dates.  But I think we are in = agreement that there should be discussion about what the deliverables = should be.  This would be helped with a strawman in = advance.


On Tue, Jun 7, 2016 at 1:40 PM = Aaron Falk <aaron.falk@gmail.com> wrote:
Apologies = for being behind on the list and maybe repeating points that have been = made.  A few comments based on my review of the BoF proposal & = charter:

=E2=80=A2 1st para of the charter = says =E2=80=9CThe working group will not specify any new transport = protocols.=E2=80=9D and the 5th para says =E2=80=9CThe PLUS working = group will specify a new protocol=E2=80=9D.  I think the latter = statement is correct.

No both is correct. Yes, we want to = specify a new protocol, but I wouldn=E2=80=99t call it a transport = protocol, because it=E2=80=99s =E2=80=9Aonly=E2=80=98 a signal shim = layer, which does not have any of the other typical transport feature = because there always has to be a =E2=80=9Areal=E2=80=98 transport = protocol on top. With this first sentences we wanted to make that clear; = maybe it=E2=80=99s still not clear enough.

I am = unclear.  Maybe others are not.  Are you inventing a new = =E2=80=99thing=E2=80=99 by not calling it a "shim that is not a = transport protocol"?  Is there some reason to do so? =  



=E2=80=A2 I=E2=80=99d like to see a comment on PLUS = re-enabling ICMP functionality

Yes, that=E2=80=99s = a very good use case and clearly in scope. However, there are other good = use cases as well, see the use case draft, and we decided to not = explicitly outline one (of a subset of them) in the charter.

Fair point but I think the charter would benefit = from at least a brief listing of the benefits that come from light = weight, in-band signaling.  Besides their important role as scoping = documents for working groups, charters (IMO) should help someone figure = out what problems you are solving.  This can of course be done at = length in a use-case doc but I believe providing a clue for the curious = outsider as to whether the work is relevant.  YMMV.


=E2=80=A2 There=E2=80=99s the = obvious & unaddressed question about the relation to QUIC

I also think that this does not really belong in = the charter. It=E2=80=99s for sure important to make this clear in the = BoF and that why we have the agenda item on 'Relationship to other work = in the IETF=E2=80=99.

OK.  I = probably should have figured that out by who was presenting.


=E2=80=A2 The PLUS Bof = description should start something like =E2=80=9CThis BoF is to discuss = the proposed PLUS working group.  The wg=E2=80=99s goal is = to=E2=80=A6=E2=80=9D

Don=E2=80=99t know; isn=E2=80=99t that = implicit for a working group forming BoF=E2=80=A6?

Meh, I disagree.  Clearly a = nit.



=E2=80=A2 No discussion of wg anti-goals.  I had = heard some interest in ruling middlebox to middlebox signaling as out of = scope.

That=E2=80=99s a good point. I believe = that=E2=80=99s out of scope and would be willing to add that.

Are there other anti-goals?


=E2=80=A2 (To ADs:) Would like to = see the QUIC and PLUS BoFs scheduled back-to-back.  While I think = the topics are mostly separable, if the discussion gets out of sync it = will be a headache.

As AD, we already discussed that we would = like to see the QUIC BoF first because at least I believe otherwise = there is a high risk to have the QUIC BoF in the SPUD BoF. However, I = don=E2=80=99t think back to back is a good idea (to have some cooling = down phase in the mean time). And given that both BoFs look for a 2.5h = slots, they probably will be in two morning slots on different = days.

Fair = enough.  My feelings about back-to-back are not strong and I am = glad you=E2=80=99ve given it thought.

=E2=80=94aaron
= --Apple-Mail=_DA40B6EF-78BF-47A1-9C97-D17B7BF93FDF-- From nobody Tue Jun 7 13:05: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 2A4C512D743 for ; Tue, 7 Jun 2016 13:05:36 -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 dXCNX4tsm3zW for ; Tue, 7 Jun 2016 13:05:33 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8D212D5D0 for ; Tue, 7 Jun 2016 13:05:32 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id e72so294801558oib.1 for ; Tue, 07 Jun 2016 13:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T+BS1ho9zsv1e5kNOycrexnoSy4N6ukfmWG/R/vBAbw=; b=Peuvp0JATo6seSLuYSy+UxYN2CVCKDYT6/xLgBAWD2l2Tzmj/caErebOCJVlM1b5nb btq/NOvQFZv98d4B7PptvrxZusolroQyakbZUBCw8et0MWP+DDrWhv/n4o9evpU2Ugae DeVooqlyTjk3DC4v8HikQw9QgS41JWUS2WtPlqk+1jg4846jktuIaiAOheGDrT1ng4hi tFD2NT9417zSSShvWjeYMEv3cgrhyzxRyyICggNPuqfYnXX/ThR+QJkC5GZSzlh5BWeO iiuNCHiVbKvFblzcCxZyfBYfQGHr843aB3zad6uh93eB4n39KoMCZlUNz4BObH84nSBe kOTA== 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=T+BS1ho9zsv1e5kNOycrexnoSy4N6ukfmWG/R/vBAbw=; b=gZhsvPGaP3S+cj/s24uyheKb83gYRMT50gDLgRVYuuhCwO3UObm3wdDaol2zWjDk1o tkUxqC/SDnRf0Y2hr8rH32teSF3Z4de2wHpwmchTsrA6BIZQseojGsYHQBfkv3LbGEg+ Wg6EOrWs9CaliLlBskZ460/7KZwWGorKI3kRd0TRV94K/KwklDvF2/bR+YHsH0xwIrT7 H9L4PLExCaZ088ciq22VrYtPe7lWuIr25LqyXLawjHmC6nEIXEATepqV6RVbBxKZ8h/M E9Uj2H14Uo6p5f8jYigQ2QhhE0aVQMn3Gww/QbS011ldi8VjmP6/L352PHuGiq3S51Sb Ckug== X-Gm-Message-State: ALyK8tKLv+P1g7Xg/pL68CwwxM7QQGqmWRF01Co2D4VEfOPPh2HuxXGdfu4VIl/Bd3SEgMQv+8+sBJTwa7uXqw== X-Received: by 10.157.1.140 with SMTP id e12mr838189ote.180.1465329931848; Tue, 07 Jun 2016 13:05:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Tue, 7 Jun 2016 13:05:12 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> From: Ted Hardie Date: Tue, 7 Jun 2016 13:05:12 -0700 Message-ID: To: Aaron Falk Content-Type: multipart/alternative; boundary=001a114fd90c11127b0534b5b63b Archived-At: Cc: Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:05:36 -0000 --001a114fd90c11127b0534b5b63b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, No both is correct. Yes, we want to specify a new protocol, but I wouldn=E2= =80=99t call it a transport protocol, because it=E2=80=99s =E2=80=9Aonly=E2=80=98 a= signal shim layer, which does not have any of the other typical transport feature because there always has to be a =E2=80=9Areal=E2=80=98 transport protocol on top. = With this first sentences we wanted to make that clear; maybe it=E2=80=99s still not clear = enough. > I am unclear. Maybe others are not. Are you inventing a new =E2=80=99th= ing=E2=80=99 by > not calling it a "shim that is not a transport protocol"? Is there some > reason to do so? > > Well, I don't want to speak for Mirja, but from my perspective, you get a different thing if you want to recreate a re-usable shim/toolkit than what you get from creating a transport. Imagine for a moment that we are talking about transporting RTP/UDP, and we would like signalling from the path to give us icmp-like information. We could do that by recreating RTP with a signalling piece built in to a protocol replacing UDP; we could do that by updating UDP itself; we could describe how to encapsulate the RTP/UDP in something that carried signalling but was otherwise relying on the encapsulated protocol for everything. The advantage of doing the last is that you don't have to recreate each transport when you want to use it with signalling. You can also use the standard transports without this, if your deployment doesn't need it. YMMV, obviously. Ted > > > =E2=80=A2 I=E2=80=99d like to see a comment on PLUS re-enabling ICMP func= tionality > > > Yes, that=E2=80=99s a very good use case and clearly in scope. However, t= here are > other good use cases as well, see the use case draft, and we decided to n= ot > explicitly outline one (of a subset of them) in the charter. > > > Fair point but I think the charter would benefit from at least a brief > listing of the benefits that come from light weight, in-band signaling. > Besides their important role as scoping documents for working groups, > charters (IMO) should help someone figure out what problems you are > solving. This can of course be done at length in a use-case doc but I > believe providing a clue for the curious outsider as to whether the work = is > relevant. YMMV. > > > =E2=80=A2 There=E2=80=99s the obvious & unaddressed question about the re= lation to QUIC > > > I also think that this does not really belong in the charter. It=E2=80=99= s for > sure important to make this clear in the BoF and that why we have the > agenda item on 'Relationship to other work in the IETF=E2=80=99. > > > OK. I probably should have figured that out by who was presenting. > > > =E2=80=A2 The PLUS Bof description should start something like =E2=80=9CT= his BoF is to > discuss the proposed PLUS working group. The wg=E2=80=99s goal is to=E2= =80=A6=E2=80=9D > > > Don=E2=80=99t know; isn=E2=80=99t that implicit for a working group formi= ng BoF=E2=80=A6? > > > Meh, I disagree. Clearly a nit. > > > > =E2=80=A2 No discussion of wg anti-goals. I had heard some interest in r= uling > middlebox to middlebox signaling as out of scope. > > > That=E2=80=99s a good point. I believe that=E2=80=99s out of scope and wo= uld be willing to > add that. > > > Are there other anti-goals? > > > =E2=80=A2 (To ADs:) Would like to see the QUIC and PLUS BoFs scheduled > back-to-back. While I think the topics are mostly separable, if the > discussion gets out of sync it will be a headache. > > > As AD, we already discussed that we would like to see the QUIC BoF first > because at least I believe otherwise there is a high risk to have the QUI= C > BoF in the SPUD BoF. However, I don=E2=80=99t think back to back is a goo= d idea (to > have some cooling down phase in the mean time). And given that both BoFs > look for a 2.5h slots, they probably will be in two morning slots on > different days. > > > Fair enough. My feelings about back-to-back are not strong and I am glad > you=E2=80=99ve given it thought. > > =E2=80=94aaron > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > > --001a114fd90c11127b0534b5b63b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

No both is correct. Yes, we want to spe= cify a new protocol, but I wouldn=E2=80=99t call it a transport protocol, b= ecause it=E2=80=99s =E2=80=9Aonly=E2=80=98 a signal shim layer, which does = not have any of the other typical transport feature because there always ha= s to be a =E2=80=9Areal=E2=80=98 transport protocol on top. With this first= sentences we wanted to make that clear; maybe it=E2=80=99s still not clear= enough.


I am unclear.=C2=A0 Maybe others are not.=C2=A0 Are you inventing= a new =E2=80=99thing=E2=80=99 by not calling it a "shim that is not a= transport protocol"?=C2=A0 Is there some reason to do so? =C2=A0


Well, I don't want to speak for Mirja, but from my pers= pective, you get a different thing if you want to recreate a re-usable shim= /toolkit than what you get from creating a transport.=C2=A0

Imagine= for a moment that we are talking about transporting RTP/UDP, and we would = like signalling from the path to give us icmp-like information.=C2=A0 We co= uld do that by recreating RTP with a=C2=A0 signalling piece built in to a p= rotocol replacing UDP; we could do that by updating UDP itself; we could de= scribe how to encapsulate the RTP/UDP in something that carried signalling = but was otherwise relying on the encapsulated protocol for everything.=C2= =A0 The advantage of doing the last is that you don't have to recreate = each transport when you want to use it with signalling.=C2=A0 You can also = use the standard transports without this, if your deployment doesn't ne= ed it.

YMMV, obviously.

Ted

=C2=A0


=E2=80=A2 I=E2=80=99d like to see a comm= ent on PLUS re-enabling ICMP functionality

Yes, that=E2=80=99s a very goo= d use case and clearly in scope. However, there are other good use cases as= well, see the use case draft, and we decided to not explicitly outline one= (of a subset of them) in the charter.

Fair point= but I think the charter would benefit from at least a brief listing of the= benefits that come from light weight, in-band signaling.=C2=A0 Besides the= ir important role as scoping documents for working groups, charters (IMO) s= hould help someone figure out what problems you are solving.=C2=A0 This can= of course be done at length in a use-case doc but I believe providing a cl= ue for the curious outsider as to whether the work is relevant.=C2=A0 YMMV.=


= =E2=80=A2 There=E2=80=99s the obvious & unaddressed question about the = relation to QUIC

I also think that this does not really belong in the cha= rter. It=E2=80=99s for sure important to make this clear in the BoF and tha= t why we have the agenda item on 'Relationship to other work in the IET= F=E2=80=99.

OK.=C2=A0 I probably should have figu= red that out by who was presenting.


=E2=80=A2 The PLUS Bof description should= start something like =E2=80=9CThis BoF is to discuss the proposed PLUS wor= king group.=C2=A0 The wg=E2=80=99s goal is to=E2=80=A6=E2=80=9D

Don=E2=80= =99t know; isn=E2=80=99t that implicit for a working group forming BoF=E2= =80=A6?

Meh, I disagree.=C2=A0 Clearly a nit.



=E2=80=A2 No discussion of wg anti-goals.=C2=A0 I had heard some = interest in ruling middlebox to middlebox signaling as out of scope.

That= =E2=80=99s a good point. I believe that=E2=80=99s out of scope and would be= willing to add that.

Are there other anti-goals?=


= =E2=80=A2 (To ADs:) Would like to see the QUIC and PLUS BoFs scheduled back= -to-back.=C2=A0 While I think the topics are mostly separable, if the discu= ssion gets out of sync it will be a headache.

As AD, we already discussed= that we would like to see the QUIC BoF first because at least I believe ot= herwise there is a high risk to have the QUIC BoF in the SPUD BoF. However,= I don=E2=80=99t think back to back is a good idea (to have some cooling do= wn phase in the mean time). And given that both BoFs look for a 2.5h slots,= they probably will be in two morning slots on different days.

Fair enough.=C2=A0 My feelings about back-to-back are not str= ong and I am glad you=E2=80=99ve given it thought.

=E2=80=94aaron
=

______________________________________________= _
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud


--001a114fd90c11127b0534b5b63b-- From nobody Tue Jun 7 13:07: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 0CA8412D1CB for ; Tue, 7 Jun 2016 13:07:35 -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 IXTEm5t3IJ2w for ; Tue, 7 Jun 2016 13:07:33 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 8CC3212D0DD for ; Tue, 7 Jun 2016 13:07:33 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id i187so101055910qkd.3 for ; Tue, 07 Jun 2016 13:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=3vuWKYyUJLXLyobhyZV/uD4/OQjJhx+9aRlR2tIvW4Y=; b=JbQIuA7/ZOn3gHx5mM3tkVd/ymq0DMhYQV/8/DGDANkT6pwY2RJXZsQFvbywl9Haoc UVd8gWiA78+vPmYo79XSZ4iEkhkNSK3kxj+FIsr95ZqeNf3LVy9AD/KeNYadHH97SZUO /RU4nt/I7xpdqPgvaz/gtvj5lnkzSfQvpzAqT1rkpwZfxeBQBy76bVEndl3wnjkHtPIX v5EvetohL4MR4h4Yqz52lTS1wbxcF/ESol/UBdO+ZqlmVCSVmKarl3AZdy3m63jZ+ooQ hsL1MtSU0nCOB5Yq41sh2L8R/y3g/kiFnNaOo4zaS9lNReBvGGg5vFKHc7vKlHRgbc/n o/Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3vuWKYyUJLXLyobhyZV/uD4/OQjJhx+9aRlR2tIvW4Y=; b=D+shBAqh46gsm5g1T+lHF1mSqQicnqmYOWuguUgrQjhY1rMDm97blOg0r8GEBdu7zM +gqOMuZKSBR9vrJNsouaHcLYpOl1b8CNcgB93el0m/8URnw1lZMGub7JnGM4PjcK1+Io S0v3IM2yvmhpeUtwaGYOAKySDUbY60vSVkuVu1/iemDVnbS9C3MI+74ECWFz9cs3C/Aa 5r0wBe0Y8vb0qk3mShPBwhAWowzXuAGQ2Kttj2KBd1WzdCYY1R8aPtDo1VEdAIjiY8Jm CTAgoA35bjy1KIXuiR9SjKYMSEdCj4e7Q04GDnQX+ItbC+44N9kO0RxOvon07eZL3ibf fBJw== X-Gm-Message-State: ALyK8tLoVqXqpp21UYvaHfiJLiDoQf/kTYEfk10qzGJU7d077jMljjD82wPLhQqg0gwVgg== X-Received: by 10.55.43.130 with SMTP id r2mr1351445qkr.150.1465330052614; Tue, 07 Jun 2016 13:07:32 -0700 (PDT) Received: from bos-mppgj.kendall.corp.akamai.com (a23-79-238-10.deploy.static.akamaitechnologies.com. [23.79.238.10]) by smtp.gmail.com with ESMTPSA id d7sm6583056qkf.37.2016.06.07.13.07.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Jun 2016 13:07:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0C86EBAD-C7B4-46FD-8386-5D7595063817" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Aaron Falk In-Reply-To: Date: Tue, 7 Jun 2016 16:07:30 -0400 Message-Id: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> To: Ted Hardie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:07:35 -0000 --Apple-Mail=_0C86EBAD-C7B4-46FD-8386-5D7595063817 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 7, 2016, at 4:05 PM, Ted Hardie wrote: >=20 >> No both is correct. Yes, we want to specify a new protocol, but I = wouldn=E2=80=99t call it a transport protocol, because it=E2=80=99s = =E2=80=9Aonly=E2=80=98 a signal shim layer, which does not have any of = the other typical transport feature because there always has to be a = =E2=80=9Areal=E2=80=98 transport protocol on top. With this first = sentences we wanted to make that clear; maybe it=E2=80=99s still not = clear enough. >=20 >=20 > I am unclear. Maybe others are not. Are you inventing a new = =E2=80=99thing=E2=80=99 by not calling it a "shim that is not a = transport protocol"? Is there some reason to do so? =20 >=20 >=20 > Well, I don't want to speak for Mirja, but from my perspective, you = get a different thing if you want to recreate a re-usable shim/toolkit = than what you get from creating a transport. =20 >=20 > Imagine for a moment that we are talking about transporting RTP/UDP, = and we would like signalling from the path to give us icmp-like = information. We could do that by recreating RTP with a signalling = piece built in to a protocol replacing UDP; we could do that by updating = UDP itself; we could describe how to encapsulate the RTP/UDP in = something that carried signalling but was otherwise relying on the = encapsulated protocol for everything. The advantage of doing the last = is that you don't have to recreate each transport when you want to use = it with signalling. You can also use the standard transports without = this, if your deployment doesn't need it. Hi Ted! So, we are creating an extension to UDP then, yes? Why not call it = that? =E2=80=94aaron= --Apple-Mail=_0C86EBAD-C7B4-46FD-8386-5D7595063817 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 7, 2016, at 4:05 PM, Ted Hardie <ted.ietf@gmail.com> = wrote:

No= both is correct. Yes, we want to specify a new protocol, but I = wouldn=E2=80=99t call it a transport protocol, because it=E2=80=99s = =E2=80=9Aonly=E2=80=98 a signal shim layer, which does not have any of = the other typical transport feature because there always has to be a = =E2=80=9Areal=E2=80=98 transport protocol on top. With this first = sentences we wanted to make that clear; maybe it=E2=80=99s still not = clear enough.


I am unclear.  Maybe others = are not.  Are you inventing a new =E2=80=99thing=E2=80=99 by not = calling it a "shim that is not a transport protocol"?  Is there = some reason to do so?  

Well, I don't want to speak for Mirja, = but from my perspective, you get a different thing if you want to = recreate a re-usable shim/toolkit than what you get from creating a = transport.  

Imagine for a moment that we are talking about = transporting RTP/UDP, and we would like signalling from the path to give = us icmp-like information.  We could do that by recreating RTP with = a  signalling piece built in to a protocol replacing UDP; we could = do that by updating UDP itself; we could describe how to encapsulate the = RTP/UDP in something that carried signalling but was otherwise relying = on the encapsulated protocol for everything.  The advantage of = doing the last is that you don't have to recreate each transport when = you want to use it with signalling.  You can also use the standard = transports without this, if your deployment doesn't need = it.

Hi Ted!

So, we are creating an extension to UDP = then, yes?  Why not call it that?

=E2=80=94aaron
= --Apple-Mail=_0C86EBAD-C7B4-46FD-8386-5D7595063817-- From nobody Tue Jun 7 13:25: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 961DA12D0A7 for ; Tue, 7 Jun 2016 13:25:26 -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 emU3PYsO4tLe for ; Tue, 7 Jun 2016 13:25:25 -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 373B812D7B4 for ; Tue, 7 Jun 2016 13:25:24 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id e72so295640615oib.1 for ; Tue, 07 Jun 2016 13:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XGDT4uQSqk/NdNmKLO7OvYlkJiFS1nBRay8mqfRxGBI=; b=m8chS8CKUNvTjY8U7FbPe4XqlcuYOuldYzYoCz1LpXBH/uN7z17yphahvsfIBZXpwE NXiFcd3ZC83z2zhy/PIafMqLFyMgoSC4NBdo2oufH3Mo2d+HqLigaEo/DSLZBHlMIJz3 xjNCCn5TZ3vnTaPEhzxSQ38K94wHcoyK3Kn/4j+Eat+dWfTbKfCULEI/nGukvshGyHAS vBHdVUzHvaw17FnP80i3T7vknMwrCne80Xrp/G6ethPPC2lzOmwc5PqnorfR7yewmsrU Q5pUBCeDEpG61EQtNpB3BYRXIXH+QsnOFIaQkmPPCYbgkoKlL9L5T3CiRY4ifaUCsCP1 7Jnw== 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=XGDT4uQSqk/NdNmKLO7OvYlkJiFS1nBRay8mqfRxGBI=; b=IFuAGDctuCGE4Bl774mMu0cHjMS+CWAzeh5gzhdMFCWqAoqkHLqS6F/r+V50XDpUPE g6Wjkz9ZGWbJLgHWqp4B4CSuIIv8igHtpwKJ/6WXy9CsXPounQzCRqU3JwviSEVuvBvQ 1C+o0w1TDsX0eddCkNsnK4yHEAKPBdh1KugylvYYzNUYr/zBgrNkw6PmPW7Pzj4U/xDK o7uYiZKWnVHm8a1hJaI73IMHZ4e+V8na1xIzweD6hyc+2kfzkFHGsHlB3d32gmO66gKh VowHZMiHqoCUKChwb2jJu8+jdTveWWqvJRHNQiFWQwVgr1slVOAubpRGP87q7u2cBw2d Ki1w== X-Gm-Message-State: ALyK8tJrdYesIe4PJAECXrwiYkCnYAE9EezmfR88Z3oJ25lM68gaJFWLNp5WO4WQeDIIBlJJ+sQm9u/VdRQS8A== X-Received: by 10.157.35.111 with SMTP id k44mr931721otd.18.1465331123409; Tue, 07 Jun 2016 13:25:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Tue, 7 Jun 2016 13:25:03 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> From: Ted Hardie Date: Tue, 7 Jun 2016 13:25:03 -0700 Message-ID: To: Aaron Falk Content-Type: multipart/alternative; boundary=001a113d0c2816db180534b5fd43 Archived-At: Cc: Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:25:26 -0000 --001a113d0c2816db180534b5fd43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 7, 2016 at 1:07 PM, Aaron Falk wrote: > > > > Hi Ted! > > So, we are creating an extension to UDP then, yes? Why not call it that? > > Well, because "extension" doesn't sound like you're creating an encapsulating substrate? I don't really want to paint the bikeshed too much over this, but if you think "substrate" is hurting people's understanding of what this effort is trying to do, we can certainly consider other terms. Almost all of the obvious ones are heavily overloaded, at least as I number them off on my fingers and toes, though, so we may be stuck with phrases ("path-layer UDP substrate") or invented metasyntactic variables ("fleen"). Ted > =E2=80=94aaron > --001a113d0c2816db180534b5fd43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 7, 2016 at 1:07 PM, Aaron Falk <aaron.falk= @gmail.com> wrote:



Hi Ted!
<= div>
So, we are creating an extension to UDP then, yes?=C2=A0= Why not call it that?
=


Well, b= ecause "extension" doesn't sound like you're creating an = encapsulating substrate?

I don't really want to paint= the bikeshed too much over this, but if you think "substrate" is= hurting people's understanding of what this effort is trying to do, we= can certainly consider other terms.=C2=A0 Almost all of the obvious ones a= re heavily overloaded, at least as I number them off on my fingers and toes= , though, so we may be stuck with phrases ("path-layer UDP substrate&q= uot;) or invented metasyntactic variables ("fleen").

Ted


=C2=A0
=
=E2=80=94aaron

--001a113d0c2816db180534b5fd43-- From nobody Tue Jun 7 13:37:20 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E2312D0A7 for ; Tue, 7 Jun 2016 13:37:18 -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 3dZ_i_8zenri for ; Tue, 7 Jun 2016 13:37:15 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDB712D842 for ; Tue, 7 Jun 2016 13:37:15 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id z189so106668944itg.0 for ; Tue, 07 Jun 2016 13:37: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:content-transfer-encoding; bh=nrzIg+6wb74vm4gsYm1TwRPYnDk+IhF5DFvo1OQ8LfY=; b=k6gLIjejJxLjTidUd4DtzPpR4ZcFpuwlrDD1WWBisYzwhghMr4KfSGLZXTZvVT5whI 4Aqc9vwN28eSetQoUiwYwbbJvkuMDhfa/BxHXT4jQ7c/YAJyZ/qwpL9s8lbZ+iXZXyNe egUtR7vxgIQ/A33b7YcB9TtJNJZSibUPJOaU8Yb1RITiizgWfwub/kY4PUmpdARmF+2h NzM6OLTIyTbyMzB16P93LVMFUp1eEaTX+fukIKtWqeIxkLQ3xWood1bGGwW9abX0YcpJ gcA9m1xIgtRRz0BXXCD8YxO18K3xSgB92YVeuw8V9SWndDW/iv8KpkFULuE4Z2t8wTfL nHAg== 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=nrzIg+6wb74vm4gsYm1TwRPYnDk+IhF5DFvo1OQ8LfY=; b=D8KOVkgHSkoTYyNiiAilThroNbl1lrsSrNPKFO2J0rpz3ZEeQ17yslMnqxVmk8wTP/ jlNAJ59PGfgTDfhyGHuV2qlDu/x3A+SLltHe1U4j33hb6FlUwGMU2RNZepzI7Nz6NGTf V8t37hsVkvwgpjVsIK8y2VGpCHHbQF81BqvKxmey0p+yJTQkg9TBp2Yd/hG6un4ZikHz VKDN05e23h0dcr0rso8CFUFQZX5J/tP2IlEWhuraTveuBipHslc3t7VBBDCklru7iqIH HNnhF7+abZAqqEMQPwBSCZfAfvqY+uhzYNtrju4C138fHL1iaCyOktSHsUU1l/fq9MRP UW0A== X-Gm-Message-State: ALyK8tLwXOXuB6PI3QVct1PWDtcv8GZbrPg1EsXWCGvd75hKpuevDS77GuEWsmCe9bK5Dwn4jkiGlFyQDZhX1A== MIME-Version: 1.0 X-Received: by 10.36.16.67 with SMTP id 64mr2864438ity.88.1465331834936; Tue, 07 Jun 2016 13:37:14 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Tue, 7 Jun 2016 13:37:14 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> Date: Tue, 7 Jun 2016 13:37:14 -0700 Message-ID: From: Tom Herbert To: Aaron Falk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Trammell , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:37:18 -0000 On Tue, Jun 7, 2016 at 10:40 AM, Aaron Falk wrote: > Apologies for being behind on the list and maybe repeating points that ha= ve > been made. A few comments based on my review of the BoF proposal & chart= er: > > 1st para of the charter says =E2=80=9CThe working group will not specify = any new > transport protocols.=E2=80=9D and the 5th para says =E2=80=9CThe PLUS wor= king group will > specify a new protocol=E2=80=9D. I think the latter statement is correct= . > I=E2=80=99d like to see a comment on PLUS re-enabling ICMP functionality What does "re-enabling ICMP functionality" mean? Thanks, Tom > There=E2=80=99s the obvious & unaddressed question about the relation to = QUIC > The PLUS Bof description should start something like =E2=80=9CThis BoF is= to discuss > the proposed PLUS working group. The wg=E2=80=99s goal is to=E2=80=A6=E2= =80=9D > No discussion of wg anti-goals. I had heard some interest in ruling > middlebox to middlebox signaling as out of scope. > (To ADs:) Would like to see the QUIC and PLUS BoFs scheduled back-to-back= . > While I think the topics are mostly separable, if the discussion gets out= of > sync it will be a headache. > > HTH, > > --aaron > > > On Wed, Jun 1, 2016 at 6:45 AM Brian Trammell wrote: >> >> Greetings, all, >> >> We've taken another editing pass to tighten the charter; results inline >> below at on GitHub (https://github.com/ietf-plus/charter). We think this= is >> getting close to something it would be useful to discuss and wordsmith a= t a >> BoF. >> >> Further comments welcome. >> >> 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 define a common shim layer atop the >> User >> Datagram Protocol (UDP) to provide a transport-independent method to >> signal >> flow semantics under transport and application control, necessary to >> enable >> the deployment of new, encrypted transport protocols within the existing >> Internet. UDP provides compatibility with currently deployed middleboxes >> as >> well as ubiquitous support in endpoints, and supports userspace >> implementation >> of new transport protocols. The working group will not specify any new >> transport protocols. >> >> The current Internet protocol stack does not provide explicit, in-band, >> transport-independent signaling to on-path network devices. This has led >> to >> the deployment of devices which perform implicit discovery of transport >> semantics and traffic characteristics via inspection of protocol headers >> and >> payload, a practice made possible when these are sent in the clear. >> >> In order to support more ubiquitous deployment of encryption, and the >> encryption of transport headers to allow deployment of new transport >> protocols, explicit in-band signaling must be added to the stack. This >> signaling must be transport protocol independent, and the types of >> information >> signaled must be based on characteristics that can be independently >> verified >> by devices on path, or that can be usefully applied without requiring a >> trust >> relationship between endpoints and the path. Further, a feedback channel >> that >> provides information from on-path devices back to endpoints and >> applications, >> e.g. for error handling, is essential for the deployment and success of = an >> explicit cooperation approach. >> >> While IP would seem to be the natural home for this facility, both IPv4 >> and >> IPv6 options and extensions have deployment problems on their own, which >> makes >> it hard to include any additional information in these protocols. >> >> The PLUS working group will specify a new protocol as a Path Layer >> UDP Substrate (PLUS), to support experimental deployment of >> explicit cooperation between endpoints and devices on path, with the >> following goals: >> >> - enable ubiquitous deployment of encrypted higher layer protocols >> by providing exposure of basic TCP-like semantics (e.g. SYN, FIN, >> RST flags) to devices on path (e.g. NATs and firewalls). >> >> - allow applications and transport protocols to explicitly provide >> limited information with integrity protection to devices on path >> >> - allow devices on path to provide unencrypted feedback and information >> about the path directly to sending endpoints, under sending endpoint >> control >> >> - allow devices on path to provide unencrypted information about the >> path to receiving endpoints, with encrypted feedback to the >> sending endpoint, under sending endpoint control >> >> This approach explicitly gives the control of information exposure back >> the >> application and/or transport layer protocol on the end host. It is the >> goal of >> PLUS to minimize the information exposed, to make information exposure >> transparent, and to limit the level of detail to that useful for network >> treatment, while encrypting everything else. Endpoint verification of >> signaling integrity, careful design of minimal data structures, and >> restrictive policies for registration of signals can help to meet this >> goal. >> This is important to avoid future implicit treatment and resulting >> ossification, as well as to minimize the privacy risks presented by >> explicit >> cooperation. >> >> Given that the primary goal of PLUS is to enable the deployment of >> transport >> protocols with encrypted headers, we assume that the higher-layer protoc= ol >> can >> provide an encryption context that can be used by PLUS to provide >> authentication, integrity, and encryption where needed. The primary thre= at >> model to defend against will be modification or deletion of exposed >> information by middleboxes and other devices on path, by allowing a remo= te >> endpoint to detect modifications. >> >> The working group will start with an initial set of use cases (see draft= - >> kuehlewind-spud-use-cases) and requirements (see draft-trammell-spud-req= ), >> taken from experience with the Substrate Protocol for User Datagrams >> (SPUD) >> prototype. The working group's main output will be an experimental >> protocol >> specification, together with an initial registry of types of information >> that >> can be exposed using PLUS, clearly aligned to the use cases determined b= y >> the >> working group. The working group will close if it is not able to come to >> consensus on a protocol design to meet these requirements. >> >> The working group will additionally aim to identify and work with other >> working groups that could address parts of these requirements within >> existing >> protocols, e.g. by specifying new protocol extensions, or as input for o= n- >> going standardization work. It will aim to work with working groups >> defining >> encryption protocols (e.g. DTLS) which could be used for encryption of >> transport protocols running over PLUS. >> >> _______________________________________________ >> 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 Tue Jun 7 13:41: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 A77B312D7CE for ; Tue, 7 Jun 2016 13:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 v5i9CsdA4q3O for ; Tue, 7 Jun 2016 13:41:24 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 0CC2412D17A for ; Tue, 7 Jun 2016 13:41:24 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 37so20002397qtc.3 for ; Tue, 07 Jun 2016 13:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=78zsrsYBjKYOFncUiL/amNro/vP/OoVN5hbJY5Pb+z4=; b=Z37R9dlLC+scSfWkTTK8z7T3o7T9jaSb6nSbsbxoR6947jJ4aYTLdY9QDqy3Bxf9bj Gg8H7nXrgKQfdF7rNfQWeSEdO5MI8m+OgBRYHTI+xoE/yQ6b/GrfwFXVWxoLnqwqgvNe 4gGVWD4FpJZGKmNYNYFVAq3vafBUOLSVONXjEspyBQrna9TKKJyhoSYuzvQtnJRIDgoN hJtAuHgqIGDX/WIZgdDWQyzB0cevtg+aB/5CR0AazLSpBak4+G7UhPoU802086aZrrnv Rh9/uacL9jzvpumWI2n4Lw7ShlASVsk18emM2/KtcQkvNuQBBAYZ/sNMSd/1uKKU9Vb/ Qwrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=78zsrsYBjKYOFncUiL/amNro/vP/OoVN5hbJY5Pb+z4=; b=eBAwkYjDhaVkkTe4LDKaLyEDL2Cfwo4lOMAtCwap/Ai0KWIt6GGTguDk47QJZ4HqCg KPZq+GKCHpr5lQmnK7K3w35ySAh/kEcyOkVJHSFBU6QdJBsEmgeKuKoZ4lZ8vQCGny8I 7ydG/oyn+51HOLufzjRoWuPXXP4Oyui71sjoR9GxRNDryZci06zxzwQUj6ABA2xWD4Lz xwBtIn1IPw9gleefQK5vORRkV18crzBP/XbBXG2P6eYBM//haevMvCd4vzzLD1fhSaow Nz20BgDdjpWZdUbhPh/CEbrycS5sYeDiKTPeTl7seLVpAkgfdZXidCAL9yLfQmUjxOeI xHXw== X-Gm-Message-State: ALyK8tIzzG3XEgbm3IihDT6Y2uTF4tD8COdZAMKyO2o5L2vYfwTgg93zHr42w8DJtPw0YA== X-Received: by 10.237.33.35 with SMTP id 32mr1587830qtc.8.1465332083135; Tue, 07 Jun 2016 13:41:23 -0700 (PDT) Received: from bos-mppgj.kendall.corp.akamai.com (a23-79-238-10.deploy.static.akamaitechnologies.com. [23.79.238.10]) by smtp.gmail.com with ESMTPSA id 81sm7506173qht.38.2016.06.07.13.41.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Jun 2016 13:41:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F9C918DF-CD9E-4BD4-B2A7-B08B1FEEFDDA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Aaron Falk In-Reply-To: Date: Tue, 7 Jun 2016 16:41:21 -0400 Message-Id: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:41:26 -0000 --Apple-Mail=_F9C918DF-CD9E-4BD4-B2A7-B08B1FEEFDDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 7, 2016, at 4:37 PM, Tom Herbert wrote: >=20 >> 1st para of the charter says =E2=80=9CThe working group will not = specify any new >> transport protocols.=E2=80=9D and the 5th para says =E2=80=9CThe PLUS = working group will >> specify a new protocol=E2=80=9D. I think the latter statement is = correct. >> I=E2=80=99d like to see a comment on PLUS re-enabling ICMP = functionality >=20 > What does "re-enabling ICMP functionality" mean? The usefulness of many of the the ICMP signals has been reduced since = you have no indication of who is sending them. With PLUS you can at = least have some confidence the sender is on the path. =E2=80=94aaron= --Apple-Mail=_F9C918DF-CD9E-4BD4-B2A7-B08B1FEEFDDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 7, 2016, at 4:37 PM, Tom Herbert <tom@herbertland.com>= wrote:

1st para of the charter says =E2=80=9CThe working group will = not specify any new
transport protocols.=E2=80=9D and the = 5th para says =E2=80=9CThe PLUS working group will
specify = a new protocol=E2=80=9D.  I think the latter statement is = correct.
I=E2=80=99d like to see a comment on PLUS = re-enabling ICMP functionality

What does = "re-enabling ICMP functionality" = mean?

The usefulness of many of the the ICMP signals has been = reduced since you have no indication of who is sending them.  With = PLUS you can at least have some confidence the sender is on the = path.

=E2=80=94aaron
= --Apple-Mail=_F9C918DF-CD9E-4BD4-B2A7-B08B1FEEFDDA-- From nobody Tue Jun 7 13:47: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 CE95112D0BF for ; Tue, 7 Jun 2016 13:47:30 -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 4J2aM-Prfsar for ; Tue, 7 Jun 2016 13:47:29 -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 8206712D0FE for ; Tue, 7 Jun 2016 13:47:29 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id z123so107886974itg.0 for ; Tue, 07 Jun 2016 13:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=T/XohFGivo7Dvrq/EJSpZJV1UcUuvBRE8CwMNeoWug8=; b=pMBtVzAimR2Ia68jXiM5oIrLmq+Ln1Iyz3rpI+GJBMn6g0Hijl0iX66cUatoyYukEb cg9rtYQU4HlfRiZ7iM7Fc96RtNt+Dll7hNlN96vkt73TXhGbC0gci/nztx9c7E1sA1i9 gT+q0OLSACZJm/DEtFwEPfqvRvhI3dsY1yAl4Z4o6fUgOmSwF927SIF/+/c5uDgB+RoZ +7IEUz++zeMHBaUd9ku3pH1fFs5uFSGlkZaIlFkVgh0YEF0KFB63wYKP92LEikN/UMi4 hqd4Ev1ITCXT36Hm8enCX1QEpqRFAyQaY4kwIvCL9g18ZzOVHwsRGl8ZyWsxQZbrppPE q47A== 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=T/XohFGivo7Dvrq/EJSpZJV1UcUuvBRE8CwMNeoWug8=; b=GUtBqjwvAaYx3OOWwjIskokkQWHFTpQzOoDgP3jZ871b0QEX/2SM5lMT23NCuynUzb Op2ufmIu5RB0UIvhvLVuizsd5oFSLl4fDe+M6Lq5Suv59HpDsh7XBX93Tp840RUdOEpt 0auWWAuyOK31QQE/HFoIS5Aej6RM5mQI2mSLEKgGNl8aDvaqwDJR2YkHlCrGllOv/bkL uN+eDrq9Q2KK12quHq4Id8g6BvlVnMIGjGb0U4zoZG2IrhK+z2XNi5KUsofqLq6MCMNi OVDpOHl1/7Q7VO3XrnUQsOpF5AaqSTjMJzWtWPmvNvPyBhPzSYO4esHEJjC7AQD9RFAo zNTA== X-Gm-Message-State: ALyK8tKQxPDZW9fGEfqNQdC8KeYbWQTlW1vFo9lt1QTrdODdJCED5DAyHN3yQ5i8AWlDH/FS+Eue/4gZSQYorw== MIME-Version: 1.0 X-Received: by 10.107.162.131 with SMTP id l125mr2807756ioe.84.1465332448850; Tue, 07 Jun 2016 13:47:28 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Tue, 7 Jun 2016 13:47:28 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> Date: Tue, 7 Jun 2016 13:47:28 -0700 Message-ID: From: Tom Herbert To: Aaron Falk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Trammell , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:47:31 -0000 On Tue, Jun 7, 2016 at 1:41 PM, Aaron Falk wrote: > > On Jun 7, 2016, at 4:37 PM, Tom Herbert wrote: > > 1st para of the charter says =E2=80=9CThe working group will not specify = any new > transport protocols.=E2=80=9D and the 5th para says =E2=80=9CThe PLUS wor= king group will > specify a new protocol=E2=80=9D. I think the latter statement is correct= . > I=E2=80=99d like to see a comment on PLUS re-enabling ICMP functionality > > > What does "re-enabling ICMP functionality" mean? > > > The usefulness of many of the the ICMP signals has been reduced since you > have no indication of who is sending them. With PLUS you can at least ha= ve > some confidence the sender is on the path. > I'm still missing it. ICMP packets have a source address which of the router or host that is sending the packet. Tom > =E2=80=94aaron From nobody Tue Jun 7 13:57: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 796D512D14D for ; Tue, 7 Jun 2016 13:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYCnit39zIad for ; Tue, 7 Jun 2016 13:57:50 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 A9E0E12B026 for ; Tue, 7 Jun 2016 13:57:50 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id p34so64999173qgp.1 for ; Tue, 07 Jun 2016 13:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=I2SLlIXaWAJTwrAoKukjeFqQsmCaGxGDMn9oY+g0q0w=; b=i+F7dQFAj03FqZtXBTF2CSZIkaOycaBUmPe5xL5f/2+KDAbn26wQ7Q71YR+ntTCYZZ oh6fO9Tb4ha6YLmfsgU8L9JO9dauXXOqh+uJQb89w2xaAh1AOT9CSmbOXQbd6j76/kLG 0KEKoA6BdUhXXPJpvB6G3whMBECYUndWD/dDYI3JCcPj9OMvyM+eRtNXL66twvNQrkSh heLHg9Ewx4h5C4n5EBEaKMandCEUQCugfLs9Kv1adFBfjl1tEP7ajqWS+Yw38jkYgyiz GkYgc59vDyCRw5sWaT2wKyfA4Fhik4oP6cqZUVi8DVX4EQSmYCKS/1c4dIRDWp6Xyis4 tiSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=I2SLlIXaWAJTwrAoKukjeFqQsmCaGxGDMn9oY+g0q0w=; b=b+ZP7wziHlnsLaYoQe4Bk2kuipuVzJSnrWsoh3gzVCaogrqf1iOMoh9EMsn4DsxT3Y Ozo1VxYciUKFZfPZaOtcqNkJxcoqRsJRdyB5wH1d0gZ4vXQSyr4FUTH0NmxBjpFmqH/N 9RV///imYLvYAPDcIbnIaNTaKOF59siYyUvdce+jSbv2DOQbZgP/JpZHljGKzK3NCReu 4XdbuS02SymhQl/VX5+ftr8UpivK7dfqtHdy32BPdKIMqIpsuVleWR0csGEHg5exr0Lt BjKFnCC1QTlwuuQPuduo7cSxhohhTMcYibfbd8kdcx7/mmzOQfx8mqRyBy5nCtU0qR4P QMUg== X-Gm-Message-State: ALyK8tKcL2LH3cOgB4fm3siwQPjOw4HeOCk3rL/QXRYot7FuA2x6Df1KVEPvCw1dnr56Bw== X-Received: by 10.140.132.147 with SMTP id 141mr1549410qhe.17.1465333069757; Tue, 07 Jun 2016 13:57:49 -0700 (PDT) Received: from bos-mppgj.kendall.corp.akamai.com (a23-79-238-10.deploy.static.akamaitechnologies.com. [23.79.238.10]) by smtp.gmail.com with ESMTPSA id w22sm79189qta.15.2016.06.07.13.57.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Jun 2016 13:57:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_02E2391F-09FA-4841-B0FB-F362E1F424B3" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Aaron Falk In-Reply-To: Date: Tue, 7 Jun 2016 16:57:47 -0400 Message-Id: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:57:52 -0000 --Apple-Mail=_02E2391F-09FA-4841-B0FB-F362E1F424B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 7, 2016, at 4:47 PM, Tom Herbert wrote: >=20 > On Tue, Jun 7, 2016 at 1:41 PM, Aaron Falk > wrote: >>=20 >> On Jun 7, 2016, at 4:37 PM, Tom Herbert wrote: >>=20 >> 1st para of the charter says =E2=80=9CThe working group will not = specify any new >> transport protocols.=E2=80=9D and the 5th para says =E2=80=9CThe PLUS = working group will >> specify a new protocol=E2=80=9D. I think the latter statement is = correct. >> I=E2=80=99d like to see a comment on PLUS re-enabling ICMP = functionality >>=20 >>=20 >> What does "re-enabling ICMP functionality" mean? >>=20 >>=20 >> The usefulness of many of the the ICMP signals has been reduced since = you >> have no indication of who is sending them. With PLUS you can at = least have >> some confidence the sender is on the path. >>=20 > I'm still missing it. ICMP packets have a source address which of the > router or host that is sending the packet. >=20 You can build equivalent functionality with PLUS. Would be a different = protocol but more trustworthy. =E2=80=94aaron --Apple-Mail=_02E2391F-09FA-4841-B0FB-F362E1F424B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 7, 2016, at 4:47 PM, Tom Herbert <tom@herbertland.com>= wrote:

On Tue, Jun 7, 2016 at 1:41 PM, Aaron Falk = <aaron.falk@gmail.com> = wrote:

On Jun 7, 2016, at 4:37 PM, Tom Herbert <tom@herbertland.com>= wrote:

1st para of the charter says =E2=80=9C= The working group will not specify any new
transport = protocols.=E2=80=9D and the 5th para says =E2=80=9CThe PLUS working = group will
specify a new protocol=E2=80=9D.  I think = the latter statement is correct.
I=E2=80=99d like to see a = comment on PLUS re-enabling ICMP functionality


What does "re-enabling ICMP functionality" = mean?


The usefulness of many = of the the ICMP signals has been reduced since you
have no = indication of who is sending them.  With PLUS you can at least = have
some confidence the sender is on the path.

I'm still missing = it. ICMP packets have a source address which of the
router or host that = is sending the packet.


You can build = equivalent functionality with PLUS.  Would be a different protocol = but more trustworthy.

=E2=80=94aaron

= --Apple-Mail=_02E2391F-09FA-4841-B0FB-F362E1F424B3-- From nobody Tue Jun 7 14:17: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 3596012D6A6 for ; Tue, 7 Jun 2016 14:17:39 -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 MsvVCKy_z2oE for ; Tue, 7 Jun 2016 14:17:37 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B5C12D508 for ; Tue, 7 Jun 2016 14:17:37 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id k23so297827719oih.0 for ; Tue, 07 Jun 2016 14:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JlAR+Uo033QNPxKsOLxBC4PfFC+acb4jF+XghXqP01A=; b=cm6ys4a5EtzfUN6OyRs5rKqkiPVroRVUfnipgUZ+WXU7bD9xJsezmduSYHPvKgNMVH iWt1GRa0pWuNVu8v9RR+2eEgbto6W9FmKqI/f3oGV4RMe32vxjyEJ2TTKBpU15TqR9sP ZEjV+JesM4BHddaojouzQLVpp8i7DJzWM1SexzK4lLqMbeqVJCxWEwCIFADKB0ePsavL X8N3iy9Zrl0JH7bvrw++x7Ho9K7ZILBxHPsHXg+owfg/n5bH6vZ8xK2DoVPjK2QXOCW2 z+1MEH7F5Qymef4spJNb6j4oxqXH4YMIF0zsjuyqG56ChMZuBgm1QDIeZSwV3L9jCYYC zsGw== 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=JlAR+Uo033QNPxKsOLxBC4PfFC+acb4jF+XghXqP01A=; b=RuElQgA+HXj6v0njYw80LmLRVxVO6m7aNCx3kHiDiQxSo5oRV5J2sQsY+doP4fyEkc 5bgsl+4l1+sBgRRAeZgbptyNhqlmyIeF3dCXBBuJpB3yWMyBis64ec68ZnzDuq6ajuND vV/f0xnX7A0WsHhN+qplGgisx/BJ0OoliCB8w9ANrizYiPxFZ6B3IsX1go0asgE8A/oq MJLeB2b55QVLFFQ03JABXntK2zJpeWT6hku7So1gn228i1woot2PgHH+ew9cFr318WuW LxRg3wImt29EsGoe91s0x7a9YqN9/YAgMlN4Ft5Q2clkg4iQC+/STX64y6OfwDJt3Ow4 ICUw== X-Gm-Message-State: ALyK8tLib4nFbqwGeu6VM00gqrhqU7J1cSfLvw54kgRVpDFEGTKf1xobLVu/9ri12nRUnB5ycZRU+kahyOVAEA== X-Received: by 10.202.87.205 with SMTP id l196mr236064oib.53.1465334257168; Tue, 07 Jun 2016 14:17:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Tue, 7 Jun 2016 14:17:17 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> From: Ted Hardie Date: Tue, 7 Jun 2016 14:17:17 -0700 Message-ID: To: Tom Herbert Content-Type: multipart/alternative; boundary=001a113df23ee03a360534b6b7be Archived-At: Cc: Aaron Falk , Brian Trammell , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 21:17:40 -0000 --001a113df23ee03a360534b6b7be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 7, 2016 at 1:47 PM, Tom Herbert wrote: > On Tue, Jun 7, 2016 at 1:41 PM, Aaron Falk wrote: > > > > On Jun 7, 2016, at 4:37 PM, Tom Herbert wrote: > > > > 1st para of the charter says =E2=80=9CThe working group will not specif= y any new > > transport protocols.=E2=80=9D and the 5th para says =E2=80=9CThe PLUS w= orking group will > > specify a new protocol=E2=80=9D. I think the latter statement is corre= ct. > > I=E2=80=99d like to see a comment on PLUS re-enabling ICMP functionalit= y > > > > > > What does "re-enabling ICMP functionality" mean? > > > ICMP often isn't available to the application; by putting similar information in in-band signalling, it would reach the application. For the RTP application I noted above, for example, that might result in a codec shift or change in FEC tuning. regards, Ted --001a113df23ee03a360534b6b7be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 7, 2016 at 1:47 PM, Tom Herbert <tom@herber= tland.com> wrote:
On Tue, Jun 7= , 2016 at 1:41 PM, Aaron Falk <a= aron.falk@gmail.com> wrote:
>
> On Jun 7, 2016, at 4:37 PM, Tom Herbert <tom@herbertland.com> wrote:
>
> 1st para of the charter says =E2=80=9CThe working group will not speci= fy any new
> transport protocols.=E2=80=9D and the 5th para says =E2=80=9CThe PLUS = working group will
> specify a new protocol=E2=80=9D.=C2=A0 I think the latter statement is= correct.
> I=E2=80=99d like to see a comment on PLUS re-enabling ICMP functionali= ty
>
>
> What does "re-enabling ICMP functionality" mean?
>

ICMP often isn't available to t= he application; by putting similar information in in-band signalling, it wo= uld reach the application.=C2=A0 For the RTP application I noted above, for= example, that might result in a codec shift or change in FEC tuning.
regards,

Ted
--001a113df23ee03a360534b6b7be-- From nobody Tue Jun 7 14:25: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 1415F12D866 for ; Tue, 7 Jun 2016 14:25: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 yarR-ka-ir7c for ; Tue, 7 Jun 2016 14:25:28 -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 0D77712D52F for ; Tue, 7 Jun 2016 14:25:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 993A0D9303; Tue, 7 Jun 2016 23:25:26 +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 lU5CyZ5IJoiK; Tue, 7 Jun 2016 23:25:26 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2B24.dip0.t-ipconnect.de [93.236.43.36]) (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 26A45D9302; Tue, 7 Jun 2016 23:25:26 +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, 7 Jun 2016 23:25:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <15FD8521-8354-4A08-BBBA-F62ADF991052@tik.ee.ethz.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> To: Aaron Falk X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 21:25:30 -0000 Hi Aaron, on this point: > Am 07.06.2016 um 21:53 schrieb Aaron Falk : >=20 >>>=20 >>> =E2=80=A2 I=E2=80=99d like to see a comment on PLUS re-enabling = ICMP functionality >>=20 >> Yes, that=E2=80=99s a very good use case and clearly in scope. = However, there are other good use cases as well, see the use case draft, = and we decided to not explicitly outline one (of a subset of them) in = the charter. >=20 > Fair point but I think the charter would benefit from at least a brief = listing of the benefits that come from light weight, in-band signaling. = Besides their important role as scoping documents for working groups, = charters (IMO) should help someone figure out what problems you are = solving. This can of course be done at length in a use-case doc but I = believe providing a clue for the curious outsider as to whether the work = is relevant. YMMV. Actually it=E2=80=99s in the charter (hidden): "Further, a feedback channel that provides information from on-path = devices back to endpoints and applications, e.g. for error handling, is = essential for the deployment and success of an explicit cooperation = approach.=E2=80=9C Mirja From nobody Tue Jun 7 14:34: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 BF09712D86C for ; Tue, 7 Jun 2016 14:34:32 -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 apXA-xIPTu2K for ; Tue, 7 Jun 2016 14:34:32 -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 00F7212D86D for ; Tue, 7 Jun 2016 14:34:31 -0700 (PDT) Received: from [128.9.184.141] ([128.9.184.141]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u57LY9Lf000121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Jun 2016 14:34:10 -0700 (PDT) To: Ted Hardie , Aaron Falk References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> From: Joe Touch Message-ID: <57573DCF.1030402@isi.edu> Date: Tue, 7 Jun 2016 14:34:07 -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: u57LY9Lf000121 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 21:34:33 -0000 On 6/7/2016 1:05 PM, Ted Hardie wrote: > Imagine for a moment that we are talking about transporting RTP/UDP, > and we would like signalling from the path to give us icmp-like > information. We could do that by recreating RTP with a signalling > piece built in to a protocol replacing UDP; we could do that by > updating UDP itself; FWIW, this might be a very interesting use of draft-touch-tsvwg-udp-options (we are developing an implementation this summer after successful NAT-traversal and legacy endsystem tests last year) Joe From nobody Tue Jun 7 14:58: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 958C312D87A for ; Tue, 7 Jun 2016 14:58:11 -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 Nq3BnBSX4LRg for ; Tue, 7 Jun 2016 14:58:02 -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 44CED12D5FC for ; Tue, 7 Jun 2016 14:57:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1E9D2D9303; Tue, 7 Jun 2016 23:57: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 q4WiAbGe5qAN; Tue, 7 Jun 2016 23:57:55 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2B24.dip0.t-ipconnect.de [93.236.43.36]) (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 8FCACD9302; Tue, 7 Jun 2016 23:57: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: <57573DCF.1030402@isi.edu> Date: Tue, 7 Jun 2016 23:57:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Aaron Falk , Brian Trammell , Ted Hardie , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 21:58:11 -0000 Hi Joe, > Am 07.06.2016 um 23:34 schrieb Joe Touch : >=20 >=20 >=20 > On 6/7/2016 1:05 PM, Ted Hardie wrote: >> Imagine for a moment that we are talking about transporting RTP/UDP, >> and we would like signalling from the path to give us icmp-like >> information. We could do that by recreating RTP with a signalling >> piece built in to a protocol replacing UDP; we could do that by >> updating UDP itself; >=20 > FWIW, this might be a very interesting use of = draft-touch-tsvwg-udp-options Yes, I still have this in mind. However, in the mean time I=E2=80=99d = prefer a proper architectural solution (and not just a hack). :-) >=20 > (we are developing an implementation this summer after successful > NAT-traversal and legacy endsystem tests last year) Cool. Good to know! Mirja >=20 > Joe >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Tue Jun 7 15:05: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 5CF1412D5FC for ; Tue, 7 Jun 2016 15:05:37 -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 aqUrg83GDN3m for ; Tue, 7 Jun 2016 15:05:35 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80AA12B006 for ; Tue, 7 Jun 2016 15:05:35 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id h190so34576674ith.1 for ; Tue, 07 Jun 2016 15:05:35 -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=7KhvODk/9+Mnn9KJVLv/WsqYaHSZtCLZEiuwM5t0Gcw=; b=J+q2lBxK6CI/6wBGusiLXxlckjVsSYggUWBJ69Ww8GycvunL+nDBhwGriHWgXg6GCF pe56SyEGzxzvNiabw4gmsNBFzfLkNjDsCN/xf1dwstZq2aSEWe9G/miI8xiHwtNWoZ1h XE6HJNOUs6+tZZgO75eboMi73KfyCdKkHVrcBSS/i+FEk9vgCRFHNuNjtew43gq7o3tr e3cYZoGu3AHq3jIy/feMYNx6XIYGfiM1CIX1LjnYshmE+/BmtJbZFCphGGly0yzRHbps +wFVtNvD/hUMfqAkOoOJMXdpZ6GxM0Ah37x421210DwhZd8JE9NSA+igX6qw9f7QM4fU vZsg== 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=7KhvODk/9+Mnn9KJVLv/WsqYaHSZtCLZEiuwM5t0Gcw=; b=itN/SzXtRNz8CtAJnMTNGI72AJegB7ZBQZWtYO1meZBaXdFlTNngpUNqpYjtpHMma6 T1DKoodbSiUkkgptzftOCm+lhYtwWaGM3+PpOK9qrPJPWB/isRPA1t69UTFknAFNujqZ BsyoUgfpKywt8ASVw59YV1pRUKD6TRggGkEx6m2frLzkkGhUDWOrkt7QgPRRFD8jasc5 8fiDyxzEszVDe3+GiZXC/Mf1Vd3ICboGrqy99fj6oIpDcqcKlJVTm6GnMFC6n1AGdpup QD7rT9N1PFQppL8kH2aQpa6IVTpJIJr6W2er6kmM5YwXuHAHtHueJNzjC2t1MdLytCM/ bmVw== X-Gm-Message-State: ALyK8tIIGqE1RWcytXOv4AP3v/aBb6FeD9AFm6S97j6VUrJMhgbsflizsxkESLNUco3U6rg5lxPTAuPbv5/85g== MIME-Version: 1.0 X-Received: by 10.107.162.131 with SMTP id l125mr3256680ioe.84.1465337135008; Tue, 07 Jun 2016 15:05:35 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Tue, 7 Jun 2016 15:05:34 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> Date: Tue, 7 Jun 2016 15:05:34 -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: Aaron Falk , Brian Trammell , Ted Hardie , spud , Joe Touch Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:05:37 -0000 On Tue, Jun 7, 2016 at 2:57 PM, Mirja K=C3=BChlewind wrote: > Hi Joe, > > >> Am 07.06.2016 um 23:34 schrieb Joe Touch : >> >> >> >> On 6/7/2016 1:05 PM, Ted Hardie wrote: >>> Imagine for a moment that we are talking about transporting RTP/UDP, >>> and we would like signalling from the path to give us icmp-like >>> information. We could do that by recreating RTP with a signalling >>> piece built in to a protocol replacing UDP; we could do that by >>> updating UDP itself; >> >> FWIW, this might be a very interesting use of draft-touch-tsvwg-udp-opti= ons > > Yes, I still have this in mind. However, in the mean time I=E2=80=99d pre= fer a proper architectural solution (and not just a hack). :-) > The proper architectural solution is to place network layer information like what is being proposed in the network layer :-) Trying to make a network layer out of UDP fails on several accounts (fragments don't contain UDP headers, ports do not have global meaning, etc.). IPv6 extension headers are designed for carrying information like this, I really hope there is more investigation as to whether they are workable for signaling. Tom >> >> (we are developing an implementation this summer after successful >> NAT-traversal and legacy endsystem tests last year) > > Cool. Good to know! > > Mirja > > >> >> Joe >> >> _______________________________________________ >> 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 Tue Jun 7 15:08: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 A03E412D89D for ; Tue, 7 Jun 2016 15:08:41 -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 pEX3_yWVZgSk for ; Tue, 7 Jun 2016 15:08:38 -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 D8DB312D89A for ; Tue, 7 Jun 2016 15:08:38 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u57M7usg006962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Jun 2016 15:07:56 -0700 (PDT) To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> From: Joe Touch Message-ID: Date: Tue, 7 Jun 2016 15:07:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailScanner-ID: u57M7usg006962 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , Brian Trammell , Ted Hardie , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:08:41 -0000 On 6/7/2016 2:57 PM, Mirja Kühlewind wrote: > Hi Joe, > > >> Am 07.06.2016 um 23:34 schrieb Joe Touch : >> >> >> >> On 6/7/2016 1:05 PM, Ted Hardie wrote: >>> Imagine for a moment that we are talking about transporting RTP/UDP, >>> and we would like signalling from the path to give us icmp-like >>> information. We could do that by recreating RTP with a signalling >>> piece built in to a protocol replacing UDP; we could do that by >>> updating UDP itself; >> FWIW, this might be a very interesting use of draft-touch-tsvwg-udp-options > Yes, I still have this in mind. However, in the mean time I’d prefer a proper architectural solution (and not just a hack). :-) The UDP option field is a vehicle in which an architecture could send info back in-band without affecting the UDP stream. It's not the only solution and won't work for other transports, but if you want ICMP-like feedback in-band for UDP, it will work and is as architecturally clean as any other new/shim layer would be. Joe From nobody Tue Jun 7 15:10: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 D1CF812D89B for ; Tue, 7 Jun 2016 15:10:07 -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 YgWhdooDa21B for ; Tue, 7 Jun 2016 15:10:06 -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 CA69912D5FC for ; Tue, 7 Jun 2016 15:10:06 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u57M9mnk007446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Jun 2016 15:09:48 -0700 (PDT) To: Tom Herbert , =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> From: Joe Touch Message-ID: <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> Date: Tue, 7 Jun 2016 15:09:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u57M9mnk007446 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , Brian Trammell , Ted Hardie , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:10:08 -0000 On 6/7/2016 3:05 PM, Tom Herbert wrote: > The proper architectural solution is to place network layer > information like what is being proposed in the network layer :-) > Trying to make a network layer out of UDP fails on several accounts > (fragments don't contain UDP headers, ports do not have global > meaning, etc.). IPv6 extension headers are designed for carrying > information like this, I really hope there is more investigation as to > whether they are workable for signaling. It depends on what layer is actually doing the signaling. If it's on-path, I agree - that's network layer and should be somewhere besides the transport header. If'it's on-path but not from the endpoint it also begs the question of whether IP packet headers should be extended in-transit (I made the case long ago that this was valid for IPv6 but I think someone is working to close that loophole or already has). Joe From nobody Tue Jun 7 15:19:07 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE4A12D8A6 for ; Tue, 7 Jun 2016 15:19:05 -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 AT17HcZq1fBz for ; Tue, 7 Jun 2016 15:19:03 -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 935B212D89C for ; Tue, 7 Jun 2016 15:19:03 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id k23so300005766oih.0 for ; Tue, 07 Jun 2016 15:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F6DPWXZZwxayrGm7kATM5VNDeyXmWK2BFlFkr9zRkUI=; b=wXdaTJ7hCnIyAkGAkbRJnCJGvBe0e8+46BG1XBGJXhnB1UpyXbXj7Ll5E/H6sQ9QUx iiLk4Dd6FeZAcRo3Q3KbiZ6fka+Fpj7zOES1FrKGJgOjgCcAOYm7JcGt15X74isXKngD nfpuo3Uv2BpKojGOsO62OsrX5m8dzbZpHUsnY9KZ2wvcrExBpMfcjSwktHwTw1BSd7dD 6lLZjErTM63BRaWJPzxIco507vzpB6RW1p57aY0l63dphN81nikF0jTBEk1ebe34JAUH kL3ngWHYCDvy9TUTFOl1g/BZF23BSaLdoYBjj0IKNzrf9KJV1CIgLfMuCIj1vLp2NVyx g/jg== 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=F6DPWXZZwxayrGm7kATM5VNDeyXmWK2BFlFkr9zRkUI=; b=l8VsVaPVEmVZ2A+pdRtW01DQj/16P4IaeI7RwHNUR3x+Ibgf+51Soi5mxYEngAiIlN sHbwC9FxaUOPWxmlDLz8+9AIcP1ggn8iQOp8YptoXNEaQj69sdf4uiYP/eqQFzxs63Hg h2UPCk/Vvxa/m1Bge6/TO0CxMKbaqfRUgLcifxPX5BnTJOQMSaB9lKGLavtUXt5OVdqV dHHBVeIbvhYEEY85WWZ6r3umtdQHq25ZmT+V+HdOJ5scbBUw9hio8RSdYYu0iNX4wx13 LEoMYBcunnyFbneVhG3g6EQdudVdBacaBaVWX6CKSbH9/yRLL+tLimO6djFo0s2MCWcA RHKQ== X-Gm-Message-State: ALyK8tKRsuLDakMZmylNtMTMt8ESXnDhBAnNBVDuexI2uAYEV5SoAAnZC92Wj+UALdSiwiSnon99nUx7QyDyGg== X-Received: by 10.202.171.143 with SMTP id u137mr970636oie.71.1465337942874; Tue, 07 Jun 2016 15:19:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Tue, 7 Jun 2016 15:18:43 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> From: Ted Hardie Date: Tue, 7 Jun 2016 15:18:43 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a113c2efe8fa18a0534b793ad Archived-At: Cc: Aaron Falk , Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:19:05 -0000 --001a113c2efe8fa18a0534b793ad Content-Type: text/plain; charset=UTF-8 On Tue, Jun 7, 2016 at 3:07 PM, Joe Touch wrote: > The UDP option field is a vehicle in which an architecture could send > info back in-band without affecting the UDP stream. > > It's not the only solution and won't work for other transports, but if > you want ICMP-like feedback in-band for UDP, it will work and is as > architecturally clean as any other new/shim layer would be. > > So the problem with talking about any single requirement is that it looks a good bit easier to match the capabilities required than it turns out to be. If you go back to Section 5 of draft-trammell-spud-req-04, you'll see why the tube-id is useful (and necessary to avoid packet injection attacks). Unfortunately, the space available in this option field isn't really sufficient for a reasonable tube-id plus the ICMP (or other signalling) desired. Just my view of the requirements, of course; I certainly see that folks have different views of this. regards, Ted Joe > > --001a113c2efe8fa18a0534b793ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 7, 2016 at 3:07 PM, Joe Touch <touch@isi.edu&= gt; wrote:
=
=C2=A0
The UDP option field is a vehicle in which an architecture could sen= d
info back in-band without affecting the UDP stream.

It's not the only solution and won't work for other transports, but= if
you want ICMP-like feedback in-band for UDP, it will work and is as
architecturally clean as any other new/shim layer would be.


So the problem with talking about any single requirement i= s that it looks a good bit easier to match the capabilities required=C2=A0 = than it turns out to be.=C2=A0 If you go back to Section 5 of=C2=A0 draft-t= rammell-spud-req-04, you'll see why the tube-id is useful (and necessar= y to avoid packet injection attacks).=C2=A0 Unfortunately, the space availa= ble in this option field isn't really sufficient for a reasonable tube-= id plus the ICMP (or other signalling) desired.
=C2=A0
Just my view of the requirements, of course; I certainly see that f= olks have different views of this.

regards,

=
Ted

Joe


--001a113c2efe8fa18a0534b793ad-- From nobody Tue Jun 7 15:19: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 BBB5312D89C for ; Tue, 7 Jun 2016 15:19:17 -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 BT61RJ7Nemdu for ; Tue, 7 Jun 2016 15:19:16 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 4356A12D8AA for ; Tue, 7 Jun 2016 15:19:16 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id h62so49292680itb.1 for ; Tue, 07 Jun 2016 15:19:16 -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=EPj2n0LcKRFTuA1JFebEyDx0i9kt8s41TiP2y1qZc/8=; b=yBFhEG9phc5RhLDD1cRartaV6mkxBwfNjvs7by1fyro20QsQv9KNVX0tzt+ujjIVhf g/ze+vwEKyEesONo/BGPusU5dR+mo33uKzeKMSmBX2yrW52jnmYveKys2lS16wqpumd/ c3il/I6tyrN2I43JnrwIVFKAFu7HJ0XP+wf/mafX+wtLXjL0/c2bgzyUHJsyhZozZPH7 9KCgdhQfIlnFA7nfNoMN6q7XZTlzR2/oe6NXnI/kFUrC1HDyvLEfCgqEKoPUZZPZ0VPD slV+1aGo03ZHjp+pU/TGBQv/IDortUtWftN39nEzXXfxQd9LqPDq2pdDGd+AXrd7zWdQ rfMw== 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=EPj2n0LcKRFTuA1JFebEyDx0i9kt8s41TiP2y1qZc/8=; b=d4w01t0WqRy1+5fjPB8lOfve8JWIJj4KDiaQ0pEN9SGre0nDO+40kCib775WZGeJf2 +l+wcqT1nWsrtYMizoqZ+YMAZ017JMdNrzV4MKXbX4sXAClzhUyFGBhqS8ZcdhaMNRkY 49573DbUDts/ydO5o74JPYx3kSmAtRaxQUhoTeaA+7EsG/2rVJSjoEfMrdTzB4jAOZoU dRyIwckDsWSmSXjAkg8z69syruLc3yLBKmsDksprUBsBbT6JUNMP0ImLHxu60NkfFaxK Vd+5bumLnXfAmjwzBZgk7zIjVsg+kq4TCkuqKDwuJQalXu56xrzctdUh2am3LC32DxPl 09Ig== X-Gm-Message-State: ALyK8tL/tfC+XvFsvoHsDRYxnUuI3H7UL9M9IWchj0GWaReIChpKuAaK79xuyzBMDLJ+r3I6pfL4xrucm2E9rw== MIME-Version: 1.0 X-Received: by 10.107.11.20 with SMTP id v20mr3517397ioi.107.1465337955628; Tue, 07 Jun 2016 15:19:15 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Tue, 7 Jun 2016 15:19:15 -0700 (PDT) In-Reply-To: <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> Date: Tue, 7 Jun 2016 15:19:15 -0700 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Aaron Falk , Brian Trammell , Ted Hardie , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:19:18 -0000 On Tue, Jun 7, 2016 at 3:09 PM, Joe Touch wrote: > > > On 6/7/2016 3:05 PM, Tom Herbert wrote: >> The proper architectural solution is to place network layer >> information like what is being proposed in the network layer :-) >> Trying to make a network layer out of UDP fails on several accounts >> (fragments don't contain UDP headers, ports do not have global >> meaning, etc.). IPv6 extension headers are designed for carrying >> information like this, I really hope there is more investigation as to >> whether they are workable for signaling. > > It depends on what layer is actually doing the signaling. If it's > on-path, I agree - that's network layer and should be somewhere besides > the transport header. If'it's on-path but not from the endpoint it also > begs the question of whether IP packet headers should be extended > in-transit (I made the case long ago that this was valid for IPv6 but I > think someone is working to close that loophole or already has). > There has been a long discussion in 6man for 2460bis as to whether IPv6 extension headers can be added by middelboxes. The consensus seems to be that is it not allowed primarily because such actions change the size of the packet and hence mess up PMTU discovery. I would think this rationale must apply if devices are allowed to change UDP payload in flight. Devices should never increase the size of a packet, if they wish to add information to a packet for transit across one network then encapsulation is a good alternative. Tom > Joe > From nobody Tue Jun 7 15:36: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 DCA1D12D8AD for ; Tue, 7 Jun 2016 15:36:04 -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 4JazwByCgM1t for ; Tue, 7 Jun 2016 15:36:03 -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 D1B8D12D8AC for ; Tue, 7 Jun 2016 15:36:03 -0700 (PDT) Received: from [128.9.184.141] ([128.9.184.141]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u57MZdGu012237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Jun 2016 15:35:39 -0700 (PDT) To: Tom Herbert References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> From: Joe Touch Message-ID: <57574C38.6070402@isi.edu> Date: Tue, 7 Jun 2016 15:35:36 -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: u57MZdGu012237 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , Brian Trammell , Ted Hardie , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:36:05 -0000 On 6/7/2016 3:19 PM, Tom Herbert wrote: > On Tue, Jun 7, 2016 at 3:09 PM, Joe Touch wrote: >> >> On 6/7/2016 3:05 PM, Tom Herbert wrote: >>> The proper architectural solution is to place network layer >>> information like what is being proposed in the network layer :-) >>> Trying to make a network layer out of UDP fails on several accounts >>> (fragments don't contain UDP headers, ports do not have global >>> meaning, etc.). IPv6 extension headers are designed for carrying >>> information like this, I really hope there is more investigation as to >>> whether they are workable for signaling. >> It depends on what layer is actually doing the signaling. If it's >> on-path, I agree - that's network layer and should be somewhere besides >> the transport header. If'it's on-path but not from the endpoint it also >> begs the question of whether IP packet headers should be extended >> in-transit (I made the case long ago that this was valid for IPv6 but I >> think someone is working to close that loophole or already has). >> > There has been a long discussion in 6man for 2460bis as to whether > IPv6 extension headers can be added by middelboxes. The consensus > seems to be that is it not allowed primarily because such actions > change the size of the packet and hence mess up PMTU discovery. I > would think this rationale must apply if devices are allowed to change > UDP payload in flight. Devices should never increase the size of a > packet, if they wish to add information to a packet for transit across > one network then encapsulation is a good alternative. Encapsulation doesn't magically solve the PTMU problem. The only solution is to reserve space - e.g., for the IPv6 header to have included "NOP" or other variants of reserved space that can be overwritten. UDP payloads should NEVER be modified in flight. Only the end system or its designee should ever do so. I sincerely hope we end up assuming DTLS or some such to ensure that this is the case. Joe From nobody Tue Jun 7 21:27: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 D4BA812D0EE for ; Tue, 7 Jun 2016 21:27: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 2jHfDkPj4C4D for ; Tue, 7 Jun 2016 21:27:50 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4569112B025 for ; Tue, 7 Jun 2016 21:27:49 -0700 (PDT) Received: from [10.0.12.118] (unknown [94.107.234.194]) by trammell.ch (Postfix) with ESMTPSA id C6DB01A03C4; Wed, 8 Jun 2016 06:27:16 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Brian Trammell X-Mailer: iPhone Mail (13F69) In-Reply-To: <57574C38.6070402@isi.edu> Date: Wed, 8 Jun 2016 06:27:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> To: Joe Touch Archived-At: Cc: Aaron Falk , Tom Herbert , Ted Hardie , =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 04:27:52 -0000 Hi Joe, all, Inline... > On 08 Jun 2016, at 00:35, Joe Touch wrote: >=20 >> On 6/7/2016 3:19 PM, Tom Herbert wrote: >>> On Tue, Jun 7, 2016 at 3:09 PM, Joe Touch wrote: >>>=20 >>>> On 6/7/2016 3:05 PM, Tom Herbert wrote: >>>> The proper architectural solution is to place network layer >>>> information like what is being proposed in the network layer :-) >>>> Trying to make a network layer out of UDP fails on several accounts >>>> (fragments don't contain UDP headers, ports do not have global >>>> meaning, etc.). IPv6 extension headers are designed for carrying >>>> information like this, I really hope there is more investigation as to >>>> whether they are workable for signaling. I know that Jen Linkova has done some measurement work on this with respect t= o on-path treatment; I forget the conclusions. Of course that leaves the que= stion of userspace implementation open. >>> It depends on what layer is actually doing the signaling. If it's >>> on-path, I agree - that's network layer and should be somewhere besides >>> the transport header. If'it's on-path but not from the endpoint it also >>> begs the question of whether IP packet headers should be extended >>> in-transit (I made the case long ago that this was valid for IPv6 but I >>> think someone is working to close that loophole or already has). >> There has been a long discussion in 6man for 2460bis as to whether >> IPv6 extension headers can be added by middelboxes. The consensus >> seems to be that is it not allowed primarily because such actions >> change the size of the packet and hence mess up PMTU discovery. I >> would think this rationale must apply if devices are allowed to change >> UDP payload in flight. Devices should never increase the size of a >> packet, if they wish to add information to a packet for transit across >> one network then encapsulation is a good alternative. >=20 > Encapsulation doesn't magically solve the PTMU problem. >=20 > The only solution is to reserve space - e.g., for the IPv6 header to > have included "NOP" or other variants of reserved space that can be > overwritten. In the earlier thread on how to enforce endpoint control over what middlebox= es can say and when, this is the solution we foresaw: reserved space in the P= LUS header whose type and length are MAC'd, but the content not (probably im= plemented as a MAC over a fixed-length array of zeroes), this treatment bein= g a property of the type. > UDP payloads should NEVER be modified in flight. Only the end system or > its designee should ever do so. In this pattern, the end system explicitly designates the set of PLUS-speaki= ng devices on path to modify that value, in accordance with the type's defin= ition. > I sincerely hope we end up assuming DTLS > or some such to ensure that this is the case. That's my assumption. I've been thinking of this in terms of a MAC using a key negotiated by the s= uperstrate's crypto layer, which I assume is DTLS. But if we limit superstra= tes to those over DTLS, we can just use DTLS directly for this. Cheers,=20 Brian= From nobody Tue Jun 7 22:59: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 B172F12D77F for ; Tue, 7 Jun 2016 22:59:22 -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=unavailable 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 3LrNV6XbfJuj for ; Tue, 7 Jun 2016 22:59:21 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 9DDA312D76E for ; Tue, 7 Jun 2016 22:59:20 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id h19so191108211ywc.0 for ; Tue, 07 Jun 2016 22:59:20 -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=q+NksMW/poUNneLg4oWmK7/CiygAlnN+R1bukcy5P0A=; b=LnkUkE0fTmbove/3t7Wmnb82wpkG4A2ZP/KI1OlR0JwMetjyv2qEIPi1i4xW7ZUhHi 0rEeLG19MLWsgCqVhRtIrOkW8meSeNofSoy5PK9QXvsD9omvh38Ha/aNd33ydts43bZi J+AOBcYzvtDsrF/tHMFeNJ9mhVtbjNp7OfJ6fiSt6gcj+9Hv93ZR8y75HZXQi6mFSPK1 fYrDqBW1P1/bsmg8diftP5FC/J9p82ZsFYFkHdR1tlyhuVG3YuTx+JgG4a702xIF2cnM EBhW7akPG99sWbzvXhJj+nKZwjRNx4De1Of5s4Bjat1tOG6iwVCNH2A093WnCeZAcY1E yZOA== 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=q+NksMW/poUNneLg4oWmK7/CiygAlnN+R1bukcy5P0A=; b=bLcEAQbgaG4f2m+D4DS1Np9P8jnpHZt53HSE9nAj/iQwdSx3cs5UhclLtu7NiFTWHA XLDdwY5e+fjfcNq55CXJs1lokDqP7LqOA08Mw1DMUFMKibqWs86ytDniRmR8mS+icLad fix46uDiPJnCW3Lt/yiov0sHWwNIG7tNd/yPYCA+gMWVeYmjBNsH/43Rd+SzjA0MQKqL TAb5feGQFGbEzLXVOH+hu2Oj0eBvsRub0dM2hcZ9+/a/EvGgXN2IV7er0zMh7PYvQSo2 TbsQovcOHU6+So2+NPp3D9m1ovFoYER+YZ0fIRyySTvaGyB9h0OXxT5jkTJJZXOx2Aez IY7g== X-Gm-Message-State: ALyK8tIhv/s1wbWdLZbwXt/KnApxgugW4E8xP4u9xCbmFdUj6Xg7/Lt3xdoRApf7WY9Jxwu/wTqNHsIfVx//3ebZ X-Received: by 10.37.34.84 with SMTP id i81mr1640990ybi.156.1465365559701; Tue, 07 Jun 2016 22:59:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.221.193 with HTTP; Tue, 7 Jun 2016 22:59:19 -0700 (PDT) In-Reply-To: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> From: Jana Iyengar Date: Tue, 7 Jun 2016 22:59:19 -0700 Message-ID: To: Tom Herbert Content-Type: multipart/alternative; boundary=001a11c113a0a771ee0534be01e4 Archived-At: Cc: tsvwg WG , draft-ietf-tsvwg-rfc5405bis@ietf.org, tsvwg-chairs@ietf.org, spud , Brian Trammell , quic@ietf.org, ietf@ietf.org Subject: Re: [Spud] Last Call: (UDP Usage Guidelines) to Best Current Practice 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, 08 Jun 2016 05:59:23 -0000 --001a11c113a0a771ee0534be01e4 Content-Type: text/plain; charset=UTF-8 Just adding my 2c if this still isn't too late: I agree with Brian that the wording in the draft seems limiting. His suggested wording does make things better, but there still is the contradiction that Tom pointed out: I would agree, this paragraph also seems a little self > contradictory.There is an acknowledgment that "middleboxes that only > support TCP and UDP are not rare", but then the next sentence > recommends the use of several other protocols besides UDP and TCP. If > I put these two together, the only congested controlled protocol that > is recommended and expected to work on the Internet is TCP. This caught my attention as well. As it stands, the recommendation in this paragraph is very unclear. What exactly is the goal here? If it is to ensure that the recommendations allow for deployable protocols, then UDP-based ones must be allowed. Otherwise, the recommendation seems to be to only use TCP. I don't think that was the intent... but then what is the intent in this paragraph? - jana --001a11c113a0a771ee0534be01e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just adding my 2c if this still isn't too late: I agre= e with Brian that the wording in the draft seems limiting. His suggested wo= rding does make things better, but there still is the contradiction that To= m pointed out:

I would agree, this paragraph also seems a= little self
contradictory.There is an acknowledgment that "middleboxes that only support TCP and UDP are not rare", but then the next sentence
recommends the use of several other protocols besides UDP and TCP. If
I put these two together, the only congested controlled protocol that
is recommended and expected to work on the Internet is TCP.

This caught my attention as well. As it stands, the recomm= endation in this paragraph is very unclear.=C2=A0

= What exactly is the goal here? If it is to ensure that the recommendations = allow for deployable protocols, then UDP-based ones must be allowed. Otherw= ise, the recommendation seems to be to only use TCP. I don't think that= was the intent... but then what is the intent in this paragraph?

- jana
--001a11c113a0a771ee0534be01e4-- From nobody Wed Jun 8 03:38: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 5DAB912D5D7 for ; Wed, 8 Jun 2016 03:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, 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 JD4TqEHKOMO2 for ; Wed, 8 Jun 2016 03:38:56 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id DFBBA12D5C8 for ; Wed, 8 Jun 2016 03:38:55 -0700 (PDT) Received: from [172.17.186.217] (unknown [147.67.241.226]) by trammell.ch (Postfix) with ESMTPSA id 8FBA31A130D for ; Wed, 8 Jun 2016 12:38:23 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_401C8C0A-C6C4-4485-806E-05FACD10E71B"; 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: Date: Wed, 8 Jun 2016 12:38:22 +0200 Message-Id: <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> To: spud X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 10:38:58 -0000 --Apple-Mail=_401C8C0A-C6C4-4485-806E-05FACD10E71B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 08 Jun 2016, at 06:27, Brian Trammell wrote: >=20 > Hi Joe, all, >=20 > Inline... >=20 >> On 08 Jun 2016, at 00:35, Joe Touch wrote: >>=20 >>> On 6/7/2016 3:19 PM, Tom Herbert wrote: >>>> On Tue, Jun 7, 2016 at 3:09 PM, Joe Touch wrote: >>>>=20 >>>>> On 6/7/2016 3:05 PM, Tom Herbert wrote: >>>>> The proper architectural solution is to place network layer >>>>> information like what is being proposed in the network layer :-) >>>>> Trying to make a network layer out of UDP fails on several = accounts >>>>> (fragments don't contain UDP headers, ports do not have global >>>>> meaning, etc.). IPv6 extension headers are designed for carrying >>>>> information like this, I really hope there is more investigation = as to >>>>> whether they are workable for signaling. >=20 > I know that Jen Linkova has done some measurement work on this with = respect to on-path treatment; I forget the conclusions. Of course that = leaves the question of userspace implementation open. On the question of path transparency to DO extension headers in V6, see = this talk from IEPG at IETF91: = http://iepg.org/2014-11-09-ietf91/iepg-ietf91-ipv6-ehs-in-the-real-world-v= 3.0.pdf (thanks Jen Linkova and Fernando Gont), the takeaway from which = is that the minimum observed drop rate of small (8-byte) DO EH on UDP = packets is about 6%. There was also Geoff Huston's IPv6 WG presentation at RIPE a couple of = weeks ago: = https://ripe72.ripe.net/presentations/67-2016-05-23-bigipv6.pdf: in = addition to a nice summary of why ICMP-as-is is broken, he found an = upper bound of 16% on in-network fragmentation EH drops. So the situation with IPv6 EH seems to be slightly worse than the = situation with UDP, probably harder to diagnose at runtime, and requires = kernel support. So while I agree this is architecturally cleaner, I'm = skeptical that it's as deployable as a UDP encapsulation-based approach. Cheers, Brian --Apple-Mail=_401C8C0A-C6C4-4485-806E-05FACD10E71B 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 iQIcBAEBCgAGBQJXV/WfAAoJEIoSt78L6kajqo0P/jx8Rd7BYpFTBkIxAONuyDqQ Hj/owX9TPnw/H9u8s6kDjlonFRJYUSG8bM9yEiJs+5tPjjK7UBLhF5FQivRjh+Oz VTDWKv1htFjdyBHdCaeJkulD/4ORliKh60G8ntb2ySuOuNQKV0QAMa8A/gHNjcGO ilr8yZl9HytRN1Lwmh3mAuVGxetCBNm2JNraqqrP2lPrTzatPJ2J2OOvOHA00658 ORLCGgQ1le4m2vGAgti4JPLv6zu7FdWfdJr0fq552x4grm6mX2YCpeAzmH/L2o0d fe6SIyyG52iDEUBWIzhrfftZoemQ+5vTMnHVA2HrjV1xIsQhp0p+QQC6I6MEacKL 8nXqHnh6BJsV6h+jk0/+6WhULvmk6g3dqPctUueHbZvHmKDx4LitxuT2NVpUVONW P5/xLCP6VguNtYSlyn5G8evabwlo9vDFZVzPIDQ7qhYvKwverIodYoWy6nUDLF33 MnPw+cFnDsXq0W+4laL07NqKr8vFose627mjNn5INlfRTXvzq8gspFZxONkpDqbI cZ2Rw4anxxCGFOgBQDP+g41NNXInWfnqTv9YvlzwQy/fQAaw7oN1HLbdN5FBD7Wn 7ZnMLuw4Aa5xg0Omduhe2OOZVXu3T6Iczsz5/q3JCMqzYGqtzg9lrzMOclKVaRCq Tivs19lDYR9m568Vcyg2 =6M2Q -----END PGP SIGNATURE----- --Apple-Mail=_401C8C0A-C6C4-4485-806E-05FACD10E71B-- From nobody Wed Jun 8 05:20:48 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D9F12D53D; Wed, 8 Jun 2016 05:20:44 -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 HnbyGG9bpAcW; Wed, 8 Jun 2016 05:20:40 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 4042512D1EA; Wed, 8 Jun 2016 05:20:40 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id n184so179016203wmn.1; Wed, 08 Jun 2016 05:20:40 -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=oGG8Vy1xecl2gchf3lAjRbHRbPZhJAaQ46e/iQXpI1U=; b=BAOXoR4C6tdHNAcYYVia75xsrQktD3J7v/zB6U9u07c8kTaF4zU65J7VSTGp6Baqrf Vqx3ipRU1LTE7PsZNCqWltx1lTjN6W91TVAxoWNduAVCuqMaTaYt5JwdC2zcjnHIxJjp /MrK31QYRsaByA2IjtqmqIBWsFA471lv3ORJqGl3Bjn4ikv/yAePMhfAnNmX3SLPYOcF OuOZt6OJGY+8qBT9Tomke0oYQOx5uNle10n6qUYuajgJQvzl76A6jPgYCZJaaMX+zhVB 4EnucmTtoA8W0BBW3EU1PFm7PSbME0sX8PgnbuuPnn0lW/i/5rvRuTVdpNMbPBfHmKjx zK5g== 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=oGG8Vy1xecl2gchf3lAjRbHRbPZhJAaQ46e/iQXpI1U=; b=C1zThgmRWvQlfVHetOxzqFe1nmMT8r2Tkmcpodz/w1Al1zpbJCcITvwqdp9hxcjN9a 4tfHVc6jzSrFQhM7lvbFWLrNnzpT4xfXTXICbfFHLnEtA2wJkQT6FdLjooVYA35kles0 wQH38Nmyp9vbBPdop71Cb1obSzmIHEioJbe0EhQMY6S6PkBj46TSOPILfKiUhMA3bJ4e YPuCw9+hJ193PDM1FQOBAmucfMFu3oDgtI2l5x+N9z+nKXVF1KA01DZZQzCZeYxbIpDv UXGN7RY7C4HE5SGEAZRAjwcp7bNv912xTRr6OKPEgpMt3S8yCuAWRPyCpLlHrrxMMaj0 GdOg== X-Gm-Message-State: ALyK8tIylU9gDeh0vL6IWHDTotNK8WbHnLnS3oLpCVJLeo6UDgQdNC+ZN2vj1a6tNJ+fyrLuraLL6xNQhjioNg== MIME-Version: 1.0 X-Received: by 10.28.211.142 with SMTP id k136mr7777814wmg.29.1465388438767; Wed, 08 Jun 2016 05:20:38 -0700 (PDT) Received: by 10.28.234.13 with HTTP; Wed, 8 Jun 2016 05:20:38 -0700 (PDT) In-Reply-To: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> Date: Wed, 8 Jun 2016 05:20:38 -0700 Message-ID: From: Ca By To: Jim Roskind Content-Type: multipart/alternative; boundary=001a1147136a59d17a0534c355b4 Archived-At: Cc: tsvwg WG , Tom Herbert , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , Brian Trammell , "quic@ietf.org" , "ietf@ietf.org" Subject: [Spud] [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice 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, 08 Jun 2016 12:20:44 -0000 --001a1147136a59d17a0534c355b4 Content-Type: text/plain; charset=UTF-8 On Sunday, June 5, 2016, Jim Roskind > wrote: > > > On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert wrote: > >> On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell wrote: >> > Greetings, all, >> > >> > Apologies for the late last call comment; I have only one, relatively >> minor. I hope it's still useful. >> > >> > I understand that Section 3 was written to encourage application >> developers not to roll their own transports ("trust us when we say this is >> hard, this document is a list of reasons why") but as written it would seem >> to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data >> channel, anything-over-PLUS), which I very much hope was not the intent. >> The problematic recommendation is in the second paragraph: >> > >> > These mechanisms are difficult to implement correctly. For most >> > applications, the use of one of the existing IETF transport protocols >> > is the simplest method of acquiring the required mechanisms. Doing >> > so also avoids issues that protocols using a new IP protocol number >> > face when being deployed over the Internet, where middleboxes that >> > only support TCP and UDP are not rare. Consequently, the RECOMMENDED >> > alternative to the UDP usage described in the remainder of this >> > section is the use of an IETF transport protocol such as TCP >> > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and >> > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram >> > Congestion Control Protocol (DCCP) [RFC4340] with its different >> > congestion control types [RFC4341][RFC4342][RFC5622]. >> > >> > First, this paragraph ignores potential deployment issues with any of >> these other than TCP, which risks seeming out of touch, but this is a minor >> point and probably not worth a late edit. Second, I'm concerned this >> recommendation could be taken as broader than intended, against the >> definition of any new transport protocol encapsulated within UDP that >> performs substantially the same function as the listed protocols. >> > >> I would agree, this paragraph also seems a little self >> contradictory.There is an acknowledgment that "middleboxes that only >> support TCP and UDP are not rare", but then the next sentence >> recommends the use of several other protocols besides UDP and TCP. If >> I put these two together, the only congested controlled protocol that >> is recommended and expected to work on the Internet is TCP. >> > > +1 TCP (implemented in kernel space) can't possibly evolve congestion > avoidance as fast as the Internet has changed, or will change (example: > good handling of middle boxes that use "policers" rather than some flavor > of buffer-size based packet-drop). > The rationale for using UDP for QUIC was indeed that a new IP number would > never make it through the Internet (other protocol deployment attempts have > commonly verified this). It turns out that even UDP is partially blocked > (as recently as 2011) by paths to 5-7% of all chrome clients, which lead to > the "automated fallback" elements of QUIC, > > I think this changes with ipv6, no? Google sees over 26% ipv6 in the usa and growing quickly http://www.google.com/intl/en/ipv6/statistics.html And there is evidence that middle boxes go away in ipv6. .... So perhaps the world is changing and your assuptions do not hold > > Hopefully the benefits that QUIC is bringing to the Internet will not be > outlawed (precluded by such commentary). > > Jim > > >> >> Tom >> >> > I think this can be made clearer by simply adding to the list of >> examples: >> > >> > NEW: >> > >> > These mechanisms are difficult to implement correctly. For most >> > applications, the use of one of the existing IETF transport protocols >> > is the simplest method of acquiring the required mechanisms. Doing >> > so also avoids issues that protocols using a new IP protocol number >> > face when being deployed over the Internet, where middleboxes that >> > only support TCP and UDP are not rare. Consequently, the RECOMMENDED >> > alternative to the UDP usage described in the remainder of this >> > section is the use of an IETF transport protocol such as TCP >> > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and >> > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram >> > Congestion Control Protocol (DCCP) [RFC4340] with its different >> > congestion control types [RFC4341][RFC4342][RFC5622], or transport >> > protocols specified by the IETF in the future. >> > >> > and removing the examples from the summary in section 7: >> > >> > OLD: >> > >> > | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | >> > >> > NEW: >> > >> > | SHOULD use a full-featured transport | | >> > >> > Thanks, cheers, >> > >> > Brian >> > >> > >> >> On 18 May 2016, at 02:17, The IESG wrote: >> >> >> >> >> >> The IESG has received a request from the Transport Area Working Group >> WG >> >> (tsvwg) to consider the following document: >> >> - 'UDP Usage Guidelines' >> >> as Best Current Practice >> >> >> >> The IESG plans to make a decision in the next few weeks, and solicits >> >> final comments on this action. Please send substantive comments to the >> >> ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, comments >> may be >> >> sent to iesg@ietf.org instead. In either case, please retain the >> >> beginning of the Subject line to allow automated sorting. >> >> >> >> Abstract >> >> >> >> >> >> The User Datagram Protocol (UDP) provides a minimal message-passing >> >> transport that has no inherent congestion control mechanisms. This >> >> document provides guidelines on the use of UDP for the designers of >> >> applications, tunnels and other protocols that use UDP. Congestion >> >> control guidelines are a primary focus, but the document also >> >> provides guidance on other topics, including message sizes, >> >> reliability, checksums, middlebox traversal, the use of ECN, DSCPs, >> >> and ports. >> >> >> >> Because congestion control is critical to the stable operation of the >> >> Internet, applications and other protocols that choose to use UDP as >> >> an Internet transport must employ mechanisms to prevent congestion >> >> collapse and to establish some degree of fairness with concurrent >> >> traffic. They may also need to implement additional mechanisms, >> >> depending on how they use UDP. >> >> >> >> Some guidance is also applicable to the design of other protocols >> >> (e.g., protocols layered directly on IP or via IP-based tunnels), >> >> especially when these protocols do not themselves provide congestion >> >> control. >> >> >> >> This document obsoletes RFC5405 and adds guidelines for multicast UDP >> >> usage. >> >> >> >> >> >> >> >> >> >> The file can be obtained via >> >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ >> >> >> >> IESG discussion can be tracked via >> >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ >> >> >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> > >> > >> > _______________________________________________ >> > Spud mailing list >> > Spud@ietf.org >> > https://www.ietf.org/mailman/listinfo/spud >> > >> >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >> > > --001a1147136a59d17a0534c355b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, June 5, 2016, Jim Roskind <Ji= mRoskind@gmail.com> wrote:


On = Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert <tom@herbe= rtland.com> wrote:
On Thu, Jun 2, 2= 016 at 3:11 AM, Brian Trammell <ietf@trammell.ch> wrote:
> Greetings, all,
>
> Apologies for the late last call comment; I have only one, relatively = minor. I hope it's still useful.
>
> I understand that Section 3 was written to encourage application devel= opers not to roll their own transports ("trust us when we say this is = hard, this document is a list of reasons why") but as written it would= seem to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB da= ta channel, anything-over-PLUS), which I very much hope was not the intent.= The problematic recommendation is in the second paragraph:
>
>=C2=A0 =C2=A0 These mechanisms are difficult to implement correctly.=C2= =A0 For most
>=C2=A0 =C2=A0 applications, the use of one of the existing IETF transpo= rt protocols
>=C2=A0 =C2=A0 is the simplest method of acquiring the required mechanis= ms.=C2=A0 Doing
>=C2=A0 =C2=A0 so also avoids issues that protocols using a new IP proto= col number
>=C2=A0 =C2=A0 face when being deployed over the Internet, where middleb= oxes that
>=C2=A0 =C2=A0 only support TCP and UDP are not rare.=C2=A0 Consequently= , the RECOMMENDED
>=C2=A0 =C2=A0 alternative to the UDP usage described in the remainder o= f this
>=C2=A0 =C2=A0 section is the use of an IETF transport protocol such as = TCP
>=C2=A0 =C2=A0 [RFC0793], Stream Control Transmission Protocol (SCTP) [R= FC4960], and
>=C2=A0 =C2=A0 SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], o= r Datagram
>=C2=A0 =C2=A0 Congestion Control Protocol (DCCP) [RFC4340] with its dif= ferent
>=C2=A0 =C2=A0 congestion control types [RFC4341][RFC4342][RFC5622].
>
> First, this paragraph ignores potential deployment issues with any of = these other than TCP, which risks seeming out of touch, but this is a minor= point and probably not worth a late edit. Second, I'm concerned this r= ecommendation could be taken as broader than intended, against the definiti= on of any new transport protocol encapsulated within UDP that performs subs= tantially the same function as the listed protocols.
>
I would agree, this paragraph also seems a little self
contradictory.There is an acknowledgment that "middleboxes that only support TCP and UDP are not rare", but then the next sentence
recommends the use of several other protocols besides UDP and TCP. If
I put these two together, the only congested controlled protocol that
is recommended and expected to work on the Internet is TCP.

+1 =C2=A0 TCP (implemented in kernel space) can't = possibly evolve congestion avoidance as fast as the Internet has changed, o= r will change (example: good handling of middle boxes that use "police= rs" rather than some flavor of buffer-size based packet-drop).=C2=A0
The rationale for using UDP for QUIC was indeed that a new IP numb= er would never make it through the Internet (other protocol deployment atte= mpts have commonly verified this).=C2=A0 It turns out that even UDP is part= ially blocked (as recently as 2011) by paths to 5-7% of all chrome clients,= which lead to the "automated fallback" elements of QUIC, =C2=A0= =C2=A0


I think this changes with ipv6, no?=C2=A0=C2=A0Google sees = over 26% ipv6 in the usa and growing quickly


And ther= e is evidence that middle boxes go away in ipv6. .... So perhaps the world = is changing and your assuptions do not hold



=C2=A0
<= /blockquote>
Hopefully the benefits that QUI= C is bringing to the Internet will not be outlawed (precluded by such comme= ntary).

Jim
=C2=A0

Tom

> I think this can be made clearer by simply adding to the list of examp= les:
>
> NEW:
>
>=C2=A0 =C2=A0 These mechanisms are difficult to implement correctly.=C2= =A0 For most
>=C2=A0 =C2=A0 applications, the use of one of the existing IETF transpo= rt protocols
>=C2=A0 =C2=A0 is the simplest method of acquiring the required mechanis= ms.=C2=A0 Doing
>=C2=A0 =C2=A0 so also avoids issues that protocols using a new IP proto= col number
>=C2=A0 =C2=A0 face when being deployed over the Internet, where middleb= oxes that
>=C2=A0 =C2=A0 only support TCP and UDP are not rare.=C2=A0 Consequently= , the RECOMMENDED
>=C2=A0 =C2=A0 alternative to the UDP usage described in the remainder o= f this
>=C2=A0 =C2=A0 section is the use of an IETF transport protocol such as = TCP
>=C2=A0 =C2=A0 [RFC0793], Stream Control Transmission Protocol (SCTP) [R= FC4960], and
>=C2=A0 =C2=A0 SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], o= r Datagram
>=C2=A0 =C2=A0 Congestion Control Protocol (DCCP) [RFC4340] with its dif= ferent
>=C2=A0 =C2=A0 congestion control types [RFC4341][RFC4342][RFC5622], or = transport
>=C2=A0 =C2=A0 protocols specified by the IETF in the future.
>
> and removing the examples from the summary in section 7:
>
> OLD:
>
>=C2=A0 =C2=A0 | SHOULD use a full-featured transport (TCP, SCTP, DCCP)= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>
> NEW:
>
>=C2=A0 =C2=A0 | SHOULD use a full-featured transport=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
>
> Thanks, cheers,
>
> Brian
>
>
>> On 18 May 2016, at 02:17, The IESG <iesg-secretary@ietf.org<= /a>> wrote:
>>
>>
>> The IESG has received a request from the Transport Area Working Gr= oup WG
>> (tsvwg) to consider the following document:
>> - 'UDP Usage Guidelines'
>>=C2=A0 <draft-ietf-tsvwg-rfc5405bis-13.txt> as Best Current P= ractice
>>
>> The IESG plans to make a decision in the next few weeks, and solic= its
>> final comments on this action. Please send substantive comments to= the
>> ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, c= omments may be
>> sent to iesg@ietf.org instead. In either case, please retai= n the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>=C2=A0 =C2=A0The User Datagram Protocol (UDP) provides a minimal me= ssage-passing
>>=C2=A0 =C2=A0transport that has no inherent congestion control mech= anisms.=C2=A0 This
>>=C2=A0 =C2=A0document provides guidelines on the use of UDP for the= designers of
>>=C2=A0 =C2=A0applications, tunnels and other protocols that use UDP= .=C2=A0 Congestion
>>=C2=A0 =C2=A0control guidelines are a primary focus, but the docume= nt also
>>=C2=A0 =C2=A0provides guidance on other topics, including message s= izes,
>>=C2=A0 =C2=A0reliability, checksums, middlebox traversal, the use o= f ECN, DSCPs,
>>=C2=A0 =C2=A0and ports.
>>
>>=C2=A0 =C2=A0Because congestion control is critical to the stable o= peration of the
>>=C2=A0 =C2=A0Internet, applications and other protocols that choose= to use UDP as
>>=C2=A0 =C2=A0an Internet transport must employ mechanisms to preven= t congestion
>>=C2=A0 =C2=A0collapse and to establish some degree of fairness with= concurrent
>>=C2=A0 =C2=A0traffic.=C2=A0 They may also need to implement additio= nal mechanisms,
>>=C2=A0 =C2=A0depending on how they use UDP.
>>
>>=C2=A0 =C2=A0Some guidance is also applicable to the design of othe= r protocols
>>=C2=A0 =C2=A0(e.g., protocols layered directly on IP or via IP-base= d tunnels),
>>=C2=A0 =C2=A0especially when these protocols do not themselves prov= ide congestion
>>=C2=A0 =C2=A0control.
>>
>>=C2=A0 =C2=A0This document obsoletes RFC5405 and adds guidelines fo= r multicast UDP
>>=C2=A0 =C2=A0usage.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/d= oc/draft-ietf-tsvwg-rfc5405bis/
>>
>> IESG discussion can be tracked via
>> https://datatracker.iet= f.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--001a1147136a59d17a0534c355b4-- From nobody Wed Jun 8 09:41: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 8073712DA2E; Wed, 8 Jun 2016 09:41:00 -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 Ea3kiNXWmHGV; Wed, 8 Jun 2016 09:40:58 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id ECADD12DA1F; Wed, 8 Jun 2016 09:40:57 -0700 (PDT) Received: from [10.44.157.122] (212-88-240-96.access.telenet.be [212.88.240.96]) by trammell.ch (Postfix) with ESMTPSA id AFC611A0302; Wed, 8 Jun 2016 18:40:25 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_178C65FE-32D5-4259-A227-F4D8168B3E70"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Wed, 8 Jun 2016 18:40:24 +0200 Message-Id: <6B252567-A532-42FF-B035-E457400EECF5@trammell.ch> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> To: Ca By X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tsvwg WG , Tom Herbert , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , Jim Roskind , "quic@ietf.org" Subject: Re: [Spud] [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice 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, 08 Jun 2016 16:41:00 -0000 --Apple-Mail=_178C65FE-32D5-4259-A227-F4D8168B3E70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 >> On 08 Jun 2016, at 14:20, Ca By wrote: >>=20 >>=20 >>=20 >> On Sunday, June 5, 2016, Jim Roskind wrote: >>=20 >>=20 >> On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert = wrote: >> On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell = wrote: >> > Greetings, all, >> > >> > Apologies for the late last call comment; I have only one, = relatively minor. I hope it's still useful. >> > >> > I understand that Section 3 was written to encourage application = developers not to roll their own transports ("trust us when we say this = is hard, this document is a list of reasons why") but as written it = would seem to discourage transport innovation atop UDP (e.g. QUIC, the = RTCWEB data channel, anything-over-PLUS), which I very much hope was not = the intent. The problematic recommendation is in the second paragraph: >> > >> > These mechanisms are difficult to implement correctly. For most >> > applications, the use of one of the existing IETF transport = protocols >> > is the simplest method of acquiring the required mechanisms. = Doing >> > so also avoids issues that protocols using a new IP protocol = number >> > face when being deployed over the Internet, where middleboxes = that >> > only support TCP and UDP are not rare. Consequently, the = RECOMMENDED >> > alternative to the UDP usage described in the remainder of this >> > section is the use of an IETF transport protocol such as TCP >> > [RFC0793], Stream Control Transmission Protocol (SCTP) = [RFC4960], and >> > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or = Datagram >> > Congestion Control Protocol (DCCP) [RFC4340] with its different >> > congestion control types [RFC4341][RFC4342][RFC5622]. >> > >> > First, this paragraph ignores potential deployment issues with any = of these other than TCP, which risks seeming out of touch, but this is a = minor point and probably not worth a late edit. Second, I'm concerned = this recommendation could be taken as broader than intended, against the = definition of any new transport protocol encapsulated within UDP that = performs substantially the same function as the listed protocols. >> > >> I would agree, this paragraph also seems a little self >> contradictory.There is an acknowledgment that "middleboxes that only >> support TCP and UDP are not rare", but then the next sentence >> recommends the use of several other protocols besides UDP and TCP. If >> I put these two together, the only congested controlled protocol that >> is recommended and expected to work on the Internet is TCP. >>=20 >> +1 TCP (implemented in kernel space) can't possibly evolve = congestion avoidance as fast as the Internet has changed, or will change = (example: good handling of middle boxes that use "policers" rather than = some flavor of buffer-size based packet-drop). >> The rationale for using UDP for QUIC was indeed that a new IP number = would never make it through the Internet (other protocol deployment = attempts have commonly verified this). It turns out that even UDP is = partially blocked (as recently as 2011) by paths to 5-7% of all chrome = clients, which lead to the "automated fallback" elements of QUIC, >>=20 >=20 > I think this changes with ipv6, no? Google sees over 26% ipv6 in the = usa and growing quickly >=20 > http://www.google.com/intl/en/ipv6/statistics.html >=20 > And there is evidence that middle boxes go away in ipv6. .... So = perhaps the world is changing and your assuptions do not hold (dropping ietf@, saving my Narten points since we're a bit off topic on = the draft last call) I'd like to see evidence, if you can share it. We've done a few measurements with Atlas that suggest the brokenness on = v6 is different, but not necessarily better, but don't have enough data = points to make an informed statement on the fact. Any time you touch a = NAPT (which lives at the core of any transition technology for v6-only = access to the v4 Internet), you run into the "only TCP and UDP have = ports" fallacy. But yes, we need to compare and contrast v4 and v6 = access network impairments for non-(6,17) protocol numbers. Cheers, Brian --Apple-Mail=_178C65FE-32D5-4259-A227-F4D8168B3E70 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 iQIcBAEBCgAGBQJXWEp5AAoJEIoSt78L6kajnYgP/3N/uJHh8+g4Qo/gscnWlYu2 tSC0qa5rzJ9j9VDBI8f9dya+mcI2N+PALwlL2ltznIANbRTYccWlisd+EC0ySxtc ln49ibyBH6YIX4jZXBclGAZRT6VidhXMkPTBTV3J1rYIF99FRosHbytkQtwzXxlF OOq9OIGc+Cb/krSld8j6jX7PoUSZk1dICL+7uHd5qtcrMzpZrwtQ73MHshlOROQE SgkE/36eI7m2k2WraYCKCJYAsvTol8czlGhd7/uOjFa+djyk82JHcyBqWz/hXCRU gW7jOSm83VYFDo7ijfIx50Eeu0zvyiifOaBASsFAWtIXd3zSwdj/BhDeEZELoqv9 W6PN8M6SurFs1ZjOjrbHsUFD/QgKyhBNq/lJmW5M+2eijXQzYwvDXB24ZRCeXFk6 9STH8u+sYMVxtKfQVyPUrRbqeUO2ITtbSNPDvp4DOCKD2xrnbRB0C+dxb4D0440M aNeXqrN6TctplkmY9A6cepY3fFLcPt7NDbWX2KZYsH2tfQkpPeE9NPSXfVO5YpGu rxaso2e+Fh2AKUjmEnwavwfgPsF12xndSboiDRFzJs/eXA0Y3kSWMQf5yz1DOy3F yNBrBNEKLHe8lAYVUGxF+6SnI4sivrhnEn41lzP1+lMTic+PyO1fni/zaKD3ksp4 yeR/bhTDYgujISd7/rpN =9pgK -----END PGP SIGNATURE----- --Apple-Mail=_178C65FE-32D5-4259-A227-F4D8168B3E70-- From nobody Wed Jun 8 15:17: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 4FF5312D5AA for ; Wed, 8 Jun 2016 15:17:31 -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 qa37uoGszrC0 for ; Wed, 8 Jun 2016 15:17:26 -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 9B08812D7CA for ; Wed, 8 Jun 2016 15:17:26 -0700 (PDT) Received: from [128.9.184.172] ([128.9.184.172]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u58MHBWn009424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Jun 2016 15:17:12 -0700 (PDT) To: Brian Trammell , spud References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> From: Joe Touch Message-ID: <57589967.9090004@isi.edu> Date: Wed, 8 Jun 2016 15:17: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: <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> 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: Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 22:17:31 -0000 On 6/8/2016 3:38 AM, Brian Trammell wrote: > So the situation with IPv6 EH seems to be slightly worse than the situation with UDP, probably harder to diagnose at runtime, and requires kernel support. So while I agree this is architecturally cleaner, I'm skeptical that it's as deployable as a UDP encapsulation-based approach. It'd useful to consider the impact of current non-compliant systems on new approaches, but not to be severely limited by them. Nothing is universally deployable except HTTP in TCP, and we really don't need to be reinventing the Internet inside HTTP. Joe From nobody Thu Jun 9 01:46: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 834C612D1E0 for ; Thu, 9 Jun 2016 01:46:40 -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 sIRtM4eOUbdw for ; Thu, 9 Jun 2016 01:46:38 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8491412D0A3 for ; Thu, 9 Jun 2016 01:46:38 -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 859911A09E2; Thu, 9 Jun 2016 10:46:06 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B5EFF17D-AFFC-46B3-B7DD-85188D67B6F7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <57589967.9090004@isi.edu> Date: Thu, 9 Jun 2016 10:46:05 +0200 Message-Id: <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 08:46:40 -0000 --Apple-Mail=_B5EFF17D-AFFC-46B3-B7DD-85188D67B6F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 09 Jun 2016, at 00:17, Joe Touch wrote: >=20 >=20 >=20 > On 6/8/2016 3:38 AM, Brian Trammell wrote: >> So the situation with IPv6 EH seems to be slightly worse than the = situation with UDP, probably harder to diagnose at runtime, and requires = kernel support. So while I agree this is architecturally cleaner, I'm = skeptical that it's as deployable as a UDP encapsulation-based approach. > It'd useful to consider the impact of current non-compliant systems on > new approaches, but not to be severely limited by them. AFAIC, the marginal difference in brokenness between EH-based and UDP = encapsulation-based approaches is way less important than lack of = universal userspace access to extension headers. (I'm also not convinced = that the types of path signaling envisioned in the use case draft are = properly "network layer" -- since they involve the explicit = participation of devices on path neither as packet forwarding devices at = layer 3 nor as proper endpoints -- but that is a literally academic = argument.) It would be useful if whatever comes out of an eventual PLUS working = group could be implemented either over UDP or IPv6 EH, since the lack of = access to EH problem is simply a matter of changing APIs. But I'm not = convinced that's a hard requirement. > Nothing is universally deployable except HTTP in TCP, and we really > don't need to be reinventing the Internet inside HTTP. We also don't have to, since it's already been done. Cheers, Brian --Apple-Mail=_B5EFF17D-AFFC-46B3-B7DD-85188D67B6F7 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 iQIcBAEBCgAGBQJXWSzOAAoJEIoSt78L6kaj+IkP/3wHRbBJQ40BLzfevIVx0SL0 6z2Rb2fjBxC57un2FTtqIQUWn5xFoTQwlDXVGACnJslRIABcv/W0q4mZpQfFs+u2 se/ntwODUoTYYhJrK9OJYAQakPYEWbmDGIwR+7kId3AEmxyR9oLEIQStxgvuMCTS IkBDd51G9bpsovG4kA96Jv5TL2jEletQVMtKB9hTns0DJksPdX9sFaNmtv1Q/O04 FlH0gZfNaz8FJdLy8nMIs/J1SAbNmYoTPnDzW/k2bd1KHQZogI0Tu74iyCGwIOMz jW6pzB5nakzCyQJ2xQitoEOeDOCmrDHMs4OfGTTrFqnHWSs96fTgjdSeH+yj0/M/ aKWpdg8uUg44yev7xqFuovHDowzaP19AvRK99dxYrjpCk+BtKgZ3BGH5+KjVA++L Fwdij4JGLw2FlRrwT0yfzRA7y0DI1ZywL6KyOIvw9GPv11MrI+6hMj9BxsDyiNpB evjbi35jxfqCjfzfHrdJMkWKIoa8KZzi2CNaq5sKp2Y4mMdt0HQSSmHs9QjgWcbP ITH3yCP1RUTo/b29GasW4wiRcigGiGXsUrkLJRvzWwmg4XgTIvMO5AhrCTbqLvMm Y6HvxqyjzCdIC/iOIxa5BrW50LKar1WF8Fb7wdgp48Ak1Z5R2HWiIWb0S2X1ybWH +StK4EW4Boa3d30CuTWj =MdJS -----END PGP SIGNATURE----- --Apple-Mail=_B5EFF17D-AFFC-46B3-B7DD-85188D67B6F7-- From nobody Thu Jun 9 03:42: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 9850C12D0B9; Thu, 9 Jun 2016 03:42:03 -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 g97HKFCbN3Yh; Thu, 9 Jun 2016 03:42:01 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0561112B02D; Thu, 9 Jun 2016 03:42:00 -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 C073C1A0302; Thu, 9 Jun 2016 12:41:29 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_086C2124-3961-4AF3-932A-081514904FF6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Thu, 9 Jun 2016 12:41:29 +0200 Message-Id: <3A0781FE-D2F2-4AD8-8F4D-4AC3A8D4D177@trammell.ch> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> To: Randall Stewart X-Mailer: Apple Mail (2.3124) Archived-At: Cc: =?utf-8?Q?Michael_T=C3=BCxen?= , "Scharf, Michael \(Nokia - DE\)" , spud , "quic@ietf.org" , Jana Iyengar Subject: [Spud] Segment offload for UDP-based protocols Re: [QUIC] Requirements 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, 09 Jun 2016 10:42:04 -0000 --Apple-Mail=_086C2124-3961-4AF3-932A-081514904FF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Randall, > On 09 Jun 2016, at 12:30, Randall Stewart wrote: >=20 >=20 >> On Jun 9, 2016, at 5:06 AM, Michael Tuexen = wrote: >>=20 >>=20 >>> On 09 Jun 2016, at 10:03, Scharf, Michael (Nokia - DE) = wrote: >>>=20 >>> My concern is that the current charter suggestion markets the = protocol by =E2=80=9Cminimizing (=E2=80=A6) overall transport latency = for applications=E2=80=9D. IMHO this can have rebound effects. >>>=20 >>> Here is what I mean by wrong expectations: Whether a protocol is = indeed fast or not depends on many parameters including aspects such as = hardware acceleration/offload (which matters at 10G/40G line speed, to = the best of my knowledge). Some of these effects of >> I think this refers to high throughput. For TCP, offloading TCP = processing to a NIC improves performance >> of the TCP processing. I'm not sure if this still helps if = encryption/decryption comes into the game. >=20 > I too was thinking Michael meant offloading such as TSO and LRO. I = know on most of the caches > I develop on if I turn off TSO and LRO performance of the box drops by = roughly 50%=E2=80=A6 and I think > this will be a consequence of encrypting everything since I don=E2=80=99= t think you can do TSO/LRO unless > the hardware/lower-layers has access to things equivalent to TCP = sequence numbers and ACK values, > which is what I believe the encryption is meant to hide (from middle = boxes). >=20 > That will be an extreme price to pay the question is, is it worth it = /and or/ is there some other way > to get the benefits of the TSO/LRO even with encryption=E2=80=A6 :-) (adding spud@ietf.org, as this is a relevant question for PLUS, too): The question is what is the minimum information xSO/LRO needs to work. = If I understand how generic segment offload works, if QUIC(/PLUS) = exposes: (1) a header field that can be used to order packets and find gaps that = the kernel can find and interpret, (2) a defined and easily-found boundary between header and payload, such = that the payload retains any framing/message boundaries needed to meet = API contracts, and (3) rules about which header to choose for the "big" segment on receive then adding QUIC(/PLUS) aware SO/LRO to the kernel should be reasonably = simple. I don't see why you need ACK-equivalents to be exposed to make = this work, but I might be missing something. Hardware offload takes longer to deploy, obviously, but runs on = equivalent information. Cheers, Brian --Apple-Mail=_086C2124-3961-4AF3-932A-081514904FF6 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 iQIcBAEBCgAGBQJXWUfZAAoJEIoSt78L6kajK7oP/1o1URTm4SjFhApczfEpYklr pZCtX2bQd2Wlv9RvIFu6Lnb/qMnMxA01qkYwr5O2KCxZo1iJ8QDVIZWvTrLs+SLQ u9IVD3MMqrn038bfu6gTBTfSkHewADaujna4xa+oBe6C4x8L1ZLwGgPIHVGzJPWR sb9DRGw+go5PtAbJIFYbP20zZWqAbDMwK9lu9D0HtdJafbQrLTiprctS+SwwKPTV Wds6qJJpHLgVYaN9KNWQROSHQii3I0fIF9+uTOdTUE3lGhyw0vuh5O7J7hC34ac1 kqaI4zB3dg5iRJAEo9v4iXx3S26bPC9wKtZCslgC7t80KlJadJ+YheMzYbfGCy6w jC5n/HIXMf/tYo2zadQNoZynbXsZLv0KN5ilJR/L5X+b5W5bSkF7TAWxt21se1QJ 6qhTSQ0ghJ/V++iAtytZgW+3nQ3BMcvzY9nWd04MnAk3yw9Lno3irQPNt3sjhAax VMQ3BuiKitNrzX7v3bU3Q8VExQGIapuhyWOjTmHXa+Nayd2FmF8IJ5t3bDBxciQ9 Csz8oDhMBd4RudUqUBNYPwRsQrLLd3C6I6VaMJyUlQ7mTSMWysOPMprHTnZJ3Avw HAGzG/Kak5/pCzxBHU4/zl4Gq4dW2OTRrPfhMRtGjWQ5YZhGReYIzrkrDtC1qHgR Gjg0fY3Zud1QNPTpdr6c =16gW -----END PGP SIGNATURE----- --Apple-Mail=_086C2124-3961-4AF3-932A-081514904FF6-- From nobody Thu Jun 9 04:03: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 6D2DB12D124 for ; Thu, 9 Jun 2016 04:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 wE_lF7i6hoDD for ; Thu, 9 Jun 2016 04:02:58 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 5101D12B069 for ; Thu, 9 Jun 2016 04:02:58 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id q32so18136386qgq.3 for ; Thu, 09 Jun 2016 04:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LI9iH2ewDsJlQj+egIR3Quqmf1f2Z7B2vjnig9qhXHw=; b=bWbKgcJJpIaGeN2ttmAcxO3G5f/byZ/Ed3XxQEYpR1dnl+eXDmQDvrUAmva+aQ6Wq3 ou+66xM+t+vx+MUPDaPiIBC52gQpo3XZ+bninUwjAik/IC8HbMyIdRYhq3TgaNeJR5tR W1lNRoLX0LRFFyO40Eo1wumRFSyG5GcXdxg5s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LI9iH2ewDsJlQj+egIR3Quqmf1f2Z7B2vjnig9qhXHw=; b=PlPjUSXuHS50vWXRKJhHtRi87zRpihCHWZcTylScqAJje8I6zxkJjuIKM/R86cPlB1 Di4FK33rQER8GSJHwKgwGfo7QLvatcSaIsNW2HBFy1GtpvnVwsuXKOlYfFW4IGrCA931 8xUIzg1kinYk6Mk6lQJEiHRpqm1mvZAj4YoHS9vziIzCycP8sCWVj38MhMSmbYYNrc3w KY4Lz3kjU8JlZYtMOtWjjiZf7z9KRR1e05SSjTIF5brDDNOIP1/3oCYxaYh01v+IbrDC lu6OF6P7uY8I6MIeepUbcR02BNLJsbSVjz9iPZ+exkiqyuNTRwUmIfLTR4sLitbemN7G kwdA== X-Gm-Message-State: ALyK8tIQQ7yzuT8vzhlxzYThqyApQZJTcQBKMFkufd7s8OcdOWn3hlADn/mg/74WdgjZWeWf X-Received: by 10.140.27.203 with SMTP id 69mr9127653qgx.96.1465470177000; Thu, 09 Jun 2016 04:02:57 -0700 (PDT) Received: from [100.127.83.115] ([69.53.246.16]) by smtp.gmail.com with ESMTPSA id h66sm1518760qgh.15.2016.06.09.04.02.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jun 2016 04:02:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Randall Stewart In-Reply-To: <3A0781FE-D2F2-4AD8-8F4D-4AC3A8D4D177@trammell.ch> Date: Thu, 9 Jun 2016 07:02:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> <3A0781FE-D2F2-4AD8-8F4D-4AC3A8D4D177@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: =?utf-8?Q?Michael_T=C3=BCxen?= , Jana Iyengar , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" , spud Subject: Re: [Spud] [QUIC] Segment offload for UDP-based protocols Re: Requirements 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, 09 Jun 2016 11:03:00 -0000 > On Jun 9, 2016, at 6:41 AM, Brian Trammell wrote: >=20 > hi Randall, >=20 >> On 09 Jun 2016, at 12:30, Randall Stewart wrote: >>=20 >>=20 >>> On Jun 9, 2016, at 5:06 AM, Michael Tuexen = wrote: >>>=20 >>>=20 >>>> On 09 Jun 2016, at 10:03, Scharf, Michael (Nokia - DE) = wrote: >>>>=20 >>>> My concern is that the current charter suggestion markets the = protocol by =E2=80=9Cminimizing (=E2=80=A6) overall transport latency = for applications=E2=80=9D. IMHO this can have rebound effects. >>>>=20 >>>> Here is what I mean by wrong expectations: Whether a protocol is = indeed fast or not depends on many parameters including aspects such as = hardware acceleration/offload (which matters at 10G/40G line speed, to = the best of my knowledge). Some of these effects of >>> I think this refers to high throughput. For TCP, offloading TCP = processing to a NIC improves performance >>> of the TCP processing. I'm not sure if this still helps if = encryption/decryption comes into the game. >>=20 >> I too was thinking Michael meant offloading such as TSO and LRO. I = know on most of the caches >> I develop on if I turn off TSO and LRO performance of the box drops = by roughly 50%=E2=80=A6 and I think >> this will be a consequence of encrypting everything since I don=E2=80=99= t think you can do TSO/LRO unless >> the hardware/lower-layers has access to things equivalent to TCP = sequence numbers and ACK values, >> which is what I believe the encryption is meant to hide (from middle = boxes). >>=20 >> That will be an extreme price to pay the question is, is it worth it = /and or/ is there some other way >> to get the benefits of the TSO/LRO even with encryption=E2=80=A6 :-) >=20 > (adding spud@ietf.org, as this is a relevant question for PLUS, too): >=20 > The question is what is the minimum information xSO/LRO needs to work. = If I understand how generic segment offload works, if QUIC(/PLUS) = exposes: >=20 > (1) a header field that can be used to order packets and find gaps = that the kernel can find and interpret, My understanding of TSO (which is where we find the most benefit since = its hardware) is the hardware gets a *large* segment (say 64k) and cuts it up into MTU sized pieces duplicating the IP header and doing the = right things with the tcp-sequence number. If the sequence number is encrypted and not exposed that would be rather = difficult with Quic (or any such protocol for that matter even TCP if it was wrapped in UDP and encrypted). The other benefit is of course comes from LRO and thats really not done = in hardware but in software (at least in the implementation on which I work that is) .. where Acks Segments are = combined into bigger chunks.=20 For my work the Acks are what I care about having to process less Acks = is a win (but not nearly as much as TSO).=20 Both Seq and Ack can be compiled by LRO into a =E2=80=9Clarger = segment=E2=80=9D so you need again the exposure of the Ack value as well as the sequence number.. R >=20 > (2) a defined and easily-found boundary between header and payload, = such that the payload retains any framing/message boundaries needed to = meet API contracts, and >=20 > (3) rules about which header to choose for the "big" segment on = receive >=20 > then adding QUIC(/PLUS) aware SO/LRO to the kernel should be = reasonably simple. I don't see why you need ACK-equivalents to be = exposed to make this work, but I might be missing something. >=20 > Hardware offload takes longer to deploy, obviously, but runs on = equivalent information. >=20 > Cheers, >=20 > Brian >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic -------- Randall Stewart rrs@netflix.com 803-317-4952 From nobody Thu Jun 9 07:55: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 0E26F12D823 for ; Thu, 9 Jun 2016 07:55:58 -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 O2VXVc3IhdlA for ; Thu, 9 Jun 2016 07:55:56 -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 44F6C12D820 for ; Thu, 9 Jun 2016 07:55:56 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id m62so40175997iof.0 for ; Thu, 09 Jun 2016 07:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=y/n0CxiOhjrwuZvAZTT/GeNH4A8ilovIG6MoUfYTNvI=; b=YH45lPpep0gF9FVSWmDCuSP/ZE5tqCsDuium+AYBZnTKcSiZwWnVMFF4Bf6EE5AjoC jt0c+e4lF/4ShJiNnPZa/pM5OgQyJGTMj3Vz9X2f4gYuG9N0p/YF4l/2n+tkWWgWpJnt cvhu953GYrY4l2FsNAl9wHgkHGpKN8FXOVxayu955y5eAiL2hC9j2R6G2d5bfY1OM7k8 mPrDic8DC0wSqY+DWxBHezR+Zb4CE08Mjb3rc+eXJIJX7N3LTA33gBtzsR/5rNb0VB44 1bVAx++8PyWQsx5e0irGGKo6d0FKlBBOr1+4XLoXJppav02UV6O/vCK5Nj8mwPhtsx32 XtwA== 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=y/n0CxiOhjrwuZvAZTT/GeNH4A8ilovIG6MoUfYTNvI=; b=mbW6RXvXsf2PeI31OpLJjXrUsh2xckM0UhzuIc8zoJn3r4BRHvWF5maGbqDko3lwGR bN+LjR17E+y1jEL9abYTIRdEJ/wNsl3yrbIq5y2OtVkCBK9/9yQKgUU7EWpynM5MLJjN oaGrQWhJOMCNg1Nwq7o9VJtjinWwxg/5kHuu7FLiTSav4ooTzbkavG5yOLUyml7u6n34 vti79jesszHU6PPN9rSdRmRxCrRr8XDSj5RCwQOsE3B71QW7/7pv9Yt+JWr+g66+2K1f 8YPqST1hEuBQoy7HbGRJ+x4RzPV92MchtLFHe9gy7jG5Wnd2e7Ti3haOU9WsJYFyuDvq 2ezQ== X-Gm-Message-State: ALyK8tJWS+HRcSoZIt2b9FFIwGsvSCtSwbDIg0z+7y6i5jEJPMMbctdIZVR5eI3CC4bH089ceHor1p1C4/c+bQ== MIME-Version: 1.0 X-Received: by 10.107.162.131 with SMTP id l125mr17742695ioe.84.1465484155437; Thu, 09 Jun 2016 07:55:55 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Thu, 9 Jun 2016 07:55:55 -0700 (PDT) In-Reply-To: <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> Date: Thu, 9 Jun 2016 07:55:55 -0700 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 14:55:58 -0000 On Wed, Jun 8, 2016 at 3:38 AM, Brian Trammell wrote: > >> On 08 Jun 2016, at 06:27, Brian Trammell wrote: >> >> Hi Joe, all, >> >> Inline... >> >>> On 08 Jun 2016, at 00:35, Joe Touch wrote: >>> >>>> On 6/7/2016 3:19 PM, Tom Herbert wrote: >>>>> On Tue, Jun 7, 2016 at 3:09 PM, Joe Touch wrote: >>>>> >>>>>> On 6/7/2016 3:05 PM, Tom Herbert wrote: >>>>>> The proper architectural solution is to place network layer >>>>>> information like what is being proposed in the network layer :-) >>>>>> Trying to make a network layer out of UDP fails on several accounts >>>>>> (fragments don't contain UDP headers, ports do not have global >>>>>> meaning, etc.). IPv6 extension headers are designed for carrying >>>>>> information like this, I really hope there is more investigation as = to >>>>>> whether they are workable for signaling. >> >> I know that Jen Linkova has done some measurement work on this with resp= ect to on-path treatment; I forget the conclusions. Of course that leaves t= he question of userspace implementation open. > > On the question of path transparency to DO extension headers in V6, see t= his talk from IEPG at IETF91: > http://iepg.org/2014-11-09-ietf91/iepg-ietf91-ipv6-ehs-in-the-real-world-= v3.0.pdf (thanks Jen Linkova and Fernando Gont), the takeaway from which is= that the minimum observed drop rate of small (8-byte) DO EH on UDP packets= is about 6%. > > There was also Geoff Huston's IPv6 WG presentation at RIPE a couple of we= eks ago: https://ripe72.ripe.net/presentations/67-2016-05-23-bigipv6.pdf: i= n addition to a nice summary of why ICMP-as-is is broken, he found an upper= bound of 16% on in-network fragmentation EH drops. > > So the situation with IPv6 EH seems to be slightly worse than the situati= on with UDP, probably harder to diagnose at runtime, and requires kernel su= pport. So while I agree this is architecturally cleaner, I'm skeptical that= it's as deployable as a UDP encapsulation-based approach. > Brian, It's not just a question of being "architecturally cleaner" it's a question of correctness. I do not believe the neither the standard nor the architecture of the Internet allows for middleboxes to parse transport layer payloads (UDP is a transport layer protocol). This obviously was happening for a long time with devices that were parsing into TCP payloads to inspect HTTP headers and content, but that was never done under a standard and we closing that loophole by using TLS. A major problem is that in order for middleboxes to be able to parse something they have to positively identify what they are parsing. Port numbers are not sufficient for this since they only have end to end meaning (RFC7605). For instance, port 80 does not always have to be HTTP and conversely not all HTTP traffic has to use port 80. Magic numbers are the suggested recourse, but regardless of how many bits are used for the number that technique is still probabilistic to be correct (btw at Internet scale 32 bits is way to small, I'm not even sure 64 bits is okay). This also potentially creates new attack vectors. Consider that an attacker sends a well formed PLUS packet to a server running a UDP Echo Protocol (RFC862). The server will happily reflect the data in a UDP packet so that devices in the network now thinks it sees a PLUS packets being sent from the server-- this is not correct. Note that EH does not have these issues since IP protocol numbers have global and unambiguous meaning. If an IPv6 packet contains 60 in a next header field, then that next header may always be parsed to be destination options. Tom > Cheers, > > Brian > > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Thu Jun 9 09:05: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 889B912D84C for ; Thu, 9 Jun 2016 09:05:18 -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 XoAOvMoYA2B2 for ; Thu, 9 Jun 2016 09:05:16 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 37BD912D13B for ; Thu, 9 Jun 2016 09:05:16 -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 4CCDC1A0C5F; Thu, 9 Jun 2016 18:04:45 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_430C26B1-4151-4F31-A103-756F7BF90FE0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Thu, 9 Jun 2016 18:04:44 +0200 Message-Id: <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 16:05:18 -0000 --Apple-Mail=_430C26B1-4151-4F31-A103-756F7BF90FE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Tom, >> On the question of path transparency to DO extension headers in V6, = see this talk from IEPG at IETF91: >> = http://iepg.org/2014-11-09-ietf91/iepg-ietf91-ipv6-ehs-in-the-real-world-v= 3.0.pdf (thanks Jen Linkova and Fernando Gont), the takeaway from which = is that the minimum observed drop rate of small (8-byte) DO EH on UDP = packets is about 6%. >>=20 >> There was also Geoff Huston's IPv6 WG presentation at RIPE a couple = of weeks ago: = https://ripe72.ripe.net/presentations/67-2016-05-23-bigipv6.pdf: in = addition to a nice summary of why ICMP-as-is is broken, he found an = upper bound of 16% on in-network fragmentation EH drops. >>=20 >> So the situation with IPv6 EH seems to be slightly worse than the = situation with UDP, probably harder to diagnose at runtime, and requires = kernel support. So while I agree this is architecturally cleaner, I'm = skeptical that it's as deployable as a UDP encapsulation-based approach. >>=20 > Brian, >=20 > It's not just a question of being "architecturally cleaner" it's a > question of correctness. I don't see these questions as distinct. > I do not believe the neither the standard nor > the architecture of the Internet allows for middleboxes to parse > transport layer payloads (UDP is a transport layer protocol). I disagree with the assertion that UDP is actually a transport layer = protocol. UDP is a facility to allow processes on multitasking operating = systems to safely send as-raw-as-possible datagrams to each other in an = environment where one still expects link layer bit errors; i.e. the = Internet of 1993. Basically all of the functions of a real transport layer protocol must = be implemented atop UDP-based protocols, and most UDP-based application = protocols that actually work in the Internet either really only send one = packet at a time or behave like transport-layer protocols. > This > obviously was happening for a long time with devices that were parsing > into TCP payloads to inspect HTTP headers and content, but that was > never done under a standard and we closing that loophole by using TLS. TLS does nothing to keep the middleboxes from mucking about in the TCP = header, which is why we're having this whole discussion in the first = place. > A major problem is that in order for middleboxes to be able to parse > something they have to positively identify what they are parsing. Port > numbers are not sufficient for this since they only have end to end > meaning (RFC7605). For instance, port 80 does not always have to be > HTTP and conversely not all HTTP traffic has to use port 80. Too few bits in port numbers as well, yes. > Magic > numbers are the suggested recourse, but regardless of how many bits > are used for the number that technique is still probabilistic to be > correct (btw at Internet scale 32 bits is way to small, Agreed. > I'm not even sure 64 bits is okay The observation that 64 bit strings at given positions in packets do not = appear with uniform probability makes this a bit more okay, but yeah, = I'd like to see data too. > This also potentially creates new attack vectors. Consider that an > attacker sends a well formed PLUS packet to a server running a UDP > Echo Protocol (RFC862). The server will happily reflect the data in a > UDP packet so that devices in the network now thinks it sees a PLUS > packets being sent from the server-- this is not correct. I'll point out that the operational error here is connecting a server = running Echo to the Internet; it might be that there's lots of echo = running out there that people don't care about because its amplification = factor is a bit crap, though. And this attack doesn't work against a = PLUS that meets requirement 6.6 in the spud-req draft. I don't see how any of this is germane to the PLUS-in-UDP versus = PLUS-in-DO question though. > Note that EH does not have these issues since IP protocol numbers have > global and unambiguous meaning. If an IPv6 packet contains 60 in a > next header field, then that next header may always be parsed to be > destination options. Using DO to communicate with middleboxes is also not really all that = proper -- "destination" is IMO always distinct from "path" -- but since = I'm basically saying we need to add a new layer to the stack on top of = UDP headers, I probably shouldn't be talking about "proper". :) So, this is all well and good; a little digging in ip6(7) and sendmsg(2) = seems to indicate that I can at least get and set these with the = IPV6_DSTOPT socket option, at least on Linux, but the types involved are = still unclear from the documentation. I still think getting this right = in a cross-platform way tends to indicate an over-UDP implementation. = But that's an engineering question. Cheers, Brian >=20 --Apple-Mail=_430C26B1-4151-4F31-A103-756F7BF90FE0 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 iQIbBAEBCgAGBQJXWZOdAAoJEIoSt78L6kajPMcP93hk52o2BfdsM2JGv42EuRdl 1bGczSC3e/73mRuJKn8VHcyeJ3ZNszGEpTajmf4WMyGQfBzRCDteD+CV05j/2oBZ HG80xA6q2V3j8lMN25OwsgSZpsXh6aYnHzsnwACQGrPUTpS7Q1yjy+Lh2hTKPEms RIgI73BJ3NbEOaLLapzLVLVqxYNMalR8o4hquiBERxApaqpYEE8S29A6TeyZBDoc T71lCb2gMJIzF0E/gkfRe7A40/1NFLtYDG9VhZNETbMq1KGE0KsPYtGcO6Dp7zYh +cLLgGFx0iDuCTCZK5nQFmcWD1U2KU2Z6TIVcUjbebNp0+BTJqmQmo+eG+ljhCit 7sMdDaTaGyUECf50oXvGGL5XaB9cJw0+a+ulfzupGAuvQ8nSR842/cJ32etkdSjZ rvsYcTsDghDmPEJ1xHVWYEnvSZWQ8jrIKMQQ9tHQU0piSaQGUQIaJt6CLJ3tS/aR P8rXVOajG9rquaK8niB/mQFbHXrtl0u0/bIheJjuiS4G42lSy13XpD/dt6ZCeOdm 2G798nB7Bp6wgvIbIx/7UiKngC9knvimzhN/DbTdutnZ4OCnnTDz7v/1aU1yvQcm DnNb7knP4O8dHhdTGESbYpuV4drybXmbvZG+skYNhlzT2x7eARuXynIGqFEVdILK VdWvenKg6nKKV5C0cUA= =xpM3 -----END PGP SIGNATURE----- --Apple-Mail=_430C26B1-4151-4F31-A103-756F7BF90FE0-- From nobody Thu Jun 9 10:23:33 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C93D12D78F for ; Thu, 9 Jun 2016 10:23:32 -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 BJH-bBjT2KRm for ; Thu, 9 Jun 2016 10:23:31 -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 846EF12D8C4 for ; Thu, 9 Jun 2016 10:23:31 -0700 (PDT) Received: from [128.9.184.172] ([128.9.184.172]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u59HN0Wl020064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Jun 2016 10:23:00 -0700 (PDT) To: Brian Trammell , Tom Herbert References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> From: Joe Touch Message-ID: <5759A5F4.7060209@isi.edu> Date: Thu, 9 Jun 2016 10:23:00 -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: <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> 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: spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 17:23:32 -0000 On 6/9/2016 9:04 AM, Brian Trammell wrote: ... > I disagree with the assertion that UDP is actually a transport layer > protocol. UDP is a facility to allow processes on multitasking > operating systems to safely send as-raw-as-possible datagrams to each > other in an environment where one still expects link layer bit errors; > i.e. the Internet of 1993. Basically all of the functions of a real > transport layer protocol must be implemented atop UDP-based protocols, > and most UDP-based application protocols that actually work in the > Internet either really only send one packet at a time or behave like > transport-layer protocols. By your argument, there are no transport protocols. UDP *is* a transport by providing all-or-nothing messaging, demuxing to an upper layer protocol/application, and preserving message boundaries. Granted that's not everything some apps want, but neither is TCP. Consider that TCP provides reliable, ordered, bytestream service even though many apps really want message boundaries. Or concurrent interleaved messages. Or message chunking-and-muxing to avoid HOL blocking of large messages. I.e., that's how we ended up with a lot of what's in HTTP - to adjust for things TCP didn't provide or to undo some things it did provide. Your argument that apps often want services existing transports don't exactly provide is undeniable, but that doesn't mean these aren't transport protocols. You've only pointed out the known flaw in the OSI model - that there's no such thing as a fixed number of protocol layers or any one layer with a single defining property. Joe From nobody Fri Jun 10 07:57: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 6E01812D618 for ; Fri, 10 Jun 2016 07:57:48 -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 iNbpLOEmffGU for ; Fri, 10 Jun 2016 07:57:47 -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 E0FC612D0A9 for ; Fri, 10 Jun 2016 07:57:46 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id e5so12286333ith.0 for ; Fri, 10 Jun 2016 07:57: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=8yWqqe5at/6zp3Rg/y0Ok03E+H0v/EVfwlFlIggIYjs=; b=HyOPdyGwfcvOMNZA3Z9s2VvOC0yn7qGHd/K7kEYzmwMG9PIWJD+SXo7F/0zoEMDOvR Q83k+C/BGohJIKvkZRxPOJZPhjc12JSQhPEvR02EwxXNFEYsgMrGYJeSJE882qI93+A9 YwrBkvBCayhwjmEG4Ec7F6B7Sgkb3QZBuyWfKqOSqhAA0ZlBxBe5VagwTJseG7mY4kHh RaM5K3X+hJlA8BpMlSSYJe9oObGUhQ8VYkXNnKV79P26ikFaNL1T/qpgUNGSPl4ktypC kDWHUWCI480+iCqHk37xMPJ2sGJ2UKEaA11xRO0ZITWfAkxX8Gv6PDrJKrn3e/JVPh6a bfuw== 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=8yWqqe5at/6zp3Rg/y0Ok03E+H0v/EVfwlFlIggIYjs=; b=MU1D5k1sTIdrlqS9ENLOIUPgbT6yQ1AVafa6EwbWLA7BYk9eABFmj30ZVstmdwKqAM zeN/HmRbaXkVEOJBa5dLYayg90Qj/Z/vrg99Zmyd/w1iPxKhdtf11M/95hj98v6vOlDx huwISqtOH6ffVua4vhhwn+3Eny0ledPshVB6tY8Q71Ub/H3V2LhsfMVrMLMAuyf4mZrJ WHdD5/DBwgUxI6xxbX2UCFyfnuP7IuH7r3eGc7xhrc/WLurQJrP8mCs3zwEJ+kLMLYjB /xxZ2QTM0SPdAo4lLYRc2Lnyeq4l2gozmkrh3CWiJrZlCfAuJBIctyUZurjXJq9hD3Km dPQA== X-Gm-Message-State: ALyK8tJwlyb842ohP/Fj3/3NBcUPy0PeaHkb2PfdIcRfIfxasHsVUJ5USHLDJNWdROgD5Vlb3/WkARgC+YXxyQ== MIME-Version: 1.0 X-Received: by 10.36.66.68 with SMTP id i65mr32254372itb.91.1465570666098; Fri, 10 Jun 2016 07:57:46 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Fri, 10 Jun 2016 07:57:45 -0700 (PDT) In-Reply-To: <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> Date: Fri, 10 Jun 2016 07:57:45 -0700 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 14:57:48 -0000 >> This also potentially creates new attack vectors. Consider that an >> attacker sends a well formed PLUS packet to a server running a UDP >> Echo Protocol (RFC862). The server will happily reflect the data in a >> UDP packet so that devices in the network now thinks it sees a PLUS >> packets being sent from the server-- this is not correct. > > I'll point out that the operational error here is connecting a server run= ning Echo to the Internet; it might be that there's lots of echo running ou= t there that people don't care about because its amplification factor is a = bit crap, though. And this attack doesn't work against a PLUS that meets re= quirement 6.6 in the spud-req draft. > Regardless of what we think of Echo Server, it is a standard and it is legitimate to deploy it on the Internet (DOS concerns can be mitigated by rate limiting). Anti address spoofing does not help since nothing is being spoofed, all address are properly routable, without any sort of authentication between senders and network devices I don't that there is anything we can put into in the UDP payload to resolve this issue. > I don't see how any of this is germane to the PLUS-in-UDP versus PLUS-in-= DO question though. Robustness, correctness, and security are germane to any discussion of a proposed protocol. > >> Note that EH does not have these issues since IP protocol numbers have >> global and unambiguous meaning. If an IPv6 packet contains 60 in a >> next header field, then that next header may always be parsed to be >> destination options. > > Using DO to communicate with middleboxes is also not really all that prop= er -- "destination" is IMO always distinct from "path" -- but since I'm bas= ically saying we need to add a new layer to the stack on top of UDP headers= , I probably shouldn't be talking about "proper". :) > I was not suggesting DO that was only an example of the invariant property that IP protocol numbers have and UDP port numbers don't. Hop-by-hop options are probably more appropriate for signaling to/from network. > So, this is all well and good; a little digging in ip6(7) and sendmsg(2) = seems to indicate that I can at least get and set these with the IPV6_DSTOP= T socket option, at least on Linux, but the types involved are still unclea= r from the documentation. I still think getting this right in a cross-platf= orm way tends to indicate an over-UDP implementation. But that's an enginee= ring question. > AFIACT all the major OSes (Linux, WIndows, IOS, BSDs) implement the APIs in RFC3542. The caveat is that sending of particular options by an unprivileged user can be restricted. As options are defined and shown to be safe to use by unprivileged user they can be whitelisted and allowed. Tom > Cheers, > > Brian >> > From nobody Fri Jun 10 08:26: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 AF0E412D0D9 for ; Fri, 10 Jun 2016 08:25:55 -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 jnB9jdG8zQvq for ; Fri, 10 Jun 2016 08:25:48 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id D01E412D756 for ; Fri, 10 Jun 2016 08:25:46 -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 D94521A1677; Fri, 10 Jun 2016 17:25:44 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C043AD8C-B83E-4E90-A91C-60F1053A5C6C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Fri, 10 Jun 2016 17:25:44 +0200 Message-Id: <780953BA-CE7B-4B17-AB9A-27324246FB86@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 15:25:56 -0000 --Apple-Mail=_C043AD8C-B83E-4E90-A91C-60F1053A5C6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 10 Jun 2016, at 16:57, Tom Herbert wrote: >=20 >>> This also potentially creates new attack vectors. Consider that an >>> attacker sends a well formed PLUS packet to a server running a UDP >>> Echo Protocol (RFC862). The server will happily reflect the data in = a >>> UDP packet so that devices in the network now thinks it sees a PLUS >>> packets being sent from the server-- this is not correct. >>=20 >> I'll point out that the operational error here is connecting a server = running Echo to the Internet; it might be that there's lots of echo = running out there that people don't care about because its amplification = factor is a bit crap, though. And this attack doesn't work against a = PLUS that meets requirement 6.6 in the spud-req draft. >>=20 > Regardless of what we think of Echo Server, it is a standard and it > is legitimate to deploy it on the Internet (DOS concerns can be > mitigated by rate limiting). Anti address spoofing does not help since > nothing is being spoofed, all address are properly routable, without > any sort of authentication between senders and network devices I don't > that there is anything we can put into in the UDP payload to resolve > this issue. Reflecting off an echo server doesn't give you return routability. >> I don't see how any of this is germane to the PLUS-in-UDP versus = PLUS-in-DO question though. >=20 > Robustness, correctness, and security are germane to any discussion of > a proposed protocol. You're raising an issue with any protocol that runs over UDP in an = Internet with echo servers in it, and my understanding is the = arrangement you're proposing here is: ip (EH for path exposure) udp dtls (new protocols) whereas the one I think works is: ip udp plus for path exposure dtls (new protocols) I don't see how these are any different with respect to how they have to = handle the echo server attack. What am I missing here? >>> Note that EH does not have these issues since IP protocol numbers = have >>> global and unambiguous meaning. If an IPv6 packet contains 60 in a >>> next header field, then that next header may always be parsed to be >>> destination options. >>=20 >> Using DO to communicate with middleboxes is also not really all that = proper -- "destination" is IMO always distinct from "path" -- but since = I'm basically saying we need to add a new layer to the stack on top of = UDP headers, I probably shouldn't be talking about "proper". :) >>=20 > I was not suggesting DO that was only an example of the invariant > property that IP protocol numbers have and UDP port numbers don't. > Hop-by-hop options are probably more appropriate for signaling to/from > network. My impression is that HBH options were being more or less deprecated, = because they're largely unimplementable in hardware, due to = unpredictable header chain lengths and header chain walking time. Am I = incorrect here? (FWIW, sticking this in UDP makes it possible to provide constant = offsets when no extension headers are in use and when the superstrate = uses the path MTU correctly.) >> So, this is all well and good; a little digging in ip6(7) and = sendmsg(2) seems to indicate that I can at least get and set these with = the IPV6_DSTOPT socket option, at least on Linux, but the types involved = are still unclear from the documentation. I still think getting this = right in a cross-platform way tends to indicate an over-UDP = implementation. But that's an engineering question. >>=20 > AFIACT all the major OSes (Linux, WIndows, IOS, BSDs) implement the > APIs in RFC3542. Good to know; this makes this idea more deployable. :) Regards, Brian > The caveat is that sending of particular options by > an unprivileged user can be restricted. As options are defined and > shown to be safe to use by unprivileged user they can be whitelisted > and allowed. >=20 > Tom >=20 >> Cheers, >>=20 >> Brian >>>=20 >>=20 --Apple-Mail=_C043AD8C-B83E-4E90-A91C-60F1053A5C6C 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 iQIcBAEBCgAGBQJXWtv4AAoJEIoSt78L6kajXocP/jHqy4uem73NM7eHFTzsLmmk cK0pzVIk7Fo3nuK041xlC/K4PFbRGJTf50OcqLiYkwCaC8GsgvGNWEslWnEAzU7V FWmIMM3eyuoUCI+b0mAly7L+0xYehF/N/lys1FjgRnyc6DCO6nsTUc9aRpKGRfx8 Q1QJBXtu2C3banGvfeBd62+iXoQzEKoHqI60/WuK6zumYBx18wnfgYuNrx6gKRY+ R8IqZUQ8ySy7rF0d6Wszsr4KAgyRUrWorWiPWFcdTABmu2XZsU0HtctrT/38PEyu rxFRLyi03pfeg9gEKUOb28nIxdbrc+108OIV8tIHw/Jb2w6IIxoXbohScV2eTDdP 9eDT+Hc7JQSkFuOFoALgkbDX8io09ng6OWDEyiJIe1LnZM6yHhjV+Xv8CgJf2PKt IpgDCWmctLFf8QZ17Wua6wWNMbrslolsGJBgPxoviuTuXOWwqhtAjTxMIF4LBzhZ NXFyhCg5ukDAqNwVFmJ6l1FFnsgdK/ya1ksgNzPM8b3ZbfZJU32I/CCMg0rfwyoB EtthXicZI3VHFhx874WuMw5QFR9Ns/zWky9j10jABJcMIS9QC3wA31+Lvx05fokx QgK/bE/y/kZlAKnVfKhCwggC98SzWJ8tcgnvtiOC48ED4pooZv0EdQF5JQWRae6D eaWhjMM29VN9hO39nEbm =uPxU -----END PGP SIGNATURE----- --Apple-Mail=_C043AD8C-B83E-4E90-A91C-60F1053A5C6C-- From nobody Fri Jun 10 09:03: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 1EF4D12D7D8 for ; Fri, 10 Jun 2016 09:03: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 jW1oa6aSJ9_A for ; Fri, 10 Jun 2016 09:03:31 -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 BF04312D745 for ; Fri, 10 Jun 2016 09:03:31 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id h190so63034263ith.1 for ; Fri, 10 Jun 2016 09:03: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; bh=ZKYszJtK5l/5Krrl3ETDjmPb46N0qY5Kg9TNIOzEmSs=; b=n/gZB58G+5oFGAQsFB1GqX9ZyJtpa7K+I3V+IGP6LsJppE3M7vMOqvaL2PtkhtRsqv 9lGGhRTFSSjdEVS2T662yl+OP6xp7e1xcGCQGOLveZvY/SiYGYtPTdrrXn7ozJBG487x dI+oT8Ia97O+oNYCsEhy4dFgWtAAtgNEfWTFJUi2wN5sx6oqIpomPXJa6PtgTxeDethZ QEElxjmo1LaWhEsyKFXtOiTwf40OlcCo0+wutfI7GEcXKDRmdkxom23BNyGhs1EBTspv gLuK7YficDD1TkitT6N6ryTwU4Eq4x/ddLUttjOZVIOPXsCsCykm9/ba/oF7gczJRCGf p59A== 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=ZKYszJtK5l/5Krrl3ETDjmPb46N0qY5Kg9TNIOzEmSs=; b=Xhl6TU3JcbrK/CnEA+zObqgeiZHz+V5YM3MSWREeORSZx0cxxAw3KT6ISF4xSGmf4X Ze7jpqqBWRqkGa2x6q1pEpSsaLHxQgdhyKSDwGgZBq1qYZX/CaVynS5vm7/7tWxN4KQA akm5ufdV6K74rZISDZxSQfFb2OOQlQQjywXXcQ9TFDDiQp+nTsLfXpoGm/AtITGQKHFK IGw8xmwBNZRhle2MBzf/+kPkK6CfxKAxkNsMGQEgkOnsOhtCLQZ599RGuwvKhvTkz7pT 4RP648f+t/iftdNgp+W5GDQLJt2AMegAo/tI0IiXiXYpAiU1tXvC1m96Ac7qMwsxhiOX QshQ== X-Gm-Message-State: ALyK8tJ24OFqkRA7Pb4pJibqk10qM85prjtjl/BuK5E7xvdduHZDT6G+Z78M0P473rYSUgkzgyXks9XsFZ2JHQ== MIME-Version: 1.0 X-Received: by 10.36.80.4 with SMTP id m4mr33509154itb.37.1465574610983; Fri, 10 Jun 2016 09:03:30 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Fri, 10 Jun 2016 09:03:30 -0700 (PDT) In-Reply-To: <780953BA-CE7B-4B17-AB9A-27324246FB86@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> <780953BA-CE7B-4B17-AB9A-27324246FB86@trammell.ch> Date: Fri, 10 Jun 2016 09:03:30 -0700 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 16:03:33 -0000 > You're raising an issue with any protocol that runs over UDP in an Internet with echo servers in it, and my understanding is the arrangement you're proposing here is: Plus introduces new issues. All prior uses of UDP on the Internet have been end to end communications, application to application. PLUS is introducing the notion that UDP is used for application to network and network to application communications also. For end to end communications we can apply strong security (e.g. DTLS) so that spoofed or reflected UDP packets are not accepted. The issues are even worse if intermediate devices are allowed to modify payloads. Consider that we can not retroactively reserve a stream of bits at the beginning of every UDP payload to indicate PLUS. Regardless of how much data we collect on a set of safe bits to use, eventually some user will happen send those same exact bits in their application protocol. If such packets are modified by PLUS we now have introduced a silent data corruption. A protocol that allows silent data corruptions cannot be considered correct. > > ip > (EH for path exposure) > udp > dtls > (new protocols) > > whereas the one I think works is: > > ip > udp > plus for path exposure > dtls > (new protocols) > > I don't see how these are any different with respect to how they have to handle the echo server attack. What am I missing here? > The difference is that in case one the EH headers in a packet sent an echo server and not automatically reflected in the reply packet. In case #2 the whole UDP payload is reflected so the faux PLUS header is reflected and devices on the return path will process that information as signals to the network being sent from the Echo Server. This allows an attacker to affect the affect the devices in the reverse path. > My impression is that HBH options were being more or less deprecated, because they're largely unimplementable in hardware, due to unpredictable header chain lengths and header chain walking time. Am I incorrect here? > If nodes can't process HBH headers they can be ignored. This needs to be clarified in 2460bis. Tom From nobody Fri Jun 10 13: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 EA28412D0FB for ; Fri, 10 Jun 2016 13:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 Ao1mVesGgKNi for ; Fri, 10 Jun 2016 13:12:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CCF412D786 for ; Fri, 10 Jun 2016 13:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rLIIbySK6305F8U5t+llVnoFFXzxHq9wq2Uz4c8lE8M=; b=OIoBSg+YDI3k+XZ/dL71+aaHRIhuigdO6EKKMHjEFCcxOwooNhVFEBg3y4P/HCexWt3WXS//Glk20ofseyHZL1XnaZd4uzFYb/MBJHDyogsBkSTxY7fuWa9lAP4vDosfjKu4GDpcGl0fD21xWBa31Q50tnrU0Pi2bEjVIAcQCzM= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Fri, 10 Jun 2016 20:12:42 +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.0517.005; Fri, 10 Jun 2016 20:12:42 +0000 From: Christian Huitema To: Tom Herbert , Brian Trammell Thread-Topic: [Spud] updated draft PLUS charter, rev. 1 June Thread-Index: AQHRu/KkknslUV6vnUS4tzs14whv9J/eT28AgAABG4CAAB43AIAABfgAgAADLQCAABjYgIAABqUAgAACJQCAAAEtgIAAAqWAgAAEkgCAAGJBAIAAZ68AgAHaSoCAABM7AIABf52AgAAH0gCAAAqNAIAAQ7cA Date: Fri, 10 Jun 2016 20:12:41 +0000 Message-ID: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> <780953BA-CE7B-4B17-AB9A-27324246FB86@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:e::59a] x-ms-office365-filtering-correlation-id: 9f6fb4e2-6b87-4d84-fd15-08d3916b9437 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 6:vePCuSjqsEq6Jhb9xo3Yb7CG61MFLt4mioYqAKSOnNMpuukV0hgx0ikvDuhL9HevPJAmD+AWRtv4MSDAYvK+n7llsmul/1BfkNRvwoLJj4XzopH5AO5Maf6owVL3uizNMLk6YPHoH8djA3oOZ1/qpbTnnQr0GEukfheg90zAaGrCJg87YRIYb2gQDeSiLnUzOprGZFnn87IUozZxoymoZFgSzIVMpItY0j54Nkx6MghWsd9ydztW/aAM5OBx14Xxhw3bEvCDEqaagAbUif6Ym+dUeYmBuiPGrGoW8I1Tc5/Jaqcxo21I8Bjg6fRXtya3; 5:bbsdvNwokioAA3Nc64t1ws9JOJGWvfbT4ojUiI+EOB/Flk8kCgrgX4nJ0unHDdeE6RqW51nCGfINuaKHvon+dU7fQ1Yf0zIRrUFPLDSvoXjoeSFTkEyIq6mmm2x5DV8gCMgo4gP80D2VF1yFP0EIhg==; 24:c8tcnvYfiyDK2HPTej/x0UKQIYm2duAtAlUD1CeYRieZNN4gJ5ATTmKszuaey+8elvdCiySsW305qCSOfeoYioPdUplJkNVHRBAX3S51Leo=; 7:2fNW5WlTdIaZt6OC3M8nJlaS+fIvclWQ9by8di7Kolbe/1dTMkDTnELY3e3jrecRkRfuV1gjf2mEgOTpxTdnWQSsy4BMCR9cCjAEhkfzOsFI4SYa0C8Yc6gvrvQXkkYi7ks7d2lf8yMYCsQMUeXCunUoLtUnn+0lUGrrR/2fwR4wDwsIMSFYOTpTlzXGwqdb3g6buTHecQUJc85hXNeE/SMq1t6NoWi2lD6kZJzFm9PqWUnV0QAlIKh0FKuP7KIT x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(24454002)(199003)(76176999)(122556002)(54356999)(50986999)(2900100001)(77096005)(2950100001)(74316001)(86612001)(93886004)(106356001)(106116001)(105586002)(97736004)(5004730100002)(5002640100001)(6116002)(5008740100001)(9686002)(102836003)(5001770100001)(586003)(10290500002)(99286002)(189998001)(86362001)(92566002)(4326007)(2906002)(5003600100002)(68736007)(15650500001)(76576001)(3280700002)(11100500001)(3660700001)(10400500002)(5005710100001)(101416001)(8676002)(87936001)(81166006)(10090500001)(8936002)(81156014)(8990500004)(33656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 20:12:41.6187 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654 Archived-At: Cc: spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 20:12:46 -0000 On Friday, June 10, 2016 9:04 AM, Tom Herbert wrote: > ... > Plus introduces new issues. All prior uses of UDP on the Internet have be= en end > to end communications, application to application. PLUS is introducing th= e > notion that UDP is used for application to network and network to applica= tion > communications also. For end to end communications we can apply strong > security (e.g. DTLS) so that spoofed or reflected UDP packets are not acc= epted. I think Tom has a good point here. PLUS does introduce new communication pa= tterns, passing information to intermediate routers and expecting routers t= o act on the information. These communication patterns can very well introd= uce new attack vectors. We actually discussed a few of those on the list so= me time back. For example, an attacker could inject a packet that mimics th= e closure of a flow, and cause intermediate firewalls to close the holes op= en for that flow. I suggest that we recognize the link between new patterns and new attacks i= n the charter, and have an explicit goal to investigate these attacks and t= heir mitigations.=20 -- Christian Huitema From nobody Fri Jun 10 17: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 249DE12D5A0 for ; Fri, 10 Jun 2016 17:14: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 CCN_lDvCaJCL for ; Fri, 10 Jun 2016 17:14:51 -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 1EE1E12B02B for ; Fri, 10 Jun 2016 17:14:51 -0700 (PDT) Received: from [128.9.184.155] ([128.9.184.155]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u5B0EEof008104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jun 2016 17:14:14 -0700 (PDT) To: Brian Trammell , Tom Herbert References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> <780953BA-CE7B-4B17-AB9A-27324246FB86@trammell.ch> From: Joe Touch Message-ID: <575B57D6.2080102@isi.edu> Date: Fri, 10 Jun 2016 17:14:14 -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: <780953BA-CE7B-4B17-AB9A-27324246FB86@trammell.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u5B0EEof008104 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 00:14:52 -0000 On 6/10/2016 8:25 AM, Brian Trammell wrote: > ip > (EH for path exposure) > udp > dtls > (new protocols) > > whereas the one I think works is: > > ip > udp > plus for path exposure > dtls > (new protocols) The former will work with IPsec and is consistent with the Internet architecture. The latter is not. A distributed protocol that both relies on IP and is not consistent with IPsec is, IMO, a non-starter. Joe From nobody Sat Jun 11 04:49:20 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7938512DB1E for ; Sat, 11 Jun 2016 04:49:18 -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 HqlfVvTORwnN for ; Sat, 11 Jun 2016 04:49:16 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 505EF12B030 for ; Sat, 11 Jun 2016 04:49:15 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2:4d21:d389:2b88:a579] (unknown [IPv6:2001:470:26:9c2:4d21:d389:2b88:a579]) by trammell.ch (Postfix) with ESMTPSA id CDE161A0F1C; Sat, 11 Jun 2016 13:49:13 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B97DAF6D-1042-4FA6-B0F0-E006453FED6C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Sat, 11 Jun 2016 13:49:12 +0200 Message-Id: <0216496B-9083-49B1-8778-AA150DEE8392@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> <780953BA-CE7B-4B17-AB9A-27324246FB86@tra mmell.ch> To: Christian Huitema X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 11:49:18 -0000 --Apple-Mail=_B97DAF6D-1042-4FA6-B0F0-E006453FED6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 10 Jun 2016, at 22:12, Christian Huitema = wrote: >=20 > On Friday, June 10, 2016 9:04 AM, Tom Herbert wrote: >> ... >> Plus introduces new issues. All prior uses of UDP on the Internet = have been end >> to end communications, application to application. PLUS is = introducing the >> notion that UDP is used for application to network and network to = application >> communications also. For end to end communications we can apply = strong >> security (e.g. DTLS) so that spoofed or reflected UDP packets are not = accepted. >=20 > I think Tom has a good point here. PLUS does introduce new = communication patterns, passing information to intermediate routers and = expecting routers to act on the information. These communication = patterns can very well introduce new attack vectors. We actually = discussed a few of those on the list some time back. For example, an = attacker could inject a packet that mimics the closure of a flow, and = cause intermediate firewalls to close the holes open for that flow. Except this isn't really a new attack vector; there's no real difference = between this and a FIN/RST injection in TCP, except we get a chance to = make the space the attacker has to successfully guess in larger. > I suggest that we recognize the link between new patterns and new = attacks in the charter, and have an explicit goal to investigate these = attacks and their mitigations. Absolutely; added an issue to the draft charter, will propose text next = week Cheers, Brian --Apple-Mail=_B97DAF6D-1042-4FA6-B0F0-E006453FED6C 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 iQIcBAEBCgAGBQJXW/q5AAoJEIoSt78L6kajh+IQAKcuJkTMjS6PAmYrvibK9RBw kqg0IOcYKGlT8TcR5KYaN9kh4kcNWAdI6DGYLkA9ilrD2gkBXnfngcaPY3BXzXeQ KqWmUT0XRwWLL+yMWh1nSJfP0tHqmJi6C9qdLzPqbIpPeijrWn+cThKAAlg4IpT1 +JqYxUEUTjH7gzszk+rszZ6c1WBoJMnN70rfJ9MX5EWTVdJ2dHysYYkvsLJNihkA sCAjPdMyU6QhaaYmhdD4nVbyuMY6n2HcKQvBtFvxQ93XtLHUzNnkqBoHa+YxQyyB 2X9U2E5iawSUI28Y+y5L3COPS0DcJtv9asi4NUaD6auJjQFRyb60jWxhhOZWgxaA +7TWHVL8ZMuHCsu2XwiWmINUzHHTA/AgxcRFPK8iJqJef+lg2kF6u55zsvk/aH/H V+8pjeuzHqNW+waGYbiWXcw8/OkedCCIz36Jq8UdBdJ5WJeKTeIt+RuGY74RKG5K LyEndWKj1mjWUSdubOlDLqhBT3SS2DEA3Lp+U3RI3fBskUZbs13+m0j17Q94h3v3 PETWoxFND2rqD170bP27LqUwyUnuBLgxbQpMfKJsn+onNP47ivs9CLLi+tqnDQpi E1NYo52cXwjUgR4F5een6EPPS6RLPXCvroZGJ4cnbUNDy0j5QnUKP6v363XJ+aGb YZG4b5VTQXE0GwZtmXnH =xbnv -----END PGP SIGNATURE----- --Apple-Mail=_B97DAF6D-1042-4FA6-B0F0-E006453FED6C-- From nobody Sat Jun 11 09:23:30 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD84F12D739 for ; Sat, 11 Jun 2016 09:23:28 -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 BkIiOPzXq8SG for ; Sat, 11 Jun 2016 09:23:27 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 ABA4C12D738 for ; Sat, 11 Jun 2016 09:23:25 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id a5so18454386ita.1 for ; Sat, 11 Jun 2016 09:23:25 -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=F1yS260y89hEi8g8AnI10N1dY4S8C9dzdiY7eLUpyrQ=; b=QSKi+i7bavHLTnNsvJzh6E5Mk2CpKgf54nQMxuTVLxOul50dr6b0qrdKhlTpEVZElX N6bBBVFfTbUO5z6tDcQYpfP09CfmYRFMD/5f1V9lgQtynQNVIBWTG5WmC1JCEdJrE1lY 9Mwzgk3zlLMoJjzNsZqLqsBiqh4buitVe32Z9sKVsQcTYLzo680EDc7pPoEznr2CX0xr wV1NxaC+R8fbkOZ5kK/EJoe4IbMnV0yMU1dN940cCTtBVvLyTzfWZPWzFdSe1F/IltPb KeH6Jg0I8LbkMSLrxm6siS7oSGkwdcEHR55iNv9iXqwgU2j/T/rC6cSCLryTdQHPnIsR 1flw== 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=F1yS260y89hEi8g8AnI10N1dY4S8C9dzdiY7eLUpyrQ=; b=L6mhGd61aQKl8hu7BB3+05c/Z0hVgYUx672OtyP8GrmdXvrlyzYO819rnnCEMogMr+ uHCgivHeEtAsJO4HfxuAhZaRHWOK1F7ne/CgdHNS4LN17fy/rdGexCfqs5fPQ8ZDxf/S OLIOAddefpDLTD8gZBfFJIyDthIko1SPgKXT3U/Hqqrz9gRm5d+tih98KV6heeSaNK8z WnuKrxxP7bn61a8Ug1o5IN4zaCLblVbJxOT6mEu7OtcZjo/jUzGha+hGXcyEP69hANPS 2TXU9ZLnc0mUCNL20IkmlXc50jvfizC8DHIfdwWbFwq0rLSjL5WhGr1vB0eaVZTNhRvO 1S8A== X-Gm-Message-State: ALyK8tIUYIM1Al6CKvWk6KM57tbQ8qXTkuxPc0MxIpCoYeDhdQBzhl01XOyA1r3SkIoJfdZB4NSfH1auZt9Y5w== MIME-Version: 1.0 X-Received: by 10.36.80.4 with SMTP id m4mr6922909itb.37.1465662204085; Sat, 11 Jun 2016 09:23:24 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Sat, 11 Jun 2016 09:23:23 -0700 (PDT) In-Reply-To: <0216496B-9083-49B1-8778-AA150DEE8392@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> <0216496B-9083-49B1-8778-AA150DEE8392@trammell.ch> Date: Sat, 11 Jun 2016 09:23:23 -0700 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Christian Huitema , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 16:23:29 -0000 On Sat, Jun 11, 2016 at 4:49 AM, Brian Trammell wrote: > >> On 10 Jun 2016, at 22:12, Christian Huitema wrot= e: >> >> On Friday, June 10, 2016 9:04 AM, Tom Herbert wrote: >>> ... >>> Plus introduces new issues. All prior uses of UDP on the Internet have = been end >>> to end communications, application to application. PLUS is introducing = the >>> notion that UDP is used for application to network and network to appli= cation >>> communications also. For end to end communications we can apply strong >>> security (e.g. DTLS) so that spoofed or reflected UDP packets are not a= ccepted. >> >> I think Tom has a good point here. PLUS does introduce new communication= patterns, passing information to intermediate routers and expecting router= s to act on the information. These communication patterns can very well int= roduce new attack vectors. We actually discussed a few of those on the list= some time back. For example, an attacker could inject a packet that mimics= the closure of a flow, and cause intermediate firewalls to close the holes= open for that flow. > > Except this isn't really a new attack vector; there's no real difference = between this and a FIN/RST injection in TCP, except we get a chance to make= the space the attacker has to successfully guess in larger. > By doing TCP over DTLS over UDP we eliminate the possibility of injection attacks against TCP like this. That is a major reason why we want to encrypt transport headers. >> I suggest that we recognize the link between new patterns and new attack= s in the charter, and have an explicit goal to investigate these attacks an= d their mitigations. > > Absolutely; added an issue to the draft charter, will propose text next w= eek > > Cheers, > > Brian > From nobody Sat Jun 11 16:24:18 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EFB12D113; Sat, 11 Jun 2016 16:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 x_flt3sI3d7G; Sat, 11 Jun 2016 16:24:11 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 2062712D0AD; Sat, 11 Jun 2016 16:24:11 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id n184so33708797wmn.1; Sat, 11 Jun 2016 16:24:10 -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=uB5VYr7NJj6zQWnx53KqNj1uz7hosxjAX+ATvnTdzGY=; b=kIt6f5zsK4WiECTBSLL9eVrpuLd/dGUFgo/ZMPyaxa2lxeRA5u3JudVLUdrWquRSWw kUYcET3Qk/h9ebe1wl6QNX7jwzW/eMgKO2qZuODkSj+HjG3V6K0W/bDDii8yDCiRr7HZ GI8gtyxPstyDMUdPv0g7dhzFuObNdJEDMjNWPp4vVVKYWG0uA5BCx/CuZx2lEmFJcobi xA3KRzNFBLL0LLhCQBWl7V5HjHiZutC5YiEEHxLlo2h0WXB2LDI3WDwvces5bDjNyzVA 4tciOdcCU3AqD9MYc4++QccgDDmWFdw4kWxTJr7lgEbS/AE+n6API4K0M9W9vthXecIm WUKw== 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=uB5VYr7NJj6zQWnx53KqNj1uz7hosxjAX+ATvnTdzGY=; b=AGwcI2ophcRUQR90Ke++5iqW2Y4Z/+PoeAjhFxVKBqiJ92cDiCpPwMOzvuD1gX6REm szEkhf3GkESlMnzV6SpMBuQDJ6JgbTbKFgINNsfTqQl8O27CinjgNkjlK13YQnIVXDj9 ac1SMXP6/VjdYtnsxBhcmB3hqiFUg65N5m6rTk9qOz1U9enPdJ10cC1w2JtxPes+SIKU u3ZIHNKTk/lAEp+gm/S3jMiE3fYQyD8f7mGdYhAaA1H7jzbQPLByPxOFthW4O2cqAsq+ dn2vnWbXkLeqkcTjsAaaqmKsNxybFRIZ1W2z39NL1n+MtxGTgtXsNdwAzaUeWbqObizm cC8A== X-Gm-Message-State: ALyK8tIhmN8r0kPH2Uw/qpgwrMnt8uRdo6TaCh+7q+LvsyczwHVbXvJx0WwXij9s2O/D2Btg+NC9r4CfM+N0dA== MIME-Version: 1.0 X-Received: by 10.28.148.203 with SMTP id w194mr5033791wmd.10.1465687449538; Sat, 11 Jun 2016 16:24:09 -0700 (PDT) Received: by 10.28.234.13 with HTTP; Sat, 11 Jun 2016 16:24:09 -0700 (PDT) In-Reply-To: <6B252567-A532-42FF-B035-E457400EECF5@trammell.ch> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> <6B252567-A532-42FF-B035-E457400EECF5@trammell.ch> Date: Sat, 11 Jun 2016 16:24:09 -0700 Message-ID: From: Ca By To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114b322ac81c71053508f333 Archived-At: Cc: tsvwg WG , Tom Herbert , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , Jim Roskind , "quic@ietf.org" Subject: Re: [Spud] [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice 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, 11 Jun 2016 23:24:13 -0000 --001a114b322ac81c71053508f333 Content-Type: text/plain; charset=UTF-8 On Wednesday, June 8, 2016, Brian Trammell wrote: > > > >> On 08 Jun 2016, at 14:20, Ca By > > wrote: > >> > >> > >> > >> On Sunday, June 5, 2016, Jim Roskind > wrote: > >> > >> > >> On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert > wrote: > >> On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell > wrote: > >> > Greetings, all, > >> > > >> > Apologies for the late last call comment; I have only one, relatively > minor. I hope it's still useful. > >> > > >> > I understand that Section 3 was written to encourage application > developers not to roll their own transports ("trust us when we say this is > hard, this document is a list of reasons why") but as written it would seem > to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data > channel, anything-over-PLUS), which I very much hope was not the intent. > The problematic recommendation is in the second paragraph: > >> > > >> > These mechanisms are difficult to implement correctly. For most > >> > applications, the use of one of the existing IETF transport > protocols > >> > is the simplest method of acquiring the required mechanisms. Doing > >> > so also avoids issues that protocols using a new IP protocol number > >> > face when being deployed over the Internet, where middleboxes that > >> > only support TCP and UDP are not rare. Consequently, the > RECOMMENDED > >> > alternative to the UDP usage described in the remainder of this > >> > section is the use of an IETF transport protocol such as TCP > >> > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], > and > >> > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > >> > Congestion Control Protocol (DCCP) [RFC4340] with its different > >> > congestion control types [RFC4341][RFC4342][RFC5622]. > >> > > >> > First, this paragraph ignores potential deployment issues with any of > these other than TCP, which risks seeming out of touch, but this is a minor > point and probably not worth a late edit. Second, I'm concerned this > recommendation could be taken as broader than intended, against the > definition of any new transport protocol encapsulated within UDP that > performs substantially the same function as the listed protocols. > >> > > >> I would agree, this paragraph also seems a little self > >> contradictory.There is an acknowledgment that "middleboxes that only > >> support TCP and UDP are not rare", but then the next sentence > >> recommends the use of several other protocols besides UDP and TCP. If > >> I put these two together, the only congested controlled protocol that > >> is recommended and expected to work on the Internet is TCP. > >> > >> +1 TCP (implemented in kernel space) can't possibly evolve congestion > avoidance as fast as the Internet has changed, or will change (example: > good handling of middle boxes that use "policers" rather than some flavor > of buffer-size based packet-drop). > >> The rationale for using UDP for QUIC was indeed that a new IP number > would never make it through the Internet (other protocol deployment > attempts have commonly verified this). It turns out that even UDP is > partially blocked (as recently as 2011) by paths to 5-7% of all chrome > clients, which lead to the "automated fallback" elements of QUIC, > >> > > > > I think this changes with ipv6, no? Google sees over 26% ipv6 in the > usa and growing quickly > > > > http://www.google.com/intl/en/ipv6/statistics.html > > > > And there is evidence that middle boxes go away in ipv6. .... So perhaps > the world is changing and your assuptions do not hold > > (dropping ietf@, saving my Narten points since we're a bit off topic on > the draft last call) > > I'd like to see evidence, if you can share it. > > " Verizon uses transparent proxy servers on IPv4 but not on IPv6" https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html We've done a few measurements with Atlas that suggest the brokenness on v6 > is different, but not necessarily better, but don't have enough data points > to make an informed statement on the fact. Any time you touch a NAPT (which > lives at the core of any transition technology for v6-only access to the v4 > Internet), you run into the "only TCP and UDP have ports" fallacy. But yes, > we need to compare and contrast v4 and v6 access network impairments for > non-(6,17) protocol numbers. > > NAPT is an edge case for v6 users, less than 30% and shrinking by bit volume as the whales have moved to v6 already https://blogs.akamai.com/2016/06/four-years-since-world-ipv6-launch-entering-the-mainstream.html > Cheers, > > Brian > --001a114b322ac81c71053508f333 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, June 8, 2016, Brian Trammell <ietf@trammell.ch> wrote:
>
>> On 08 Jun 2016, at 14:20, Ca By <cb.list6@gma= il.com> wrote:
>>
>>
>>
>> On Sunday, June 5, 2016, Jim Roskind <JimRo= skind@gmail.com> wrote:
>>
>>
>> On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert <tom@herbertland.com> wrote:
>> On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell <ietf@trammell.ch> wrote:
>> > Greetings, all,
>> >
>> > Apologies for the late last call comment; I have only one, re= latively minor. I hope it's still useful.
>> >
>> > I understand that Section 3 was written to encourage applicat= ion developers not to roll their own transports ("trust us when we say= this is hard, this document is a list of reasons why") but as written= it would seem to discourage transport innovation atop UDP (e.g. QUIC, the = RTCWEB data channel, anything-over-PLUS), which I very much hope was not th= e intent. The problematic recommendation is in the second paragraph:
>> >
>> >=C2=A0 =C2=A0 These mechanisms are difficult to implement corr= ectly.=C2=A0 For most
>> >=C2=A0 =C2=A0 applications, the use of one of the existing IET= F transport protocols
>> >=C2=A0 =C2=A0 is the simplest method of acquiring the required= mechanisms.=C2=A0 Doing
>> >=C2=A0 =C2=A0 so also avoids issues that protocols using a new= IP protocol number
>> >=C2=A0 =C2=A0 face when being deployed over the Internet, wher= e middleboxes that
>> >=C2=A0 =C2=A0 only support TCP and UDP are not rare.=C2=A0 Con= sequently, the RECOMMENDED
>> >=C2=A0 =C2=A0 alternative to the UDP usage described in the re= mainder of this
>> >=C2=A0 =C2=A0 section is the use of an IETF transport protocol= such as TCP
>> >=C2=A0 =C2=A0 [RFC0793], Stream Control Transmission Protocol = (SCTP) [RFC4960], and
>> >=C2=A0 =C2=A0 SCTP Partial Reliability Extension (SCTP-PR) [RF= C3758], or Datagram
>> >=C2=A0 =C2=A0 Congestion Control Protocol (DCCP) [RFC4340] wit= h its different
>> >=C2=A0 =C2=A0 congestion control types [RFC4341][RFC4342][RFC5= 622].
>> >
>> > First, this paragraph ignores potential deployment issues wit= h any of these other than TCP, which risks seeming out of touch, but this i= s a minor point and probably not worth a late edit. Second, I'm concern= ed this recommendation could be taken as broader than intended, against the= definition of any new transport protocol encapsulated within UDP that perf= orms substantially the same function as the listed protocols.
>> >
>> I would agree, this paragraph also seems a little self
>> contradictory.There is an acknowledgment that "middleboxes th= at only
>> support TCP and UDP are not rare", but then the next sentence=
>> recommends the use of several other protocols besides UDP and TCP.= If
>> I put these two together, the only congested controlled protocol t= hat
>> is recommended and expected to work on the Internet is TCP.
>>
>> +1=C2=A0 =C2=A0TCP (implemented in kernel space) can't possibl= y evolve congestion avoidance as fast as the Internet has changed, or will = change (example: good handling of middle boxes that use "policers"= ; rather than some flavor of buffer-size based packet-drop).
>> The rationale for using UDP for QUIC was indeed that a new IP numb= er would never make it through the Internet (other protocol deployment atte= mpts have commonly verified this).=C2=A0 It turns out that even UDP is part= ially blocked (as recently as 2011) by paths to 5-7% of all chrome clients,= which lead to the "automated fallback" elements of QUIC,
>>
>
> I think this changes with ipv6, no?=C2=A0 Google sees over 26% ipv6 in= the usa and growing quickly
>
> http://www.google.com/intl/en/ipv6/statistics.html
>
> And there is evidence that middle boxes go away in ipv6. .... So perha= ps the world is changing and your assuptions do not hold

(dropping ietf@, saving my Narten points since we're a bit off topic on= the draft last call)

I'd like to see evidence, if you can share it.


"=C2=A0Verizon uses transparent proxy = servers on IPv4 but not on IPv6"

=
=
=

We've done a few measurements with Atlas that suggest the brokenness on= v6 is different, but not necessarily better, but don't have enough dat= a points to make an informed statement on the fact. Any time you touch a NA= PT (which lives at the core of any transition technology for v6-only access= to the v4 Internet), you run into the "only TCP and UDP have ports&qu= ot; fallacy. But yes, we need to compare and contrast v4 and v6 access netw= ork impairments for non-(6,17) protocol numbers.


NAPT is an edge case for v6 users, les= s than 30% and shrinking by bit volume as the whales have moved to v6 alrea= dy


=C2=A0
Cheers,

Brian
--001a114b322ac81c71053508f333-- From nobody Mon Jun 13 01:32:01 2016 Return-Path: X-Original-To: spud@ietf.org Delivered-To: spud@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B9E12D0DD; Mon, 13 Jun 2016 01:32:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613083200.12414.89497.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 01:32:00 -0700 Archived-At: Cc: spud@ietf.org, ietf@kuehlewind.net, spencerdawkins.ietf@gmail.com, plus-chairs@ietf.org Subject: [Spud] plus - Update to a Meeting Session Request for IETF 96 X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 08:32:01 -0000 An update to a meeting session request has just been submitted by Mirja Kuehlewind, a TSV Area Director. --------------------------------------------------------- Working Group Name: Path Layer UDP Substrate Area Name: Transport Area Session Requester: Mirja Kühlewind Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: tsvarea saag tls rtcweb dispatch tsvwg iccrg tcpm tcpinc mptcp taps lurk uta quic l4s maprg rmcat Special Requests: If possible, please schedule after QUIC BOF --------------------------------------------------------- From nobody Mon Jun 13 08:21:33 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9716612D800 for ; Mon, 13 Jun 2016 08:21:32 -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 2tTKRj5NhJEF for ; Mon, 13 Jun 2016 08:21:31 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29BD112D7F9 for ; Mon, 13 Jun 2016 08:21:31 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-52-575ecf79274b Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FB.33.12926.97FCE575; Mon, 13 Jun 2016 17:21:29 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.158]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0294.000; Mon, 13 Jun 2016 17:21:28 +0200 From: Szilveszter Nadas To: Brian Trammell , Joe Touch Thread-Topic: [Spud] updated draft PLUS charter, rev. 1 June Thread-Index: AQHRu/KkcInCrLyS7Uapq4/J4k4pzp/eLegAgAABG4CAAB43AIAABfgAgAADLQCAABjYgIAABqUAgAACJQCAAAEtgIAAAqWAgAAEkgCAAGJBAIAAZ68AgADDP4CAAK+3gIAG2Ogg Date: Mon, 13 Jun 2016 15:21:27 +0000 Message-ID: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> In-Reply-To: <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7nG7l+bhwg48nZC02trxjs1h04Smj xbo/c1kcmD2WLPnJ5LH7/VYWjyf7Z7IEMEdx2aSk5mSWpRbp2yVwZbQ3vGAuWM5ccfNKK0sD 4zGmLkZODgkBE4m7H5ezQthiEhfurWfrYuTiEBI4wijROqeFBSQhJLCEUeJdszqIzSZgIdGw cjMbiC0i4CCx8fB8ZhCbWUBCYtGkT2BDhQWsJdp3fGOHqLGR+N/dwQQyVERgGqPE88UtYM0s AqoSZxYdBmvmFfCVeN/1iwVi80s2iW2Tj4EVcQrYS7x4O40RxGYEOu/7qTVMENvEJW49mQ/1 goDEkj3nmSFsUYmXj/9BvaMosfNsO9R1OhILdn9ig7C1JZYtfA21WFDi5MwnLBMYxWYhGTsL ScssJC2zkLQsYGRZxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYVwe3/FbdwXj5jeMhRgEO RiUe3oTbseFCrIllxZW5hxglOJiVRHi1T8SFC/GmJFZWpRblxxeV5qQWH2KU5mBREuf1f6kY LiSQnliSmp2aWpBaBJNl4uCUamAUrZ33TkiW+6yWioWXjb33vz/lu6Q3v5m4p6D7y8Hf87Z3 7vvdkPTl9546sbOKx3WDN14zeTOlLSPcls2iruGcW8p6UevvBg8WtO7YxlPnssPTfqfC1eW/ J872PS429wmj94Fm11UVd3/vWfvkT/2NrOM5n8T9BLa+WezxWcWpOHTR041+8S0tSizFGYmG WsxFxYkAnzoGdKcCAAA= Archived-At: Cc: spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 15:21:32 -0000 Hi, =20 > It would be useful if whatever comes out of an eventual PLUS working grou= p > could be implemented either over UDP or IPv6 EH, since the lack of access= to > EH problem is simply a matter of changing APIs. But I'm not convinced tha= t's a > hard requirement. Is a separate protocol number for SPUD also an option? Then the happy eyeba= ll mechanism used could also consider that. Cheers, Sz. From nobody Mon Jun 13 08:47: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 16A6E12D839 for ; Mon, 13 Jun 2016 08:47:21 -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=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 k7lmgimNxCJr for ; Mon, 13 Jun 2016 08:47:20 -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 AC89812D81D for ; Mon, 13 Jun 2016 08:38:55 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-d4-575ed38dc04d Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A5.F2.27088.D83DE575; Mon, 13 Jun 2016 17:38:54 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.158]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0294.000; Mon, 13 Jun 2016 17:38:50 +0200 From: Szilveszter Nadas To: Tom Herbert , Brian Trammell Thread-Topic: [Spud] updated draft PLUS charter, rev. 1 June Thread-Index: AQHRu/KkcInCrLyS7Uapq4/J4k4pzp/eLegAgAABG4CAAB43AIAABfgAgAADLQCAABjYgIAABqUAgAACJQCAAAEtgIAAAqWAgAAEkgCAAGJBAIAAZ68AgAHaSoCABnU6cA== Date: Mon, 13 Jun 2016 15:38:50 +0000 Message-ID: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> 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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7sW7f5bhwg7vRFhtb3rFZLLrwlNHi 8qVHzA7MHr1zp7F6LFnyk8njyf6ZLAHMUVw2Kak5mWWpRfp2CVwZE5dwFhxjrnjVtpSxgfE1 UxcjJ4eEgInEh3tLmCFsMYkL99azgdhCAkcYJaZ/lYWwlzBK3H3hAGKzCVhINKzcDFYjIuAh MXH/YVYQm1lAQmLRpE9gM4UFrCXad3xjh6ixkfjf3QEU5wKyJzFKvLz1FKyZRUBV4tbSR2BF vAK+EvdPHGUFKRISeMAmsX3CErAiToFAiVWr/oNdxwh03fdTa5ggtolL3HoyH+oDAYkle85D fSAq8fLxP1YIW1Fi59l2Zoh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjGKzkIydhaRlFpKW WUhaFjCyrGIULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIjKiDW34b7GB8+dzxEKMAB6MSD2/C 7dhwIdbEsuLK3EOMEhzMSiK80y7GhQvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5Y kpqdmlqQWgSTZeLglGpg7HwqKrLv/vnLnfEn12l+Fr8f9tzs368/m16lmEx7crrY6P7Binud fpNPm9952iew38+reV7wpJt7JreE3LQUV084mrnu57qwn6cMFoqumfVVZteNyNUv7lVfUlVr O3mhKfBbAjeD1/RV6/PZr0pMW9c787v6+ki24qeXN77XWHGpNcHiXPafaTOVWIozEg21mIuK EwEr8R4QpAIAAA== Archived-At: Cc: spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 15:47:21 -0000 Hi, On the topics of what is included and what not. The PLUS protocol kind of r= eminds me of this paper "Breaking Up the Transport Logjam" http://bford.inf= o/pub/net/logjam.pdf . Though the "Flow Regulation Layer" in the paper can = be used for much more than PLUS. Does PLUS intends to be extensible to impl= ement/aid things like this in the far future or do things like this belong = to different part of the stack? Cheers, Szilveszter From nobody Mon Jun 13 08:47: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 EECE212D549 for ; Mon, 13 Jun 2016 08:47:35 -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 q7vzLLviJBXs for ; Mon, 13 Jun 2016 08:47:35 -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 40C4612D193 for ; Mon, 13 Jun 2016 08:47:35 -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 boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5DFkoJI013747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Jun 2016 08:46:51 -0700 (PDT) To: Brian Trammell , Christian Huitema References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> <780953BA-CE7B-4B17-AB9A-27324246FB86@tra mmell.ch> <0216496B-9083-49B1-8778-AA150DEE8392@trammell.ch> From: Joe Touch Message-ID: <575ED56A.1000009@isi.edu> Date: Mon, 13 Jun 2016 08:46:50 -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: <0216496B-9083-49B1-8778-AA150DEE8392@trammell.ch> 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] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 15:47:36 -0000 On 6/11/2016 4:49 AM, Brian Trammell wrote: >> I think Tom has a good point here. PLUS does introduce new communication patterns, passing information to intermediate routers and expecting routers to act on the information. These communication patterns can very well introduce new attack vectors. We actually discussed a few of those on the list some time back. For example, an attacker could inject a packet that mimics the closure of a flow, and cause intermediate firewalls to close the holes open for that flow. > Except this isn't really a new attack vector; Not a new type, but it would be a new instance. > there's no real difference between this and a FIN/RST injection in TCP, except we get a chance to make the space the attacker has to successfully guess in larger. It would be very useful to be clear about your threat model before assuming a given solution. E.g., no increase in number space will prevent middlebox FIN/RST manipulation of endpoint associations ("connections"). Joe From nobody Mon Jun 13 10:34:01 2016 Return-Path: X-Original-To: spud@ietf.org Delivered-To: spud@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 792A112D8CD; Mon, 13 Jun 2016 10:33:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613173359.6824.38880.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 10:33:59 -0700 Archived-At: Cc: cmorgan@amsl.com, spencerdawkins.ietf@gmail.com, spud@ietf.org, plus-chairs@ietf.org Subject: [Spud] plus - Update to a Meeting Session Request for IETF 96 X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:33:59 -0000 An update to a meeting session request has just been submitted by Cindy Morgan, on behalf of the plus working group. --------------------------------------------------------- Working Group Name: Path Layer UDP Substrate Area Name: Transport Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: rmcat maprg l4s quic uta lurk taps mptcp tcpinc tcpm iccrg tsvwg dispatch rtcweb tls saag tsvarea Special Requests: If possible, please schedule after QUIC BOF --------------------------------------------------------- From nobody Tue Jun 14 05:45: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 F003E12DB97 for ; Tue, 14 Jun 2016 05:45:41 -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 HXiEuuWm_sMP for ; Tue, 14 Jun 2016 05:45:36 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 15B8312D62F for ; Tue, 14 Jun 2016 05:45:36 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id r5so22173950wmr.0 for ; Tue, 14 Jun 2016 05:45:35 -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=gRup0uQKB7oME15cHCpsd0nXXzHwvpl8AXcdHc9M7UY=; b=c7PZdWtzCNRLyR8bXkNGuyO2oAjb5/asUqcuYdwogq8eKwaj95S7Hp4wEMOY6fWCnA Y5ow7czE7xmxXsOZemBEMxb6bVk5k8jxpFCCMr/X02gsGtBynxJEUo4rViNNu+63JmF/ S1e056yLhtmaV5HNH81YjydKpAn130IVEAFbZLIY+20Nrwo678BUd/ksIHxZGQCq602H jKPf/7jQ2qxsPj2sMSQ0LIGy7rMunLVZqYfIFlC5IvzUh4WlVyFNxgzlSuE+3dZ89wCg 5Ag+VUSPxmjwWZpuizJIcLHSWDEXhj2Cc6pHFUP5E/N4RJfxPgJZgizVmZz7Vv+SgMFG /e6Q== 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=gRup0uQKB7oME15cHCpsd0nXXzHwvpl8AXcdHc9M7UY=; b=EhFFEE3pHqwRlcedOl4oBRK/tAt5cG3Bx80UQ3qHH1AxAWMZE6CnhIp+4dvBZhgY5v um86IJ5MoomOYHaY+rrHiSqK26AuLTAtuqVb9rs06vWOOAN7BNlhbXyuDIkt6aFBdT8F c8k1aTGW7HZYFStej5O4KQlc4Ncn0esI2BXa65+KQBy0dfVOaZwATjV0oZCoohHyotsE 8rSOeIKVumO+3Gx0LglbF/zcLvjl5RRguXv3a2i8cpyxLTmjpgQtQAOTOXDKScqAbNLU nBFshcRev4TXGu8EVQmZufmNcpTikP+yI5jibtiFU68PV29LxOcw7sbSe4oYVwmpl/xA gVqQ== X-Gm-Message-State: ALyK8tI5abkaQG57nZA2vS+gpkHfaFlBvs/BpW6/7VXZMdQg9PelQufg1u/NgyKyQ7NAgJPCNUbjBBNfeTL/MA== MIME-Version: 1.0 X-Received: by 10.28.25.129 with SMTP id 123mr4701529wmz.10.1465908334619; Tue, 14 Jun 2016 05:45:34 -0700 (PDT) Received: by 10.28.234.13 with HTTP; Tue, 14 Jun 2016 05:45:34 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> Date: Tue, 14 Jun 2016 05:45:34 -0700 Message-ID: From: Ca By To: Szilveszter Nadas Content-Type: multipart/alternative; boundary=001a114d3cee8ef56805353c615b Archived-At: Cc: Brian Trammell , spud , Joe Touch Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 12:45:42 -0000 --001a114d3cee8ef56805353c615b Content-Type: text/plain; charset=UTF-8 On Monday, June 13, 2016, Szilveszter Nadas wrote: > Hi, > > > > It would be useful if whatever comes out of an eventual PLUS working > group > > could be implemented either over UDP or IPv6 EH, since the lack of > access to > > EH problem is simply a matter of changing APIs. But I'm not convinced > that's a > > hard requirement. > > Is a separate protocol number for SPUD also an option? Then the happy > eyeball mechanism used could also consider that. > > Cheers, > Sz. > > All my concerns with spud and quic would be solved by using a new protocol number since it would allow for the network to, at scale, identify good spud/quic traffic from the known bad udp ddos mess This network operator concern has been repeatedly ignored since it is easier to access udp in userspace. This conflict will not end well if not addressed _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --001a114d3cee8ef56805353c615b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, June 13, 2016, Szilveszter Nadas <Szilveszter.Nadas@ericsson.com> wrote= :
Hi,


> It would be useful if whatever comes out of an eventual PLUS working g= roup
> could be implemented either over UDP or IPv6 EH, since the lack of acc= ess to
> EH problem is simply a matter of changing APIs. But I'm not convin= ced that's a
> hard requirement.

Is a separate protocol number for SPUD also an option? Then the happy eyeba= ll mechanism used could also consider that.

Cheers,
Sz.


All my concerns with spud and quic wou= ld be solved by using a new protocol number since it would allow for the ne= twork to, at scale, identify good spud/quic traffic from the known bad=C2= =A0=C2=A0udp ddos mess

This network operator=C2=A0conce= rn has been repeatedly ignored since it is=C2=A0easier to access udp in use= rspace.=C2=A0

This conflict will not end well if not add= ressed=C2=A0

_______________________________________________
Spud mailing list
Spud@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/spud
--001a114d3cee8ef56805353c615b-- From nobody Tue Jun 14 07:50: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 4B10112DBD0 for ; Tue, 14 Jun 2016 07:50:40 -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 1VOBxfBfORCF for ; Tue, 14 Jun 2016 07:50:37 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFFF12DBCC for ; Tue, 14 Jun 2016 07:50:36 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-54-576019ba4d0f Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 63.A3.12516.AB910675; Tue, 14 Jun 2016 16:50:34 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.158]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0294.000; Tue, 14 Jun 2016 16:50:34 +0200 From: Szilveszter Nadas To: Brian Trammell Thread-Topic: [Spud] updated draft PLUS charter, rev. 1 June Thread-Index: AQHRu/KkcInCrLyS7Uapq4/J4k4pzp/eLegAgAABG4CAAB43AIAABfgAgAADLQCAABjYgIAABqUAgAACJQCAAAEtgIAAAqWAgAAEkgCAAGJBAIAAZ68AgADDP4CAAK+3gIAG2OgggAFmuQCAACHMUA== Date: Tue, 14 Jun 2016 14:50:33 +0000 Message-ID: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> <273B68FC-7E86-4F5B-85BF-EA5F01AED2B0@trammell.ch> In-Reply-To: <273B68FC-7E86-4F5B-85BF-EA5F01AED2B0@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7se4uyYRwg0sXzCw2trxjs1h04Smj xbo/c1kcmD2WLPnJ5LH7/VYWjyf7Z7IEMEdx2aSk5mSWpRbp2yVwZdx9/pelYINwxdyZL1ga GJfydzFyckgImEi0PfvOAmGLSVy4t56ti5GLQ0jgCKPElinHmEESQgJLGCVef88DsdkELCQa Vm5mA7FFBFQluhsvsYPYzALGEo8nTQOrFxawlmjf8Y0dosZG4n93BxOEvYxR4sBNLRCbBaj3 0ZK1YDW8Ar4SE++2MEEsfsIucen6JLAFnAL2EpOutIM1MwJd9/3UGiaIZeISt57MZ4K4WkBi yZ7zzBC2qMTLx/9YIWwliR8bLrFA1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7Cwk LbOQtMxC0rKAkWUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmBUHdzyW3cH4+rXjocYBTgY lXh4H+jEhwuxJpYVV+YeYpTgYFYS4Z0rmhAuxJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4 kEB6YklqdmpqQWoRTJaJg1OqgXHlpdyKleXdWpv2cfxf6/l9Yn6V3zpvwWDlJR2P7a6xLhNV XHAl5ibXgaoFdaHn3v9P/Z9XzPhWQGLWvGu/urf+TTWYnhobtL9xa0ncj6/3C4sC/ti+Y1Kt fvzk79qd19kv1Lct2ZZ/tb+3+/hWxppN2skT3mzOXrXc28085p7l2vN5LqeyXDYrsRRnJBpq MRcVJwIATnMNWaYCAAA= Archived-At: Cc: spud , Joe Touch Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 14:50:40 -0000 Hi, I was probably mis-using the term happy eyeballs. I meant that whatever mec= hanism selecting how SPUD is used may also consider and try the separate pr= otocol number option before falling back to e.g. UDP. I agree that separate protocol number is not deployable in itself. Whether = it is at all practical now and in the foreseeable future, I am not sure, it= might be worth a consideration. Some data on this (similarly that for UDP = and IPv6 extension header) might help.=20 Summarizing, I see it as something to consider during the design, and defin= itely not the mainstream solution in the short run.=20 Cheers, Sz. > -----Original Message----- > From: Brian Trammell [mailto:ietf@trammell.ch] > Sent: Tuesday, June 14, 2016 16:44 > To: Szilveszter Nadas > Cc: Joe Touch; spud > Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June >=20 >=20 > > On 13 Jun 2016, at 17:21, Szilveszter Nadas > wrote: > > > > Hi, > > > > > >> It would be useful if whatever comes out of an eventual PLUS working > >> group could be implemented either over UDP or IPv6 EH, since the lack > >> of access to EH problem is simply a matter of changing APIs. But I'm > >> not convinced that's a hard requirement. > > > > Is a separate protocol number for SPUD also an option? >=20 >=20 > It doesn't seem to me that using an alternate protocol number for PLUS (o= r > QUIC) actually meets the requirements of either effort. One is the abilit= y to run > on unmodified kernels, which is a somewhat bigger deal for QUIC than for > PLUS. Another is middlebox transparency, where experience with SCTP has n= ot > been great. True, we don't have a lot of data here; on our list of path > transparency measurements to run at ETH is "UDP/TCP with mangled protocol > number"; I suspect that NAPT breaks in the overwhelming majority of cases > here.=09 >=20 > In a world in which every kernel is relatively quickly updatable, NAPT is > irrelevant, and other middlebox brokenness negligent, alternate protocol > numbers are an option. We are somewhat closer to that world, I think, tha= n > we were a decade ago. But I don't think we live in it yet. >=20 > > Then the happy eyeball mechanism used could also consider that. >=20 > I'm not sure how the protocol number is relevant to happy eyeballs... can= you > expand on this a bit? >=20 > Cheers, >=20 > Brian >=20 > > Cheers, > > Sz. From nobody Tue Jun 14 07:52: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 6E99512D78A for ; Tue, 14 Jun 2016 07:52:21 -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=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 3RbV0QMjfAHw for ; Tue, 14 Jun 2016 07:52:20 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 61F4F12D7AD for ; Tue, 14 Jun 2016 07:43:57 -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 52BCB1A0106; Tue, 14 Jun 2016 16:43:55 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5B1BC5B8-1887-47F1-96BC-0CA7448F05A4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Tue, 14 Jun 2016 16:43:54 +0200 Message-Id: <273B68FC-7E86-4F5B-85BF-EA5F01AED2B0@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> To: Szilveszter Nadas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spud , Joe Touch Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 14:52:21 -0000 --Apple-Mail=_5B1BC5B8-1887-47F1-96BC-0CA7448F05A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13 Jun 2016, at 17:21, Szilveszter Nadas = wrote: >=20 > Hi, >=20 >=20 >> It would be useful if whatever comes out of an eventual PLUS working = group >> could be implemented either over UDP or IPv6 EH, since the lack of = access to >> EH problem is simply a matter of changing APIs. But I'm not convinced = that's a >> hard requirement. >=20 > Is a separate protocol number for SPUD also an option? It doesn't seem to me that using an alternate protocol number for PLUS = (or QUIC) actually meets the requirements of either effort. One is the = ability to run on unmodified kernels, which is a somewhat bigger deal = for QUIC than for PLUS. Another is middlebox transparency, where = experience with SCTP has not been great. True, we don't have a lot of = data here; on our list of path transparency measurements to run at ETH = is "UDP/TCP with mangled protocol number"; I suspect that NAPT breaks in = the overwhelming majority of cases here. In a world in which every kernel is relatively quickly updatable, NAPT = is irrelevant, and other middlebox brokenness negligent, alternate = protocol numbers are an option. We are somewhat closer to that world, I = think, than we were a decade ago. But I don't think we live in it yet. > Then the happy eyeball mechanism used could also consider that. I'm not sure how the protocol number is relevant to happy eyeballs... = can you expand on this a bit? Cheers, Brian > Cheers, > Sz. --Apple-Mail=_5B1BC5B8-1887-47F1-96BC-0CA7448F05A4 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 iQIcBAEBCgAGBQJXYBgrAAoJEIoSt78L6kajMukP/jyOTwaIx+bgfQg76AlHk2OP odvyE3q50yZOJWW8mTxhgjgrRItfSyK1bC7Y/n8gtEHrNVuvk8FfIChtUFvCmmhD hNE5wR9sYG+0Dqi4aQn143NT1LrbaaNRPfch3m1Kecd761Lvoi7c0FeucKKG5BVi IeIFJn8lpRw0lKtJkV5klvnZwVy5AfwGxRQH+viDqzSvpG24CVTRtbxdK+eX2Ev/ iMVAt3oSBGSeCz0BLfbP+ooC9aZUBOsGj1CRypMrZPourYHDDEt7GYTUGeWK+X5C xel+lYda7aaVZqy6wXQzEXtxflJ5wLaAmSGF+4D6Gh3ixoGI4qmkylwGXd8QVJAh Pdpo64VD1RHRG1itckJj0Eilqu3Nx/B2+g4zuITTPiSEhfRGh+wtd5cW5TOk88a7 K84PHOtFLnlpyzhiZVWiPfC5DjO5TYjlxI5g0HGVRqMdCCfg3UORykpJhlXRsicY gEv4rikpoPwG8aoL1UNZJc99GuzqsEq5+P9cO+kcZJKhresstUjROgy8Qu6yy1Qz svsXh2s55aBO5FpF8UkOO1eSvr/Z00txJSFvi9qCxwdX1F/H5HdRnNF4IORlfTcO iBn3R+fsRS5sdgBwhrobKnASIxJm7A74Yk5zKEMyFEfXhMlQM03kdBuh4ZKbeNGJ jj+8zyrplvjuOS0VubVO =A8K9 -----END PGP SIGNATURE----- --Apple-Mail=_5B1BC5B8-1887-47F1-96BC-0CA7448F05A4-- From nobody Tue Jun 14 07:58: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 A2CC612D7BF for ; Tue, 14 Jun 2016 07:57:59 -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 R_RqfOojTh-g for ; Tue, 14 Jun 2016 07:57:57 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 86F4B12D7AD for ; Tue, 14 Jun 2016 07:57:57 -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 EA0B21A0F1F; Tue, 14 Jun 2016 16:57:56 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F2016C4D-5464-4318-AA3F-110A6A735BA2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <575ED56A.1000009@isi.edu> Date: Tue, 14 Jun 2016 16:57:56 +0200 Message-Id: <248D5235-3D59-4071-9F81-A72C252AF6DB@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> <780953BA-CE7B-4B17-AB9A-27324246FB86@tra mmell.ch> <0216496B-9083-49B1-8778-AA150DEE8392@trammell.ch> <575ED56A.1000009@isi.edu > To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Christian Huitema , spud , Tom Herbert Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 14:57:59 -0000 --Apple-Mail=_F2016C4D-5464-4318-AA3F-110A6A735BA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13 Jun 2016, at 17:46, Joe Touch wrote: >=20 >=20 >=20 > On 6/11/2016 4:49 AM, Brian Trammell wrote: >>> I think Tom has a good point here. PLUS does introduce new = communication patterns, passing information to intermediate routers and = expecting routers to act on the information. These communication = patterns can very well introduce new attack vectors. We actually = discussed a few of those on the list some time back. For example, an = attacker could inject a packet that mimics the closure of a flow, and = cause intermediate firewalls to close the holes open for that flow. >> Except this isn't really a new attack vector; >=20 > Not a new type, but it would be a new instance. >=20 >> there's no real difference between this and a FIN/RST injection in = TCP, except we get a chance to make the space the attacker has to = successfully guess in larger. > It would be very useful to be clear about your threat model before > assuming a given solution. >=20 > E.g., no increase in number space will prevent middlebox FIN/RST > manipulation of endpoint associations ("connections"). True, but defending against endpoint state manipulation by a box on = path, in the present deployed Internet in which at least = endpoint-to-endpoint flows are always identified by a five-tuple, = wherein said box can always simply drop packets identified by said = five-tuple, is not very useful. The best you can do is detect it = happened. At least an RST-injecting on-path device is nice enough to = tell you it's killing your flow. In the case of a PLUS-encapsulated, encrypted transport, the flow state = bits would presumably be integrity-protected against change, using a MAC = that could only be generated by the sender, so a receiving endpoint = could certainly detect that the flow state bits were manipulated, or = that the packet was forged. But just as today, it couldn't detect that = the middlebox decided simply to start dropping all the packets (or = rather, differentiate that state from some other link failure). You're correct that the number-space defense is primarily useful against = off-path attacks, which are more useful to defend against than on-path = ones; indeed, if [1] is to be believed (which I tend to think it is), = this is still very much a problem in TCP as deployed. Cheers, Brian [1] Luckie et al "Resilience of Deployed TCP to Blind Attacks" = http://conferences.sigcomm.org/imc/2015/papers/p13.pdf > Joe >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_F2016C4D-5464-4318-AA3F-110A6A735BA2 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 iQIcBAEBCgAGBQJXYBt0AAoJEIoSt78L6kaj2EwQAILA3KWe3eGvK1h/2ELYd+wL o0rxqbmCrbXNUB3jWYILLDqERxkkX96lyZ7jgC8Cyc+S5Ko1px2VcvkhzJG04WWS v5RmC+xfAoNrrLVQDcMcxeSYbRWGh+avt1NolYROkttYc5gD9lWHBlxn3ZVKZLx/ 2I5z2hNncnIfH2d/GJnN6L/Qydvzd2puLyqT12bRC6p+yfsxZKpCE37E/i1sOAU6 Q5IO9ETsLhPufzHsRLykkt8pL35ULTG4R0Wrnklo/pHQ7x/dAy0zSrGrSMNsThi5 5CH7fvQaPdBfjjI3ypuWd9Lyxgn/Fdnuh4RJt0PD96AWSlULjkC/fu71Y8FHh8x8 +sf03hgc+bocECZGg3uBnROyRNgqinmx4pDVpHJtV3MNaRwZ3xMMCFVTXSlwhRbb EZrvhxALUrZuJqCoAoN/HiQpMd1GrKXQglg2iQWh+DBDf+Prs8D68xdP8DbKZaN4 bG1gFm2E/MtEEKPjpEJy8ppv4jP+JW13+cdgq/OZiEZ64HD9KeQcaJxaTrvtJ/Hf 8NIg0tVZEB1NWahCW864tmqSTNd2gI/4Q9F6jBuHTYLwa4AoDiHbm5qNEnAcsU+v SAD/m0xhESlhAJ7jGUMos5wCJd+5VPyO23FVICtmR2GTalAironWyl+FbVU/RAwd h0m16lLvR6EJ8wMp6F68 =XE1y -----END PGP SIGNATURE----- --Apple-Mail=_F2016C4D-5464-4318-AA3F-110A6A735BA2-- From nobody Tue Jun 14 07:59:56 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 A17F712D7AD for ; Tue, 14 Jun 2016 07:59:54 -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 sdqYSdlj7DyZ for ; Tue, 14 Jun 2016 07:59:52 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE9012D534 for ; Tue, 14 Jun 2016 07:59:52 -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 F0F971A0F1F; Tue, 14 Jun 2016 16:59:21 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_ECE093E0-C672-419D-A963-0BA28B49CD5F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Tue, 14 Jun 2016 16:59:21 +0200 Message-Id: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> <273B68FC-7E86-4F5B-85BF-EA5F01AED2B0@trammell.ch> To: Szilveszter Nadas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Joe Touch , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 14:59:55 -0000 --Apple-Mail=_ECE093E0-C672-419D-A963-0BA28B49CD5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Szilveszter, > On 14 Jun 2016, at 16:50, Szilveszter Nadas = wrote: >=20 > Hi, >=20 > I was probably mis-using the term happy eyeballs. I meant that = whatever mechanism selecting how SPUD is used may also consider and try = the separate protocol number option before falling back to e.g. UDP. >=20 > I agree that separate protocol number is not deployable in itself. = Whether it is at all practical now and in the foreseeable future, I am = not sure, it might be worth a consideration. Some data on this = (similarly that for UDP and IPv6 extension header) might help. >=20 > Summarizing, I see it as something to consider during the design, and = definitely not the mainstream solution in the short run. I'd tend to say that designing PLUS such that it can never run over a = protocol number than 17 would be a mistake, yes. But in the short term = it's the only thing I see that has a chance to deploy. Cheers, Brian >=20 > Cheers, > Sz. >=20 >> -----Original Message----- >> From: Brian Trammell [mailto:ietf@trammell.ch] >> Sent: Tuesday, June 14, 2016 16:44 >> To: Szilveszter Nadas >> Cc: Joe Touch; spud >> Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June >>=20 >>=20 >>> On 13 Jun 2016, at 17:21, Szilveszter Nadas >> wrote: >>>=20 >>> Hi, >>>=20 >>>=20 >>>> It would be useful if whatever comes out of an eventual PLUS = working >>>> group could be implemented either over UDP or IPv6 EH, since the = lack >>>> of access to EH problem is simply a matter of changing APIs. But = I'm >>>> not convinced that's a hard requirement. >>>=20 >>> Is a separate protocol number for SPUD also an option? >>=20 >>=20 >> It doesn't seem to me that using an alternate protocol number for = PLUS (or >> QUIC) actually meets the requirements of either effort. One is the = ability to run >> on unmodified kernels, which is a somewhat bigger deal for QUIC than = for >> PLUS. Another is middlebox transparency, where experience with SCTP = has not >> been great. True, we don't have a lot of data here; on our list of = path >> transparency measurements to run at ETH is "UDP/TCP with mangled = protocol >> number"; I suspect that NAPT breaks in the overwhelming majority of = cases >> here. >>=20 >> In a world in which every kernel is relatively quickly updatable, = NAPT is >> irrelevant, and other middlebox brokenness negligent, alternate = protocol >> numbers are an option. We are somewhat closer to that world, I think, = than >> we were a decade ago. But I don't think we live in it yet. >>=20 >>> Then the happy eyeball mechanism used could also consider that. >>=20 >> I'm not sure how the protocol number is relevant to happy eyeballs... = can you >> expand on this a bit? >>=20 >> Cheers, >>=20 >> Brian >>=20 >>> Cheers, >>> Sz. >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_ECE093E0-C672-419D-A963-0BA28B49CD5F 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 iQIcBAEBCgAGBQJXYBvJAAoJEIoSt78L6kajRvkP/R0c6W1WIvDi8SHjwWuuHXxu g+/AoHkogMlTDpSDWg8AwNEyD5c/L1/X2RDLEzjIPbmGl/7amPVxDBkDVQ6SXbco vlxLoxmk6apzQEek79FVhAHEHf15OOJ0SG8OeJrElDoPAwhUgNm3tqCLSNkf77yQ jCW7W8Rr8mIwImH/ebicoDJCKWMp9Ih5lsO3dV3IRqVQHR+Wl/pNiK34kmpmI9Jq nxsaOl4KqywmhoxMsee1YomYdTp0j7UK6LDhGJxpVTzvfjouKz20xXmgGHsq76ck 3po1jHsyo68VHJyZIdN694M82EgfgyolfO54wMG64J/j7HbHwXIVEjBHldxXx95s krczg0LrvQZK68c1OouiMw2H+WEQSXWlS96NaHPbcIb7Pn/ZUBtv2IAprbai1tq+ FWvihzqVdm/YPs/JRYInRIPsT3At2a77tz5w5ysgzft4WJZMMDh4LXadoTuHMlvv yxzsP6xI//0YLO9d83X9DA3Ccvx1Tvmjm67iSuenbvgfkqdGZoz3pyefAlE6cE6I PijHI0dmAzOHP3Oipr08T2oDJj+V2E+csI65jrd/o1JMO/wmIkZpGEF5nWiLW+HW Auz29PZl2HdseFsfHLIbJ0hM74dUCog1je59WiOSky/ZcZX73+Lv3nIKFTQMjQKM myVIiu53kij3Y0adfYhU =JpRS -----END PGP SIGNATURE----- --Apple-Mail=_ECE093E0-C672-419D-A963-0BA28B49CD5F-- From nobody Tue Jun 14 08:06: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 6456312D7C7 for ; Tue, 14 Jun 2016 08:06:34 -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 gqIi3ljLfw1k for ; Tue, 14 Jun 2016 08:06:32 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 979A512D7B0 for ; Tue, 14 Jun 2016 08:06:32 -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 71B341A0F7C; Tue, 14 Jun 2016 17:06:01 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A7E08480-9820-42DE-B3B6-7F01F94D2678"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Tue, 14 Jun 2016 17:06:01 +0200 Message-Id: <6524A223-52A6-4CA1-A17C-2417F1AB24C0@trammell.ch> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> To: Szilveszter Nadas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Tom Herbert , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 15:06:34 -0000 --Apple-Mail=_A7E08480-9820-42DE-B3B6-7F01F94D2678 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13 Jun 2016, at 17:38, Szilveszter Nadas = wrote: >=20 > Hi, >=20 > On the topics of what is included and what not. The PLUS protocol kind = of reminds me of this paper "Breaking Up the Transport Logjam" = http://bford.info/pub/net/logjam.pdf . I'm a big fan of that paper, too. :) > Though the "Flow Regulation Layer" in the paper can be used for much = more than PLUS. Does PLUS intends to be extensible to implement/aid = things like this in the far future or do things like this belong to = different part of the stack? In Logjam terminology, PLUS uses UDP as an endpoint layer, and adds = additional path communication to that layer (or rather to a Path Layer = over that layer). Think of it as "Transport Independent Middlebox = Traversal" (section 2.2.2) greatly expanded. Some of the functions of Flow Regulation might be implementable with = middlebox cooperation over PLUS, but the logjam paper really assumes a = bit more understanding and implementation of transport semantics within = flow middleboxes than PLUS to date has assumed. Definitely a detailed = discussion to have within the BoF or any future WG. Cheers, Brian >=20 > Cheers, > Szilveszter --Apple-Mail=_A7E08480-9820-42DE-B3B6-7F01F94D2678 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 iQIcBAEBCgAGBQJXYB1ZAAoJEIoSt78L6kajUSgQALZtiGZJ1AqcmpPV6he/pap2 pPUOB269a9uW+BuXiHBOYPV4QivFI1ifIaTA+TfDXALvZpc+01c9O+scP8KQsqDs 4yctKT9ALiLFolvrDhMAGie0W1+bG4LHu1P0TQdK8ITdXL8tjd+YxRUBBVtcMFDQ yTHosJ+zOpD/QY9VlxldA8CWwwyQgAydaex14utE00raTV0SAszxfGy5os7Iszdy 567wWjpbM8IcB8D/VVWtj5+AJRJOQQExjwYCKSUrng7sjwnGEAXDNFhM/Y9JeJDN 7F2tI8HOKNJgjA7Wg092Dc5p6216X5DNHNifJihOHnjKFmy61rpky8dcsWdhoy5z W2n9n89C69bZPDGYzwmc0KRKu0FuqKmon3nR6tALNjjN8YLOJA2/edZzkO0wVzCm 1pOmW6HvQ+o7oxRYoCr2m9+brgyLwOBsuIOxjkLa8a7TJXH3Ayjx68gi2ZM3vnO+ KUbzVXsjf8ak9hrWsTU7XLq7Ou3GexN/Zmhv9/99fCivMxylO2SKrEeI+klG/w3M +5degpyVJNBwkgdDw3o/WnktAqBbQa124ZqGUNLbRaB44Mt2fiettB9MQpe0hy+6 WyJQZ1dIRJzhFZd2lDPu7ehyh1dEXTqtSmbWg73f8EAvB9OaFJ4HKRTeNpSGBmiO sWLVklYigjDQlvez7iWx =Oft5 -----END PGP SIGNATURE----- --Apple-Mail=_A7E08480-9820-42DE-B3B6-7F01F94D2678-- From nobody Tue Jun 14 12:47: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 9FE1312D187 for ; Tue, 14 Jun 2016 12:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 sLuSP9DTxHrp for ; Tue, 14 Jun 2016 12:47:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93A812B01B for ; Tue, 14 Jun 2016 12:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z44iG5b34/4lCbOCoqPY5ogRsUr/q6qBmZOaXZ86unY=; b=cRL8pli+TbJpbo84F0ksY/9C7I0jH7MNIbuC76n5hg2Ms0fsyPr0pbL5386OSI2XxuoVFyLTIHnbh8bcRkYfAZEFbde6Omaryz3oT9MGN62zZ6XbSkjQ/NAilyKwE6gjItfeabluF2R5MqJleiJBs6oJlOs3LQuMTxMI8F8KnP4= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Tue, 14 Jun 2016 19:47:04 +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.0517.011; Tue, 14 Jun 2016 19:47:04 +0000 From: Christian Huitema To: Ca By , Szilveszter Nadas Thread-Topic: [Spud] updated draft PLUS charter, rev. 1 June Thread-Index: AQHRu/KkknslUV6vnUS4tzs14whv9J/eT28AgAABG4CAAB43AIAABfgAgAADLQCAABjYgIAABqUAgAACJQCAAAEtgIAAAqWAgAAEkgCAAGJBAIAAZ68AgADDP4CAAK+3gIAGt8qAgAFmxwCAAHIJoA== Date: Tue, 14 Jun 2016 19:47:04 +0000 Message-ID: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:2::14d] x-ms-office365-filtering-correlation-id: 52eaa50d-727b-474f-bc44-08d3948ca981 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 6:W5OErRKpVg5bGah9FWdxXvAapNd2iytgjgfmb+sAPtFZwvcsxzCM9IRUbID0Tvh2kRCihZhA+l9WKdHEma28FMQyCob9Z3NyPkZqlPm1zmptpIJUuOBWKA8tgWNy1lKhU9AsDblxRIJsxkaeajk6rTpHxEgg7siLlT5SgAwJMNsq0nxHOZDwTNCO+uAouI4OcIPmUXAwnmGmknLMoWZlfa+bXlhwBwljNSkcZ0YKZblJI8vuKT+e1O3Kfh2V/7cwJlV6HY0EX0fHG677HVHZqg0PuoZzPOb4kasE+JykpfCnFKGkD5LWtqzT+DNSLLtrItN+cR3TFlEue8qrgdPF3w==; 5:QZwzriLQDUjmzqRwANI9sMaBEoKHLeuBw22w8HQiFu4Gd1ZJQXbSiJWqbEg9XASOWaDjEVutBrAzkEjlDBSbWOpVtSlbtc5o5n8ufh6DR4tFims3ygWuq+4w9peFmsorWj/pUvUI/Nwgq7byOD5MdQ==; 24:pP7TmtwwpkbexCHX76zAzG3j6xahDbPrlJNfWhhfxdzK5YnuBQeAOWahFPKrmDU4GYIJY96Pw0J5cxBTaLsoRBV+sO8Z1jUagQORJsbcMyk=; 7:cKDSTP943p3A+a4xeMTIbtT7I/EJao/fO9WvoQRxF7w/1FsNuOe7HlBmVi4JZv1ly/j+XB6Aev/kzjl6m+ryYnMkyZdnCAtkcnq5LMYpkAVedKc0Qawo++hIa6F8R6Zc0iDRESqXjaWLGFKI3yOd3rKSCz1v6KxrUWsQAjJzrPeN+Xsp0T1M7Y6YEKcY7oc/b31fsjRJv03SqvwtKOEPBCtju4EXScWTnnZFhiLZNgEJJAvaJZrYo9qDmQZti8yX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(189002)(377454003)(199003)(8936002)(9686002)(50986999)(10090500001)(189998001)(68736007)(10400500002)(81156014)(86612001)(8990500004)(5005710100001)(92566002)(76176999)(105586002)(54356999)(11100500001)(5004730100002)(10290500002)(8676002)(6116002)(102836003)(81166006)(97736004)(87936001)(586003)(5008740100001)(5001770100001)(77096005)(2950100001)(2900100001)(2906002)(4326007)(3280700002)(3660700001)(93886004)(5003600100002)(122556002)(99286002)(86362001)(101416001)(106356001)(106116001)(33656002)(74316001)(76576001)(5002640100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 19:47:04.8254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 Archived-At: Cc: Brian Trammell , Joe Touch , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 19:47:10 -0000 T24gVHVlc2RheSwgSnVuZSAxNCwgMjAxNiA1OjQ2IEFNLCBDYSBCeSB3cm90ZToNCg0KPg0KPiBB bGwgbXkgY29uY2VybnMgd2l0aCBzcHVkIGFuZCBxdWljIHdvdWxkIGJlIHNvbHZlZCBieSB1c2lu ZyBhIA0KPiBuZXcgcHJvdG9jb2wgbnVtYmVyIHNpbmNlIGl0IHdvdWxkIGFsbG93IGZvciB0aGUg bmV0d29yayB0bywgDQo+IGF0IHNjYWxlLCBpZGVudGlmeSBnb29kIHNwdWQvcXVpYyB0cmFmZmlj IGZyb20gdGhlIGtub3duIGJhZMKgwqB1ZHAgZGRvcyBtZXNzDQoNCkkgdGhpbmsgd2UgbmVlZCB0 byBkaWcgYSBiaXQgZnVydGhlciB0aGVyZS4gQm90bmV0cyBjb3VsZCBpc3N1ZSBzcHVkL3F1aWMg dHJhZmZpYyBqdXN0IGZpbmUuIEdyYW50ZWQsIGl0IHdpbGwgdGFrZSB0aGVtIHNvbWUgdGltZSB0 byBhZGFwdCwgYnV0IGhpc3Rvcnkgc2hvd3MgdGhhdCB0aGV5IHdpbGwgYWRhcHQuIFNvLCBJIGRv bid0IHNlZSBob3cgcGFpbnRpbmcgYSBmaXhlZCBzZXQgb2YgYml0cyBpbiB0aGUgcGFja2V0cyB3 b3VsZCBoZWxwIGluIHRoZSBsb25nIHJ1bi4gQm90bmV0cyBlbmdhZ2VkIGluIERPUyB3aWxsIGp1 c3Qgc2V0IHRoZSBzYW1lIGJpdHMsIGJlIGl0IGEgcHJvdG9jb2wgbnVtYmVyIG9yIGEgaGVhZGVy IGZpZWxkLg0KDQpUaGVyZSBtYXkgYmUgc29tZXRoaW5nIHNwZWNpZmljIHRvIGRvIGFib3V0IGRp ZmZlcmVudGlhdGlvbiBmcm9tIFVEUCByZWZsZWN0aW9uIGF0dGFja3MuIEkgYW0gYXdhcmUgdGhh dCBhIGxvdCBvZiB0aGVzZSBhcmUgRE5TIHBhY2tldHMuIFRoZXJlIG1heSBiZSBzb21lIG90aGVy IFVEUCBzZXJ2aWNlcyBhcyB3ZWxsLiBCdXQgdGhlIGdlbmVyYWwgY2hhcmFjdGVyaXN0aWMgaXMg dGhhdCBzdWNoIGF0dGFja3MgcmV1c2UgYSBkZXBsb3llZCBpbmZyYXN0cnVjdHVyZSB0byB0aGVp ciBiZW5lZml0cywgYW5kIHRodXMgaGF2ZSBzcGVjaWZpYyBtYXJrZXJzLiBUaGUgaW5mcmFzdHJ1 Y3R1cmUgaXMgbm90IGdvaW5nIHRvIGNoYW5nZSwgc28gdGhlIG1hcmtlcnMgd2lsbCBzdGF5LiBU aGUgbmV3IHByb3RvY29scyBzaG91bGQgY2VydGFpbmx5IHRyeSB0byBkaWZmZXJlbnRpYXRlIGZy b20gdGhlc2UgZXhpc3RpbmcgYXR0YWNrcy4gDQoNCj4gVGhpcyBuZXR3b3JrIG9wZXJhdG9ywqBj b25jZXJuIGhhcyBiZWVuIHJlcGVhdGVkbHkgaWdub3JlZCBzaW5jZQ0KPiBpdCBpc8KgZWFzaWVy IHRvIGFjY2VzcyB1ZHAgaW4gdXNlcnNwYWNlLsKgDQoNCkFzIG1hbnkgc2FpZCwgdXNlciBzcGFj ZSBpcyBqdXN0IG9uZSBvZiB0aGUgcHJvYmxlbXMuIFRoZSBvdGhlciBpcyB0aGUgaW5zdGFsbGVk IGJhc2Ugb2YgTkFUcyB0aGF0IHdvbid0IHBhc3MgYW55dGhpbmcgZWxzZSB0aGFuIFRDUCBhbmQg VURQLiBEbyB3ZSBoYXZlIHN0dWRpZXMgaW5kaWNhdGluZyB3aGV0aGVyIHRoYXQgY2hhbmdlcyB3 aXRoIElQdjY/DQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg0KDQo= From nobody Tue Jun 14 12:58: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 8675612D0C2 for ; Tue, 14 Jun 2016 12:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_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 ulng0rblbWMx for ; Tue, 14 Jun 2016 12:58: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 8015412D936 for ; Tue, 14 Jun 2016 12:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3839; q=dns/txt; s=iport; t=1465934328; x=1467143928; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=+x608AlrV9jpRw7th7JwbGWNMCakvVBH0l0gk8FIdQI=; b=KIS6oInQHQNfxR85KMnL11PqNpkGBCntNOOxgU8M5wKgZdyrewFT+VHr KygCHfj5+mm9PYgidBgDmXlyr5Nk+IXlb3b0yzXbwmBLrCnDJvnj5IvX/ qyaprziMevIObhqbafSbzTua1k0q/iifYJi44FlCnbTCSM+0dRYD2tcyR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGBgBlYWBX/5JdJa1TCoM+Vn2vOIcBg?= =?us-ascii?q?nKECCKFdQKBNDwQAQEBAQEBAWUnhEsBAQEDAXkFCwsECgonByElEQYTiBYDDwg?= =?us-ascii?q?OuUkNg3MBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYngXcIgk6CQ4FVg1SCLwWOZ?= =?us-ascii?q?IlLNIYFhiqBeolFhV2IB4dtNR+EDR0yiggBAQE?= X-IronPort-AV: E=Sophos;i="5.26,472,1459814400"; d="scan'208,217";a="113277614" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2016 19:58:47 +0000 Received: from [10.152.176.55] ([10.152.176.55]) (authenticated bits=0) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5EJwlA6002588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2016 19:58:47 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_BE806F04-AEFB-4FAE-B7F8-AFF14E2BF932" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Tue, 14 Jun 2016 13:58:46 -0600 Message-Id: <373B94B3-B609-4447-8882-61B1A34AD3CE@cisco.com> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> To: Ca By X-Mailer: Apple Mail (2.3124) X-Authenticated-User: dwing Archived-At: Cc: Joe Touch , Szilveszter Nadas , spud , Brian Trammell Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 19:58:51 -0000 --Apple-Mail=_BE806F04-AEFB-4FAE-B7F8-AFF14E2BF932 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14-Jun-2016 06:45 am, Ca By wrote:=20 >=20 >=20 > On Monday, June 13, 2016, Szilveszter Nadas = > = wrote: > Hi, >=20 >=20 > > It would be useful if whatever comes out of an eventual PLUS working = group > > could be implemented either over UDP or IPv6 EH, since the lack of = access to > > EH problem is simply a matter of changing APIs. But I'm not = convinced that's a > > hard requirement. >=20 > Is a separate protocol number for SPUD also an option? Then the happy = eyeball mechanism used could also consider that. >=20 > Cheers, > Sz. >=20 >=20 > All my concerns with spud and quic would be solved by using a new = protocol number since it would allow for the network to, at scale, = identify good spud/quic traffic from the known bad udp ddos mess >=20 > This network operator concern has been repeatedly ignored since it is = easier to access udp in userspace.=20 >=20 > This conflict will not end well if not addressed=20 See the just-published = https://tools.ietf.org/html/draft-wing-quic-network-req-00#section-2 = . -d --Apple-Mail=_BE806F04-AEFB-4FAE-B7F8-AFF14E2BF932 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 14-Jun-2016 06:45 am, Ca By <cb.list6@gmail.com> wrote:


On Monday, June 13, 2016, Szilveszter Nadas <Szilveszter.Nadas@ericsson.com> wrote:
Hi,


> It would be useful if whatever comes out of an eventual PLUS working group
> could be implemented either over UDP or IPv6 EH, since the lack of access to
> EH problem is simply a matter of changing APIs. But I'm not convinced that's a
> hard requirement.

Is a separate protocol number for SPUD also an option? Then the happy eyeball mechanism used could also consider that.

Cheers,
Sz.


All my concerns with spud and quic would be solved by using a new protocol number since it would allow for the network to, at scale, identify good spud/quic traffic from the known bad  udp ddos mess

This network operator concern has been repeatedly ignored since it is easier to access udp in userspace. 

This conflict will not end well if not addressed 


-d

--Apple-Mail=_BE806F04-AEFB-4FAE-B7F8-AFF14E2BF932-- From nobody Tue Jun 14 23:15:48 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CA212B047 for ; Tue, 14 Jun 2016 23:15: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 Bf3PDbIb34Ga for ; Tue, 14 Jun 2016 23:15:44 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8C76212B040 for ; Tue, 14 Jun 2016 23:15:44 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id 400C11A0373; Wed, 15 Jun 2016 08:15:12 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8D6C5E48-9BD1-4BCF-AF06-BFAB23734ABE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Wed, 15 Jun 2016 08:15:14 +0200 Message-Id: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> To: Christian Huitema X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Szilveszter Nadas , Ca By , Joe Touch , spud Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 06:15:47 -0000 --Apple-Mail=_8D6C5E48-9BD1-4BCF-AF06-BFAB23734ABE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Christian, > On 14 Jun 2016, at 21:47, Christian Huitema = wrote: >=20 > On Tuesday, June 14, 2016 5:46 AM, Ca By wrote: >=20 >>=20 >> All my concerns with spud and quic would be solved by using a >> new protocol number since it would allow for the network to, >> at scale, identify good spud/quic traffic from the known bad udp = ddos mess >=20 > I think we need to dig a bit further there. Botnets could issue = spud/quic traffic just fine. Granted, it will take them some time to = adapt, but history shows that they will adapt. So, I don't see how = painting a fixed set of bits in the packets would help in the long run. = Botnets engaged in DOS will just set the same bits, be it a protocol = number or a header field. Agreed. > There may be something specific to do about differentiation from UDP = reflection attacks. I am aware that a lot of these are DNS packets. = There may be some other UDP services as well. Reflection attacks tend to follow the amplification factor: more = amplification, bigger win. NTP (due, I think, to a widely deployed = configuration that was amplification-friendly) was the champion here; = DNS with DNSSEC looms as the next one (see the work of Roland van = Rijswijk-Deij, Anna Sperotto, and Aiko Pras here: [1, 2]). > But the general characteristic is that such attacks reuse a deployed = infrastructure to their benefits, and thus have specific markers. The = infrastructure is not going to change, so the markers will stay. The new = protocols should certainly try to differentiate from these existing = attacks. This is the rationale behind the selection of the magic number in the = SPUD prototype, and the presence of a magic number in the requirements = derived therefrom. I am also intrigued by Tom's earlier suggestion that using IPv6 DO = headers might have reflection-reducing properties, given the installed = base. We should look into that more deeply. None of this does *anything* against direct botnet attacks -- there are = maybe things you could do in a world with ubiquitous PLUS-speaking = middleboxes that distinguished a PLUS magic number flood from a bot from = real PLUS-encapsulated traffic. But relying on both ubiquitous = deployment (a decade out in the wildly optimistic case) and the kindness = of strangers to actually deploy egress filtering (which has worked oh so = well in the past) isn't what I'd call a security plan. >> This network operator concern has been repeatedly ignored since >> it is easier to access udp in userspace. >=20 > As many said, user space is just one of the problems. The other is the = installed base of NATs that won't pass anything else than TCP and UDP. = Do we have studies indicating whether that changes with IPv6? No direct numbers, in part because the measurement infrastructures = available to us give us much smaller population sizes for v6 = measurement. Anecdotally, taken from analysis of the data in [3, 4, 5], = I can say that the magnitude of brokenness on v6 in general is lower, = but the kinds of brokenness you run into is weirder. Slide 9 in [5] is = v4 only because we still haven't been able to explain anomalies in the = MTU curve for UDP on IPv6; in both [3] and the detailed analysis linked = from [4] we see ECN negotiation anomalies five times more often for v6 = than v4. If I had to make up an explanation for that, I'd say that v6 traffic = does indeed tend to pass through fewer middleboxes, but that the v6 = functionality in those middleboxes is far less well tested. Happy = eyeballs works so well because it quite effectively hides a multitude of = sins. Cheers, Brian [1] DNSSEC and its potential for DDoS attacks at IMC '14 = https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/imc101-vanrijswijk.pdf [2] Making the case for elliptic curves in DNSSEC in CCR, Oct '15 = https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/ccr-ecdsa-2015.pdf [3] Enabling Internet-wide deployment of ECN, PAM '15 http://ecn.ethz.ch/ecn-pam15.pdf [4] 70% of popular Web sites support ECM, blog post = https://mami-project.eu/index.php/2016/06/13/70-of-popular-web-sites-suppo= rt-ecn/ [5] Can we run the Internet over UDP, MAPRG presentation https://www.ietf.org/proceedings/95/slides/slides-95-maprg-3.pdf --Apple-Mail=_8D6C5E48-9BD1-4BCF-AF06-BFAB23734ABE 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 iQIcBAEBCgAGBQJXYPJyAAoJEIoSt78L6kajszUP/iEhLMDB5k/kH/stIWWbI3ge +m8tW6GkH7h59TFLkXz4dI0xetIWK4bDvhJO/K0YXN3Q0DdV+X9PVhiobGKtwotg SMl5el7B2qzjFP+RzvN4phaGoW6bRxGGhsg6JkLWyyyTbBw5nnsdypktXqR2S2bU HrvY+ql52JIjiQZDdebGyIGDPzfTvwISGMKgmUoueGDX+ZEQLK4p6B5Y+xFoWkSU JYLqzHFuY3TTxvTi59gdGprJLYunJ4uuze7infIsUxieGnolh+1oPG/q+NjQ5oEX MJ7aI/47IKk5t70A8U6+5cLFB9+9tTESY69e69rLcMEV7LtoOiwD4m1Z46PGyMJr IRkibTfDYs7Ki5H8dauWwcc2TR1qV2+VC/TYFePV98xMXc3LEcNi0+UwCd6LIKRb lLTNRKQRY05TOYDeRKz1qovrOYRUrwk8g86UaLB7F6XFxAaD+QE9RQH8vTSR3Ivx wGTa3mdMlTVKI7Ecq7IW6KTP3akeb6XiAKBtiuRJ/4657otnNKI4qVOaP7zH30oC a+KZ6TedZLwPUQqM6Q7RkZin4Q6nsXHw++7Egcv2PO1abvux5yjnhQzmbK759sMd 5x/u3qtNZgCuy8vtrEfj3OmxrqEwwRKsEr0kKd4M5lRTkN9XMVIZJsBtAjjVrdmA rBKglnjzfPpGi1FBCH/7 =9JUK -----END PGP SIGNATURE----- --Apple-Mail=_8D6C5E48-9BD1-4BCF-AF06-BFAB23734ABE-- From nobody Wed Jun 15 05:17: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 6E4BC12D0EE for ; Wed, 15 Jun 2016 05:17:36 -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 E0Qnu7w0N_Al for ; Wed, 15 Jun 2016 05:17:33 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 45DFA12B00F for ; Wed, 15 Jun 2016 05:17:33 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id m124so33526941wme.1 for ; Wed, 15 Jun 2016 05:17:33 -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=A87YcUpL4e8lBUqvDjSHjGSN4RW8O/k0dECvgu6Jf9E=; b=P2Oepph2JkAfYRGuCPfcT0gLtwW5XC49M86waH5QwQ7uovulsVbGBN2lEAxdUYPfEu IUWIM9Wku2CGnXqYqwdcPZJ2wxP/HBrojB9VY6uzQm+lmG4Ew7t1ulO32JSFMgXGGc6l Zysh4RyKKBPzsGSa2CM5opx5ERoiEkJPntl7Ct75Vlq/ItepkG/FeXy9et/QLUavEKoQ SsCpe98RxonLj6aMrVnDxbsQV7Onos2p/Q4m7xiUOYBMBwzNJRkD2+ZwceBH3ABr8Who quU45Vajha2clTOW70vARAKFgKiJEGxSBZoU8AVzNTe74afBS1jb16KtW7zsJPHpk140 c4zg== 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=A87YcUpL4e8lBUqvDjSHjGSN4RW8O/k0dECvgu6Jf9E=; b=Gj0xef7iBxXPA701g17pWTx8GvoO7e/xfyGBJtTvP5VT+zmUJG+q7gIEE37UewcRgl sC5Qxou4a5/SyGwNL2nUvxbgcSp0UlZciD/kx2gFat5eJUxZwJSGyD4XyXVB1p66nWAC tCUrL0MnI7HCuuMR3D+8Mk1Q7g5ze9ZKHpbmyvBp3YJkISJCXzIJoXDhTA8Qj11Pkw9g /SSCO+/2552YYHCRZxjiKCI4XRNBajTWX5hUw7/x2n2er+5cupw265au51v15TmJxAsT 63NOOv4HX7orJ/8nJwZg7mnBXSnKIt/6EDzm1Rp6mxB6GuZG4rMemADKIOwEOlgci2Lq unSw== X-Gm-Message-State: ALyK8tJmVT7ogM2ZclqcNt9FLxP2uyCMUu1q7i6IybEfjxsZ+KHSnw05NypUizswpHhxPnlObwTtjhEL9r32Bg== MIME-Version: 1.0 X-Received: by 10.28.164.198 with SMTP id n189mr6910140wme.12.1465993051674; Wed, 15 Jun 2016 05:17:31 -0700 (PDT) Received: by 10.28.154.209 with HTTP; Wed, 15 Jun 2016 05:17:31 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> Date: Wed, 15 Jun 2016 05:17:31 -0700 Message-ID: From: Ca By To: Brian Trammell Content-Type: multipart/alternative; boundary=94eb2c081fbc16a5560535501bc6 Archived-At: Cc: Joe Touch , Christian Huitema , spud , Szilveszter Nadas Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 12:17:36 -0000 --94eb2c081fbc16a5560535501bc6 Content-Type: text/plain; charset=UTF-8 On Tuesday, June 14, 2016, Brian Trammell wrote: > hi Christian, > > > On 14 Jun 2016, at 21:47, Christian Huitema > wrote: > > > > On Tuesday, June 14, 2016 5:46 AM, Ca By wrote: > > > >> > >> All my concerns with spud and quic would be solved by using a > >> new protocol number since it would allow for the network to, > >> at scale, identify good spud/quic traffic from the known bad udp ddos > mess > > > > I think we need to dig a bit further there. Botnets could issue > spud/quic traffic just fine. Granted, it will take them some time to adapt, > but history shows that they will adapt. So, I don't see how painting a > fixed set of bits in the packets would help in the long run. Botnets > engaged in DOS will just set the same bits, be it a protocol number or a > header field. > > Agreed. > > > There may be something specific to do about differentiation from UDP > reflection attacks. I am aware that a lot of these are DNS packets. There > may be some other UDP services as well. > > Reflection attacks tend to follow the amplification factor: more > amplification, bigger win. NTP (due, I think, to a widely deployed > configuration that was amplification-friendly) was the champion here; DNS > with DNSSEC looms as the next one (see the work of Roland van > Rijswijk-Deij, Anna Sperotto, and Aiko Pras here: [1, 2]). > > > But the general characteristic is that such attacks reuse a deployed > infrastructure to their benefits, and thus have specific markers. The > infrastructure is not going to change, so the markers will stay. The new > protocols should certainly try to differentiate from these existing attacks. > > This is the rationale behind the selection of the magic number in the SPUD > prototype, and the presence of a magic number in the requirements derived > therefrom. > > Magic numbers do no work on existing router. Just like the constraint you have that we must work with the intall base so we must use udp. The solution space is "no change" > I am also intrigued by Tom's earlier suggestion that using IPv6 DO headers > might have reflection-reducing properties, given the installed base. We > should look into that more deeply. > > None of this does *anything* against direct botnet attacks -- there are > maybe things you could do in a world with ubiquitous PLUS-speaking > middleboxes that distinguished a PLUS magic number flood from a bot from > real PLUS-encapsulated traffic. > Is there anyone from a middle box vendor here? Do you want to hear what PLUS is telling you? Or will middleboxes keep doing what they want? I am concerned plus is saying things nobody is listening to. > > But relying on both ubiquitous deployment (a decade out in the wildly > optimistic case) and the kindness of strangers to actually deploy egress > filtering (which has worked oh so well in the past) isn't what I'd call a > security plan. > > >> This network operator concern has been repeatedly ignored since > >> it is easier to access udp in userspace. > > > > As many said, user space is just one of the problems. The other is the > installed base of NATs that won't pass anything else than TCP and UDP. Do > we have studies indicating whether that changes with IPv6? > > No direct numbers, in part because the measurement infrastructures > available to us give us much smaller population sizes for v6 measurement. > Anecdotally, taken from analysis of the data in [3, 4, 5], I can say that > the magnitude of brokenness on v6 in general is lower, but the kinds of > brokenness you run into is weirder. Slide 9 in [5] is v4 only because we > still haven't been able to explain anomalies in the MTU curve for UDP on > IPv6; in both [3] and the detailed analysis linked from [4] we see ECN > negotiation anomalies five times more often for v6 than v4. > > If I had to make up an explanation for that, I'd say that v6 traffic does > indeed tend to pass through fewer middleboxes, but that the v6 > functionality in those middleboxes is far less well tested. Happy eyeballs > works so well because it quite effectively hides a multitude of sins. > > Cheers, > > Brian > > > [1] DNSSEC and its potential for DDoS attacks at IMC '14 > https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/imc101-vanrijswijk.pdf > > [2] Making the case for elliptic curves in DNSSEC in CCR, Oct '15 > https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/ccr-ecdsa-2015.pdf > > [3] Enabling Internet-wide deployment of ECN, PAM '15 > http://ecn.ethz.ch/ecn-pam15.pdf > > [4] 70% of popular Web sites support ECM, blog post > > https://mami-project.eu/index.php/2016/06/13/70-of-popular-web-sites-support-ecn/ > > [5] Can we run the Internet over UDP, MAPRG presentation > https://www.ietf.org/proceedings/95/slides/slides-95-maprg-3.pdf > --94eb2c081fbc16a5560535501bc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, June 14, 2016, Brian Trammell <ietf@trammell.ch> wrote:
hi Christian,

> On 14 Jun 2016, at 21:47, Christian Huitema <h= uitema@microsoft.com> wrote:
>
> On Tuesday, June 14, 2016 5:46 AM, Ca By wrote:
>
>>
>> All my concerns with spud and quic would be solved by using a
>> new protocol number since it would allow for the network to,
>> at scale, identify good spud/quic traffic from the known bad=C2=A0= udp ddos mess
>
> I think we need to dig a bit further there. Botnets could issue spud/q= uic traffic just fine. Granted, it will take them some time to adapt, but h= istory shows that they will adapt. So, I don't see how painting a fixed= set of bits in the packets would help in the long run. Botnets engaged in = DOS will just set the same bits, be it a protocol number or a header field.=

Agreed.

> There may be something specific to do about differentiation from UDP r= eflection attacks. I am aware that a lot of these are DNS packets. There ma= y be some other UDP services as well.

Reflection attacks tend to follow the amplification factor: more amplificat= ion, bigger win. NTP (due, I think, to a widely deployed configuration that= was amplification-friendly) was the champion here; DNS with DNSSEC looms a= s the next one (see the work of Roland van Rijswijk-Deij, Anna Sperotto, an= d Aiko Pras here: [1, 2]).

> But the general characteristic is that such attacks reuse a deployed i= nfrastructure to their benefits, and thus have specific markers. The infras= tructure is not going to change, so the markers will stay. The new protocol= s should certainly try to differentiate from these existing attacks.

This is the rationale behind the selection of the magic number in the SPUD = prototype, and the presence of a magic number in the requirements derived t= herefrom.


Magic numbers do no work on existing r= outer. Just like the constraint you have that we must work with the intall = base so we must use udp. The solution space is "no change"
<= div>=C2=A0
I am also intrigued by Tom's earlier suggestion that using IPv6 DO head= ers might have reflection-reducing properties, given the installed base. We= should look into that more deeply.

None of this does *anything* against direct botnet attacks -- there are may= be things you could do in a world with ubiquitous PLUS-speaking middleboxes= that distinguished a PLUS magic number flood from a bot from real PLUS-enc= apsulated traffic.=C2=A0


Is there anyone from a middle box vendor here= ? Do you want to hear what PLUS is telling you? Or will middleboxes keep do= ing what they want?

I am concerned plus is saying = things nobody is listening to.=C2=A0
=C2=A0

But relying = on both ubiquitous deployment (a decade out in the wildly optimistic case) = and the kindness of strangers to actually deploy egress filtering (which ha= s worked oh so well in the past) isn't what I'd call a security pla= n.

>> This network operator concern has been repeatedly ignored since >> it is easier to access udp in userspace.
>
> As many said, user space is just one of the problems. The other is the= installed base of NATs that won't pass anything else than TCP and UDP.= Do we have studies indicating whether that changes with IPv6?

No direct numbers, in part because the measurement infrastructures availabl= e to us give us much smaller population sizes for v6 measurement. Anecdotal= ly, taken from analysis of the data in [3, 4, 5], I can say that the magnit= ude of brokenness on v6 in general is lower, but the kinds of brokenness yo= u run into is weirder. Slide 9 in [5] is v4 only because we still haven'= ;t been able to explain anomalies in the MTU curve for UDP on IPv6; in both= [3] and the detailed analysis linked from [4] we see ECN negotiation anoma= lies five times more often for v6 than v4.

If I had to make up an explanation for that, I'd say that v6 traffic do= es indeed tend to pass through fewer middleboxes, but that the v6 functiona= lity in those middleboxes is far less well tested. Happy eyeballs works so = well because it quite effectively hides a multitude of sins.

Cheers,

Brian


[1] DNSSEC and its potential for DDoS attacks at IMC '14 https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/imc101-vanrijswi= jk.pdf

[2] Making the case for elliptic curves in DNSSEC in CCR, Oct '15 https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/ccr-ecdsa-20= 15.pdf

[3] Enabling Internet-wide deployment of ECN, PAM '15
http://ecn.e= thz.ch/ecn-pam15.pdf

[4] 70% of popular Web sites support ECM, blog post
https://mami-project.eu/index.php/2016= /06/13/70-of-popular-web-sites-support-ecn/

[5] Can we run the Internet over UDP, MAPRG presentation
https://www.ietf.org/proceedings/95/slides/slides-95-ma= prg-3.pdf
--94eb2c081fbc16a5560535501bc6-- From nobody Thu Jun 16 02:13: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 A606412B042; Thu, 16 Jun 2016 02:13:39 -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 aid5LXFS1bK7; Thu, 16 Jun 2016 02:13:32 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2B612B008; Thu, 16 Jun 2016 02:13:29 -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 47EED1A056B; Thu, 16 Jun 2016 11:12:57 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F6BBC019-2440-49E6-859E-E9FEE99F7F7D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Thu, 16 Jun 2016 11:12:56 +0200 Message-Id: <27E99769-77F1-4F61-B7FD-31AFF3866F68@trammell.ch> References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ted Hardie , =?utf-8?Q?=F0=9F=94=93Dan_Wing?= , Joe Hildebrand , spud , Christian Huitema , "quic@ietf.org" Subject: Re: [Spud] [QUIC] Network Path Requirements for QUIC 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, 16 Jun 2016 09:13:39 -0000 --Apple-Mail=_F6BBC019-2440-49E6-859E-E9FEE99F7F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, all, (adding spud@ietf.org) On one point, below: > On 16 Jun 2016, at 03:41, Jana Iyengar wrote: >=20 > Hi Dan, >=20 >> draft-wing-quic-network-req tries to up-level its recommendations by = saying 'we need consent' rather than suggesting how to achieve it. = Consent could be achieved in probably 3 or 4 different ways, and we need = a technique that works with multicast QUIC and with persistent QUIC = connections. It's up to WG to agree consent is >> necessary, then to agree how to accomplish consent. We have = identified other things that impact the network and need discussion in = the working group (some small, some larger): Should the network clear = its state immediately after QUIC public reset, set timer, wait for a = little while. Is the network's sole identification the QUIC version in = the client-initiated connection, and can we avoid the network treating = that specially (which will be good and bad, I am remembering network = treatment of IKE's UDP 500 and 4500). If QUIC endpoint sends or = receives many bogus QUIC packets, how can network help stop or rate = limit those, to defend the links and defend other hosts on that network. = If path drops state due to a timeout (or crash, or software update, or = whatever), how should the endpoints learn and how should they react. = Those previous things are discussed in the I-D. In addition, QUIC = complicates network diagnostics and measurements, as well, which will be = added in a later version of the I-D. >=20 > I understand what the draft describes, and as I said, I think this is = useful when the wg is discussing what is visible in the QUIC header and = what isn't. The wg can decide whether to care about a particular = middlebox function or not. >=20 > That said, I think this may be one of our core disagreements: absent = agreement on what middlebox functions are essential, it's hard to argue = how QUIC should solve for them. We saw a very similar conversation play = out in MPTCP. There were many questions about how legacy middleboxes = would treat MPTCP options and modifications to TCP header bits. The = problem was that there were too many boogeymen middleboxes out there, = and it was usually anybody's guess how important any one particular = behavior was. There was small-scale measurement work done that helped = direct the conversation, but this is tricky territory -- tricky largely = because of the lack of substantial data about particular middlebox = behaviors and their prevalence and importance. >=20 > In terms of how these apply to QUIC, we have data from the current = deployment of QUIC, and that can hopefully be brought to bear on the = decisions in the working group. Beyond that, I think it's all thin ice. = We can certainly try and get consensus on specific middlebox behaviors = as important, but that conversation is more general than just QUIC, and = since your draft is precisely such a list, I'd argue that it probably = belongs in PLUS, TSVAREA/TSVWG, or INTAREA. PLUS BoF proponent hat on: I think there is a point here that might make = sense to add to the PLUS draft charter that would naturally feed into = QUIC: - Define a view of "essential middlebox functions", and a description of = the information from endpoints required to drive them. As you say, part of the problem is there is no agreement on either of = these questions. A focused discussion here could hopefully come to some = consensus. QUIC isn't really the place for this IMO, since the answer is = bigger than one instance of a new protocol over UDP. I'm not sure a = general INTAREA/TSVAREA activity would have the right focus, and I'm not = sure it's really in scope for TSVWG. draft-wing-quic-network-req looks to me (slightly rearranged and with = the QUIC-specific language stripped out) as a candidate document for = this work item. It's alsouseful input to the engineering work on a = universal shim protocol we intend to do in PLUS. (And as a bonus, if = both QUIC and PLUS are working from a common, defined view of what sort = of functions are essential, future integration between them won't be = complicated by differing architectural views). Cheers, Brian --Apple-Mail=_F6BBC019-2440-49E6-859E-E9FEE99F7F7D 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 iQIcBAEBCgAGBQJXYm2ZAAoJEIoSt78L6kajRNoP/j79ts/kO8/qOIjr9xpVbKwA lk27WXkd0wPVagddcQqeOPxndJj4q6DuEmFVzYDseMNiEDtRvO9qnQS5oLlMGmkf 5x5YGLNKoUIrdUWFsNw8iAF6qsDvnRR8jBt+UB+qN41Ru6NQDdzoyyW2YJxfQCcV DAqrQIaZk0JWs8sRyBTuYYExoBBcSukVI9TUVH02nbEZCNpESGpZOGx2ufIvqAm2 pKLlA5/F6KdgcPVrozLPiU+gUYL4VXTs6uV1R2r2evSHwOBgo43uqzbrJlC7N98I Wz5zceIp2tnhrGBvdI2LMx9lGCVv0+It+glaJyPud0zEAr8OQ27al9WMMrYbBTlP lvzAmx1rrPtvXIkfL57fj/2AuIH7TiCi5VgZZGjRgSrGiKUOB/ScexY830mmEsEK qtSyCYC8FZKMaIuULCP2n1TUuyI8ZhzvWWYBVF9f2AdyrE8B7DHp8Zmf9Evw2aQ9 o8lLcwl0dzyaD+/VN47LekkQb+opEbJJtzVfRWupIRJg4lCBwf8ld6E/9/hftlUT W0pkksOnDT3j1UXr93BdlYYPIpN1RkCJjyHcoM073lnevDuThoOZ5ddM1WlCVLud rgqpZv4B4p/IpBo0dZDl8/Fr+xLFJfPnjZ7/46uPQ49ICYoXU37+5l+c+a+2cGYQ s+1qIwfiAHP64MvmSLLA =VrAW -----END PGP SIGNATURE----- --Apple-Mail=_F6BBC019-2440-49E6-859E-E9FEE99F7F7D-- From nobody Fri Jun 17 18:26: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 B5E0D12DCC7 for ; Fri, 17 Jun 2016 18:26:26 -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=unavailable 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 21MOX9bjPrnO for ; Fri, 17 Jun 2016 18:26:24 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 6698912DCC2 for ; Fri, 17 Jun 2016 18:26:21 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id w195so527654ywd.0 for ; Fri, 17 Jun 2016 18:26:21 -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=w/wOn9xFRJxVX6EH9Nvp5EPfcodh5//rrVYn1tqc4jc=; b=K/MPywquGzyP7wcwFDVwj08315Cijb6CxlAJYJYyU1Rbv/nGIFQPpnwT5WWcOYz3D6 NX+uUXBqcOwoFMXNlzMUTNfA//B6bsXalhIMtbE6mK9ygJ/9plMttpfq9JnJS2ae2nsQ /89GDLxZwLznqi8o5aB0+QfgqirWA/eC6fJKUaRF/lXKg7AM4eUIJcn0O0nlWMBLBFkx dp/xBw0LHr6Dw44sGxmBP5inmyTtXpcgJQhMhQA9udtZcLpPXQuHcGZ7Ak2NFJbV6QuG issk0+C/2+QJK5gXbz9EGwvB9AdeOKocNyeY83xkaQI701hlbouXLojP5OUSyriENk98 RgVg== 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=w/wOn9xFRJxVX6EH9Nvp5EPfcodh5//rrVYn1tqc4jc=; b=NPTsIFQaPhCaZ7wUNoYenojA97uI/sziSxy5eB9ts59tlN4AsZJbkWtJNs+y/ImADf W7cgFEU385wKL1sKPhXr3ZJ1SwQXCbxTjhjMfaWn6wpXRUxdRJ/BIEFhS7TGQWINh/Z/ M6miV0pUqpUvMBhGgxxlt8pus0JLwosEdJkJA3eE/evG0Joe63LF6rWcIjd2Y6fRf7v0 P7e5AJim5YWmLTGsWQdkIi3SzJkOF70aS/RrjU8AshGunxaNWx3jpduWzRma5vl3rqC4 7XGLDEfgQ0kn4n5kMV6r+ZtbZIPW6Tc33v9nos7JnSp+3GSBFv605qCWcNDM/FYXy3x0 /1OA== X-Gm-Message-State: ALyK8tJW15Wfc2wOI0/xGczI2d+K4IG/FWm1jjvzpK1SJnAwZquQhNq91N4j5pIFLlhj+Gdp3ac2JetmJT6Y4Q0C X-Received: by 10.13.210.67 with SMTP id u64mr2913222ywd.42.1466213180304; Fri, 17 Jun 2016 18:26:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.219.83 with HTTP; Fri, 17 Jun 2016 18:26:19 -0700 (PDT) In-Reply-To: <27E99769-77F1-4F61-B7FD-31AFF3866F68@trammell.ch> References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> <27E99769-77F1-4F61-B7FD-31AFF3866F68@trammell.ch> From: Jana Iyengar Date: Fri, 17 Jun 2016 18:26:19 -0700 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114e7e30c75be90535835b5f Archived-At: Cc: Ted Hardie , =?UTF-8?B?8J+Uk0RhbiBXaW5n?= , Joe Hildebrand , spud , Christian Huitema , "quic@ietf.org" Subject: Re: [Spud] [QUIC] Network Path Requirements for QUIC 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, 18 Jun 2016 01:26:27 -0000 --001a114e7e30c75be90535835b5f Content-Type: text/plain; charset=UTF-8 On Thu, Jun 16, 2016 at 2:12 AM, Brian Trammell wrote: > hi Jana, all, > > (adding spud@ietf.org) > > On one point, below: > > > On 16 Jun 2016, at 03:41, Jana Iyengar wrote: > > > > Hi Dan, > > > >> draft-wing-quic-network-req tries to up-level its recommendations by > saying 'we need consent' rather than suggesting how to achieve it. Consent > could be achieved in probably 3 or 4 different ways, and we need a > technique that works with multicast QUIC and with persistent QUIC > connections. It's up to WG to agree consent is > >> necessary, then to agree how to accomplish consent. We have identified > other things that impact the network and need discussion in the working > group (some small, some larger): Should the network clear its state > immediately after QUIC public reset, set timer, wait for a little while. > Is the network's sole identification the QUIC version in the > client-initiated connection, and can we avoid the network treating that > specially (which will be good and bad, I am remembering network treatment > of IKE's UDP 500 and 4500). If QUIC endpoint sends or receives many bogus > QUIC packets, how can network help stop or rate limit those, to defend the > links and defend other hosts on that network. If path drops state due to a > timeout (or crash, or software update, or whatever), how should the > endpoints learn and how should they react. Those previous things are > discussed in the I-D. In addition, QUIC complicates network diagnostics > and measurements, as well, which will be added in a later version of the > I-D. > > > > I understand what the draft describes, and as I said, I think this is > useful when the wg is discussing what is visible in the QUIC header and > what isn't. The wg can decide whether to care about a particular middlebox > function or not. > > > > That said, I think this may be one of our core disagreements: absent > agreement on what middlebox functions are essential, it's hard to argue how > QUIC should solve for them. We saw a very similar conversation play out in > MPTCP. There were many questions about how legacy middleboxes would treat > MPTCP options and modifications to TCP header bits. The problem was that > there were too many boogeymen middleboxes out there, and it was usually > anybody's guess how important any one particular behavior was. There was > small-scale measurement work done that helped direct the conversation, but > this is tricky territory -- tricky largely because of the lack of > substantial data about particular middlebox behaviors and their prevalence > and importance. > > > > In terms of how these apply to QUIC, we have data from the current > deployment of QUIC, and that can hopefully be brought to bear on the > decisions in the working group. Beyond that, I think it's all thin ice. We > can certainly try and get consensus on specific middlebox behaviors as > important, but that conversation is more general than just QUIC, and since > your draft is precisely such a list, I'd argue that it probably belongs in > PLUS, TSVAREA/TSVWG, or INTAREA. > > PLUS BoF proponent hat on: I think there is a point here that might make > sense to add to the PLUS draft charter that would naturally feed into QUIC: > > - Define a view of "essential middlebox functions", and a description of > the information from endpoints required to drive them. > > As you say, part of the problem is there is no agreement on either of > these questions. A focused discussion here could hopefully come to some > consensus. QUIC isn't really the place for this IMO, since the answer is > bigger than one instance of a new protocol over UDP. I'm not sure a general > INTAREA/TSVAREA activity would have the right focus, and I'm not sure it's > really in scope for TSVWG. > > draft-wing-quic-network-req looks to me (slightly rearranged and with the > QUIC-specific language stripped out) as a candidate document for this work > item. It's alsouseful input to the engineering work on a universal shim > protocol we intend to do in PLUS. (And as a bonus, if both QUIC and PLUS > are working from a common, defined view of what sort of functions are > essential, future integration between them won't be complicated by > differing architectural views). > +1. - jana --001a114e7e30c75be90535835b5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 16, 2016 at 2:12 AM, Brian Trammell <<= a href=3D"mailto:ietf@trammell.ch" target=3D"_blank">ietf@trammell.ch&g= t; wrote:
hi Jana, all,

(adding spud@ietf.org)

On one point, below:

> On 16 Jun 2016, at 03:41, Jana Iyengar <jri@google.com> wrote:
>
> Hi Dan,
>
>> draft-wing-quic-network-req tries to up-level its recommendations = by saying 'we need consent' rather than suggesting how to achieve i= t.=C2=A0 Consent could be achieved in probably 3 or 4 different ways, and w= e need a technique that works with multicast QUIC and with persistent QUIC = connections.=C2=A0 It's up to WG to agree consent is
>> necessary, then to agree how to accomplish consent.=C2=A0 We have = identified other things that impact the network and need discussion in the = working group (some small, some larger):=C2=A0 Should the network clear its= state immediately after QUIC public reset, set timer, wait for a little wh= ile.=C2=A0 Is the network's sole identification the QUIC version in the= client-initiated connection, and can we avoid the network treating that sp= ecially (which will be good and bad, I am remembering network treatment of= =C2=A0 IKE's UDP 500 and 4500).=C2=A0 If QUIC endpoint sends or receive= s many bogus QUIC packets, how can network help stop or rate limit those, t= o defend the links and defend other hosts on that network.=C2=A0 If path dr= ops state due to a timeout (or crash, or software update, or whatever), how= should the endpoints learn and how should they react.=C2=A0 Those previous= things are discussed in the I-D.=C2=A0 In addition, QUIC complicates netwo= rk diagnostics and measurements, as well, which will be added in a later ve= rsion of the I-D.
>
> I understand what the draft describes, and as I said, I think this is = useful when the wg is discussing what is visible in the QUIC header and wha= t isn't. The wg can decide whether to care about a particular middlebox= function or not.
>
> That said, I think this may be one of our core disagreements: absent a= greement on what middlebox functions are essential, it's hard to argue = how QUIC should solve for them. We saw a very similar conversation play out= in MPTCP. There were many questions about how legacy middleboxes would tre= at MPTCP options and modifications to TCP header bits. The problem was that= there were too many boogeymen middleboxes out there, and it was usually an= ybody's guess how important any one particular behavior was. There was = small-scale measurement work done that helped direct the conversation, but = this is tricky territory -- tricky largely because of the lack of substanti= al data about particular middlebox behaviors and their prevalence and impor= tance.
>
> In terms of how these apply to QUIC, we have data from the current dep= loyment of QUIC, and that can hopefully be brought to bear on the decisions= in the working group. Beyond that, I think it's all thin ice. We can c= ertainly try and get consensus on specific middlebox behaviors as important= , but that conversation is more general than just QUIC, and since your draf= t is precisely such a list, I'd argue that it probably belongs in PLUS,= TSVAREA/TSVWG, or INTAREA.

PLUS BoF proponent hat on: I think there is a point here that might = make sense to add to the PLUS draft charter that would naturally feed into = QUIC:

- Define a view of "essential middlebox functions", and a descrip= tion of the information from endpoints required to drive them.

As you say, part of the problem is there is no agreement on either of these= questions. A focused discussion here could hopefully come to some consensu= s. QUIC isn't really the place for this IMO, since the answer is bigger= than one instance of a new protocol over UDP. I'm not sure a general I= NTAREA/TSVAREA activity would have the right focus, and I'm not sure it= 's really in scope for TSVWG.

draft-wing-quic-network-req looks to me (slightly rearranged and with the Q= UIC-specific language stripped out) as a candidate document for this work i= tem. It's alsouseful input to the engineering work on a universal shim = protocol we intend to do in PLUS. (And as a bonus, if both QUIC and PLUS ar= e working from a common, defined view of what sort of functions are essenti= al, future integration between them won't be complicated by differing a= rchitectural views).

+1.
=C2= =A0
- jana
--001a114e7e30c75be90535835b5f-- From nobody Mon Jun 20 04:32: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 3A27612D613 for ; Mon, 20 Jun 2016 04:32:02 -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 rVBZdXwlKKvT for ; Mon, 20 Jun 2016 04:32:00 -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 EFF0712D5CB for ; Mon, 20 Jun 2016 04:31:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 72B8CD9316; Mon, 20 Jun 2016 13:31:57 +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 eptEnNkH+cab; Mon, 20 Jun 2016 13:31:57 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2E4F.dip0.t-ipconnect.de [93.236.46.79]) (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 06EC3D930D; Mon, 20 Jun 2016 13:31:57 +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: <655C07320163294895BBADA28372AF5D48861FF5@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Mon, 20 Jun 2016 13:31:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4009EAE1-FF74-4078-AF0E-72A7943037AF@tik.ee.ethz.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> 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, 20 Jun 2016 11:32:02 -0000 Hi Michael, I know I=E2=80=99m late but I=E2=80=99d like to comment briefly on the = points below. =20 > Am 22.05.2016 um 19:30 schrieb Scharf, Michael (Nokia - DE) = : >=20 > =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 I think here are two points to mention: 1) We were writing the charter with the understanding that PLUS itself = is not a transport protocol, but whatever is above PLUS is. So, of = course there will be information in PLUS header that will be in clear = (but hopefully integrity protected to detect mangling), because this new = (shim)layer is meant for communication with elements on the path. 2) Further I guess the word =E2=80=9Afully=E2=80=98 is here to emphasis = that also the header of the transport should be encrypted. Maybe that = needs further clarified.=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. We don=E2=80=99t have considered that use case yet. But we also decided = to not list specific use cases in the charter. So from my point of view = it would be in scope if someone brings it up. Mirja= From nobody Mon Jun 20 09:24: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 EBCD112D623 for ; Mon, 20 Jun 2016 09:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvGHUJI3P10d for ; Mon, 20 Jun 2016 09:24:27 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 26D5A12D550 for ; Mon, 20 Jun 2016 09:24:27 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id c73so168827667qkg.2 for ; Mon, 20 Jun 2016 09:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=My9169qiQBX+uYTKMxWEIVAaqeX40Kq2T56WlhpHJX8=; b=OhAb0yzNjiC9iCHqHR7nPfXfCdP6CU8ZRGvWfTnSFDv0zX+/uHmrTpQT91q5XRT0j4 vHX3HzA6OSuNwJvHu8EETgWSOReOhZCk5HhiYt5TBEW21BTWK3Q+SMBRSJbvvjfxstgQ pJV5UyRNLLZFymCLa5iUb5GUsujOnqOiSb0zBpF+DdVmI/r0fM98ZZjZsX5miSkkOVQb Mxf3rx7AatAO+cuHtzndNkhHoeK2C27cUejpo+jHHW0Nr+dziGjhB2l8WJObyciJnj0n UBt6wyr+F56oEosWjkH+6yHq1J0kNvuUYg/yurSuqYahu3jQjl6IFmkvMzyTa7UQmo4D pv7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=My9169qiQBX+uYTKMxWEIVAaqeX40Kq2T56WlhpHJX8=; b=PfEFdzMH5c62BKpSRr4ziEwsrUhSmQINNlNMW4F9BAY9LfS0eDeuSRc0fp1xVKdsG3 GPqh/UJRXMu3MqCL5TlRrMCT6zzarmmJMyi8+dUH/YjCCXnHynvzIFTgaLlAHTj1/89P RZLuc6rBqnMqfbM7KTAByjew/sJIK8ZFtxmux631D4my/bIwGcgpHQIw9I2utf82v/6b SXJVJ8I5miG5+CtKDAr7Qeltf4eCiQwEscctA4MUopRuvN1OCWXqpUXqKmLLftp8lnVC yyO84LuCnzEcUcIi0H596qJHXCTVfH+HZC91HlDHZavffVRPTfSs61Gwiy7unVd6bP5R fK7w== X-Gm-Message-State: ALyK8tJpp3a6zP5zyjtMK0OOKL6gsfWxapzwORhR7UDCPI4EX1jNP7LymMVHnTc/z/jbxQ== X-Received: by 10.55.45.134 with SMTP id t128mr17106193qkh.197.1466439866163; Mon, 20 Jun 2016 09:24:26 -0700 (PDT) Received: from bos-mpy2z.kendall.corp.akamai.com ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id c192sm20688343qke.2.2016.06.20.09.24.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Jun 2016 09:24:24 -0700 (PDT) From: Aaron Falk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2016 12:24:23 -0400 Message-Id: To: spud Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Natasha Rooney , Spencer Dawkins Subject: [Spud] meeting conflicts 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, 20 Jun 2016 16:24:29 -0000 I observe that the PLUS BoF conflicts with COSE & ICE. Does anyone = think that is a problem? =E2=80=94aaron= From nobody Mon Jun 20 10:00: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 C91D612D57B for ; Mon, 20 Jun 2016 10:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc8RMxCUuKC0 for ; Mon, 20 Jun 2016 10:00:31 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0697.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::697]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152C012D806 for ; Mon, 20 Jun 2016 10:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IkzqokoJaHmm9PyFxzOlV4ECTs+Bn5rZVeChS/L2BWc=; b=ckm06UI6RbFHgWhaopQOi8CW/5p7tS18VvqdyCrnC9XdPMNEvaC4pXVacLx8jDVNrxxHBI2IpYp4RuxOuYWKZqsAzbFeZKnsNcKHoR+SXKbbIuLIVZd3C6ZxhyeAjsgehnP6/xK0Q68YqDa/FB2V6YcU+/WW9JYtSgOnp9F+UvQ= Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) with Microsoft SMTP Server (TLS) id 15.1.523.12; Mon, 20 Jun 2016 16:58:36 +0000 Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0523.015; Mon, 20 Jun 2016 16:58:36 +0000 From: Natasha Rooney To: spud Thread-Topic: Details about PLUS BoF Thread-Index: AQHRyxT83BGGTANixEyVnDmg5KXCqQ== Date: Mon, 20 Jun 2016 16:58:36 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [87.112.85.58] x-ms-office365-filtering-correlation-id: 56858743-8d64-43c5-e8f4-08d3992c1edb x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2064; 6:FaZK0+q7aBFUe8bPnULPYcETqZWgcx/OosfgPvof6t66uui1HvCma6cQODmPLF3/zqKnLVZHaBmM2rS0jFROsOZbpECFWSSCd2yzwYmBC85XgIQzrP9rSaLsvyta2o3vCNOf/W8RH3n/Xzw4w7COKJkPCPQ6fNakm40HjhuSXFJZ2mhjt5nEVIDNvXnv2vFsGuMAREKnJNclbw1/8s/nBfw2lWQXkRB62N9ofv/zm9TPDqTN+FiDFtXRzl7PlqSgDYHIP23z7iPj32r42zKy9eju/XodFqPi+7qDc4RAAco=; 5:d+Qxj06L19+CjdGX3WaGWStTDZbqJpkF1soWR3yn4QptgwmS4PfWojku+0lufnyyzNKgb+prlawxLC4Yg5n7lLF9Xygg0KQMkT0rO4YNqEOCujbfzPCns1BruFBxvoqFxeJV/ZwWoNGJk3W43jkJIQ==; 24:LwzkrkDUUCMmyVL3LXDDHPRO8GkIa1RDYa488kj/KF5iIzggjOtDNBpArEki4IdS4KB0WoWduvnPBLchgsPU0vJvhuxN8DAEBAfv9JRot1w=; 7:dEEd4o8mhkccI5GeJQzjew2QdrapwNH7Ffe4M8dL6Tp+STuhb23MkvXZYoMxdOaSMAkn40MhdSLrlxMDzG0vAAVuBjkbn5alVpD9WAPU5UKWezQEJtlEFHWgRAqE1drO4RdsSKUFviCYRJmhBofxUxeoZbMdLg364vnhgLBh8hHm0uUbg5T11fEcnijZ1IZJmIKgF/WIU0MUzLOR8wJdin7BHmoD1zmQ3DzSvSLHon/wjE7BPLH3TdgOQa4m24up x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2064; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR0401MB2064; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2064; x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(53754006)(189002)(52044002)(5002640100001)(16236675004)(3660700001)(3280700002)(68736007)(33656002)(3480700004)(5890100001)(8936002)(50986999)(101416001)(50226002)(7736002)(10400500002)(87936001)(11100500001)(2906002)(19580405001)(19580395003)(122556002)(81156014)(57306001)(81166006)(97736004)(586003)(82746002)(7906002)(450100001)(107886002)(36756003)(189998001)(83716003)(110136002)(8676002)(7846002)(3846002)(6116002)(92566002)(106116001)(106356001)(15975445007)(77096005)(2900100001)(105586002)(19617315012)(102836003)(229853001)(86362001)(66066001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2064; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D374C0BAE03F45B7B8B89F8BFBBE5802gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2016 16:58:36.3430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2064 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 87.112.85.58 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: VI1PR0401MB2064.eurprd04.prod.outlook.com Archived-At: Subject: [Spud] Details about PLUS BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 17:00:34 -0000 --_000_D374C0BAE03F45B7B8B89F8BFBBE5802gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQoqKioqKiBVcGNvbWluZyBCb0YgKioqKioNCkkgYW0gc3VyZSB5b3UgYWxsIGtu b3cgdGhhdCB0aGVyZSB3aWxsIGJlIGEgUExVUyBCb0YgYXQgSUVURjk2ISBBY2NvcmRpbmcgdG8g dGhlIGN1cnJlbnQgKHByZWxpbWluYXJ5KSBhZ2VuZGEgdGhlIGN1cnJlbnQgc2xvdCBpcyBUaHVy c2RheSBNb3JuaW5nIFNlc3Npb24gMVsxXS4NCg0KKioqKiogQ2hhaXJzIFNlbGVjdGVkICoqKioq DQpBYXJvbiBGYWxrIGFuZCBJIChOYXRhc2hhIFJvb25leSkgYXJlIHZlcnkgaGFwcHkgdG8gYmUg eW91ciBjaGFpcnMgZm9yIHRoZSBCb0YhIFdl4oCZbGwgYmUgd29ya2luZyBvdmVyIHRoZSBuZXh0 IGZldyB3ZWVrcyB3aXRoIHRoZSBCb0YgcHJvcG9uZW50cyBhbmQgcHJlc2VudGVycyB0byBtYWtl IHN1cmUgdGhlIEJvRiBhc2tzIHRoZSByaWdodCBxdWVzdGlvbnMgYW5kIGV2ZXJ5b25lIGludm9s dmVkIGlzIHByZXBhcmVkIHRvIG1ha2UgdGhlIHJpZ2h0IGRlY2lzaW9ucy4NCg0KKioqKiogTWFp bGluZyBMaXN0IGFuZCBCb0YgTmFtZSAqKioqKg0KU29tZSBvZiB5b3UgbWF5IGJlIGNvbmZ1c2Vk IHdpdGggdGhlIG5hbWluZyBvZiB0aGUgQm9GIGFuZCB0aGlzIG1haWxpbmcgbGlzdC4gQmV0d2Vl biBub3cgYW5kIElFVEY5NiBwbGVhc2UgY29udGludWUgdG8gdXNlIHRoZSBTUFVEIG1haWxpbmcg bGlzdCBbMl0gZm9yIGRpc2N1c3Npb25zIGFib3V0IFNQVUQgYW5kIHRoZSBQTFVTIEJvRi4gSWYg dGhlIFBMVVMgQm9GIGFncmVlcyB0byBmb3JtIGEgd29ya2luZyBncm91cCB3ZSB3aWxsIGNyZWF0 ZSBhIFBMVVMgbWFpbGluZyBsaXN0IHRoZW4sIGJ1dCB0aGlzIHdpbGwgb25seSBiZSAqYWZ0ZXIq IElFVEY5Ni4gU28gKGFnYWluIGp1c3QgZm9yIGNsYXJpdHkhKSwga2VlcCB1c2luZyB0aGUgU1BV RCBtYWlsaW5nIGxpc3QgZm9yIG5vdy4NCg0KSWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucyBmb3Ig dGhlIGNoYWlycyBvciBBRCBwbGVhc2UgZmVlbCBmcmVlIHRvIHBvc3QgdGhlbSB0byB0aGUgU1BV RCBsaXN0Lg0KDQpUaGFua3MhDQoNCk5hdGFzaGENCg0KWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbWVldGluZy85Ni9hZ2VuZGEuaHRtbA0KWzJdIHNwdWRAaWV0Zi5vcmc8bWFpbHRv OnNwdWRAaWV0Zi5vcmc+DQoNCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5k IEludGVybmV0LCBXM0MgJiBJRVRGIHwgR1NNQSB8IG5yb29uZXlAZ3NtYS5jb208bWFpbHRvOm5y b29uZXlAZ3NtYS5jb20+IHwgKzQ0ICgwKSA3NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBT a3lwZTogbnJvb25leUBnc20ub3JnPG1haWx0bzpucm9vbmV5QGdzbS5vcmc+DQoNCg0KDQpUaGlz IGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFt ZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91 IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0 IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVt YWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4NCg== --_000_D374C0BAE03F45B7B8B89F8BFBBE5802gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsLA0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+KioqKiogVXBjb21pbmcgQm9G ICoqKioqPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgYW0gc3VyZSB5b3UgYWxsIGtub3cgdGhhdCB0 aGVyZSB3aWxsIGJlIGEgUExVUyBCb0YgYXQgSUVURjk2ISBBY2NvcmRpbmcgdG8gdGhlIGN1cnJl bnQgKHByZWxpbWluYXJ5KSBhZ2VuZGEgdGhlIGN1cnJlbnQgc2xvdCBpcyBUaHVyc2RheSBNb3Ju aW5nIFNlc3Npb24gMVsxXS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPioqKioqIENoYWlycyBTZWxlY3RlZCAqKioqKjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5BYXJvbiBGYWxrIGFuZCBJIChOYXRhc2hhIFJvb25leSkgYXJlIHZl cnkgaGFwcHkgdG8gYmUgeW91ciBjaGFpcnMgZm9yIHRoZSBCb0YhIFdl4oCZbGwgYmUgd29ya2lu ZyBvdmVyIHRoZSBuZXh0IGZldyB3ZWVrcyB3aXRoIHRoZSBCb0YgcHJvcG9uZW50cyBhbmQgcHJl c2VudGVycyB0byBtYWtlIHN1cmUgdGhlIEJvRiBhc2tzIHRoZSByaWdodCBxdWVzdGlvbnMgYW5k IGV2ZXJ5b25lIGludm9sdmVkIGlzIHByZXBhcmVkIHRvDQogbWFrZSB0aGUgcmlnaHQgZGVjaXNp b25zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+KioqKiogTWFpbGluZyBMaXN0IGFuZCBCb0YgTmFtZSAqKioqKjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5Tb21lIG9mIHlvdSBtYXkgYmUgY29uZnVzZWQgd2l0aCB0aGUgbmFtaW5nIG9mIHRo ZSBCb0YgYW5kIHRoaXMgbWFpbGluZyBsaXN0LiBCZXR3ZWVuIG5vdyBhbmQgSUVURjk2IHBsZWFz ZSBjb250aW51ZSB0byB1c2UgdGhlIFNQVUQgbWFpbGluZyBsaXN0IFsyXSBmb3IgZGlzY3Vzc2lv bnMgYWJvdXQgU1BVRCBhbmQgdGhlIFBMVVMgQm9GLiBJZiB0aGUgUExVUyBCb0YgYWdyZWVzIHRv IGZvcm0gYSB3b3JraW5nIGdyb3VwIHdlDQogd2lsbCBjcmVhdGUgYSBQTFVTIG1haWxpbmcgbGlz dCB0aGVuLCBidXQgdGhpcyB3aWxsIG9ubHkgYmUgKmFmdGVyKiBJRVRGOTYuIFNvIChhZ2FpbiBq dXN0IGZvciBjbGFyaXR5ISksIGtlZXAgdXNpbmcgdGhlIFNQVUQgbWFpbGluZyBsaXN0IGZvciBu b3cuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdo aXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpJZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIGZvciB0aGUg Y2hhaXJzIG9yIEFEIHBsZWFzZSBmZWVsIGZyZWUgdG8gcG9zdCB0aGVtIHRvIHRoZSBTUFVEIGxp c3QuPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdv cmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpUaGFua3MhPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KTmF0YXNoYTwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNs YXNzPSIiPg0KWzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9t ZWV0aW5nLzk2L2FnZW5kYS5odG1sIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL21lZXRpbmcvOTYvYWdlbmRhLmh0bWw8L2E+PGJyIGNsYXNzPSIiPg0KWzJdJm5ic3A7PGEg aHJlZj0ibWFpbHRvOnNwdWRAaWV0Zi5vcmciIGNsYXNzPSIiPnNwdWRAaWV0Zi5vcmc8L2E+Jm5i c3A7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmF0YXNoYSBSb29uZXkgfCBUZWNobm9s b2dpc3QsIFdlYiZuYnNwO2FuZCBJbnRlcm5ldCwgVzNDICZhbXA7IElFVEYgfCBHU01BIHwmbmJz cDs8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc21hLmNvbSIgY2xhc3M9IiI+bnJvb25leUBnc21h LmNvbTwvYT4mbmJzcDt8ICYjNDM7NDQgKDApIDc3MzAmbmJzcDsyMTkgNzY1IHwgQHRoaXNOYXRh c2hhIHwgU2t5cGU6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtLm9yZyIgY2xhc3M9 IiI+bnJvb25leUBnc20ub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8cCBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29sb3I6Izk5 OTk5OTsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMt c2VyaWY7Y29sb3I6Izk5OTk5OTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFsOyBtc28t ZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICZx dW90O0FyaWFsJnF1b3Q7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBFTi1HQjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1haWwgYW5k IGl0cyBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFu ZCBtYXkgYmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3Ig eW91IG11c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkg b3Igc2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2Fs bCAmIzQzOzQ0IDIwNyAzNTYgMDYwMA0KIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8L3NwYW4+ PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D374C0BAE03F45B7B8B89F8BFBBE5802gsmacom_-- From nobody Mon Jun 20 10:10: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 21DF712D587 for ; Mon, 20 Jun 2016 10:10:04 -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 JAspObhnP_vk for ; Mon, 20 Jun 2016 10:10:02 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 1F28A12D556 for ; Mon, 20 Jun 2016 10:10:02 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id h190so43043959ith.1 for ; Mon, 20 Jun 2016 10:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=UdYsESLHOE4/NtBXfCVdYNtnshbRMU1lQ1qlbK8R6X4=; b=lgvdOgw0LPoLsEte7p/mgBIA6JgKAC26O2DoBJC2TPSZbk/rlShCJHCKhnzJ3d+HNb JZyxQl/qJV7aaZSzSD+O9HMZyS2K0ZLsVhyzH9oY2vIx6IRTcXzyLamlx3RNTZmd5zkN W5ofDiUr29PkEV7focXFqAHfehlPRPSF2wSO2oduQmtzaW9Y9/bCqk78QQKtsmeyb/vj IP3uPp2I+x5k8cnsVlxxnbpu8yNPMquMNOSlLBXG+cjo+/6xrbezjit3QfplhN3A5FsE +UDuPpHBcdk8JelANhIMpzLFVAm69P4VKB37VBuHbt8o4wWarWptAvJkyQyBagIsf3pp Y+mA== 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=UdYsESLHOE4/NtBXfCVdYNtnshbRMU1lQ1qlbK8R6X4=; b=d5Tof7J2v2zcZq4fVxwmQJH5LZ4BCLSGOttEGZDZ3h5equ+nNKsH8/zCio56qqILx+ HPM4D4nfsqW5rFRjcR7zoaR1p7F2XbKHKseQL1rByiGW2pWt+UJONj11OAEB59+SksO5 uW4XQXNSHtigzI9Hldgaeemju0ZwHEPSEfP/1QeuOQvpzlbSx2EMFXYJrTKP0t7FOQx6 DQdM1PEjVDnOQ5sIhoMfGn/ODT3+/obrb7hhRLuE0TtvRDD5xW+FgYC58XqxoD8XNjig 01pclGjkLRAfjk8Q9D6PqdzGhXZY3gPnest4HIvlX+3Z9MGMZponD7Z5NgrZgOka96YW /AXw== X-Gm-Message-State: ALyK8tIaGe0ASzLbJQiHAVpjae64y2LITn+xhGYPQkH6RucWmYkgz7ZDfbRmd0aQnILx9pLgD5cqEkOimG0dGQ== MIME-Version: 1.0 X-Received: by 10.36.73.219 with SMTP id e88mr18971442itd.88.1466442601304; Mon, 20 Jun 2016 10:10:01 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Mon, 20 Jun 2016 10:10:00 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> Date: Mon, 20 Jun 2016 10:10:00 -0700 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christian Huitema , Ca By , Joe Touch , spud , Szilveszter Nadas Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 17:10:04 -0000 > I am also intrigued by Tom's earlier suggestion that using IPv6 DO headers might have reflection-reducing properties, given the installed base. We should look into that more deeply. > The solution would be to use hop-by-hop options. These would have a lot of advantages: - HBH options work with any transport or IP protocol (TCP, SCTP, UDP, IPsec, GRE, etc.) not just new UDP based transport protocols. This means adding host to network signaling could be done as an incremental change to the existing mostly TCP Internet (I think this is a major benefit). - For a fragmented packet each fragment can contain hop-by-hop options but not each one contains transport headers. - Hop-by-hop options must be first extension header in the packet so a network device only needs to parse the IPv6 header and one type of EH. If a middlebox has to access the transport layer header and payload it would need to be able to parse over other types of extension headers (routing, DO, etc.) - HBH can be replicated as desired in the outer headers if packets go through an IP tunnel. - IP protocol numbers are unambiguous. If IPv6 next-hdr value is 0 the next header in a packet contains an extension header as a global invariant. No magic numbers needed. - Extension headers are not automatically reflected by any service. - It is within the protocol to modify the contents of HBH options (as specified in the definition of an option). There is also no checksum that needs to be updated unlike the case of UDP payload being modified. - The rules for processing HBH options are being relaxed in 2460bis. Previously, all nodes in a path were required to inspect them. The new text allows nodes in the path to ignore them and forward packets as without processing or modifying HBH options. - RFC3542 defines a sockets API that seems to be supported by the major OSes. Applications probably are permitted to set arbitrary options in packets that may affect the network, however allowing application specific options that are deemed safe can done by whitelist. - HBH options obviously only works with IPv6 and is not available in IPv4. I actually think this is a good thing since supporting forwarding looking functionality only in IPv6 would promote continued transition to IPv6 in the Internet and is in alignment with the early efforts for sunsetting IPv4. Tom From nobody Mon Jun 20 14:38: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 74EAC12D77E for ; Mon, 20 Jun 2016 14:38:50 -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 7_j9YYMhx146 for ; Mon, 20 Jun 2016 14:38:49 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF08012DA71 for ; Mon, 20 Jun 2016 14:38:48 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id a186so180727247qkf.0 for ; Mon, 20 Jun 2016 14:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=nxipB33RujhB1qwzEQXy0NGptvAKPFBb6pefwzdMMww=; b=Rjk8vqqMZQFkzD4w7loHM7n/yh1bQkJSDZEYkdPfGeUD2JXcEnPgxoLqMkVwm9Z7Tg CXvcSWi0uX4xihFaRxIE1Y1/0cQmVFB3LN4mM+7RxQZ25ReIvObpiCfiLjkIk4AUf1O+ CsfNC2bedWvs5Q3uQSBJhMLwKardjpQtBD2FefFjp5Z44Rn7OtANaF6gy0RHRXnscl6P X3w4csIESAzZ/Kbaf2ewepcXTa3kzkqzOhIprc0siaXZ10kMHMVsFuUzVa5VdmniZBJu BqEOPuI0ylc1j5UC1ON84zCf2f4NQA7gNdxHpuehq+cFx55z6KKo4fZRVRfvR9rogCUn OPDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=nxipB33RujhB1qwzEQXy0NGptvAKPFBb6pefwzdMMww=; b=KdIEU6T1KCFoovJAr+s/DhQDe2svo6L2Jsy6D/bZfW4QFo0CJLENbqC5YWtUTUAaMA UHcRfmrBBlewDniMB27r+mVwUaOe6UO84YrDF/5kBYDpECGT2FTT+XAUkZ4J7yH5OCd4 Yufv0E/D5eBO7Xz85YZ4a3cGc9pMTA7wg2itvGLY6TDmn61oN1EHpm3f0GphNHeIb1Gi WcOrd/eBUQNl/OykZJOWS74WpcoedRHbRQLnCqUHj4NaWdT3HVQNw3d7QJPaIGbkRkaO J0gr+mJlV+CkBt7QCa/wXEqQNk0QAM+/M6m/QHdq4s38apgOGtbPvQE5Av2T/eH3leZb wNxw== X-Gm-Message-State: ALyK8tKAVJbTA2o1H3oumYp6HCFOEsEp8tsvVWv7NrXEBtUXbXOOn71DB15WVzVYY1GazQ== X-Received: by 10.55.169.196 with SMTP id s187mr2688554qke.39.1466458728008; Mon, 20 Jun 2016 14:38:48 -0700 (PDT) Received: from bos-mpy2z.kendall.corp.akamai.com (a72-246-0-10.deploy.akamaitechnologies.com. [72.246.0.10]) by smtp.gmail.com with ESMTPSA id e41sm4114765qta.37.2016.06.20.14.38.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Jun 2016 14:38:45 -0700 (PDT) From: Aaron Falk Content-Type: multipart/alternative; boundary="Apple-Mail=_91E47283-9340-40A5-83A7-1D4FA3247E7A" Date: Mon, 20 Jun 2016 17:38:44 -0400 Message-Id: To: Brian Trammell Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spud Subject: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 21:38:50 -0000 --Apple-Mail=_91E47283-9340-40A5-83A7-1D4FA3247E7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian- In the charter and the draft-trammel-spud-req it says Both endpoint-to-path and path-to-endpoint signaling happen completely under endpoint control. Without additional elaboration, one could conclude that, e.g., = permission is required before a path could signal to an endpoint. = Alternatively, it could be implying an endpoint has the freedom to = ignore any signaling from the path. I have been assuming the latter. = But now I wonder if you are intentionally attempting to permit the = former. Could you clarify? Thanks, =E2=80=94aaron --Apple-Mail=_91E47283-9340-40A5-83A7-1D4FA3247E7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Brian-

In the charter and the draft-trammel-spud-req it = says

   Both endpoint-to-path and =
path-to-endpoint signaling happen
   completely under endpoint control.

Without additional elaboration, = one could conclude that, e.g., permission is required before a path = could signal to an endpoint.  Alternatively, it could be implying = an endpoint has the freedom to ignore any signaling from the path. =  I have been assuming the latter.  But now I wonder if you are = intentionally attempting to permit the former.  Could you = clarify?

Thanks,

=E2=80=94aaron


= --Apple-Mail=_91E47283-9340-40A5-83A7-1D4FA3247E7A-- From nobody Tue Jun 21 02:35: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 7B20512B04D for ; Tue, 21 Jun 2016 02:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 XmHnLA5t3xyY for ; Tue, 21 Jun 2016 02:35:37 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3861200A0 for ; Tue, 21 Jun 2016 02:35:36 -0700 (PDT) Received: from [10.44.33.3] (f56-1-soho-router.inf.ethz.ch [192.33.93.168]) by trammell.ch (Postfix) with ESMTPSA id 85A911A1677; Tue, 21 Jun 2016 11:35:34 +0200 (CEST) To: Aaron Falk References: From: Brian Trammell Message-ID: <57690A66.3050502@trammell.ch> Date: Tue, 21 Jun 2016 11:35:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010601090709030104060802" Archived-At: Cc: spud Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 09:35:39 -0000 This is a multi-part message in MIME format. --------------010601090709030104060802 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit hi Aaron, On 06/20/2016 11:38 PM, Aaron Falk wrote: > Hi Brian- > > In the charter and the draft-trammel-spud-req it says > > Both endpoint-to-path and path-to-endpoint signaling happen > completely under endpoint control. > > Without additional elaboration, one could conclude that, e.g., > permission is required before a path could signal to an endpoint. > Alternatively, it could be implying an endpoint has the freedom to > ignore any signaling from the path. I have been assuming the latter. > But now I wonder if you are intentionally attempting to permit the > former. Could you clarify? Our intention is the former: that permission is required before the path can signal to the endpoint. We have two mechanisms we've been thinking about for this: (1) For forward signaling, the sending endpoint must place "scratch space" in the packet with a label on it stating that it's okay to modify; this okay-to-modify state is enforced by a MAC which only verifies the length but not the content of the scratch space. (2) For direct reverse signaling, a path element may not send a direct reverse signaling packet to a sender unless it has also dropped a forward packet from the sender to receiver. This second mechanism is less about permission and more about reducing the attractiveness of PLUS for amplification/reflection attacks. In any case, endpoints (and path elements) can ignore whatever they want to from the PLUS-exposed information; it's what's in the encrypted transport layer headers that matters to the transport protocol on the endpoint. Cheers, Brian > Thanks, > > —aaron > > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --------------010601090709030104060802 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit hi Aaron,

On 06/20/2016 11:38 PM, Aaron Falk wrote:
Hi Brian-

In the charter and the draft-trammel-spud-req it says

   Both endpoint-to-path and path-to-endpoint signaling happen
   completely under endpoint control.

Without additional elaboration, one could conclude that, e.g., permission is required before a path could signal to an endpoint.  Alternatively, it could be implying an endpoint has the freedom to ignore any signaling from the path.  I have been assuming the latter.  But now I wonder if you are intentionally attempting to permit the former.  Could you clarify?

Our intention is the former: that permission is required before the path can signal to the endpoint. We have two mechanisms we've been thinking about for this:

(1) For forward signaling, the sending endpoint must place "scratch space" in the packet with a label on it stating that it's okay to modify; this okay-to-modify state is enforced by a MAC which only verifies the length but not the content of the scratch space.

(2) For direct reverse signaling, a path element may not send a direct reverse signaling packet to a sender unless it has also dropped a forward packet from the sender to receiver. This second mechanism is less about permission and more about reducing the attractiveness of PLUS for amplification/reflection attacks.

In any case, endpoints (and path elements) can ignore whatever they want to from the PLUS-exposed information; it's what's in the encrypted transport layer headers that matters to the transport protocol on the endpoint.

Cheers,

Brian

Thanks,

—aaron




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

--------------010601090709030104060802-- From nobody Tue Jun 21 12:17:17 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6481E12DD22 for ; Tue, 21 Jun 2016 12:17:16 -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 FLARFZ15EwWp for ; Tue, 21 Jun 2016 12:17:14 -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 CF84012DD1F for ; Tue, 21 Jun 2016 12:17:13 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id f30so25111676ioj.2 for ; Tue, 21 Jun 2016 12:17:13 -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=UwPU1XgkzV77nhDIsw9RxukBkZj9vkCnRIxSnpEzk0Q=; b=BMIFyG5pFz1BhBAe0s+K03wT8O9i6kDqgGG4KzBwdSrNYe47eXYvZymeDNJ3gNTP3/ I5E7KaWKDFRXkCiWPgYYB8OGvnCKmqf/o/7Py2/FgcR9jKUqPI2UIfU/WAVFGxUbEp2k DTu2exJsSzP01ijPqs56wSRgL+KQdOpzjspPyFBbwF7InaSA50IKNkIzDemEQ3771zg1 Ld6GM1hsCKvXpd8Lfj4mGhnfvw7PCbc1B+aR3MxhIeo1gMK6WJYok1hhm8Y/NyxVo7q6 WNvUaDtCH82WmNsYyl6R6Ww6GFYoxsfM4agRHc7kQfPMM6jxSVhrIw2gRCUJLKOVuJ4c nj8A== 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=UwPU1XgkzV77nhDIsw9RxukBkZj9vkCnRIxSnpEzk0Q=; b=Lr0hVAF/Ufn9bQRPxpfc1oGI/qNbzxaJ8nRDUlepyMyIxKqG7ZPBLkT5mypcLRvoqj UGwZeLmWzLrDukK3GqQ5A9yOQ1lsYnlMF66pXKaBqQ0DvW0E9LHC3X93jJGnwvGR8Kek PP6gthbXskqh5Rua5JsnmJpFDQwDGVun6pz/bZYQ4pD7e057DSpvabDXouHcHjtrw9Ug a1ZUMONC/qs6/1AJK6lD2c/VviCNscrb2vWsF+GAZmvw2kd+IRIhkPPd2G2sQNSaQvHW +nya+h70GTuYxUR+gNg5OZUkoHaoiSbFgopc/Ek9d9VuVgTbqDsVHvVrPQgIgDcZRhrX S2wQ== X-Gm-Message-State: ALyK8tJ7vSd/cMm42qoF1c3jrRoN+9u6csG6sl6McMwygysbkpyOEcEMKdIkPwu0BYvcF6/SlKkTSOMv74P+Dv1D X-Received: by 10.107.9.78 with SMTP id j75mr33135356ioi.33.1466536632797; Tue, 21 Jun 2016 12:17:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.15.73 with HTTP; Tue, 21 Jun 2016 12:16:53 -0700 (PDT) In-Reply-To: <3A0781FE-D2F2-4AD8-8F4D-4AC3A8D4D177@trammell.ch> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> <3A0781FE-D2F2-4AD8-8F4D-4AC3A8D4D177@trammell.ch> From: Ian Swett Date: Tue, 21 Jun 2016 15:16:53 -0400 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=001a113f90120cb12a0535ceab61 Archived-At: Cc: "Scharf, Michael \(Nokia - DE\)" , spud , Jana Iyengar , =?UTF-8?Q?Michael_T=C3=BCxen?= , "quic@ietf.org" , Randall Stewart Subject: Re: [Spud] [QUIC] Segment offload for UDP-based protocols Re: Requirements 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, 21 Jun 2016 19:17:16 -0000 --001a113f90120cb12a0535ceab61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would agree with you Brian that QUIC/PLUS could be offloaded if #2 was present. #3 is not an issue if the header is encrypted, since it's just part of the encrypted segment. If it wasn't encrypted, I would suggest it either be omitted from the non-first packets or identical across all packets. But either way, it's a solvable problem. That being said, I think we should think hard about whether we want to solve that problem, because it involves a lot of complexity and I believe we'd be better served in ensuring there are simple send/receive paths that are very fast. In regards to acks and LRO, some middleboxes/endpoints will drop all but the most recent ack if multiple arrive in close proximity. It's not clear this is always a feature from a congestion control perspective, but it likely increases throughput in some environments. However, given QUIC/PLUS can easily change the receiver's behavior, we can send fewer acks. Ideally the sender would be aware of that, so it can adjust it's congestion control to expect long pauses. I think this achieves the same goal end-to-end and CPU benchmarks in QUIC indicate it performs very well. I'm hugely concerned about the CPU performance of QUIC, but nothing has convinced me LRO or TSO would help enough to be worth the work. Instead, sending fewer acks and faster send/receive APIs show a lot more promise, at least on the host side. On Thu, Jun 9, 2016 at 6:41 AM, Brian Trammell wrote: > hi Randall, > > > On 09 Jun 2016, at 12:30, Randall Stewart wrote: > > > > > >> On Jun 9, 2016, at 5:06 AM, Michael Tuexen < > Michael.Tuexen@lurchi.franken.de> wrote: > >> > >> > >>> On 09 Jun 2016, at 10:03, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > >>> > >>> My concern is that the current charter suggestion markets the protoco= l > by =E2=80=9Cminimizing (=E2=80=A6) overall transport latency for applicat= ions=E2=80=9D. IMHO this > can have rebound effects. > >>> > >>> Here is what I mean by wrong expectations: Whether a protocol is > indeed fast or not depends on many parameters including aspects such as > hardware acceleration/offload (which matters at 10G/40G line speed, to th= e > best of my knowledge). Some of these effects of > >> I think this refers to high throughput. For TCP, offloading TCP > processing to a NIC improves performance > >> of the TCP processing. I'm not sure if this still helps if > encryption/decryption comes into the game. > > > > I too was thinking Michael meant offloading such as TSO and LRO. I know > on most of the caches > > I develop on if I turn off TSO and LRO performance of the box drops by > roughly 50%=E2=80=A6 and I think > > this will be a consequence of encrypting everything since I don=E2=80= =99t think > you can do TSO/LRO unless > > the hardware/lower-layers has access to things equivalent to TCP > sequence numbers and ACK values, > > which is what I believe the encryption is meant to hide (from middle > boxes). > > > > That will be an extreme price to pay the question is, is it worth it > /and or/ is there some other way > > to get the benefits of the TSO/LRO even with encryption=E2=80=A6 :-) > > (adding spud@ietf.org, as this is a relevant question for PLUS, too): > > The question is what is the minimum information xSO/LRO needs to work. If > I understand how generic segment offload works, if QUIC(/PLUS) exposes: > > (1) a header field that can be used to order packets and find gaps that > the kernel can find and interpret, > > (2) a defined and easily-found boundary between header and payload, such > that the payload retains any framing/message boundaries needed to meet AP= I > contracts, and > > (3) rules about which header to choose for the "big" segment on receive > > then adding QUIC(/PLUS) aware SO/LRO to the kernel should be reasonably > simple. I don't see why you need ACK-equivalents to be exposed to make > this work, but I might be missing something. > > Hardware offload takes longer to deploy, obviously, but runs on equivalen= t > information. > > Cheers, > > Brian > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --001a113f90120cb12a0535ceab61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would agree with you Brian that QUIC/PLUS could be offlo= aded if #2 was present. =C2=A0#3 is not an issue if the header is encrypted= , since it's just part of the encrypted segment.=C2=A0 If it wasn't= encrypted, I would suggest it either be omitted from the non-first packets= or identical across all packets.=C2=A0 But either way, it's a solvable= problem.

That being said, I think we should think hard = about whether we want to solve that problem, because it involves a lot of c= omplexity and I believe we'd be better served in ensuring there are sim= ple send/receive paths that are very fast.

In rega= rds to acks and LRO, some middleboxes/endpoints will drop all but the most = recent ack if multiple arrive in close proximity.=C2=A0 It's not clear = this is always a feature from a congestion control perspective, but it like= ly increases throughput in some environments.=C2=A0 However, given QUIC/PLU= S can easily change the receiver's behavior, we can send fewer acks.=C2= =A0 Ideally the sender would be aware of that, so it can adjust it's co= ngestion control to expect long pauses.=C2=A0 I think this achieves the sam= e goal end-to-end and CPU benchmarks in QUIC indicate it performs very well= .

I'm hugely concerned about the CPU performan= ce of QUIC, but nothing has convinced me LRO or TSO would help enough to be= worth the work.=C2=A0 Instead, sending fewer acks and faster send/receive = APIs show a lot more promise, at least on the host side.

On Thu, Jun 9, 2016 at 6= :41 AM, Brian Trammell <ietf@trammell.ch> wrote:
hi Randall,

> On 09 Jun 2016, at 12:30, Randall Stewart <rrs@netflix.com> wrote:
>
>
>> On Jun 9, 2016, at 5:06 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> w= rote:
>>
>>
>>> On 09 Jun 2016, at 10:03, Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com> w= rote:
>>>
>>> My concern is that the current charter suggestion markets the = protocol by =E2=80=9Cminimizing (=E2=80=A6) overall transport latency for a= pplications=E2=80=9D. IMHO this can have rebound effects.
>>>
>>> Here is what I mean by wrong expectations: Whether a protocol = is indeed fast or not depends on many parameters including aspects such as = hardware acceleration/offload (which matters at 10G/40G line speed, to the = best of my knowledge). Some of these effects of
>> I think this refers to high throughput. For TCP, offloading TCP pr= ocessing to a NIC improves performance
>> of the TCP processing. I'm not sure if this still helps if enc= ryption/decryption comes into the game.
>
> I too was thinking Michael meant offloading such as TSO and LRO. I kno= w on most of the caches
> I develop on if I turn off TSO and LRO performance of the box drops by= roughly 50%=E2=80=A6 and I think
> this will be a consequence of encrypting everything since I don=E2=80= =99t think you can do TSO/LRO unless
> the hardware/lower-layers has access to things equivalent to TCP seque= nce numbers and ACK values,
> which is what I believe the encryption is meant to hide (from middle b= oxes).
>
> That will be an extreme price to pay the question is, is it worth it /= and or/ is there some other way
> to get the benefits of the TSO/LRO even with encryption=E2=80=A6 :-)
(adding spud@ietf.org, as this is a re= levant question for PLUS, too):

The question is what is the minimum information xSO/LRO needs to work. If I= understand how generic segment offload works, if QUIC(/PLUS) exposes:

(1) a header field that can be used to order packets and find gaps that the= kernel can find and interpret,

(2) a defined and easily-found boundary between header and payload, such th= at the payload retains any framing/message boundaries needed to meet API co= ntracts, and

(3) rules about which header to choose for the "big" segment on r= eceive

then adding QUIC(/PLUS) aware SO/LRO to the kernel should be reasonably sim= ple.=C2=A0 I don't see why you need ACK-equivalents to be exposed to ma= ke this work, but I might be missing something.

Hardware offload takes longer to deploy, obviously, but runs on equivalent = information.

Cheers,

Brian


_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic


--001a113f90120cb12a0535ceab61-- From nobody Wed Jun 22 00:10:13 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2938912D12B for ; Wed, 22 Jun 2016 00:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 rNSq2o1CCqiz for ; Wed, 22 Jun 2016 00:10:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFD412B060 for ; Wed, 22 Jun 2016 00:10:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRG78773; Wed, 22 Jun 2016 07:10:07 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jun 2016 08:10:05 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 22 Jun 2016 15:09:59 +0800 From: Youjianjie To: Brian Trammell , Aaron Falk Thread-Topic: [Spud] endpoint control Thread-Index: AQHRyzwoxDCBxuKTZk6d9wR8LfPe/p/zI/AAgAHtRPA= Date: Wed, 22 Jun 2016 07:09:58 +0000 Message-ID: References: <57690A66.3050502@trammell.ch> In-Reply-To: <57690A66.3050502@trammell.ch> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.148] Content-Type: multipart/alternative; boundary="_000_F6C28B32DA084644BB6C8D0BD65B669DC0C7D3NKGEML515MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.576A39D0.00CF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9f873e2aaa8f87a5cbe1a80e61c2d3a1 Archived-At: Cc: spud Subject: [Spud] =?gb2312?b?tPC4tDogIGVuZHBvaW50IGNvbnRyb2w=?= 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, 22 Jun 2016 07:10:12 -0000 --_000_F6C28B32DA084644BB6C8D0BD65B669DC0C7D3NKGEML515MBXchina_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCigxKSBGb3IgZm9yd2FyZCBzaWduYWxpbmcsIHRoZSBzZW5kaW5nIGVuZHBv aW50IG11c3QgcGxhY2UgInNjcmF0Y2ggc3BhY2UiIGluIHRoZSBwYWNrZXQgd2l0aCBhIGxhYmVs IG9uIGl0IHN0YXRpbmcgdGhhdCBpdCdzIG9rYXkgdG8gbW9kaWZ5OyB0aGlzIG9rYXktdG8tbW9k aWZ5IHN0YXRlIGlzIGVuZm9yY2VkIGJ5IGEgTUFDIHdoaWNoIG9ubHkgdmVyaWZpZXMgdGhlIGxl bmd0aCBidXQgbm90IHRoZSBjb250ZW50IG9mIHRoZSBzY3JhdGNoIHNwYWNlLg0KDQpDb3VsZCB5 b3UgcGxlYXNlIGVsYWJvcmF0ZSBob3cgYSBNQUMgaXMgdXNlZCB0byBlbmZvcmNlIHRoZSBva2F5 LXRvLW1vZGlmeSBzdGF0ZT8gSXMgaXQgb25seSBhcHBsaWNhYmxlIHRvIEwyIG5ldHdvcms/IElz IGl0IGEgZGVzaWduZWQgZmllbGQgaW4gdGhlIFBMVVMgaGVhZGVyPw0KDQpUaGFua3MsDQpKaWFu amllDQoNCreivP7IyzogU3B1ZCBbbWFpbHRvOnNwdWQtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBC cmlhbiBUcmFtbWVsbA0Kt6LLzcqxvOQ6IDIwMTbE6jbUwjIxyNUgMTc6MzYNCsrVvP7IyzogQWFy b24gRmFsaw0Ks63LzTogc3B1ZA0K1vfM4jogUmU6IFtTcHVkXSBlbmRwb2ludCBjb250cm9sDQoN CmhpIEFhcm9uLA0KT24gMDYvMjAvMjAxNiAxMTozOCBQTSwgQWFyb24gRmFsayB3cm90ZToNCkhp IEJyaWFuLQ0KDQpJbiB0aGUgY2hhcnRlciBhbmQgdGhlIGRyYWZ0LXRyYW1tZWwtc3B1ZC1yZXEg aXQgc2F5cw0KDQoNCiAgIEJvdGggZW5kcG9pbnQtdG8tcGF0aCBhbmQgcGF0aC10by1lbmRwb2lu dCBzaWduYWxpbmcgaGFwcGVuDQoNCiAgIGNvbXBsZXRlbHkgdW5kZXIgZW5kcG9pbnQgY29udHJv bC4NCg0KV2l0aG91dCBhZGRpdGlvbmFsIGVsYWJvcmF0aW9uLCBvbmUgY291bGQgY29uY2x1ZGUg dGhhdCwgZS5nLiwgcGVybWlzc2lvbiBpcyByZXF1aXJlZCBiZWZvcmUgYSBwYXRoIGNvdWxkIHNp Z25hbCB0byBhbiBlbmRwb2ludC4gIEFsdGVybmF0aXZlbHksIGl0IGNvdWxkIGJlIGltcGx5aW5n IGFuIGVuZHBvaW50IGhhcyB0aGUgZnJlZWRvbSB0byBpZ25vcmUgYW55IHNpZ25hbGluZyBmcm9t IHRoZSBwYXRoLiAgSSBoYXZlIGJlZW4gYXNzdW1pbmcgdGhlIGxhdHRlci4gIEJ1dCBub3cgSSB3 b25kZXIgaWYgeW91IGFyZSBpbnRlbnRpb25hbGx5IGF0dGVtcHRpbmcgdG8gcGVybWl0IHRoZSBm b3JtZXIuICBDb3VsZCB5b3UgY2xhcmlmeT8NCg0KT3VyIGludGVudGlvbiBpcyB0aGUgZm9ybWVy OiB0aGF0IHBlcm1pc3Npb24gaXMgcmVxdWlyZWQgYmVmb3JlIHRoZSBwYXRoIGNhbiBzaWduYWwg dG8gdGhlIGVuZHBvaW50LiBXZSBoYXZlIHR3byBtZWNoYW5pc21zIHdlJ3ZlIGJlZW4gdGhpbmtp bmcgYWJvdXQgZm9yIHRoaXM6DQoNCigxKSBGb3IgZm9yd2FyZCBzaWduYWxpbmcsIHRoZSBzZW5k aW5nIGVuZHBvaW50IG11c3QgcGxhY2UgInNjcmF0Y2ggc3BhY2UiIGluIHRoZSBwYWNrZXQgd2l0 aCBhIGxhYmVsIG9uIGl0IHN0YXRpbmcgdGhhdCBpdCdzIG9rYXkgdG8gbW9kaWZ5OyB0aGlzIG9r YXktdG8tbW9kaWZ5IHN0YXRlIGlzIGVuZm9yY2VkIGJ5IGEgTUFDIHdoaWNoIG9ubHkgdmVyaWZp ZXMgdGhlIGxlbmd0aCBidXQgbm90IHRoZSBjb250ZW50IG9mIHRoZSBzY3JhdGNoIHNwYWNlLg0K DQooMikgRm9yIGRpcmVjdCByZXZlcnNlIHNpZ25hbGluZywgYSBwYXRoIGVsZW1lbnQgbWF5IG5v dCBzZW5kIGEgZGlyZWN0IHJldmVyc2Ugc2lnbmFsaW5nIHBhY2tldCB0byBhIHNlbmRlciB1bmxl c3MgaXQgaGFzIGFsc28gZHJvcHBlZCBhIGZvcndhcmQgcGFja2V0IGZyb20gdGhlIHNlbmRlciB0 byByZWNlaXZlci4gVGhpcyBzZWNvbmQgbWVjaGFuaXNtIGlzIGxlc3MgYWJvdXQgcGVybWlzc2lv biBhbmQgbW9yZSBhYm91dCByZWR1Y2luZyB0aGUgYXR0cmFjdGl2ZW5lc3Mgb2YgUExVUyBmb3Ig YW1wbGlmaWNhdGlvbi9yZWZsZWN0aW9uIGF0dGFja3MuDQoNCkluIGFueSBjYXNlLCBlbmRwb2lu dHMgKGFuZCBwYXRoIGVsZW1lbnRzKSBjYW4gaWdub3JlIHdoYXRldmVyIHRoZXkgd2FudCB0byBm cm9tIHRoZSBQTFVTLWV4cG9zZWQgaW5mb3JtYXRpb247IGl0J3Mgd2hhdCdzIGluIHRoZSBlbmNy eXB0ZWQgdHJhbnNwb3J0IGxheWVyIGhlYWRlcnMgdGhhdCBtYXR0ZXJzIHRvIHRoZSB0cmFuc3Bv cnQgcHJvdG9jb2wgb24gdGhlIGVuZHBvaW50Lg0KDQpDaGVlcnMsDQoNCkJyaWFuDQoNCg0KVGhh bmtzLA0KDQqhqmFhcm9uDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpTcHVkIG1haWxpbmcgbGlzdA0KDQpTcHVkQGlldGYub3Jn PG1haWx0bzpTcHVkQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NwdWQNCg0K --_000_F6C28B32DA084644BB6C8D0BD65B669DC0C7D3NKGEML515MBXchina_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Brian,<= o:p>

 = ;

(1) For forward signaling, the = sending endpoint must place "scratch space" in the packet with a = label on it stating that it's okay to modify; this okay-to-modify state is = enforced by a MAC which only verifies the length but not the content of the scratch space.

Could you = please elaborate how a MAC is used to enforce the okay-to-modify state? Is = it only applicable to L2 network? Is it a designed field in the PLUS header?

 = ;

Thanks,

Jianjie

 = ;

=B7=A2=BC=FE=C8=CB:= Spud [mailto:spud-bounces@ietf.org] =B4=FA=B1=ED Brian Trammell
=B7=A2=CB=CD=CA=B1=BC=E4:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo= r:windowtext"> 2016=C4=EA6=D4=C221=C8=D5 17:36
=CA=D5=BC=FE=C8=CB: Aaron Falk
=B3=AD=CB=CD: spud
=D6=F7=CC=E2: Re: [Spud] endpoint control

 

= hi Aaron,

On 06/20/2016 11:38 PM, Aaron F= alk wrote:

Hi Brian-

 

In the charter and the draft-tr= ammel-spud-req it says

 

   Both endpoin=
t-to-path and path-to-endpoint signaling happen
   completely under endpoint control.

 

Without additional elaboration,= one could conclude that, e.g., permission is required before a path could = signal to an endpoint.  Alternatively, it could be implying an endpoin= t has the freedom to ignore any signaling from the path.  I have been assuming the latter.  But now I wond= er if you are intentionally attempting to permit the former.  Could yo= u clarify?


Our intention is the former: that permission is required before the path ca= n signal to the endpoint. We have two mechanisms we've been thinking about = for this:

(1) For forward signaling, the sending endpoint must place "scratch sp= ace" in the packet with a label on it stating that it's okay to modify= ; this okay-to-modify state is enforced by a MAC which only verifies the le= ngth but not the content of the scratch space.

(2) For direct reverse signaling, a path element may not send a direct reve= rse signaling packet to a sender unless it has also dropped a forward packe= t from the sender to receiver. This second mechanism is less about permissi= on and more about reducing the attractiveness of PLUS for amplification/reflection attacks.

In any case, endpoints (and path elements) can ignore whatever they want to= from the PLUS-exposed information; it's what's in the encrypted transport = layer headers that matters to the transport protocol on the endpoint.

Cheers,

Brian


Thanks,

 

=A1=AAaaron

 

 




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

 
--_000_F6C28B32DA084644BB6C8D0BD65B669DC0C7D3NKGEML515MBXchina_-- From nobody Wed Jun 22 01:56: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 534D912D0A1 for ; Wed, 22 Jun 2016 01:56:22 -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 guJMqI6VrpV3 for ; Wed, 22 Jun 2016 01:56:20 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id CDD9C12B00B for ; Wed, 22 Jun 2016 01:56:19 -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 238D41A16F0; Wed, 22 Jun 2016 10:56:15 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E95F889C-689E-43E8-BE31-A5599EA8C7A5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Wed, 22 Jun 2016 10:56:14 +0200 Message-Id: <095C2E5D-D235-4017-91E2-9B437D8DBDD0@trammell.ch> References: <57690A66.3050502@trammell.ch> To: Youjianjie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Aaron Falk , spud Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 08:56:22 -0000 --Apple-Mail=_E95F889C-689E-43E8-BE31-A5599EA8C7A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Jianjie, > On 22 Jun 2016, at 09:09, Youjianjie wrote: >=20 > Hi Brian, >=20 > (1) For forward signaling, the sending endpoint must place "scratch = space" in the packet with a label on it stating that it's okay to = modify; this okay-to-modify state is enforced by a MAC which only = verifies the length but not the content of the scratch space. >=20 > Could you please elaborate how a MAC is used to enforce the = okay-to-modify state? Is it only applicable to L2 network? Sorry, acronym collision. Here MAC =3D message authentication code, not = medium access control. > Is it a designed field in the PLUS header? There isn't a "PLUS header" yet; we're only talking about potential = mechanisms that could be implemented within one. Here, the idea is that = you have some encoding that allows you to place labeled data in the PLUS = header (from the SPUD prototype experience, we like CBOR, but this is a = technical detail). Some of the types/keys in this data structure are designated end-to-end, = and some of the types/keys are designated path-modifiable. The MAC is generated by the sending endpoint using a secret shared by = both endpoints, and covers: (1) the presence and content of end-to-end PLUS header information (2) the presence and length of path-modifiable PLUS header information, = by treating the content as a length-N byte array of zeroes. This MAC is then transmitted from the sender to the receiver in = encrypted form. Additional MACs may also protect bits of the IP and UDP header, in order = to detect NAT and other sub-PLUS modifications, but these are outside = the scope of this question. Cheers, Brian >=20 > Thanks, > Jianjie >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Spud [mailto:spud-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Brian Trammell > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8821=E6=97=A5= 17:36 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Aaron Falk > =E6=8A=84=E9=80=81: spud > =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >=20 > hi Aaron, >=20 > On 06/20/2016 11:38 PM, Aaron Falk wrote: > Hi Brian- >=20 > In the charter and the draft-trammel-spud-req it says >=20 > Both endpoint-to-path and path-to-endpoint signaling happen > completely under endpoint control. >=20 > Without additional elaboration, one could conclude that, e.g., = permission is required before a path could signal to an endpoint. = Alternatively, it could be implying an endpoint has the freedom to = ignore any signaling from the path. I have been assuming the latter. = But now I wonder if you are intentionally attempting to permit the = former. Could you clarify? >=20 > Our intention is the former: that permission is required before the = path can signal to the endpoint. We have two mechanisms we've been = thinking about for this: >=20 > (1) For forward signaling, the sending endpoint must place "scratch = space" in the packet with a label on it stating that it's okay to = modify; this okay-to-modify state is enforced by a MAC which only = verifies the length but not the content of the scratch space. >=20 > (2) For direct reverse signaling, a path element may not send a direct = reverse signaling packet to a sender unless it has also dropped a = forward packet from the sender to receiver. This second mechanism is = less about permission and more about reducing the attractiveness of PLUS = for amplification/reflection attacks. >=20 > In any case, endpoints (and path elements) can ignore whatever they = want to from the PLUS-exposed information; it's what's in the encrypted = transport layer headers that matters to the transport protocol on the = endpoint. >=20 > Cheers, >=20 > Brian >=20 >=20 > Thanks, >=20 > =E2=80=94aaron >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud >=20 --Apple-Mail=_E95F889C-689E-43E8-BE31-A5599EA8C7A5 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 iQIcBAEBCgAGBQJXalKuAAoJEIoSt78L6kaj0KoP/0OtQppjvSUHh3KHsgqFdwTh bTWrNJyjacWP1miSTYSLiEyA4NJkps7E0CkI6UTIucmdZsbBYF0I4cVtfTf2HHoj mF4oWjfmQmwaH/E7q2OZjEir2W4lw89v/soWOcyOw4gaWBaODZAidhSy9ELuH3HC qykJecd6Wgs3iy17V4UjFcG0iUuBMxjMJVOS92wuXbFkQKKhelC6LSdRMwU3St8E qKjucLgxakkq5D12ZEIpbucrhgAnhD0QrsOduEvBCga+xHH1+qSxhBg78jHgH9ry osBgsK8q/zL1uGnh6Is+on21GDtCq/czrpOgRuHXd7T8S73eeuQzhKuxKXu5uV6U 5YYsZXwoNC8R2CBQH35+rHgwRs4bCmbMbvxUvtXykfe+Mw6Rw86f/m6j+Z3KW6G1 eOo1n4F5BHFIDtGF6N3WXRd8nwRnv7bMoEMH6pBBs3HnCqTF6ZyCOvrhBlgF6B30 1rlBu4bMrfaXWEbuWWXEXyuLsRNKWvGosci9msddGtC/Ie1HHOPiNUj9wCGpz7nX 0cGPRexkT0PM0ViTLAwJB0ZYIqBT3PLqOcGBPNn4gqZCnDyetu9AsaeNY3dqJLdF YXhp9zq6qNwuwcsFfx1bEp4T/KgCsRmlrlnsmGFjgxqEuPUur7iTSNoujwJiJdNx ++8rbmw32kiINhiQkCR/ =Cgy8 -----END PGP SIGNATURE----- --Apple-Mail=_E95F889C-689E-43E8-BE31-A5599EA8C7A5-- From nobody Wed Jun 22 02:36: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 8CED712B058 for ; Wed, 22 Jun 2016 02:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, 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 4c6UgpSkOx5R for ; Wed, 22 Jun 2016 02:36:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B72127058 for ; Wed, 22 Jun 2016 02:36:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRH07510; Wed, 22 Jun 2016 09:36:05 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jun 2016 10:36:03 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 22 Jun 2016 17:35:56 +0800 From: Youjianjie To: Brian Trammell Thread-Topic: [Spud] endpoint control Thread-Index: AQHRyzwoxDCBxuKTZk6d9wR8LfPe/p/zI/AAgAHtRPD//5oTAIAAjlgQ Date: Wed, 22 Jun 2016 09:35:56 +0000 Message-ID: References: <57690A66.3050502@trammell.ch> <095C2E5D-D235-4017-91E2-9B437D8DBDD0@trammell.ch> In-Reply-To: <095C2E5D-D235-4017-91E2-9B437D8DBDD0@trammell.ch> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0208.576A5C05.016A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 54788bab200ba984077cc06ccd49cc3e Archived-At: Cc: Aaron Falk , spud Subject: [Spud] =?utf-8?b?562U5aSNOiAgZW5kcG9pbnQgY29udHJvbA==?= 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, 22 Jun 2016 09:36:11 -0000 SGkgQnJpYW4sDQoNClRoYW5rcyBmb3IgeW91ciBwcm9tcHQgcmVwbHkuIFBsZWFzZSBzZWUgbXkg Y29tbWVudHMgYmVsb3c6DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6 IEJyaWFuIFRyYW1tZWxsIFttYWlsdG86aWV0ZkB0cmFtbWVsbC5jaF0NCj4g5Y+R6YCB5pe26Ze0 OiAyMDE25bm0NuaciDIy5pelIDE2OjU2DQo+IOaUtuS7tuS6ujogWW91amlhbmppZQ0KPiDmioTp gIE6IEFhcm9uIEZhbGs7IHNwdWQNCj4g5Li76aKYOiBSZTogW1NwdWRdIGVuZHBvaW50IGNvbnRy b2wNCj4gDQo+IGhpIEppYW5qaWUsDQo+IA0KPiA+IE9uIDIyIEp1biAyMDE2LCBhdCAwOTowOSwg WW91amlhbmppZSA8eW91amlhbmppZUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPg0KPiA+IEhpIEJy aWFuLA0KPiA+DQo+ID4gKDEpIEZvciBmb3J3YXJkIHNpZ25hbGluZywgdGhlIHNlbmRpbmcgZW5k cG9pbnQgbXVzdCBwbGFjZSAic2NyYXRjaCBzcGFjZSIgaW4NCj4gdGhlIHBhY2tldCB3aXRoIGEg bGFiZWwgb24gaXQgc3RhdGluZyB0aGF0IGl0J3Mgb2theSB0byBtb2RpZnk7IHRoaXMNCj4gb2th eS10by1tb2RpZnkgc3RhdGUgaXMgZW5mb3JjZWQgYnkgYSBNQUMgd2hpY2ggb25seSB2ZXJpZmll cyB0aGUgbGVuZ3RoIGJ1dA0KPiBub3QgdGhlIGNvbnRlbnQgb2YgdGhlIHNjcmF0Y2ggc3BhY2Uu DQo+ID4NCj4gPiBDb3VsZCB5b3UgcGxlYXNlIGVsYWJvcmF0ZSBob3cgYSBNQUMgaXMgdXNlZCB0 byBlbmZvcmNlIHRoZSBva2F5LXRvLW1vZGlmeQ0KPiBzdGF0ZT8gSXMgaXQgb25seSBhcHBsaWNh YmxlIHRvIEwyIG5ldHdvcms/DQo+IA0KPiBTb3JyeSwgYWNyb255bSBjb2xsaXNpb24uIEhlcmUg TUFDID0gbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlLCBub3QNCj4gbWVkaXVtIGFjY2VzcyBj b250cm9sLg0KPiANCj4gPiBJcyBpdCBhIGRlc2lnbmVkIGZpZWxkIGluIHRoZSBQTFVTIGhlYWRl cj8NCj4gDQo+IFRoZXJlIGlzbid0IGEgIlBMVVMgaGVhZGVyIiB5ZXQ7IHdlJ3JlIG9ubHkgdGFs a2luZyBhYm91dCBwb3RlbnRpYWwNCj4gbWVjaGFuaXNtcyB0aGF0IGNvdWxkIGJlIGltcGxlbWVu dGVkIHdpdGhpbiBvbmUuIEhlcmUsIHRoZSBpZGVhIGlzIHRoYXQgeW91DQo+IGhhdmUgc29tZSBl bmNvZGluZyB0aGF0IGFsbG93cyB5b3UgdG8gcGxhY2UgbGFiZWxlZCBkYXRhIGluIHRoZSBQTFVT IGhlYWRlcg0KPiAoZnJvbSB0aGUgU1BVRCBwcm90b3R5cGUgZXhwZXJpZW5jZSwgd2UgbGlrZSBD Qk9SLCBidXQgdGhpcyBpcyBhIHRlY2huaWNhbA0KPiBkZXRhaWwpLg0KPiANCj4gU29tZSBvZiB0 aGUgdHlwZXMva2V5cyBpbiB0aGlzIGRhdGEgc3RydWN0dXJlIGFyZSBkZXNpZ25hdGVkIGVuZC10 by1lbmQsIGFuZA0KPiBzb21lIG9mIHRoZSB0eXBlcy9rZXlzIGFyZSBkZXNpZ25hdGVkIHBhdGgt bW9kaWZpYWJsZS4NCj4gDQo+IFRoZSBNQUMgaXMgZ2VuZXJhdGVkIGJ5IHRoZSBzZW5kaW5nIGVu ZHBvaW50IHVzaW5nIGEgc2VjcmV0IHNoYXJlZCBieSBib3RoDQo+IGVuZHBvaW50cywgYW5kIGNv dmVyczoNCg0KSG93IGlzIHRoZSBzZWNyZXQgc2hhcmVkIGJldHdlZW4gYm90aCBlbmRwb2ludHM/ IFRoZSBlbmRwb2ludHMgbmVlZCB0byBlc3RhYmxpc2ggYSBjb25uZWN0aW9uIHRvIGV4Y2hhbmdl IGtleXM/DQoNCj4gKDEpIHRoZSBwcmVzZW5jZSBhbmQgY29udGVudCBvZiBlbmQtdG8tZW5kIFBM VVMgaGVhZGVyIGluZm9ybWF0aW9uDQoNCkRvIHlvdSBtZWFuIHRoYXQgdGhpcyBpbmZvcm1hdGlv biBpcyBlbmNyeXB0ZWQgdXNpbmcgdGhlIHNoYXJlZCBzZWNyZXQ/IE9ubHkgYm90aCBlbmRwb2lu dHMgY2FuIGtub3cgdGhlIGNvbnRlbnQ/DQoNCj4gKDIpIHRoZSBwcmVzZW5jZSBhbmQgbGVuZ3Ro IG9mIHBhdGgtbW9kaWZpYWJsZSBQTFVTIGhlYWRlciBpbmZvcm1hdGlvbiwgYnkNCj4gdHJlYXRp bmcgdGhlIGNvbnRlbnQgYXMgYSBsZW5ndGgtTiBieXRlIGFycmF5IG9mIHplcm9lcy4NCg0KSG93 IGRvZXMgdGhlIG1pZGRsZS1ib3ggYWxvbmcgdGhlIHBhdGggaW50ZXJwcmV0IHRoZSBQTFVTIGhl YWRlcj8gRG9lcyB0aGUgbWlkZGxlLWJveCBhbHNvIG5lZWQgdGhlIHNlY3JldD8gSSB1c2VkIHRv IHRoaW5rIG1pZGRsZS1ib3ggaXMgdHJhbnNwYXJlbnQuDQoNClRoYW5rcywNCkppYW5qaWUNCg0K PiBUaGlzIE1BQyBpcyB0aGVuIHRyYW5zbWl0dGVkIGZyb20gdGhlIHNlbmRlciB0byB0aGUgcmVj ZWl2ZXIgaW4gZW5jcnlwdGVkDQo+IGZvcm0uDQo+IA0KPiBBZGRpdGlvbmFsIE1BQ3MgbWF5IGFs c28gcHJvdGVjdCBiaXRzIG9mIHRoZSBJUCBhbmQgVURQIGhlYWRlciwgaW4gb3JkZXIgdG8NCj4g ZGV0ZWN0IE5BVCBhbmQgb3RoZXIgc3ViLVBMVVMgbW9kaWZpY2F0aW9ucywgYnV0IHRoZXNlIGFy ZSBvdXRzaWRlIHRoZSBzY29wZQ0KPiBvZiB0aGlzIHF1ZXN0aW9uLg0KPiANCj4gQ2hlZXJzLA0K PiANCj4gQnJpYW4NCj4gDQo+IA0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IEppYW5qaWUNCj4gPg0K PiA+IOWPkeS7tuS6ujogU3B1ZCBbbWFpbHRvOnNwdWQtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGo IEJyaWFuIFRyYW1tZWxsDQo+ID4g5Y+R6YCB5pe26Ze0OiAyMDE25bm0NuaciDIx5pelIDE3OjM2 DQo+ID4g5pS25Lu25Lq6OiBBYXJvbiBGYWxrDQo+ID4g5oqE6YCBOiBzcHVkDQo+ID4g5Li76aKY OiBSZTogW1NwdWRdIGVuZHBvaW50IGNvbnRyb2wNCj4gPg0KPiA+IGhpIEFhcm9uLA0KPiA+DQo+ ID4gT24gMDYvMjAvMjAxNiAxMTozOCBQTSwgQWFyb24gRmFsayB3cm90ZToNCj4gPiBIaSBCcmlh bi0NCj4gPg0KPiA+IEluIHRoZSBjaGFydGVyIGFuZCB0aGUgZHJhZnQtdHJhbW1lbC1zcHVkLXJl cSBpdCBzYXlzDQo+ID4NCj4gPiAgICBCb3RoIGVuZHBvaW50LXRvLXBhdGggYW5kIHBhdGgtdG8t ZW5kcG9pbnQgc2lnbmFsaW5nIGhhcHBlbg0KPiA+ICAgIGNvbXBsZXRlbHkgdW5kZXIgZW5kcG9p bnQgY29udHJvbC4NCj4gPg0KPiA+IFdpdGhvdXQgYWRkaXRpb25hbCBlbGFib3JhdGlvbiwgb25l IGNvdWxkIGNvbmNsdWRlIHRoYXQsIGUuZy4sIHBlcm1pc3Npb24gaXMNCj4gcmVxdWlyZWQgYmVm b3JlIGEgcGF0aCBjb3VsZCBzaWduYWwgdG8gYW4gZW5kcG9pbnQuICBBbHRlcm5hdGl2ZWx5LCBp dCBjb3VsZCBiZQ0KPiBpbXBseWluZyBhbiBlbmRwb2ludCBoYXMgdGhlIGZyZWVkb20gdG8gaWdu b3JlIGFueSBzaWduYWxpbmcgZnJvbSB0aGUgcGF0aC4NCj4gSSBoYXZlIGJlZW4gYXNzdW1pbmcg dGhlIGxhdHRlci4gIEJ1dCBub3cgSSB3b25kZXIgaWYgeW91IGFyZSBpbnRlbnRpb25hbGx5DQo+ IGF0dGVtcHRpbmcgdG8gcGVybWl0IHRoZSBmb3JtZXIuICBDb3VsZCB5b3UgY2xhcmlmeT8NCj4g Pg0KPiA+IE91ciBpbnRlbnRpb24gaXMgdGhlIGZvcm1lcjogdGhhdCBwZXJtaXNzaW9uIGlzIHJl cXVpcmVkIGJlZm9yZSB0aGUgcGF0aCBjYW4NCj4gc2lnbmFsIHRvIHRoZSBlbmRwb2ludC4gV2Ug aGF2ZSB0d28gbWVjaGFuaXNtcyB3ZSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0DQo+IGZvciB0aGlz Og0KPiA+DQo+ID4gKDEpIEZvciBmb3J3YXJkIHNpZ25hbGluZywgdGhlIHNlbmRpbmcgZW5kcG9p bnQgbXVzdCBwbGFjZSAic2NyYXRjaCBzcGFjZSIgaW4NCj4gdGhlIHBhY2tldCB3aXRoIGEgbGFi ZWwgb24gaXQgc3RhdGluZyB0aGF0IGl0J3Mgb2theSB0byBtb2RpZnk7IHRoaXMNCj4gb2theS10 by1tb2RpZnkgc3RhdGUgaXMgZW5mb3JjZWQgYnkgYSBNQUMgd2hpY2ggb25seSB2ZXJpZmllcyB0 aGUgbGVuZ3RoIGJ1dA0KPiBub3QgdGhlIGNvbnRlbnQgb2YgdGhlIHNjcmF0Y2ggc3BhY2UuDQo+ ID4NCj4gPiAoMikgRm9yIGRpcmVjdCByZXZlcnNlIHNpZ25hbGluZywgYSBwYXRoIGVsZW1lbnQg bWF5IG5vdCBzZW5kIGEgZGlyZWN0IHJldmVyc2UNCj4gc2lnbmFsaW5nIHBhY2tldCB0byBhIHNl bmRlciB1bmxlc3MgaXQgaGFzIGFsc28gZHJvcHBlZCBhIGZvcndhcmQgcGFja2V0IGZyb20NCj4g dGhlIHNlbmRlciB0byByZWNlaXZlci4gVGhpcyBzZWNvbmQgbWVjaGFuaXNtIGlzIGxlc3MgYWJv dXQgcGVybWlzc2lvbiBhbmQNCj4gbW9yZSBhYm91dCByZWR1Y2luZyB0aGUgYXR0cmFjdGl2ZW5l c3Mgb2YgUExVUyBmb3IgYW1wbGlmaWNhdGlvbi9yZWZsZWN0aW9uDQo+IGF0dGFja3MuDQo+ID4N Cj4gPiBJbiBhbnkgY2FzZSwgZW5kcG9pbnRzIChhbmQgcGF0aCBlbGVtZW50cykgY2FuIGlnbm9y ZSB3aGF0ZXZlciB0aGV5IHdhbnQgdG8NCj4gZnJvbSB0aGUgUExVUy1leHBvc2VkIGluZm9ybWF0 aW9uOyBpdCdzIHdoYXQncyBpbiB0aGUgZW5jcnlwdGVkIHRyYW5zcG9ydA0KPiBsYXllciBoZWFk ZXJzIHRoYXQgbWF0dGVycyB0byB0aGUgdHJhbnNwb3J0IHByb3RvY29sIG9uIHRoZSBlbmRwb2lu dC4NCj4gPg0KPiA+IENoZWVycywNCj4gPg0KPiA+IEJyaWFuDQo+ID4NCj4gPg0KPiA+IFRoYW5r cywNCj4gPg0KPiA+IOKAlGFhcm9uDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gU3B1ZCBtYWls aW5nIGxpc3QNCj4gPiBTcHVkQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHVkDQo+ID4NCg0K From nobody Wed Jun 22 03:45: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 1A60412B038 for ; Wed, 22 Jun 2016 03:45:31 -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 oC5v1-KzNGHn for ; Wed, 22 Jun 2016 03:45:28 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 962A612B004 for ; Wed, 22 Jun 2016 03:45:28 -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 BBC3F1A1442; Wed, 22 Jun 2016 12:44:56 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C7315F2D-1443-499C-AB8F-5AB3CFB2FDA6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Wed, 22 Jun 2016 12:44:55 +0200 Message-Id: References: <57690A66.3050502@trammell.ch> <095C2E5D-D235-4017-91E2-9B437D8DBDD0@trammell.ch> To: Youjianjie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Aaron Falk , spud Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 10:45:31 -0000 --Apple-Mail=_C7315F2D-1443-499C-AB8F-5AB3CFB2FDA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Jun 2016, at 11:35, Youjianjie wrote: >=20 > Hi Brian, >=20 > Thanks for your prompt reply. Please see my comments below: >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Brian Trammell [mailto:ietf@trammell.ch] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8822=E6=97=A5= 16:56 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Youjianjie >> =E6=8A=84=E9=80=81: Aaron Falk; spud >> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>=20 >> hi Jianjie, >>=20 >>> On 22 Jun 2016, at 09:09, Youjianjie wrote: >>>=20 >>> Hi Brian, >>>=20 >>> (1) For forward signaling, the sending endpoint must place "scratch = space" in >> the packet with a label on it stating that it's okay to modify; this >> okay-to-modify state is enforced by a MAC which only verifies the = length but >> not the content of the scratch space. >>>=20 >>> Could you please elaborate how a MAC is used to enforce the = okay-to-modify >> state? Is it only applicable to L2 network? >>=20 >> Sorry, acronym collision. Here MAC =3D message authentication code, = not >> medium access control. >>=20 >>> Is it a designed field in the PLUS header? >>=20 >> There isn't a "PLUS header" yet; we're only talking about potential >> mechanisms that could be implemented within one. Here, the idea is = that you >> have some encoding that allows you to place labeled data in the PLUS = header >> (from the SPUD prototype experience, we like CBOR, but this is a = technical >> detail). >>=20 >> Some of the types/keys in this data structure are designated = end-to-end, and >> some of the types/keys are designated path-modifiable. >>=20 >> The MAC is generated by the sending endpoint using a secret shared by = both >> endpoints, and covers: >=20 > How is the secret shared between both endpoints? The endpoints need to = establish a connection to exchange keys? Yes. This is assumed to be provided by the superstrate transport. >=20 >> (1) the presence and content of end-to-end PLUS header information >=20 > Do you mean that this information is encrypted using the shared = secret? Only both endpoints can know the content? No, the MAC is generated using the shared secret, so that it cannot be = forged by on-path devices. The information itself is in the clear. Cheers, Brian >> (2) the presence and length of path-modifiable PLUS header = information, by >> treating the content as a length-N byte array of zeroes. >=20 > How does the middle-box along the path interpret the PLUS header? Does = the middle-box also need the secret? I used to think middle-box is = transparent. >=20 > Thanks, > Jianjie >=20 >> This MAC is then transmitted from the sender to the receiver in = encrypted >> form. >>=20 >> Additional MACs may also protect bits of the IP and UDP header, in = order to >> detect NAT and other sub-PLUS modifications, but these are outside = the scope >> of this question. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>=20 >>>=20 >>> Thanks, >>> Jianjie >>>=20 >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Spud [mailto:spud-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Brian Trammell >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8821=E6=97=A5= 17:36 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Aaron Falk >>> =E6=8A=84=E9=80=81: spud >>> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>>=20 >>> hi Aaron, >>>=20 >>> On 06/20/2016 11:38 PM, Aaron Falk wrote: >>> Hi Brian- >>>=20 >>> In the charter and the draft-trammel-spud-req it says >>>=20 >>> Both endpoint-to-path and path-to-endpoint signaling happen >>> completely under endpoint control. >>>=20 >>> Without additional elaboration, one could conclude that, e.g., = permission is >> required before a path could signal to an endpoint. Alternatively, = it could be >> implying an endpoint has the freedom to ignore any signaling from the = path. >> I have been assuming the latter. But now I wonder if you are = intentionally >> attempting to permit the former. Could you clarify? >>>=20 >>> Our intention is the former: that permission is required before the = path can >> signal to the endpoint. We have two mechanisms we've been thinking = about >> for this: >>>=20 >>> (1) For forward signaling, the sending endpoint must place "scratch = space" in >> the packet with a label on it stating that it's okay to modify; this >> okay-to-modify state is enforced by a MAC which only verifies the = length but >> not the content of the scratch space. >>>=20 >>> (2) For direct reverse signaling, a path element may not send a = direct reverse >> signaling packet to a sender unless it has also dropped a forward = packet from >> the sender to receiver. This second mechanism is less about = permission and >> more about reducing the attractiveness of PLUS for = amplification/reflection >> attacks. >>>=20 >>> In any case, endpoints (and path elements) can ignore whatever they = want to >> from the PLUS-exposed information; it's what's in the encrypted = transport >> layer headers that matters to the transport protocol on the endpoint. >>>=20 >>> Cheers, >>>=20 >>> Brian >>>=20 >>>=20 >>> Thanks, >>>=20 >>> =E2=80=94aaron >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>>=20 >=20 --Apple-Mail=_C7315F2D-1443-499C-AB8F-5AB3CFB2FDA6 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 iQIcBAEBCgAGBQJXamwoAAoJEIoSt78L6kajSl0QAMZ6eLqHofqTdkeT3yAKZgvZ HMEeXzN/lwJet/bnd2uSeJnL8goTPi2TKocXSn6SC+kE3s+LiefRxioyhyRFYaAF 0V5J4kp/E/0zsWrrji4nNZfAIZr4rfEMvUmKZjHl5VDjTaxW1Ls5bumVFFa04v0W M2e6HUy1KOVK3B9l4Y8xiBTsNoEdwi6lYxJrt7+XHsKzr5NVRES/K6OUhGwa1yTR US9bvpplu+TXWJ/z75l3Jg33RomkMWJppk7cu2T+MSp7qCqCRdb5Y7bz4SZXgZnW vJNgfXrodJc/y7vmsvYYqBeP35xzqieQW/u38QEDfrQK4b8Hoct+tFm4P7/sJFUc FW8fkn+aRutlqroIhblbDHSlQHbKUj6wOO5PSzuIXujhmVz2nAJfOlhjDizRXKft g2iCmymBiSb9OVoCUDCf7ydFbT8/Yczv98djq6XbqI8qBYt96f0ttFE46TMg2p0I OyM/yUNPYa5jKy2c1cDWI+msNeDyfG3mpophWXHt3sBsfGHRbAoutaUe+ABszq0j ryMojEqSwWx94y9AaG9Lk+/MGuyXUJEo9J8sg38gG7K5nNxmeZcGB9p2e8GKQGvr uZpi28o1CvOOgsI0nfOv4GWcBECtLqiA1emb2ZTg3yblzFVvWGZje0+gjdMGbCSF WmxH5zuhWsrekMkRy2/G =ObXK -----END PGP SIGNATURE----- --Apple-Mail=_C7315F2D-1443-499C-AB8F-5AB3CFB2FDA6-- From nobody Wed Jun 22 12:25: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 89E5812D8E7 for ; Wed, 22 Jun 2016 12:25:21 -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 sM5CsFa4_aue for ; Wed, 22 Jun 2016 12:25:20 -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 55D5012D544 for ; Wed, 22 Jun 2016 12:25:09 -0700 (PDT) Received: from [128.9.184.120] ([128.9.184.120]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5MJOWxT003442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jun 2016 12:24:33 -0700 (PDT) To: Tom Herbert , Brian Trammell References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> From: Joe Touch Message-ID: <576AE5EF.508@isi.edu> Date: Wed, 22 Jun 2016 12:24:31 -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-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Christian Huitema , Ca By , spud , Szilveszter Nadas Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 19:25:21 -0000 See below. On 6/20/2016 10:10 AM, Tom Herbert wrote: >> I am also intrigued by Tom's earlier suggestion that using IPv6 DO headers might have reflection-reducing properties, given the installed base. We should look into that more deeply. >> > The solution would be to use hop-by-hop options. These would have a > lot of advantages: > > - HBH options work with any transport or IP protocol (TCP, SCTP, UDP, > IPsec, GRE, etc.) not just new UDP based transport protocols. This > means adding host to network signaling could be done as an incremental > change to the existing mostly TCP Internet (I think this is a major > benefit). Except that they also increase the chance your packets are just dropped at routers, or that they will take the slow-path. > - For a fragmented packet each fragment can contain hop-by-hop options > but not each one contains transport headers. > - Hop-by-hop options must be first extension header in the packet so a > network device only needs to parse the IPv6 header and one type of EH. > If a middlebox has to access the transport layer header and payload it > would need to be able to parse over other types of extension headers > (routing, DO, etc.) Except that they tend to want to jump over only a small number of such options; increasing that number increases the chance the packet is dropped. > - HBH can be replicated as desired in the outer headers if packets go > through an IP tunnel. HBH options almost never make sense to copy. They're useful in the context of the original header, not the new one. You'd have to define the desire to copy your header if that's the behavior you want, and you'd need a way to know when that didn't happen. However, this is a really nonsensical idea - the whole point of a tunnel is to present a virtual LINK - not an IP subpath. Nothing that happens on a link needs to be visible to IP unless it's already visible at the link endpoints -- which is where the tunneled packet's HBH options are already processed. > - IP protocol numbers are unambiguous. If IPv6 next-hdr value is 0 the > next header in a packet contains an extension header as a global > invariant. No magic numbers needed. > - Extension headers are not automatically reflected by any service. I'll bet money that they are. > - It is within the protocol to modify the contents of HBH options (as > specified in the definition of an option). There is also no checksum > that needs to be updated unlike the case of UDP payload being > modified. > - The rules for processing HBH options are being relaxed in 2460bis. > Previously, all nodes in a path were required to inspect them. The new > text allows nodes in the path to ignore them and forward packets as > without processing or modifying HBH options. That also means that legacy devices might not behave as you expect. > - RFC3542 defines a sockets API that seems to be supported by the > major OSes. Applications probably are permitted to set arbitrary > options in packets that may affect the network, however allowing > application specific options that are deemed safe can done by > whitelist. FWIW, ick. RFCs shouldn't be man pages. IPv6 (more specifically, RFC2460-bis) should include an abstract API that vendors can support, exactly as RFC793 did. > - HBH options obviously only works with IPv6 and is not available in > IPv4. I actually think this is a good thing since supporting > forwarding looking functionality only in IPv6 would promote continued > transition to IPv6 in the Internet and is in alignment with the early > efforts for sunsetting IPv4. > +1 on that point. From nobody Wed Jun 22 13:45: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 2444012D6A6 for ; Wed, 22 Jun 2016 13:45: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 9xUb3IXPgeVn for ; Wed, 22 Jun 2016 13:45:27 -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 932F012DBD1 for ; Wed, 22 Jun 2016 13:45:27 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id f6so48224742ith.0 for ; Wed, 22 Jun 2016 13:45: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:from:date:message-id:subject:to :cc; bh=YMBhXmsnbfhWgQ6Acd2dvt77/32vTO26IpsJWJbbhn0=; b=zvhM4P+H2xNBLmaPMekJ4q+w5jaH+cluQGaVC0insjLhUVt1ltYm+bM/UKKGzVgq/R J6jxCO/k+lmSx8Jzn7pZTnFf1HG85MBVFD1j7lCiP7Q44Zbbbi07SlQ01RrmjWabF0Gx TxTUkNqhO48s4EQXy2F5natl3HVI4VDQ5WFnKED6HhmXKIlFi/pP6LW+rcvVm0+rvy5W pWzGz48el8ayxmORK2A8WolMeyIbAp8hxV8iZIxGiGdm40ORx3qm9iodKXs85TMIpcMr 3NaG6pkFsCy0B5QeJEPG8VDsinTlripWP41InsneMPj6TAAW8yhbtGGxhM+tBTk80Cx5 fkeA== 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=YMBhXmsnbfhWgQ6Acd2dvt77/32vTO26IpsJWJbbhn0=; b=O7e2gGHCsZyvdXA+FG1To4ygn2R+cWrR05+k0wwcsGmQU0cXCiNvREj9YljDQDOzE2 zSULSZTXu6Aj6zuRUdLFRIQlZc9JBjdDHIhArHTBVN9+Xyqau5Jv/ZSyn5U/WTBoZeOT 4lrWG/7PUKt4K7ixbw+ulIB795Ovhwu3wj89jqeZ5m6nixqz+gAkhAP+6ukn6vVQsdG/ Ogr9WyiQqhmDwrTOATDJUBIIN+ZL4hrxAFvGCIS4F2mgMMoJ3c/WQdegy2kE6F5SKRBs C4w5ceLmvWwZcKNC119lwqoKpxCoGhLtQtW53vfPFOb1MD6R5eEL/ThYLYCE/aA+B0RY vZDw== X-Gm-Message-State: ALyK8tKjeErroSmQpYw3NwYcGUy41cp9wpOmDNabEbzvmrz9l34RhzGjfT2H7fz+OodPqjMug5Ce1kHeQYFqfg== X-Received: by 10.36.16.67 with SMTP id 64mr17142770ity.88.1466628326817; Wed, 22 Jun 2016 13:45:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Wed, 22 Jun 2016 13:45:25 -0700 (PDT) In-Reply-To: <576AE5EF.508@isi.edu> References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> <576AE5EF.508@isi.edu> From: Tom Herbert Date: Wed, 22 Jun 2016 13:45:25 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Trammell , Szilveszter Nadas , spud , Ca By , Christian Huitema Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 20:45:34 -0000 On Wed, Jun 22, 2016 at 12:24 PM, Joe Touch wrote: > See below. > > On 6/20/2016 10:10 AM, Tom Herbert wrote: >>> I am also intrigued by Tom's earlier suggestion that using IPv6 DO headers might have reflection-reducing properties, given the installed base. We should look into that more deeply. >>> >> The solution would be to use hop-by-hop options. These would have a >> lot of advantages: >> >> - HBH options work with any transport or IP protocol (TCP, SCTP, UDP, >> IPsec, GRE, etc.) not just new UDP based transport protocols. This >> means adding host to network signaling could be done as an incremental >> change to the existing mostly TCP Internet (I think this is a major >> benefit). > > Except that they also increase the chance your packets are just dropped > at routers, or that they will take the slow-path. > >> - For a fragmented packet each fragment can contain hop-by-hop options >> but not each one contains transport headers. >> - Hop-by-hop options must be first extension header in the packet so a >> network device only needs to parse the IPv6 header and one type of EH. >> If a middlebox has to access the transport layer header and payload it >> would need to be able to parse over other types of extension headers >> (routing, DO, etc.) > > Except that they tend to want to jump over only a small number of such > options; increasing that number increases the chance the packet is dropped. > Per RFC2460 those devices should not be jumping over any options at all, this is non standard behavior. This is why we need Happy Eyeballs in order to work around non-compliant devices. We need workarounds for IPv6 anyway, and we would need them when trying to replace TCP with UDP based transport protocol or something else. IMHO I don't believe that the fact that some number of devices don't comply with the standard justifies creating a whole new standard to accomplish the same effect while potentially opening the door for new ways to be noncompliant. Tom >> - HBH can be replicated as desired in the outer headers if packets go >> through an IP tunnel. > HBH options almost never make sense to copy. They're useful in the > context of the original header, not the new one. > > You'd have to define the desire to copy your header if that's the > behavior you want, and you'd need a way to know when that didn't happen. > > However, this is a really nonsensical idea - the whole point of a tunnel > is to present a virtual LINK - not an IP subpath. Nothing that happens > on a link needs to be visible to IP unless it's already visible at the > link endpoints -- which is where the tunneled packet's HBH options are > already processed. > >> - IP protocol numbers are unambiguous. If IPv6 next-hdr value is 0 the >> next header in a packet contains an extension header as a global >> invariant. No magic numbers needed. >> - Extension headers are not automatically reflected by any service. > I'll bet money that they are. > >> - It is within the protocol to modify the contents of HBH options (as >> specified in the definition of an option). There is also no checksum >> that needs to be updated unlike the case of UDP payload being >> modified. >> - The rules for processing HBH options are being relaxed in 2460bis. >> Previously, all nodes in a path were required to inspect them. The new >> text allows nodes in the path to ignore them and forward packets as >> without processing or modifying HBH options. > That also means that legacy devices might not behave as you expect. >> - RFC3542 defines a sockets API that seems to be supported by the >> major OSes. Applications probably are permitted to set arbitrary >> options in packets that may affect the network, however allowing >> application specific options that are deemed safe can done by >> whitelist. > > FWIW, ick. RFCs shouldn't be man pages. IPv6 (more specifically, > RFC2460-bis) should include an abstract API that vendors can support, > exactly as RFC793 did. >> - HBH options obviously only works with IPv6 and is not available in >> IPv4. I actually think this is a good thing since supporting >> forwarding looking functionality only in IPv6 would promote continued >> transition to IPv6 in the Internet and is in alignment with the early >> efforts for sunsetting IPv4. >> > +1 on that point. From nobody Wed Jun 22 14:06: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 1BD6C12DC2A for ; Wed, 22 Jun 2016 14:06:00 -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 9CmisHHuccQq for ; Wed, 22 Jun 2016 14:05:55 -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 3295912D971 for ; Wed, 22 Jun 2016 14:05:55 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5ML5NVl013859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jun 2016 14:05:23 -0700 (PDT) To: Tom Herbert References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> <576AE5EF.508@isi.edu> From: Joe Touch Message-ID: Date: Wed, 22 Jun 2016 14:05:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , Szilveszter Nadas , spud , Ca By , Christian Huitema Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 21:06:00 -0000 On 6/22/2016 1:45 PM, Tom Herbert wrote: > >>> - For a fragmented packet each fragment can contain hop-by-hop options >>> but not each one contains transport headers. >>> - Hop-by-hop options must be first extension header in the packet so a >>> network device only needs to parse the IPv6 header and one type of EH. >>> If a middlebox has to access the transport layer header and payload it >>> would need to be able to parse over other types of extension headers >>> (routing, DO, etc.) >> Except that they tend to want to jump over only a small number of such >> options; increasing that number increases the chance the packet is dropped. >> > Per RFC2460 those devices should not be jumping over any options at > all, this is non standard behavior. The two high-order bits of all options determine whether they can be ignored - at which point, they can be "jumped over". E.g., 00 allows "skip and continue processing". You haven't mentioned whether you want that behavior, but if you don't then the option will die at the first non-supporting router. Joe From nobody Wed Jun 22 14:19: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 3733212DC50 for ; Wed, 22 Jun 2016 14:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfjveQddo-Ak for ; Wed, 22 Jun 2016 14:19:01 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6F312DC52 for ; Wed, 22 Jun 2016 14:18:57 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id f30so55253892ioj.2 for ; Wed, 22 Jun 2016 14:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZmEdV3F4AxiTaYi84Tr46ap9RQjB+WErdVxB0u2j/co=; b=FDzw/o13jZrh+MwglW1OM3a4UpV3DyZuEmOipLDJ07atbkU4l+6CuCZdBC5uQej/SP W5b8VP1RUGC9QGfM3dqBAKCTcA1YIipJPP99XUHSbuAxfgED/Q2G0BqMgUJ3BE1yDyWN 8ngdiIaJgtDvlvTaAmPK+zV4EHiaS+1FmNIVREYPJIOppc0whFoCaSAWLORiiTnkTFmd 1IHGL63GpskGbExWjS1RlJIQpRnrMeG5z1bw3JT33sbobdQHZ+T5+pF0OMmCUB4aRB3M JEY3iwP6ASPc907RZMh7Ijmia5UXGcZVhTIWnOK91v3PDbZrrjuK3CXh1UZWzdsK8lho G5Mw== 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=ZmEdV3F4AxiTaYi84Tr46ap9RQjB+WErdVxB0u2j/co=; b=H1S0dro2kE2NvmWPzcfGwkpPY1Vw6qOd8x3DFOemAAQl252CSccxdJ7EJK9oY3QjjM 3fDbyLYLoykijUismBpqifxIax+ceAq0CcKOmUvz4kFtF1txYm819PcRlDHJzpV7n6qm TIDNfY0TbpZEOB7ZyscI7CsjvSRJnz99Scob06k4rBb347cIuE+iNlwA/kamcywure9N Qr6hJ+c5P3iqcZIqjW21/XABDmpBJ/Lv4wS0dpJfmkUZtDIbfUdNodtsGXtBMzctSOgR WynESrzqBQVd9ePzl9xDgzRWyGmFZw1yOJp41xltEeqv7+WA5Bsqwi/PR8qmLb3f7sN9 BSCw== X-Gm-Message-State: ALyK8tKHRpr9Ao5V9WCze61hwdA0PzJ10fJjhSf22ddskWR37cHOH/D+b8AoLz4aoTHefQmAm+DWX5c1jmyY/g== X-Received: by 10.107.11.26 with SMTP id v26mr45468529ioi.107.1466630336583; Wed, 22 Jun 2016 14:18:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Wed, 22 Jun 2016 14:18:55 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> <576AE5EF.508@isi.edu> From: Tom Herbert Date: Wed, 22 Jun 2016 14:18:55 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Trammell , Szilveszter Nadas , spud , Ca By , Christian Huitema Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 21:19:03 -0000 On Wed, Jun 22, 2016 at 2:05 PM, Joe Touch wrote: > > > On 6/22/2016 1:45 PM, Tom Herbert wrote: >> >>>> - For a fragmented packet each fragment can contain hop-by-hop options >>>> but not each one contains transport headers. >>>> - Hop-by-hop options must be first extension header in the packet so a >>>> network device only needs to parse the IPv6 header and one type of EH. >>>> If a middlebox has to access the transport layer header and payload it >>>> would need to be able to parse over other types of extension headers >>>> (routing, DO, etc.) >>> Except that they tend to want to jump over only a small number of such >>> options; increasing that number increases the chance the packet is dropped. >>> >> Per RFC2460 those devices should not be jumping over any options at >> all, this is non standard behavior. > > The two high-order bits of all options determine whether they can be > ignored - at which point, they can be "jumped over". E.g., 00 allows > "skip and continue processing". > > You haven't mentioned whether you want that behavior, but if you don't > then the option will die at the first non-supporting router. > Right, I would say that HBH options like this should be 00. Note though that the wording in RFC2460bis now allows nodes in the path to ignore HBH. That means that only nodes that are interested in what is in the options, like devices that would support the proposed signaling, need to inspect them. Tom > Joe > > From nobody Wed Jun 22 14:23: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 B923312D773 for ; Wed, 22 Jun 2016 14:23:02 -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 GTHzxveW1KbJ for ; Wed, 22 Jun 2016 14:22:59 -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 B66C512D7BF for ; Wed, 22 Jun 2016 14:22:57 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5MLMALT017786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jun 2016 14:22:10 -0700 (PDT) To: Tom Herbert References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> <576AE5EF.508@isi.edu> From: Joe Touch Message-ID: <56bf580b-ea32-393b-c59c-c970d5b9e8f4@isi.edu> Date: Wed, 22 Jun 2016 14:22:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , Szilveszter Nadas , spud , Ca By , Christian Huitema Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 21:23:03 -0000 On 6/22/2016 2:18 PM, Tom Herbert wrote: > On Wed, Jun 22, 2016 at 2:05 PM, Joe Touch wrote: >> >> On 6/22/2016 1:45 PM, Tom Herbert wrote: >>>>> - For a fragmented packet each fragment can contain hop-by-hop options >>>>> but not each one contains transport headers. >>>>> - Hop-by-hop options must be first extension header in the packet so a >>>>> network device only needs to parse the IPv6 header and one type of EH. >>>>> If a middlebox has to access the transport layer header and payload it >>>>> would need to be able to parse over other types of extension headers >>>>> (routing, DO, etc.) >>>> Except that they tend to want to jump over only a small number of such >>>> options; increasing that number increases the chance the packet is dropped. >>>> >>> Per RFC2460 those devices should not be jumping over any options at >>> all, this is non standard behavior. >> The two high-order bits of all options determine whether they can be >> ignored - at which point, they can be "jumped over". E.g., 00 allows >> "skip and continue processing". >> >> You haven't mentioned whether you want that behavior, but if you don't >> then the option will die at the first non-supporting router. >> > Right, I would say that HBH options like this should be 00. If that's the case, you can't know when a router processes a datagram but ignores this option. (note - TTL/hopcount tricks won't work - you can't know the difference between a single router that decrements the TTL/hop by 2 and a second router that ignores this option) > Note > though that the wording in RFC2460bis now allows nodes in the path to > ignore HBH. That means that only nodes that are interested in what is > in the options, like devices that would support the proposed > signaling, need to inspect them. Ick. That behavior was already supported by the choice of the option designer. Taking away the potential to create "must handle" options is a bad thing. Joe From nobody Thu Jun 23 01:03: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 608E212DD03 for ; Thu, 23 Jun 2016 01:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, 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 LY29csf2zOix for ; Thu, 23 Jun 2016 01:03:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2108512D885 for ; Thu, 23 Jun 2016 01:03:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRI59777; Thu, 23 Jun 2016 08:03:06 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 23 Jun 2016 09:03:05 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 23 Jun 2016 16:03:02 +0800 From: Youjianjie To: Brian Trammell Thread-Topic: [Spud] endpoint control Thread-Index: AQHRyzwoxDCBxuKTZk6d9wR8LfPe/p/zI/AAgAHtRPD//5oTAIAAjlgQ//+QBoCAAdzVQA== Date: Thu, 23 Jun 2016 08:03:02 +0000 Message-ID: References: <57690A66.3050502@trammell.ch> <095C2E5D-D235-4017-91E2-9B437D8DBDD0@trammell.ch> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.576B97C0.003F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 54788bab200ba984077cc06ccd49cc3e Archived-At: Cc: Aaron Falk , spud Subject: [Spud] =?utf-8?b?562U5aSNOiAgZW5kcG9pbnQgY29udHJvbA==?= 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, 23 Jun 2016 08:03:33 -0000 SGkgQnJpYW4sDQoNCkknbSB3b25kZXJpbmcgaG93IHRoZSBlbmRwb2ludCB2ZXJpZmllcyB0aGUg aW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgdGhlIGRldmljZSBvbiBwYXRoPyBJcyBpdCBhbHNvIGFz c3VtZWQgdGhhdCB0aGUga2V5IGlzIHByb3ZpZGVkIGJ5IHRoZSBzdXBlcnN0cmF0ZSB0cmFuc3Bv cnQgYmV0d2VlbiB0aGUgZGV2aWNlIG9uIHBhdGggYW5kIHRoZSBlbmRwb2ludD8NCg0KVGhhbmtz LA0KSmlhbmppZQ0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBCcmlh biBUcmFtbWVsbCBbbWFpbHRvOmlldGZAdHJhbW1lbGwuY2hdDQo+IOWPkemAgeaXtumXtDogMjAx NuW5tDbmnIgyMuaXpSAxODo0NQ0KPiDmlLbku7bkuro6IFlvdWppYW5qaWUNCj4g5oqE6YCBOiBB YXJvbiBGYWxrOyBzcHVkDQo+IOS4u+mimDogUmU6IFtTcHVkXSBlbmRwb2ludCBjb250cm9sDQo+ IA0KPiANCj4gPiBPbiAyMiBKdW4gMjAxNiwgYXQgMTE6MzUsIFlvdWppYW5qaWUgPHlvdWppYW5q aWVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBCcmlhbiwNCj4gPg0KPiA+IFRoYW5r cyBmb3IgeW91ciBwcm9tcHQgcmVwbHkuIFBsZWFzZSBzZWUgbXkgY29tbWVudHMgYmVsb3c6DQo+ ID4NCj4gPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+PiDlj5Hku7bkuro6IEJyaWFuIFRy YW1tZWxsIFttYWlsdG86aWV0ZkB0cmFtbWVsbC5jaF0NCj4gPj4g5Y+R6YCB5pe26Ze0OiAyMDE2 5bm0NuaciDIy5pelIDE2OjU2DQo+ID4+IOaUtuS7tuS6ujogWW91amlhbmppZQ0KPiA+PiDmioTp gIE6IEFhcm9uIEZhbGs7IHNwdWQNCj4gPj4g5Li76aKYOiBSZTogW1NwdWRdIGVuZHBvaW50IGNv bnRyb2wNCj4gPj4NCj4gPj4gaGkgSmlhbmppZSwNCj4gPj4NCj4gPj4+IE9uIDIyIEp1biAyMDE2 LCBhdCAwOTowOSwgWW91amlhbmppZSA8eW91amlhbmppZUBodWF3ZWkuY29tPiB3cm90ZToNCj4g Pj4+DQo+ID4+PiBIaSBCcmlhbiwNCj4gPj4+DQo+ID4+PiAoMSkgRm9yIGZvcndhcmQgc2lnbmFs aW5nLCB0aGUgc2VuZGluZyBlbmRwb2ludCBtdXN0IHBsYWNlICJzY3JhdGNoDQo+ID4+PiBzcGFj ZSIgaW4NCj4gPj4gdGhlIHBhY2tldCB3aXRoIGEgbGFiZWwgb24gaXQgc3RhdGluZyB0aGF0IGl0 J3Mgb2theSB0byBtb2RpZnk7IHRoaXMNCj4gPj4gb2theS10by1tb2RpZnkgc3RhdGUgaXMgZW5m b3JjZWQgYnkgYSBNQUMgd2hpY2ggb25seSB2ZXJpZmllcyB0aGUNCj4gPj4gbGVuZ3RoIGJ1dCBu b3QgdGhlIGNvbnRlbnQgb2YgdGhlIHNjcmF0Y2ggc3BhY2UuDQo+ID4+Pg0KPiA+Pj4gQ291bGQg eW91IHBsZWFzZSBlbGFib3JhdGUgaG93IGEgTUFDIGlzIHVzZWQgdG8gZW5mb3JjZSB0aGUNCj4g Pj4+IG9rYXktdG8tbW9kaWZ5DQo+ID4+IHN0YXRlPyBJcyBpdCBvbmx5IGFwcGxpY2FibGUgdG8g TDIgbmV0d29yaz8NCj4gPj4NCj4gPj4gU29ycnksIGFjcm9ueW0gY29sbGlzaW9uLiBIZXJlIE1B QyA9IG1lc3NhZ2UgYXV0aGVudGljYXRpb24gY29kZSwgbm90DQo+ID4+IG1lZGl1bSBhY2Nlc3Mg Y29udHJvbC4NCj4gPj4NCj4gPj4+IElzIGl0IGEgZGVzaWduZWQgZmllbGQgaW4gdGhlIFBMVVMg aGVhZGVyPw0KPiA+Pg0KPiA+PiBUaGVyZSBpc24ndCBhICJQTFVTIGhlYWRlciIgeWV0OyB3ZSdy ZSBvbmx5IHRhbGtpbmcgYWJvdXQgcG90ZW50aWFsDQo+ID4+IG1lY2hhbmlzbXMgdGhhdCBjb3Vs ZCBiZSBpbXBsZW1lbnRlZCB3aXRoaW4gb25lLiBIZXJlLCB0aGUgaWRlYSBpcw0KPiA+PiB0aGF0 IHlvdSBoYXZlIHNvbWUgZW5jb2RpbmcgdGhhdCBhbGxvd3MgeW91IHRvIHBsYWNlIGxhYmVsZWQg ZGF0YSBpbg0KPiA+PiB0aGUgUExVUyBoZWFkZXIgKGZyb20gdGhlIFNQVUQgcHJvdG90eXBlIGV4 cGVyaWVuY2UsIHdlIGxpa2UgQ0JPUiwNCj4gPj4gYnV0IHRoaXMgaXMgYSB0ZWNobmljYWwgZGV0 YWlsKS4NCj4gPj4NCj4gPj4gU29tZSBvZiB0aGUgdHlwZXMva2V5cyBpbiB0aGlzIGRhdGEgc3Ry dWN0dXJlIGFyZSBkZXNpZ25hdGVkDQo+ID4+IGVuZC10by1lbmQsIGFuZCBzb21lIG9mIHRoZSB0 eXBlcy9rZXlzIGFyZSBkZXNpZ25hdGVkIHBhdGgtbW9kaWZpYWJsZS4NCj4gPj4NCj4gPj4gVGhl IE1BQyBpcyBnZW5lcmF0ZWQgYnkgdGhlIHNlbmRpbmcgZW5kcG9pbnQgdXNpbmcgYSBzZWNyZXQg c2hhcmVkIGJ5DQo+ID4+IGJvdGggZW5kcG9pbnRzLCBhbmQgY292ZXJzOg0KPiA+DQo+ID4gSG93 IGlzIHRoZSBzZWNyZXQgc2hhcmVkIGJldHdlZW4gYm90aCBlbmRwb2ludHM/IFRoZSBlbmRwb2lu dHMgbmVlZCB0bw0KPiBlc3RhYmxpc2ggYSBjb25uZWN0aW9uIHRvIGV4Y2hhbmdlIGtleXM/DQo+ IA0KPiBZZXMuIFRoaXMgaXMgYXNzdW1lZCB0byBiZSBwcm92aWRlZCBieSB0aGUgc3VwZXJzdHJh dGUgdHJhbnNwb3J0Lg0KPiA+DQo+ID4+ICgxKSB0aGUgcHJlc2VuY2UgYW5kIGNvbnRlbnQgb2Yg ZW5kLXRvLWVuZCBQTFVTIGhlYWRlciBpbmZvcm1hdGlvbg0KPiA+DQo+ID4gRG8geW91IG1lYW4g dGhhdCB0aGlzIGluZm9ybWF0aW9uIGlzIGVuY3J5cHRlZCB1c2luZyB0aGUgc2hhcmVkIHNlY3Jl dD8NCj4gT25seSBib3RoIGVuZHBvaW50cyBjYW4ga25vdyB0aGUgY29udGVudD8NCj4gDQo+IE5v LCB0aGUgTUFDIGlzIGdlbmVyYXRlZCB1c2luZyB0aGUgc2hhcmVkIHNlY3JldCwgc28gdGhhdCBp dCBjYW5ub3QgYmUgZm9yZ2VkDQo+IGJ5IG9uLXBhdGggZGV2aWNlcy4gVGhlIGluZm9ybWF0aW9u IGl0c2VsZiBpcyBpbiB0aGUgY2xlYXIuDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBCcmlhbg0KPiAN Cj4gPj4gKDIpIHRoZSBwcmVzZW5jZSBhbmQgbGVuZ3RoIG9mIHBhdGgtbW9kaWZpYWJsZSBQTFVT IGhlYWRlcg0KPiA+PiBpbmZvcm1hdGlvbiwgYnkgdHJlYXRpbmcgdGhlIGNvbnRlbnQgYXMgYSBs ZW5ndGgtTiBieXRlIGFycmF5IG9mIHplcm9lcy4NCj4gPg0KPiA+IEhvdyBkb2VzIHRoZSBtaWRk bGUtYm94IGFsb25nIHRoZSBwYXRoIGludGVycHJldCB0aGUgUExVUyBoZWFkZXI/IERvZXMNCj4g dGhlIG1pZGRsZS1ib3ggYWxzbyBuZWVkIHRoZSBzZWNyZXQ/IEkgdXNlZCB0byB0aGluayBtaWRk bGUtYm94IGlzIHRyYW5zcGFyZW50Lg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IEppYW5qaWUNCj4g Pg0KPiA+PiBUaGlzIE1BQyBpcyB0aGVuIHRyYW5zbWl0dGVkIGZyb20gdGhlIHNlbmRlciB0byB0 aGUgcmVjZWl2ZXIgaW4NCj4gPj4gZW5jcnlwdGVkIGZvcm0uDQo+ID4+DQo+ID4+IEFkZGl0aW9u YWwgTUFDcyBtYXkgYWxzbyBwcm90ZWN0IGJpdHMgb2YgdGhlIElQIGFuZCBVRFAgaGVhZGVyLCBp bg0KPiA+PiBvcmRlciB0byBkZXRlY3QgTkFUIGFuZCBvdGhlciBzdWItUExVUyBtb2RpZmljYXRp b25zLCBidXQgdGhlc2UgYXJlDQo+ID4+IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgcXVlc3Rp b24uDQo+ID4+DQo+ID4+IENoZWVycywNCj4gPj4NCj4gPj4gQnJpYW4NCj4gPj4NCj4gPj4NCj4g Pj4+DQo+ID4+PiBUaGFua3MsDQo+ID4+PiBKaWFuamllDQo+ID4+Pg0KPiA+Pj4g5Y+R5Lu25Lq6 OiBTcHVkIFttYWlsdG86c3B1ZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggQnJpYW4gVHJhbW1l bGwNCj4gPj4+IOWPkemAgeaXtumXtDogMjAxNuW5tDbmnIgyMeaXpSAxNzozNg0KPiA+Pj4g5pS2 5Lu25Lq6OiBBYXJvbiBGYWxrDQo+ID4+PiDmioTpgIE6IHNwdWQNCj4gPj4+IOS4u+mimDogUmU6 IFtTcHVkXSBlbmRwb2ludCBjb250cm9sDQo+ID4+Pg0KPiA+Pj4gaGkgQWFyb24sDQo+ID4+Pg0K PiA+Pj4gT24gMDYvMjAvMjAxNiAxMTozOCBQTSwgQWFyb24gRmFsayB3cm90ZToNCj4gPj4+IEhp IEJyaWFuLQ0KPiA+Pj4NCj4gPj4+IEluIHRoZSBjaGFydGVyIGFuZCB0aGUgZHJhZnQtdHJhbW1l bC1zcHVkLXJlcSBpdCBzYXlzDQo+ID4+Pg0KPiA+Pj4gICBCb3RoIGVuZHBvaW50LXRvLXBhdGgg YW5kIHBhdGgtdG8tZW5kcG9pbnQgc2lnbmFsaW5nIGhhcHBlbg0KPiA+Pj4gICBjb21wbGV0ZWx5 IHVuZGVyIGVuZHBvaW50IGNvbnRyb2wuDQo+ID4+Pg0KPiA+Pj4gV2l0aG91dCBhZGRpdGlvbmFs IGVsYWJvcmF0aW9uLCBvbmUgY291bGQgY29uY2x1ZGUgdGhhdCwgZS5nLiwNCj4gPj4+IHBlcm1p c3Npb24gaXMNCj4gPj4gcmVxdWlyZWQgYmVmb3JlIGEgcGF0aCBjb3VsZCBzaWduYWwgdG8gYW4g ZW5kcG9pbnQuICBBbHRlcm5hdGl2ZWx5LA0KPiA+PiBpdCBjb3VsZCBiZSBpbXBseWluZyBhbiBl bmRwb2ludCBoYXMgdGhlIGZyZWVkb20gdG8gaWdub3JlIGFueSBzaWduYWxpbmcNCj4gZnJvbSB0 aGUgcGF0aC4NCj4gPj4gSSBoYXZlIGJlZW4gYXNzdW1pbmcgdGhlIGxhdHRlci4gIEJ1dCBub3cg SSB3b25kZXIgaWYgeW91IGFyZQ0KPiA+PiBpbnRlbnRpb25hbGx5IGF0dGVtcHRpbmcgdG8gcGVy bWl0IHRoZSBmb3JtZXIuICBDb3VsZCB5b3UgY2xhcmlmeT8NCj4gPj4+DQo+ID4+PiBPdXIgaW50 ZW50aW9uIGlzIHRoZSBmb3JtZXI6IHRoYXQgcGVybWlzc2lvbiBpcyByZXF1aXJlZCBiZWZvcmUg dGhlDQo+ID4+PiBwYXRoIGNhbg0KPiA+PiBzaWduYWwgdG8gdGhlIGVuZHBvaW50LiBXZSBoYXZl IHR3byBtZWNoYW5pc21zIHdlJ3ZlIGJlZW4gdGhpbmtpbmcNCj4gPj4gYWJvdXQgZm9yIHRoaXM6 DQo+ID4+Pg0KPiA+Pj4gKDEpIEZvciBmb3J3YXJkIHNpZ25hbGluZywgdGhlIHNlbmRpbmcgZW5k cG9pbnQgbXVzdCBwbGFjZSAic2NyYXRjaA0KPiA+Pj4gc3BhY2UiIGluDQo+ID4+IHRoZSBwYWNr ZXQgd2l0aCBhIGxhYmVsIG9uIGl0IHN0YXRpbmcgdGhhdCBpdCdzIG9rYXkgdG8gbW9kaWZ5OyB0 aGlzDQo+ID4+IG9rYXktdG8tbW9kaWZ5IHN0YXRlIGlzIGVuZm9yY2VkIGJ5IGEgTUFDIHdoaWNo IG9ubHkgdmVyaWZpZXMgdGhlDQo+ID4+IGxlbmd0aCBidXQgbm90IHRoZSBjb250ZW50IG9mIHRo ZSBzY3JhdGNoIHNwYWNlLg0KPiA+Pj4NCj4gPj4+ICgyKSBGb3IgZGlyZWN0IHJldmVyc2Ugc2ln bmFsaW5nLCBhIHBhdGggZWxlbWVudCBtYXkgbm90IHNlbmQgYQ0KPiA+Pj4gZGlyZWN0IHJldmVy c2UNCj4gPj4gc2lnbmFsaW5nIHBhY2tldCB0byBhIHNlbmRlciB1bmxlc3MgaXQgaGFzIGFsc28g ZHJvcHBlZCBhIGZvcndhcmQNCj4gPj4gcGFja2V0IGZyb20gdGhlIHNlbmRlciB0byByZWNlaXZl ci4gVGhpcyBzZWNvbmQgbWVjaGFuaXNtIGlzIGxlc3MNCj4gPj4gYWJvdXQgcGVybWlzc2lvbiBh bmQgbW9yZSBhYm91dCByZWR1Y2luZyB0aGUgYXR0cmFjdGl2ZW5lc3Mgb2YgUExVUw0KPiA+PiBm b3IgYW1wbGlmaWNhdGlvbi9yZWZsZWN0aW9uIGF0dGFja3MuDQo+ID4+Pg0KPiA+Pj4gSW4gYW55 IGNhc2UsIGVuZHBvaW50cyAoYW5kIHBhdGggZWxlbWVudHMpIGNhbiBpZ25vcmUgd2hhdGV2ZXIg dGhleQ0KPiA+Pj4gd2FudCB0bw0KPiA+PiBmcm9tIHRoZSBQTFVTLWV4cG9zZWQgaW5mb3JtYXRp b247IGl0J3Mgd2hhdCdzIGluIHRoZSBlbmNyeXB0ZWQNCj4gPj4gdHJhbnNwb3J0IGxheWVyIGhl YWRlcnMgdGhhdCBtYXR0ZXJzIHRvIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgb24gdGhlDQo+IGVu ZHBvaW50Lg0KPiA+Pj4NCj4gPj4+IENoZWVycywNCj4gPj4+DQo+ID4+PiBCcmlhbg0KPiA+Pj4N Cj4gPj4+DQo+ID4+PiBUaGFua3MsDQo+ID4+Pg0KPiA+Pj4g4oCUYWFyb24NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4+IFNwdWQgbWFpbGluZyBsaXN0DQo+ID4+PiBTcHVk QGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nw dWQNCj4gPj4+DQo+ID4NCg0K From nobody Thu Jun 23 01:11: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 8553F12D12B for ; Thu, 23 Jun 2016 01:11: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 DDX7g3rifDof for ; Thu, 23 Jun 2016 01:11:46 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7E64112D107 for ; Thu, 23 Jun 2016 01:11:46 -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 5AE7A1A1530; Thu, 23 Jun 2016 10:11:15 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_59A964F7-5AE4-4C9F-BFA4-0D2862E67D53"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Thu, 23 Jun 2016 10:11:16 +0200 Message-Id: <4F02B71A-5F3F-4595-8661-51CE07E9F0E5@trammell.ch> References: <57690A66.3050502@trammell.ch> <095C2E5D-D235-4017-91E2-9B437D8DBDD0@trammell.ch> To: Youjianjie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Aaron Falk , spud Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 08:11:49 -0000 --Apple-Mail=_59A964F7-5AE4-4C9F-BFA4-0D2862E67D53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 Jun 2016, at 10:03, Youjianjie wrote: >=20 > Hi Brian, >=20 > I'm wondering how the endpoint verifies the information provided by = the device on path? In the basic mechanism I've outlined here, it doesn't. If there exists = some relationship between the endpoint and the device on path, then the = information provided with in the PLUS header can itself be MAC'd with a = key exchanged when that relationship is established. > Is it also assumed that the key is provided by the superstrate = transport between the device on path and the endpoint? No, that doesn't really make any sense, because the transport is = end-to-end (as was the original intent of the network/transport layer = separation). Any key for authenticating and verifying endpoint-provided = information would have to reside in the PLUS layer on the endpoint. I think at this point mechanisms for *establishing* these relationships = are out of scope for a future PLUS WG (at least, they were left out of = the charter deliberately), since we're really talking about the design = of new multiparty cryptographic protocols. But I notice that the = mechanism we're discussing here two primitives (provide information to = the path that at least the remote endpoint can verify is authentic, = retrieve information from the path with sender permission) on top of = which such protocols could be designed. Cheers, Brian > Thanks, > Jianjie >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Brian Trammell [mailto:ietf@trammell.ch] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8822=E6=97=A5= 18:45 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Youjianjie >> =E6=8A=84=E9=80=81: Aaron Falk; spud >> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>=20 >>=20 >>> On 22 Jun 2016, at 11:35, Youjianjie wrote: >>>=20 >>> Hi Brian, >>>=20 >>> Thanks for your prompt reply. Please see my comments below: >>>=20 >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Brian Trammell = [mailto:ietf@trammell.ch] >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8822=E6=97= =A5 16:56 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Youjianjie >>>> =E6=8A=84=E9=80=81: Aaron Falk; spud >>>> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>>>=20 >>>> hi Jianjie, >>>>=20 >>>>> On 22 Jun 2016, at 09:09, Youjianjie = wrote: >>>>>=20 >>>>> Hi Brian, >>>>>=20 >>>>> (1) For forward signaling, the sending endpoint must place = "scratch >>>>> space" in >>>> the packet with a label on it stating that it's okay to modify; = this >>>> okay-to-modify state is enforced by a MAC which only verifies the >>>> length but not the content of the scratch space. >>>>>=20 >>>>> Could you please elaborate how a MAC is used to enforce the >>>>> okay-to-modify >>>> state? Is it only applicable to L2 network? >>>>=20 >>>> Sorry, acronym collision. Here MAC =3D message authentication code, = not >>>> medium access control. >>>>=20 >>>>> Is it a designed field in the PLUS header? >>>>=20 >>>> There isn't a "PLUS header" yet; we're only talking about potential >>>> mechanisms that could be implemented within one. Here, the idea is >>>> that you have some encoding that allows you to place labeled data = in >>>> the PLUS header (from the SPUD prototype experience, we like CBOR, >>>> but this is a technical detail). >>>>=20 >>>> Some of the types/keys in this data structure are designated >>>> end-to-end, and some of the types/keys are designated = path-modifiable. >>>>=20 >>>> The MAC is generated by the sending endpoint using a secret shared = by >>>> both endpoints, and covers: >>>=20 >>> How is the secret shared between both endpoints? The endpoints need = to >> establish a connection to exchange keys? >>=20 >> Yes. This is assumed to be provided by the superstrate transport. >>>=20 >>>> (1) the presence and content of end-to-end PLUS header information >>>=20 >>> Do you mean that this information is encrypted using the shared = secret? >> Only both endpoints can know the content? >>=20 >> No, the MAC is generated using the shared secret, so that it cannot = be forged >> by on-path devices. The information itself is in the clear. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>>> (2) the presence and length of path-modifiable PLUS header >>>> information, by treating the content as a length-N byte array of = zeroes. >>>=20 >>> How does the middle-box along the path interpret the PLUS header? = Does >> the middle-box also need the secret? I used to think middle-box is = transparent. >>>=20 >>> Thanks, >>> Jianjie >>>=20 >>>> This MAC is then transmitted from the sender to the receiver in >>>> encrypted form. >>>>=20 >>>> Additional MACs may also protect bits of the IP and UDP header, in >>>> order to detect NAT and other sub-PLUS modifications, but these are >>>> outside the scope of this question. >>>>=20 >>>> Cheers, >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Jianjie >>>>>=20 >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Spud [mailto:spud-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Brian Trammell >>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8821=E6=97= =A5 17:36 >>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Aaron Falk >>>>> =E6=8A=84=E9=80=81: spud >>>>> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>>>>=20 >>>>> hi Aaron, >>>>>=20 >>>>> On 06/20/2016 11:38 PM, Aaron Falk wrote: >>>>> Hi Brian- >>>>>=20 >>>>> In the charter and the draft-trammel-spud-req it says >>>>>=20 >>>>> Both endpoint-to-path and path-to-endpoint signaling happen >>>>> completely under endpoint control. >>>>>=20 >>>>> Without additional elaboration, one could conclude that, e.g., >>>>> permission is >>>> required before a path could signal to an endpoint. Alternatively, >>>> it could be implying an endpoint has the freedom to ignore any = signaling >> from the path. >>>> I have been assuming the latter. But now I wonder if you are >>>> intentionally attempting to permit the former. Could you clarify? >>>>>=20 >>>>> Our intention is the former: that permission is required before = the >>>>> path can >>>> signal to the endpoint. We have two mechanisms we've been thinking >>>> about for this: >>>>>=20 >>>>> (1) For forward signaling, the sending endpoint must place = "scratch >>>>> space" in >>>> the packet with a label on it stating that it's okay to modify; = this >>>> okay-to-modify state is enforced by a MAC which only verifies the >>>> length but not the content of the scratch space. >>>>>=20 >>>>> (2) For direct reverse signaling, a path element may not send a >>>>> direct reverse >>>> signaling packet to a sender unless it has also dropped a forward >>>> packet from the sender to receiver. This second mechanism is less >>>> about permission and more about reducing the attractiveness of PLUS >>>> for amplification/reflection attacks. >>>>>=20 >>>>> In any case, endpoints (and path elements) can ignore whatever = they >>>>> want to >>>> from the PLUS-exposed information; it's what's in the encrypted >>>> transport layer headers that matters to the transport protocol on = the >> endpoint. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> =E2=80=94aaron >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Spud mailing list >>>>> Spud@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spud >>>>>=20 >>>=20 >=20 --Apple-Mail=_59A964F7-5AE4-4C9F-BFA4-0D2862E67D53 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 iQIcBAEBCgAGBQJXa5mkAAoJEIoSt78L6kajCf4P/ily4ZpYNKJrNXLri8j1NMQ2 H7EnM60JQSvtIzAEsVE7SB1pz80uwi26K0M2JoEfu0BnnzgGlKGzjeqxRJnj3XDC oIb60hBoeXXQw2GCGoULoy/CF7M9uDodz0dm7ij7fZy943eUHg6rARHnEVHIk8k+ nYxzGGjpBE+CdfQGChBFtWQ53qpEUFExUgDwKkKDbO0REheRcSnr/ETxIo8U64GR wir68hiD9TA4va/r8IFVvXChBJssac3yuEuHhYoqH2Sc3/22Cj5dQX0jn6Kt745o mOH5TnXXArV2fX4fJzVX045rAmpg6SoA1SqbwXgjB4kbpXCzshjFZSev12YVdZF8 cWmO8lww9aN96FUeDn6YJieKqAi6l5lpkaJZFCxaYCMEaI1lvUUMhZeFKtdj+mkW i7/zccdGgiB3TyXvsFzE0qAVfqP/5e94u+6Gr9c/2ikKgSgaSWcaAA5CKWsF1v4y NJVoqcnYIog1sXl+pUXIH/oeDb5ILQc+1aofCwepWZjPCc/Gw+b7rWlP5mvnlb3I o6L2XhKxPSyVFT7zjZHtMwVJ5xxJJD6SJhgnZqp+D2Vzr7/H0Ux8m0FtrkW07B/z pSEfIPBXwFPjhiqz1oYT4nuPx8H4TxpyZMRVIOUtSbT+gtmvtCpINCOwjcPUvvQg DlOEIgJJ0v3GgddTR9we =qXTl -----END PGP SIGNATURE----- --Apple-Mail=_59A964F7-5AE4-4C9F-BFA4-0D2862E67D53-- From nobody Thu Jun 23 01:56: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 DD18312DF95 for ; Thu, 23 Jun 2016 01:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, 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 BXEVaoOBSNSj for ; Thu, 23 Jun 2016 01:56:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD6312DFA0 for ; Thu, 23 Jun 2016 01:55:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CML60362; Thu, 23 Jun 2016 08:55:35 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 23 Jun 2016 09:55:35 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 23 Jun 2016 16:55:30 +0800 From: Youjianjie To: Brian Trammell Thread-Topic: [Spud] endpoint control Thread-Index: AQHRyzwoxDCBxuKTZk6d9wR8LfPe/p/zI/AAgAHtRPD//5oTAIAAjlgQ//+QBoCAAdzVQP//ipIAABHnY6A= Date: Thu, 23 Jun 2016 08:55:30 +0000 Message-ID: References: <57690A66.3050502@trammell.ch> <095C2E5D-D235-4017-91E2-9B437D8DBDD0@trammell.ch> <4F02B71A-5F3F-4595-8661-51CE07E9F0E5@trammell.ch> In-Reply-To: <4F02B71A-5F3F-4595-8661-51CE07E9F0E5@trammell.ch> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.576BA408.01B8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6e2b91d179913d9b22f9f8b2aa8cf3a6 Archived-At: Cc: Aaron Falk , spud Subject: [Spud] =?utf-8?b?562U5aSNOiAgZW5kcG9pbnQgY29udHJvbA==?= 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, 23 Jun 2016 08:56:06 -0000 SGkgQnJpYW4sDQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5LiANCg0KPiBJIHRoaW5rIGF0IHRoaXMg cG9pbnQgbWVjaGFuaXNtcyBmb3IgKmVzdGFibGlzaGluZyogdGhlc2UgcmVsYXRpb25zaGlwcyBh cmUgb3V0DQo+IG9mIHNjb3BlIGZvciBhIGZ1dHVyZSBQTFVTIFdHIChhdCBsZWFzdCwgdGhleSB3 ZXJlIGxlZnQgb3V0IG9mIHRoZSBjaGFydGVyDQo+IGRlbGliZXJhdGVseSksIHNpbmNlIHdlJ3Jl IHJlYWxseSB0YWxraW5nIGFib3V0IHRoZSBkZXNpZ24gb2YgbmV3IG11bHRpcGFydHkNCj4gY3J5 cHRvZ3JhcGhpYyBwcm90b2NvbHMuIEJ1dCBJIG5vdGljZSB0aGF0IHRoZSBtZWNoYW5pc20gd2Un cmUgZGlzY3Vzc2luZyBoZXJlDQo+IHR3byBwcmltaXRpdmVzIChwcm92aWRlIGluZm9ybWF0aW9u IHRvIHRoZSBwYXRoIHRoYXQgYXQgbGVhc3QgdGhlIHJlbW90ZQ0KPiBlbmRwb2ludCBjYW4gdmVy aWZ5IGlzIGF1dGhlbnRpYywgcmV0cmlldmUgaW5mb3JtYXRpb24gZnJvbSB0aGUgcGF0aCB3aXRo DQo+IHNlbmRlciBwZXJtaXNzaW9uKSBvbiB0b3Agb2Ygd2hpY2ggc3VjaCBwcm90b2NvbHMgY291 bGQgYmUgZGVzaWduZWQuDQoNCigxKSBJZiB0aGUgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQgdG8g dGhlIHBhdGgsIHdoeSB0aGUgcmVtb3RlIGVuZHBvaW50IG5lZWRzIHRvIHZlcmlmeSBhdXRoZW50 aWM/IElzIHRoaXMgaW5mb3JtYXRpb24gYWxzbyB1c2VmdWwgZm9yIHRoZSByZW1vdGUgZW5kcG9p bnQ/IA0KDQooMikgRXZlbiBpZiB0aGUgcmV0cmlldmVkIGluZm9ybWF0aW9uIGZyb20gdGhlIHBh dGggd2l0aCBzZW5kZXIgcGVybWlzc2lvbiwgdGhlIHJlY2VpdmVyIGNhbm5vdCB2ZXJpZnkgdGhl IGluZm9ybWF0aW9uIChpLmUuIGNvbnRlbnQpIGlzIGF1dGhlbnRpYz8gDQoNClRoYW5rcywNCkpp YW5qaWUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogU3B1ZCBbbWFp bHRvOnNwdWQtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEJyaWFuIFRyYW1tZWxsDQo+IOWPkemA geaXtumXtDogMjAxNuW5tDbmnIgyM+aXpSAxNjoxMQ0KPiDmlLbku7bkuro6IFlvdWppYW5qaWUN Cj4g5oqE6YCBOiBBYXJvbiBGYWxrOyBzcHVkDQo+IOS4u+mimDogUmU6IFtTcHVkXSBlbmRwb2lu dCBjb250cm9sDQo+IA0KPiANCj4gPiBPbiAyMyBKdW4gMjAxNiwgYXQgMTA6MDMsIFlvdWppYW5q aWUgPHlvdWppYW5qaWVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBCcmlhbiwNCj4g Pg0KPiA+IEknbSB3b25kZXJpbmcgaG93IHRoZSBlbmRwb2ludCB2ZXJpZmllcyB0aGUgaW5mb3Jt YXRpb24gcHJvdmlkZWQgYnkgdGhlDQo+IGRldmljZSBvbiBwYXRoPw0KPiANCj4gSW4gdGhlIGJh c2ljIG1lY2hhbmlzbSBJJ3ZlIG91dGxpbmVkIGhlcmUsIGl0IGRvZXNuJ3QuIElmIHRoZXJlIGV4 aXN0cyBzb21lDQo+IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBlbmRwb2ludCBhbmQgdGhlIGRl dmljZSBvbiBwYXRoLCB0aGVuIHRoZQ0KPiBpbmZvcm1hdGlvbiBwcm92aWRlZCB3aXRoIGluIHRo ZSBQTFVTIGhlYWRlciBjYW4gaXRzZWxmIGJlIE1BQydkIHdpdGggYSBrZXkNCj4gZXhjaGFuZ2Vk IHdoZW4gdGhhdCByZWxhdGlvbnNoaXAgaXMgZXN0YWJsaXNoZWQuDQo+IA0KPiA+IElzIGl0IGFs c28gYXNzdW1lZCB0aGF0IHRoZSBrZXkgaXMgcHJvdmlkZWQgYnkgdGhlIHN1cGVyc3RyYXRlIHRy YW5zcG9ydA0KPiBiZXR3ZWVuIHRoZSBkZXZpY2Ugb24gcGF0aCBhbmQgdGhlIGVuZHBvaW50Pw0K PiANCj4gTm8sIHRoYXQgZG9lc24ndCByZWFsbHkgbWFrZSBhbnkgc2Vuc2UsIGJlY2F1c2UgdGhl IHRyYW5zcG9ydCBpcyBlbmQtdG8tZW5kIChhcw0KPiB3YXMgdGhlIG9yaWdpbmFsIGludGVudCBv ZiB0aGUgbmV0d29yay90cmFuc3BvcnQgbGF5ZXIgc2VwYXJhdGlvbikuIEFueSBrZXkgZm9yDQo+ IGF1dGhlbnRpY2F0aW5nIGFuZCB2ZXJpZnlpbmcgZW5kcG9pbnQtcHJvdmlkZWQgaW5mb3JtYXRp b24gd291bGQgaGF2ZSB0bw0KPiByZXNpZGUgaW4gdGhlIFBMVVMgbGF5ZXIgb24gdGhlIGVuZHBv aW50Lg0KPiANCj4gSSB0aGluayBhdCB0aGlzIHBvaW50IG1lY2hhbmlzbXMgZm9yICplc3RhYmxp c2hpbmcqIHRoZXNlIHJlbGF0aW9uc2hpcHMgYXJlIG91dA0KPiBvZiBzY29wZSBmb3IgYSBmdXR1 cmUgUExVUyBXRyAoYXQgbGVhc3QsIHRoZXkgd2VyZSBsZWZ0IG91dCBvZiB0aGUgY2hhcnRlcg0K PiBkZWxpYmVyYXRlbHkpLCBzaW5jZSB3ZSdyZSByZWFsbHkgdGFsa2luZyBhYm91dCB0aGUgZGVz aWduIG9mIG5ldyBtdWx0aXBhcnR5DQo+IGNyeXB0b2dyYXBoaWMgcHJvdG9jb2xzLiBCdXQgSSBu b3RpY2UgdGhhdCB0aGUgbWVjaGFuaXNtIHdlJ3JlIGRpc2N1c3NpbmcgaGVyZQ0KPiB0d28gcHJp bWl0aXZlcyAocHJvdmlkZSBpbmZvcm1hdGlvbiB0byB0aGUgcGF0aCB0aGF0IGF0IGxlYXN0IHRo ZSByZW1vdGUNCj4gZW5kcG9pbnQgY2FuIHZlcmlmeSBpcyBhdXRoZW50aWMsIHJldHJpZXZlIGlu Zm9ybWF0aW9uIGZyb20gdGhlIHBhdGggd2l0aA0KPiBzZW5kZXIgcGVybWlzc2lvbikgb24gdG9w IG9mIHdoaWNoIHN1Y2ggcHJvdG9jb2xzIGNvdWxkIGJlIGRlc2lnbmVkLg0KPiANCj4gQ2hlZXJz LA0KPiANCj4gQnJpYW4NCj4gDQo+ID4gVGhhbmtzLA0KPiA+IEppYW5qaWUNCj4gPg0KPiA+PiAt LS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4+IOWPkeS7tuS6ujogQnJpYW4gVHJhbW1lbGwgW21h aWx0bzppZXRmQHRyYW1tZWxsLmNoXQ0KPiA+PiDlj5HpgIHml7bpl7Q6IDIwMTblubQ25pyIMjLm l6UgMTg6NDUNCj4gPj4g5pS25Lu25Lq6OiBZb3VqaWFuamllDQo+ID4+IOaKhOmAgTogQWFyb24g RmFsazsgc3B1ZA0KPiA+PiDkuLvpopg6IFJlOiBbU3B1ZF0gZW5kcG9pbnQgY29udHJvbA0KPiA+ Pg0KPiA+Pg0KPiA+Pj4gT24gMjIgSnVuIDIwMTYsIGF0IDExOjM1LCBZb3VqaWFuamllIDx5b3Vq aWFuamllQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+IEhpIEJyaWFuLA0KPiA+Pj4N Cj4gPj4+IFRoYW5rcyBmb3IgeW91ciBwcm9tcHQgcmVwbHkuIFBsZWFzZSBzZWUgbXkgY29tbWVu dHMgYmVsb3c6DQo+ID4+Pg0KPiA+Pj4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gPj4+PiDl j5Hku7bkuro6IEJyaWFuIFRyYW1tZWxsIFttYWlsdG86aWV0ZkB0cmFtbWVsbC5jaF0NCj4gPj4+ PiDlj5HpgIHml7bpl7Q6IDIwMTblubQ25pyIMjLml6UgMTY6NTYNCj4gPj4+PiDmlLbku7bkuro6 IFlvdWppYW5qaWUNCj4gPj4+PiDmioTpgIE6IEFhcm9uIEZhbGs7IHNwdWQNCj4gPj4+PiDkuLvp opg6IFJlOiBbU3B1ZF0gZW5kcG9pbnQgY29udHJvbA0KPiA+Pj4+DQo+ID4+Pj4gaGkgSmlhbmpp ZSwNCj4gPj4+Pg0KPiA+Pj4+PiBPbiAyMiBKdW4gMjAxNiwgYXQgMDk6MDksIFlvdWppYW5qaWUg PHlvdWppYW5qaWVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+IEhpIEJyaWFu LA0KPiA+Pj4+Pg0KPiA+Pj4+PiAoMSkgRm9yIGZvcndhcmQgc2lnbmFsaW5nLCB0aGUgc2VuZGlu ZyBlbmRwb2ludCBtdXN0IHBsYWNlDQo+ID4+Pj4+ICJzY3JhdGNoIHNwYWNlIiBpbg0KPiA+Pj4+ IHRoZSBwYWNrZXQgd2l0aCBhIGxhYmVsIG9uIGl0IHN0YXRpbmcgdGhhdCBpdCdzIG9rYXkgdG8g bW9kaWZ5Ow0KPiA+Pj4+IHRoaXMgb2theS10by1tb2RpZnkgc3RhdGUgaXMgZW5mb3JjZWQgYnkg YSBNQUMgd2hpY2ggb25seSB2ZXJpZmllcw0KPiA+Pj4+IHRoZSBsZW5ndGggYnV0IG5vdCB0aGUg Y29udGVudCBvZiB0aGUgc2NyYXRjaCBzcGFjZS4NCj4gPj4+Pj4NCj4gPj4+Pj4gQ291bGQgeW91 IHBsZWFzZSBlbGFib3JhdGUgaG93IGEgTUFDIGlzIHVzZWQgdG8gZW5mb3JjZSB0aGUNCj4gPj4+ Pj4gb2theS10by1tb2RpZnkNCj4gPj4+PiBzdGF0ZT8gSXMgaXQgb25seSBhcHBsaWNhYmxlIHRv IEwyIG5ldHdvcms/DQo+ID4+Pj4NCj4gPj4+PiBTb3JyeSwgYWNyb255bSBjb2xsaXNpb24uIEhl cmUgTUFDID0gbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlLA0KPiA+Pj4+IG5vdCBtZWRpdW0g YWNjZXNzIGNvbnRyb2wuDQo+ID4+Pj4NCj4gPj4+Pj4gSXMgaXQgYSBkZXNpZ25lZCBmaWVsZCBp biB0aGUgUExVUyBoZWFkZXI/DQo+ID4+Pj4NCj4gPj4+PiBUaGVyZSBpc24ndCBhICJQTFVTIGhl YWRlciIgeWV0OyB3ZSdyZSBvbmx5IHRhbGtpbmcgYWJvdXQgcG90ZW50aWFsDQo+ID4+Pj4gbWVj aGFuaXNtcyB0aGF0IGNvdWxkIGJlIGltcGxlbWVudGVkIHdpdGhpbiBvbmUuIEhlcmUsIHRoZSBp ZGVhIGlzDQo+ID4+Pj4gdGhhdCB5b3UgaGF2ZSBzb21lIGVuY29kaW5nIHRoYXQgYWxsb3dzIHlv dSB0byBwbGFjZSBsYWJlbGVkIGRhdGENCj4gPj4+PiBpbiB0aGUgUExVUyBoZWFkZXIgKGZyb20g dGhlIFNQVUQgcHJvdG90eXBlIGV4cGVyaWVuY2UsIHdlIGxpa2UNCj4gPj4+PiBDQk9SLCBidXQg dGhpcyBpcyBhIHRlY2huaWNhbCBkZXRhaWwpLg0KPiA+Pj4+DQo+ID4+Pj4gU29tZSBvZiB0aGUg dHlwZXMva2V5cyBpbiB0aGlzIGRhdGEgc3RydWN0dXJlIGFyZSBkZXNpZ25hdGVkDQo+ID4+Pj4g ZW5kLXRvLWVuZCwgYW5kIHNvbWUgb2YgdGhlIHR5cGVzL2tleXMgYXJlIGRlc2lnbmF0ZWQgcGF0 aC1tb2RpZmlhYmxlLg0KPiA+Pj4+DQo+ID4+Pj4gVGhlIE1BQyBpcyBnZW5lcmF0ZWQgYnkgdGhl IHNlbmRpbmcgZW5kcG9pbnQgdXNpbmcgYSBzZWNyZXQgc2hhcmVkDQo+ID4+Pj4gYnkgYm90aCBl bmRwb2ludHMsIGFuZCBjb3ZlcnM6DQo+ID4+Pg0KPiA+Pj4gSG93IGlzIHRoZSBzZWNyZXQgc2hh cmVkIGJldHdlZW4gYm90aCBlbmRwb2ludHM/IFRoZSBlbmRwb2ludHMgbmVlZA0KPiA+Pj4gdG8N Cj4gPj4gZXN0YWJsaXNoIGEgY29ubmVjdGlvbiB0byBleGNoYW5nZSBrZXlzPw0KPiA+Pg0KPiA+ PiBZZXMuIFRoaXMgaXMgYXNzdW1lZCB0byBiZSBwcm92aWRlZCBieSB0aGUgc3VwZXJzdHJhdGUg dHJhbnNwb3J0Lg0KPiA+Pj4NCj4gPj4+PiAoMSkgdGhlIHByZXNlbmNlIGFuZCBjb250ZW50IG9m IGVuZC10by1lbmQgUExVUyBoZWFkZXIgaW5mb3JtYXRpb24NCj4gPj4+DQo+ID4+PiBEbyB5b3Ug bWVhbiB0aGF0IHRoaXMgaW5mb3JtYXRpb24gaXMgZW5jcnlwdGVkIHVzaW5nIHRoZSBzaGFyZWQg c2VjcmV0Pw0KPiA+PiBPbmx5IGJvdGggZW5kcG9pbnRzIGNhbiBrbm93IHRoZSBjb250ZW50Pw0K PiA+Pg0KPiA+PiBObywgdGhlIE1BQyBpcyBnZW5lcmF0ZWQgdXNpbmcgdGhlIHNoYXJlZCBzZWNy ZXQsIHNvIHRoYXQgaXQgY2Fubm90DQo+ID4+IGJlIGZvcmdlZCBieSBvbi1wYXRoIGRldmljZXMu IFRoZSBpbmZvcm1hdGlvbiBpdHNlbGYgaXMgaW4gdGhlIGNsZWFyLg0KPiA+Pg0KPiA+PiBDaGVl cnMsDQo+ID4+DQo+ID4+IEJyaWFuDQo+ID4+DQo+ID4+Pj4gKDIpIHRoZSBwcmVzZW5jZSBhbmQg bGVuZ3RoIG9mIHBhdGgtbW9kaWZpYWJsZSBQTFVTIGhlYWRlcg0KPiA+Pj4+IGluZm9ybWF0aW9u LCBieSB0cmVhdGluZyB0aGUgY29udGVudCBhcyBhIGxlbmd0aC1OIGJ5dGUgYXJyYXkgb2YgemVy b2VzLg0KPiA+Pj4NCj4gPj4+IEhvdyBkb2VzIHRoZSBtaWRkbGUtYm94IGFsb25nIHRoZSBwYXRo IGludGVycHJldCB0aGUgUExVUyBoZWFkZXI/DQo+ID4+PiBEb2VzDQo+ID4+IHRoZSBtaWRkbGUt Ym94IGFsc28gbmVlZCB0aGUgc2VjcmV0PyBJIHVzZWQgdG8gdGhpbmsgbWlkZGxlLWJveCBpcw0K PiB0cmFuc3BhcmVudC4NCj4gPj4+DQo+ID4+PiBUaGFua3MsDQo+ID4+PiBKaWFuamllDQo+ID4+ Pg0KPiA+Pj4+IFRoaXMgTUFDIGlzIHRoZW4gdHJhbnNtaXR0ZWQgZnJvbSB0aGUgc2VuZGVyIHRv IHRoZSByZWNlaXZlciBpbg0KPiA+Pj4+IGVuY3J5cHRlZCBmb3JtLg0KPiA+Pj4+DQo+ID4+Pj4g QWRkaXRpb25hbCBNQUNzIG1heSBhbHNvIHByb3RlY3QgYml0cyBvZiB0aGUgSVAgYW5kIFVEUCBo ZWFkZXIsIGluDQo+ID4+Pj4gb3JkZXIgdG8gZGV0ZWN0IE5BVCBhbmQgb3RoZXIgc3ViLVBMVVMg bW9kaWZpY2F0aW9ucywgYnV0IHRoZXNlIGFyZQ0KPiA+Pj4+IG91dHNpZGUgdGhlIHNjb3BlIG9m IHRoaXMgcXVlc3Rpb24uDQo+ID4+Pj4NCj4gPj4+PiBDaGVlcnMsDQo+ID4+Pj4NCj4gPj4+PiBC cmlhbg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhhbmtzLA0KPiA+Pj4+PiBK aWFuamllDQo+ID4+Pj4+DQo+ID4+Pj4+IOWPkeS7tuS6ujogU3B1ZCBbbWFpbHRvOnNwdWQtYm91 bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEJyaWFuIFRyYW1tZWxsDQo+ID4+Pj4+IOWPkemAgeaXtumX tDogMjAxNuW5tDbmnIgyMeaXpSAxNzozNg0KPiA+Pj4+PiDmlLbku7bkuro6IEFhcm9uIEZhbGsN Cj4gPj4+Pj4g5oqE6YCBOiBzcHVkDQo+ID4+Pj4+IOS4u+mimDogUmU6IFtTcHVkXSBlbmRwb2lu dCBjb250cm9sDQo+ID4+Pj4+DQo+ID4+Pj4+IGhpIEFhcm9uLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBP biAwNi8yMC8yMDE2IDExOjM4IFBNLCBBYXJvbiBGYWxrIHdyb3RlOg0KPiA+Pj4+PiBIaSBCcmlh bi0NCj4gPj4+Pj4NCj4gPj4+Pj4gSW4gdGhlIGNoYXJ0ZXIgYW5kIHRoZSBkcmFmdC10cmFtbWVs LXNwdWQtcmVxIGl0IHNheXMNCj4gPj4+Pj4NCj4gPj4+Pj4gIEJvdGggZW5kcG9pbnQtdG8tcGF0 aCBhbmQgcGF0aC10by1lbmRwb2ludCBzaWduYWxpbmcgaGFwcGVuDQo+ID4+Pj4+IGNvbXBsZXRl bHkgdW5kZXIgZW5kcG9pbnQgY29udHJvbC4NCj4gPj4+Pj4NCj4gPj4+Pj4gV2l0aG91dCBhZGRp dGlvbmFsIGVsYWJvcmF0aW9uLCBvbmUgY291bGQgY29uY2x1ZGUgdGhhdCwgZS5nLiwNCj4gPj4+ Pj4gcGVybWlzc2lvbiBpcw0KPiA+Pj4+IHJlcXVpcmVkIGJlZm9yZSBhIHBhdGggY291bGQgc2ln bmFsIHRvIGFuIGVuZHBvaW50LiAgQWx0ZXJuYXRpdmVseSwNCj4gPj4+PiBpdCBjb3VsZCBiZSBp bXBseWluZyBhbiBlbmRwb2ludCBoYXMgdGhlIGZyZWVkb20gdG8gaWdub3JlIGFueQ0KPiA+Pj4+ IHNpZ25hbGluZw0KPiA+PiBmcm9tIHRoZSBwYXRoLg0KPiA+Pj4+IEkgaGF2ZSBiZWVuIGFzc3Vt aW5nIHRoZSBsYXR0ZXIuICBCdXQgbm93IEkgd29uZGVyIGlmIHlvdSBhcmUNCj4gPj4+PiBpbnRl bnRpb25hbGx5IGF0dGVtcHRpbmcgdG8gcGVybWl0IHRoZSBmb3JtZXIuICBDb3VsZCB5b3UgY2xh cmlmeT8NCj4gPj4+Pj4NCj4gPj4+Pj4gT3VyIGludGVudGlvbiBpcyB0aGUgZm9ybWVyOiB0aGF0 IHBlcm1pc3Npb24gaXMgcmVxdWlyZWQgYmVmb3JlDQo+ID4+Pj4+IHRoZSBwYXRoIGNhbg0KPiA+ Pj4+IHNpZ25hbCB0byB0aGUgZW5kcG9pbnQuIFdlIGhhdmUgdHdvIG1lY2hhbmlzbXMgd2UndmUg YmVlbiB0aGlua2luZw0KPiA+Pj4+IGFib3V0IGZvciB0aGlzOg0KPiA+Pj4+Pg0KPiA+Pj4+PiAo MSkgRm9yIGZvcndhcmQgc2lnbmFsaW5nLCB0aGUgc2VuZGluZyBlbmRwb2ludCBtdXN0IHBsYWNl DQo+ID4+Pj4+ICJzY3JhdGNoIHNwYWNlIiBpbg0KPiA+Pj4+IHRoZSBwYWNrZXQgd2l0aCBhIGxh YmVsIG9uIGl0IHN0YXRpbmcgdGhhdCBpdCdzIG9rYXkgdG8gbW9kaWZ5Ow0KPiA+Pj4+IHRoaXMg b2theS10by1tb2RpZnkgc3RhdGUgaXMgZW5mb3JjZWQgYnkgYSBNQUMgd2hpY2ggb25seSB2ZXJp Zmllcw0KPiA+Pj4+IHRoZSBsZW5ndGggYnV0IG5vdCB0aGUgY29udGVudCBvZiB0aGUgc2NyYXRj aCBzcGFjZS4NCj4gPj4+Pj4NCj4gPj4+Pj4gKDIpIEZvciBkaXJlY3QgcmV2ZXJzZSBzaWduYWxp bmcsIGEgcGF0aCBlbGVtZW50IG1heSBub3Qgc2VuZCBhDQo+ID4+Pj4+IGRpcmVjdCByZXZlcnNl DQo+ID4+Pj4gc2lnbmFsaW5nIHBhY2tldCB0byBhIHNlbmRlciB1bmxlc3MgaXQgaGFzIGFsc28g ZHJvcHBlZCBhIGZvcndhcmQNCj4gPj4+PiBwYWNrZXQgZnJvbSB0aGUgc2VuZGVyIHRvIHJlY2Vp dmVyLiBUaGlzIHNlY29uZCBtZWNoYW5pc20gaXMgbGVzcw0KPiA+Pj4+IGFib3V0IHBlcm1pc3Np b24gYW5kIG1vcmUgYWJvdXQgcmVkdWNpbmcgdGhlIGF0dHJhY3RpdmVuZXNzIG9mIFBMVVMNCj4g Pj4+PiBmb3IgYW1wbGlmaWNhdGlvbi9yZWZsZWN0aW9uIGF0dGFja3MuDQo+ID4+Pj4+DQo+ID4+ Pj4+IEluIGFueSBjYXNlLCBlbmRwb2ludHMgKGFuZCBwYXRoIGVsZW1lbnRzKSBjYW4gaWdub3Jl IHdoYXRldmVyDQo+ID4+Pj4+IHRoZXkgd2FudCB0bw0KPiA+Pj4+IGZyb20gdGhlIFBMVVMtZXhw b3NlZCBpbmZvcm1hdGlvbjsgaXQncyB3aGF0J3MgaW4gdGhlIGVuY3J5cHRlZA0KPiA+Pj4+IHRy YW5zcG9ydCBsYXllciBoZWFkZXJzIHRoYXQgbWF0dGVycyB0byB0aGUgdHJhbnNwb3J0IHByb3Rv Y29sIG9uDQo+ID4+Pj4gdGhlDQo+ID4+IGVuZHBvaW50Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBDaGVl cnMsDQo+ID4+Pj4+DQo+ID4+Pj4+IEJyaWFuDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IFRo YW5rcywNCj4gPj4+Pj4NCj4gPj4+Pj4g4oCUYWFyb24NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+ Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4gU3B1ZCBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4g U3B1ZEBpZXRmLm9yZw0KPiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwdWQNCj4gPj4+Pj4NCj4gPj4+DQo+ID4NCg0K From nobody Thu Jun 23 02:21: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 5A5D012E17F for ; Thu, 23 Jun 2016 02:21:55 -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 umzywiuOtx7V for ; Thu, 23 Jun 2016 02:21:52 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6380B12E187 for ; Thu, 23 Jun 2016 02:15:47 -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 95FE71A16F7; Thu, 23 Jun 2016 11:15:46 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A4603F7B-146B-4837-92C8-CD78ACA61C2C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Thu, 23 Jun 2016 11:15:46 +0200 Message-Id: <1D5C1BA4-4359-4DC9-B1BA-2DF576AD4A92@trammell.ch> References: <57690A66.3050502@trammell.ch> <095C2E5D-D235-4017-91E2-9B437D8DBDD0@trammell.ch> <4F02B71A-5F3F-4595-8661-51CE07E9F0E5@trammell.ch> To: Youjianjie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Aaron Falk , spud Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 09:21:55 -0000 --Apple-Mail=_A4603F7B-146B-4837-92C8-CD78ACA61C2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 Jun 2016, at 10:55, Youjianjie wrote: >=20 > Hi Brian, >=20 > Thanks for the reply. >=20 >> I think at this point mechanisms for *establishing* these = relationships are out >> of scope for a future PLUS WG (at least, they were left out of the = charter >> deliberately), since we're really talking about the design of new = multiparty >> cryptographic protocols. But I notice that the mechanism we're = discussing here >> two primitives (provide information to the path that at least the = remote >> endpoint can verify is authentic, retrieve information from the path = with >> sender permission) on top of which such protocols could be designed. >=20 > (1) If the information is provided to the path, why the remote = endpoint needs to verify authentic? Is this information also useful for = the remote endpoint? It may be; one could envision future transports over PLUS where part of = the header is exposed but integrity protected, and the rest is = encrypted. Integrity protection of the PLUS-exposed information reduces = redundancy in the encrypted headers in this case. The other reason to do this is to detect and react to unauthorized = meddling in the PLUS header: this would appear as an error to the = receiver's transport layer, which could then reset the connection. In = this way the receiver acts as the verifier on behalf of all devices on = path. > (2) Even if the retrieved information from the path with sender = permission, the receiver cannot verify the information (i.e. content) is = authentic? Correct. Cheers, Brian > Thanks, > Jianjie >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Spud [mailto:spud-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Brian Trammell >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8823=E6=97=A5= 16:11 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Youjianjie >> =E6=8A=84=E9=80=81: Aaron Falk; spud >> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>=20 >>=20 >>> On 23 Jun 2016, at 10:03, Youjianjie wrote: >>>=20 >>> Hi Brian, >>>=20 >>> I'm wondering how the endpoint verifies the information provided by = the >> device on path? >>=20 >> In the basic mechanism I've outlined here, it doesn't. If there = exists some >> relationship between the endpoint and the device on path, then the >> information provided with in the PLUS header can itself be MAC'd with = a key >> exchanged when that relationship is established. >>=20 >>> Is it also assumed that the key is provided by the superstrate = transport >> between the device on path and the endpoint? >>=20 >> No, that doesn't really make any sense, because the transport is = end-to-end (as >> was the original intent of the network/transport layer separation). = Any key for >> authenticating and verifying endpoint-provided information would have = to >> reside in the PLUS layer on the endpoint. >>=20 >> I think at this point mechanisms for *establishing* these = relationships are out >> of scope for a future PLUS WG (at least, they were left out of the = charter >> deliberately), since we're really talking about the design of new = multiparty >> cryptographic protocols. But I notice that the mechanism we're = discussing here >> two primitives (provide information to the path that at least the = remote >> endpoint can verify is authentic, retrieve information from the path = with >> sender permission) on top of which such protocols could be designed. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>> Thanks, >>> Jianjie >>>=20 >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Brian Trammell = [mailto:ietf@trammell.ch] >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8822=E6=97= =A5 18:45 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Youjianjie >>>> =E6=8A=84=E9=80=81: Aaron Falk; spud >>>> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>>>=20 >>>>=20 >>>>> On 22 Jun 2016, at 11:35, Youjianjie = wrote: >>>>>=20 >>>>> Hi Brian, >>>>>=20 >>>>> Thanks for your prompt reply. Please see my comments below: >>>>>=20 >>>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Brian Trammell = [mailto:ietf@trammell.ch] >>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8822=E6=97= =A5 16:56 >>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Youjianjie >>>>>> =E6=8A=84=E9=80=81: Aaron Falk; spud >>>>>> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>>>>>=20 >>>>>> hi Jianjie, >>>>>>=20 >>>>>>> On 22 Jun 2016, at 09:09, Youjianjie = wrote: >>>>>>>=20 >>>>>>> Hi Brian, >>>>>>>=20 >>>>>>> (1) For forward signaling, the sending endpoint must place >>>>>>> "scratch space" in >>>>>> the packet with a label on it stating that it's okay to modify; >>>>>> this okay-to-modify state is enforced by a MAC which only = verifies >>>>>> the length but not the content of the scratch space. >>>>>>>=20 >>>>>>> Could you please elaborate how a MAC is used to enforce the >>>>>>> okay-to-modify >>>>>> state? Is it only applicable to L2 network? >>>>>>=20 >>>>>> Sorry, acronym collision. Here MAC =3D message authentication = code, >>>>>> not medium access control. >>>>>>=20 >>>>>>> Is it a designed field in the PLUS header? >>>>>>=20 >>>>>> There isn't a "PLUS header" yet; we're only talking about = potential >>>>>> mechanisms that could be implemented within one. Here, the idea = is >>>>>> that you have some encoding that allows you to place labeled data >>>>>> in the PLUS header (from the SPUD prototype experience, we like >>>>>> CBOR, but this is a technical detail). >>>>>>=20 >>>>>> Some of the types/keys in this data structure are designated >>>>>> end-to-end, and some of the types/keys are designated = path-modifiable. >>>>>>=20 >>>>>> The MAC is generated by the sending endpoint using a secret = shared >>>>>> by both endpoints, and covers: >>>>>=20 >>>>> How is the secret shared between both endpoints? The endpoints = need >>>>> to >>>> establish a connection to exchange keys? >>>>=20 >>>> Yes. This is assumed to be provided by the superstrate transport. >>>>>=20 >>>>>> (1) the presence and content of end-to-end PLUS header = information >>>>>=20 >>>>> Do you mean that this information is encrypted using the shared = secret? >>>> Only both endpoints can know the content? >>>>=20 >>>> No, the MAC is generated using the shared secret, so that it cannot >>>> be forged by on-path devices. The information itself is in the = clear. >>>>=20 >>>> Cheers, >>>>=20 >>>> Brian >>>>=20 >>>>>> (2) the presence and length of path-modifiable PLUS header >>>>>> information, by treating the content as a length-N byte array of = zeroes. >>>>>=20 >>>>> How does the middle-box along the path interpret the PLUS header? >>>>> Does >>>> the middle-box also need the secret? I used to think middle-box is >> transparent. >>>>>=20 >>>>> Thanks, >>>>> Jianjie >>>>>=20 >>>>>> This MAC is then transmitted from the sender to the receiver in >>>>>> encrypted form. >>>>>>=20 >>>>>> Additional MACs may also protect bits of the IP and UDP header, = in >>>>>> order to detect NAT and other sub-PLUS modifications, but these = are >>>>>> outside the scope of this question. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Jianjie >>>>>>>=20 >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Spud [mailto:spud-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Brian Trammell >>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8821=E6= =97=A5 17:36 >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Aaron Falk >>>>>>> =E6=8A=84=E9=80=81: spud >>>>>>> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>>>>>>=20 >>>>>>> hi Aaron, >>>>>>>=20 >>>>>>> On 06/20/2016 11:38 PM, Aaron Falk wrote: >>>>>>> Hi Brian- >>>>>>>=20 >>>>>>> In the charter and the draft-trammel-spud-req it says >>>>>>>=20 >>>>>>> Both endpoint-to-path and path-to-endpoint signaling happen >>>>>>> completely under endpoint control. >>>>>>>=20 >>>>>>> Without additional elaboration, one could conclude that, e.g., >>>>>>> permission is >>>>>> required before a path could signal to an endpoint. = Alternatively, >>>>>> it could be implying an endpoint has the freedom to ignore any >>>>>> signaling >>>> from the path. >>>>>> I have been assuming the latter. But now I wonder if you are >>>>>> intentionally attempting to permit the former. Could you = clarify? >>>>>>>=20 >>>>>>> Our intention is the former: that permission is required before >>>>>>> the path can >>>>>> signal to the endpoint. We have two mechanisms we've been = thinking >>>>>> about for this: >>>>>>>=20 >>>>>>> (1) For forward signaling, the sending endpoint must place >>>>>>> "scratch space" in >>>>>> the packet with a label on it stating that it's okay to modify; >>>>>> this okay-to-modify state is enforced by a MAC which only = verifies >>>>>> the length but not the content of the scratch space. >>>>>>>=20 >>>>>>> (2) For direct reverse signaling, a path element may not send a >>>>>>> direct reverse >>>>>> signaling packet to a sender unless it has also dropped a forward >>>>>> packet from the sender to receiver. This second mechanism is less >>>>>> about permission and more about reducing the attractiveness of = PLUS >>>>>> for amplification/reflection attacks. >>>>>>>=20 >>>>>>> In any case, endpoints (and path elements) can ignore whatever >>>>>>> they want to >>>>>> from the PLUS-exposed information; it's what's in the encrypted >>>>>> transport layer headers that matters to the transport protocol on >>>>>> the >>>> endpoint. >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> =E2=80=94aaron >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=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 --Apple-Mail=_A4603F7B-146B-4837-92C8-CD78ACA61C2C 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 iQIcBAEBCgAGBQJXa6jCAAoJEIoSt78L6kajTnQP/1HyUhql3mMuV4i1dmQYMfin DJ4iWALjD9KuGXk5zvPuFqH85ES6TCdsi2k040tFif0mj0aDe4yTD21zbW5FWa+H yCNCFbdyetKaRQOTxl1vfazH5oV8kO6bcyNMwupwG5KV7D5OvPedaQ0/3yoVqzjI G9P/6+ZzYbw52yV9kOoGRXyd2g3vywZ3FMK8XForE5ISZA680l4s+mc36CbAblpJ o/x8j0bjgx1TlwkyBGYmio4Kk3t8KG2BjMGpLNCrLTykxThHyvW5JT8OhAOc7Bf6 15yU+WxgejTrw+35GRV3BBRSwyNo8D/pDGcRCR1OuiikZRybaUajuqBNmzR0sJqT EJ96bkCwO3LDiQ+hXFpVGCEI5R9/8TWmVX6IlCW+Lmat6ygI3ZBAnqLTVoM3QcIO yy7KlYhndoB6NwD9hO9mcDUUG/vuO8+xtI9lMguW9LRZJ+ys6gYuSwtzqVNoZnWa /ofMTdzqQyGXCcg85uWxHZbmFYO4Wx7R7jh+SwzATfE9hL0An77dgefrNuilRAuL +QH170TTYB10e0XgZU+30rF51hyGAb4E4HNi7VMJ2s5PJS3+SjGmfSZR8Cm2PrRd qSvf3/FBxNPvRIHXmgry6jri6m1W0RprA+vhWvCAN+et9D8GyaRygR1derJr0XvV ODH8MPioi+rQDlNkU8G8 =WIlX -----END PGP SIGNATURE----- --Apple-Mail=_A4603F7B-146B-4837-92C8-CD78ACA61C2C-- From nobody Thu Jun 23 02:35: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 1C3C312E1FC for ; Thu, 23 Jun 2016 02:35:57 -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 YeG4kH3ALIOp for ; Thu, 23 Jun 2016 02:35:50 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4133812E050 for ; Thu, 23 Jun 2016 02:30: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 79FC41A19C4 for ; Thu, 23 Jun 2016 11:29:35 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_43621D2A-46F1-4FF4-9FF3-5BA3A6E40A1D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 23 Jun 2016 11:29:34 +0200 Message-Id: <32DC1941-126F-4513-801F-559617E85436@trammell.ch> To: spud Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Spud] PLUS charter rev. 23 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 09:35:57 -0000 --Apple-Mail=_43621D2A-46F1-4FF4-9FF3-5BA3A6E40A1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've updated the proposed PLUS charter based on outstanding issues = (Christian's comment on threat modeling and mitigations) and added a = list of things we believe to be out of scope based on list discussion. New charter, as always, at = https://github.com/ietf-plus/charter/blob/master/charter-plus.txt, and = inline below. Cheers, Brian Path Layer UDP Substrate (PLUS) =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 define a common shim layer atop the = User Datagram Protocol (UDP) to provide a transport-independent method to = signal flow semantics under transport and application control, necessary to = enable the deployment of new, encrypted transport protocols within the existing Internet. UDP provides compatibility with currently deployed middleboxes = as well as ubiquitous support in endpoints, and supports userspace = implementation of new transport protocols. The working group will not specify any new transport protocols. The current Internet protocol stack does not provide explicit, in-band, transport-independent signaling to on-path network devices. This has led = to the deployment of devices which perform implicit discovery of transport semantics and traffic characteristics via inspection of protocol headers = and payload, a practice made possible when these are sent in the clear. In order to support more ubiquitous deployment of encryption, and the encryption of transport headers to allow deployment of new transport protocols, explicit in-band signaling must be added to the stack. This signaling must be transport protocol independent, and the types of = information signaled must be based on characteristics that can be independently = verified by devices on path, or that can be usefully applied without requiring a = trust relationship between endpoints and the path. Further, a feedback channel = that provides information from on-path devices back to endpoints and = applications, e.g. for error handling, is essential for the deployment and success of = an explicit cooperation approach. While IP would seem to be the natural home for this facility, both IPv4 = and IPv6 options and extensions have deployment problems on their own, which = makes it hard to include any additional information in these protocols. The PLUS working group will specify a new protocol as a Path Layer UDP Substrate (PLUS), to support experimental deployment of explicit cooperation between endpoints and devices on path, with the = following goals: - enable ubiquitous deployment of encrypted higher layer protocols by providing exposure of basic TCP-like semantics (e.g. SYN, FIN, RST flags) to devices on path (e.g. NATs and firewalls). - allow applications and transport protocols to explicitly provide limited information with integrity protection to devices on path - allow devices on path to provide unencrypted feedback and information about the path directly to sending endpoints, under sending endpoint control - allow devices on path to provide unencrypted information about the path to receiving endpoints, with encrypted feedback to the sending endpoint, under sending endpoint control This approach explicitly gives the control of information exposure back = the application and/or transport layer protocol on the end host. It is the = goal of PLUS to minimize the information exposed, to make information exposure transparent, and to limit the level of detail to that useful for network treatment, while encrypting everything else. Endpoint verification of signaling integrity, careful design of minimal data structures, and restrictive policies for registration of signals can help to meet this = goal. This is important to avoid future implicit treatment and resulting ossification, as well as to minimize the privacy risks presented by = explicit cooperation. Given that the primary goal of PLUS is to enable the deployment of = transport protocols with encrypted headers, we assume that the higher-layer = protocol can provide an encryption context that can be used by PLUS to provide authentication, integrity, and encryption where needed. The primary = threat model to defend against will be modification or deletion of exposed information by middleboxes and other devices on path, by allowing a = remote endpoint to detect modifications. The working group will start with an initial set of use cases (see = draft- kuehlewind-spud-use-cases) and requirements (see = draft-trammell-spud-req), taken from experience with the Substrate Protocol for User Datagrams = (SPUD) prototype. The working group's main output will be an experimental = protocol specification, together with an initial registry of types of information = that can be exposed using PLUS, clearly aligned to the use cases determined = by the working group. This specification will consider potential attacks = against the protocol, both arising from the encapsulation chosen as well as new = attacks made possible by the protocol, and propose mitigations for these = attacks. The working group will close if it is not able to come to consensus on a protocol design to meet these requirements. The working group will additionally aim to identify and work with other working groups that could address parts of these requirements within = existing protocols, e.g. by specifying new protocol extensions, or as input for = on- going standardization work. It will aim to work with working groups = defining encryption protocols (e.g. DTLS) which could be used for encryption of transport protocols running over PLUS. Out of scope for the working group are: - The design and specification of new transport protocols running over = PLUS. - Mechanisms for signaling among multiple devices on path between two = endpoints - Mechanisms for key exchange or cryptographic context establishment = between endpoints and devices on path --Apple-Mail=_43621D2A-46F1-4FF4-9FF3-5BA3A6E40A1D 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 iQIcBAEBCgAGBQJXa6v/AAoJEIoSt78L6kajkGwQAJzGLv+dgkWASvuasWAiFp4u HqHRR+lvKeXPXVVa6ffO426c01CEszPRJX5fwMTF752U8EtSZ6a7pT86DFhAg7XO 7KepevXQyZd8AonFuVc/22wzEMg3EStkZdOh2OOwbcbx7jFSHXlaQo9ZQ5AbCulf 5xr8LXWL7Sd6v7nPEj37dQOuBtk5/iRDL/E+O2VW3A7DabylI0/N+lqfXFr32A7x Hh2SI7I1x5iQ0FOD3Wva7yw9f2jedoPig2o4EQyhPZxPmiRiaQPjbgS3Ru/Di8Ho NdxXNfV9PI4kms7v0WlzhmtZWPNSVcTVGEknDvdu5SC/IsolrX5YZlzmz9U0LbiP G+Gy6K06695wOcAw5VkGOCUC+hnd80Jdnjs//bsP7BLvfQFZUJqOzxUWVDcEummC sL3kC8tQUi+fA3OkkAgL7GxuNSFIbFUzGWNYcvD7ObEZ9JqW2feTYY1sAkWuqCya +WMKY+2JRA68jD8IFLoWlHF10bJeO5uBdq21IEJSqPOvrDdDvXsDyT4jX8TuwTJI 3grXEfPwZ9LjVSu9OCnGXsDa9KqDK0mSy9JHCijb3AHBUiuoy9l76+UptJ/YF45E tZHmXaL872gUkNgkwvsCbN32UZHNteoFhEKc816zqogPhtwZpRd176vuvL5YtkUV fzCkkJub9EbXLG++zb0u =WaAr -----END PGP SIGNATURE----- --Apple-Mail=_43621D2A-46F1-4FF4-9FF3-5BA3A6E40A1D-- From nobody Thu Jun 23 20:20: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 4FFB312D886 for ; Thu, 23 Jun 2016 20:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, 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 xCv6SHWtAcq1 for ; Thu, 23 Jun 2016 20:20:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA75F12D52F for ; Thu, 23 Jun 2016 20:20:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMM81571; Fri, 24 Jun 2016 03:20:10 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 24 Jun 2016 04:20:10 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 24 Jun 2016 11:20:02 +0800 From: Youjianjie To: Brian Trammell , spud Thread-Topic: [Spud] PLUS charter rev. 23 June Thread-Index: AQHRzTKuLdn4EOt4CkGoMceDlsdh4J/36s2w Date: Fri, 24 Jun 2016 03:20:02 +0000 Message-ID: References: <32DC1941-126F-4513-801F-559617E85436@trammell.ch> In-Reply-To: <32DC1941-126F-4513-801F-559617E85436@trammell.ch> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.148] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.576CA6EB.0028, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 32f7ec28cbaca5eadc2d707bb3332558 Archived-At: Subject: [Spud] =?gb2312?b?tPC4tDogIFBMVVMgY2hhcnRlciByZXYuIDIzIEp1bmU=?= 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, 24 Jun 2016 03:20:17 -0000 SGkgQnJpYW4sDQoNCklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIEkgdGhpbmsgUExVUyBwcm92 aWRlcyBhbiBleHBsaWNpdCBpbi1iYW5kIHNpZ25hbGluZyB3aGljaCBpcyBwcm90ZWN0ZWQgYnkg ZW5kcG9pbnQgdmVyaWZpY2F0aW9uLiBCb3RoIHRoZSBpbmZvcm1hdGlvbiBwcm92aWRlZCB0byB0 aGUgZGV2aWNlcyBvbiBwYXRoIG9yIHJldHJpZXZlZCBmcm9tIHRoZSBkZXZpY2VzIG9uIHBhdGgg Y2Fubm90IGJlIHZlcmlmaWVkIGJ5IGVhY2ggb3RoZXIuIFNvIGl0IGhhcyBzb21lIGxpbWl0YXRp b24gb24gdGhlIGluZm9ybWF0aW9uIGV4cG9zZWQuIEJ1dCB3ZSB0aGluayBpdCdzIGEgdXNlZnVs IG1ldGhvZCBmb3IgdHJhbnNwb3J0IGFuZCBlbmNyeXB0aW9uLiBXZSdkIGxpa2UgdG8gc2VlIG1v cmUgb24gdGhpcy4gDQoNClRoYW5rcywNCkppYW5qaWUNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0N Cj4gt6K8/sjLOiBTcHVkIFttYWlsdG86c3B1ZC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEJyaWFu IFRyYW1tZWxsDQo+ILeiy83KsbzkOiAyMDE2xOo21MIyM8jVIDE3OjMwDQo+IMrVvP7Iyzogc3B1 ZA0KPiDW98ziOiBbU3B1ZF0gUExVUyBjaGFydGVyIHJldi4gMjMgSnVuZQ0KPiANCj4gR3JlZXRp bmdzLCBhbGwsDQo+IA0KPiBXZSd2ZSB1cGRhdGVkIHRoZSBwcm9wb3NlZCBQTFVTIGNoYXJ0ZXIg YmFzZWQgb24gb3V0c3RhbmRpbmcgaXNzdWVzDQo+IChDaHJpc3RpYW4ncyBjb21tZW50IG9uIHRo cmVhdCBtb2RlbGluZyBhbmQgbWl0aWdhdGlvbnMpIGFuZCBhZGRlZCBhIGxpc3Qgb2YNCj4gdGhp bmdzIHdlIGJlbGlldmUgdG8gYmUgb3V0IG9mIHNjb3BlIGJhc2VkIG9uIGxpc3QgZGlzY3Vzc2lv bi4NCj4gDQo+IE5ldyBjaGFydGVyLCBhcyBhbHdheXMsIGF0DQo+IGh0dHBzOi8vZ2l0aHViLmNv bS9pZXRmLXBsdXMvY2hhcnRlci9ibG9iL21hc3Rlci9jaGFydGVyLXBsdXMudHh0LCBhbmQgaW5s aW5lDQo+IGJlbG93Lg0KPiANCj4gQ2hlZXJzLA0KPiANCj4gQnJpYW4NCj4gDQo+IA0KPiBQYXRo IExheWVyIFVEUCBTdWJzdHJhdGUgKFBMVVMpDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCj4gDQo+IFRoZSBQTFVTIHdvcmtpbmcgZ3JvdXAncyBnb2FsIGlzIHRvIGRlZmluZSBh IGNvbW1vbiBzaGltIGxheWVyIGF0b3AgdGhlIFVzZXINCj4gRGF0YWdyYW0gUHJvdG9jb2wgKFVE UCkgdG8gcHJvdmlkZSBhIHRyYW5zcG9ydC1pbmRlcGVuZGVudCBtZXRob2QgdG8gc2lnbmFsDQo+ IGZsb3cgc2VtYW50aWNzIHVuZGVyIHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24gY29udHJvbCwg bmVjZXNzYXJ5IHRvIGVuYWJsZQ0KPiB0aGUgZGVwbG95bWVudCBvZiBuZXcsIGVuY3J5cHRlZCB0 cmFuc3BvcnQgcHJvdG9jb2xzIHdpdGhpbiB0aGUgZXhpc3RpbmcNCj4gSW50ZXJuZXQuIFVEUCBw cm92aWRlcyBjb21wYXRpYmlsaXR5IHdpdGggY3VycmVudGx5IGRlcGxveWVkIG1pZGRsZWJveGVz IGFzDQo+IHdlbGwgYXMgdWJpcXVpdG91cyBzdXBwb3J0IGluIGVuZHBvaW50cywgYW5kIHN1cHBv cnRzIHVzZXJzcGFjZQ0KPiBpbXBsZW1lbnRhdGlvbiBvZiBuZXcgdHJhbnNwb3J0IHByb3RvY29s cy4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBub3Qgc3BlY2lmeQ0KPiBhbnkgbmV3IHRyYW5zcG9y dCBwcm90b2NvbHMuDQo+IA0KPiBUaGUgY3VycmVudCBJbnRlcm5ldCBwcm90b2NvbCBzdGFjayBk b2VzIG5vdCBwcm92aWRlIGV4cGxpY2l0LCBpbi1iYW5kLA0KPiB0cmFuc3BvcnQtaW5kZXBlbmRl bnQgc2lnbmFsaW5nIHRvIG9uLXBhdGggbmV0d29yayBkZXZpY2VzLiBUaGlzIGhhcyBsZWQgdG8N Cj4gdGhlIGRlcGxveW1lbnQgb2YgZGV2aWNlcyB3aGljaCBwZXJmb3JtIGltcGxpY2l0IGRpc2Nv dmVyeSBvZiB0cmFuc3BvcnQNCj4gc2VtYW50aWNzIGFuZCB0cmFmZmljIGNoYXJhY3RlcmlzdGlj cyB2aWEgaW5zcGVjdGlvbiBvZiBwcm90b2NvbCBoZWFkZXJzIGFuZA0KPiBwYXlsb2FkLCBhIHBy YWN0aWNlIG1hZGUgcG9zc2libGUgd2hlbiB0aGVzZSBhcmUgc2VudCBpbiB0aGUgY2xlYXIuDQo+ IA0KPiBJbiBvcmRlciB0byBzdXBwb3J0IG1vcmUgdWJpcXVpdG91cyBkZXBsb3ltZW50IG9mIGVu Y3J5cHRpb24sIGFuZCB0aGUNCj4gZW5jcnlwdGlvbiBvZiB0cmFuc3BvcnQgaGVhZGVycyB0byBh bGxvdyBkZXBsb3ltZW50IG9mIG5ldyB0cmFuc3BvcnQNCj4gcHJvdG9jb2xzLCBleHBsaWNpdCBp bi1iYW5kIHNpZ25hbGluZyBtdXN0IGJlIGFkZGVkIHRvIHRoZSBzdGFjay4gVGhpcyBzaWduYWxp bmcNCj4gbXVzdCBiZSB0cmFuc3BvcnQgcHJvdG9jb2wgaW5kZXBlbmRlbnQsIGFuZCB0aGUgdHlw ZXMgb2YgaW5mb3JtYXRpb24gc2lnbmFsZWQNCj4gbXVzdCBiZSBiYXNlZCBvbiBjaGFyYWN0ZXJp c3RpY3MgdGhhdCBjYW4gYmUgaW5kZXBlbmRlbnRseSB2ZXJpZmllZCBieSBkZXZpY2VzDQo+IG9u IHBhdGgsIG9yIHRoYXQgY2FuIGJlIHVzZWZ1bGx5IGFwcGxpZWQgd2l0aG91dCByZXF1aXJpbmcg YSB0cnVzdCByZWxhdGlvbnNoaXANCj4gYmV0d2VlbiBlbmRwb2ludHMgYW5kIHRoZSBwYXRoLiBG dXJ0aGVyLCBhIGZlZWRiYWNrIGNoYW5uZWwgdGhhdCBwcm92aWRlcw0KPiBpbmZvcm1hdGlvbiBm cm9tIG9uLXBhdGggZGV2aWNlcyBiYWNrIHRvIGVuZHBvaW50cyBhbmQgYXBwbGljYXRpb25zLCBl LmcuIGZvcg0KPiBlcnJvciBoYW5kbGluZywgaXMgZXNzZW50aWFsIGZvciB0aGUgZGVwbG95bWVu dCBhbmQgc3VjY2VzcyBvZiBhbiBleHBsaWNpdA0KPiBjb29wZXJhdGlvbiBhcHByb2FjaC4NCj4g DQo+IFdoaWxlIElQIHdvdWxkIHNlZW0gdG8gYmUgdGhlIG5hdHVyYWwgaG9tZSBmb3IgdGhpcyBm YWNpbGl0eSwgYm90aCBJUHY0IGFuZA0KPiBJUHY2IG9wdGlvbnMgYW5kIGV4dGVuc2lvbnMgaGF2 ZSBkZXBsb3ltZW50IHByb2JsZW1zIG9uIHRoZWlyIG93biwgd2hpY2gNCj4gbWFrZXMgaXQgaGFy ZCB0byBpbmNsdWRlIGFueSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGluIHRoZXNlIHByb3RvY29s cy4NCj4gDQo+IFRoZSBQTFVTIHdvcmtpbmcgZ3JvdXAgd2lsbCBzcGVjaWZ5IGEgbmV3IHByb3Rv Y29sIGFzIGEgUGF0aCBMYXllciBVRFANCj4gU3Vic3RyYXRlIChQTFVTKSwgdG8gc3VwcG9ydCBl eHBlcmltZW50YWwgZGVwbG95bWVudCBvZiBleHBsaWNpdCBjb29wZXJhdGlvbg0KPiBiZXR3ZWVu IGVuZHBvaW50cyBhbmQgZGV2aWNlcyBvbiBwYXRoLCB3aXRoIHRoZSBmb2xsb3dpbmcgZ29hbHM6 DQo+IA0KPiAtIGVuYWJsZSB1YmlxdWl0b3VzIGRlcGxveW1lbnQgb2YgZW5jcnlwdGVkIGhpZ2hl ciBsYXllciBwcm90b2NvbHMNCj4gICBieSBwcm92aWRpbmcgZXhwb3N1cmUgb2YgYmFzaWMgVENQ LWxpa2Ugc2VtYW50aWNzIChlLmcuIFNZTiwgRklOLA0KPiAgIFJTVCBmbGFncykgdG8gZGV2aWNl cyBvbiBwYXRoIChlLmcuIE5BVHMgYW5kIGZpcmV3YWxscykuDQo+IA0KPiAtIGFsbG93IGFwcGxp Y2F0aW9ucyBhbmQgdHJhbnNwb3J0IHByb3RvY29scyB0byBleHBsaWNpdGx5IHByb3ZpZGUNCj4g ICBsaW1pdGVkIGluZm9ybWF0aW9uIHdpdGggaW50ZWdyaXR5IHByb3RlY3Rpb24gdG8gZGV2aWNl cyBvbiBwYXRoDQo+IA0KPiAtIGFsbG93IGRldmljZXMgb24gcGF0aCB0byBwcm92aWRlIHVuZW5j cnlwdGVkIGZlZWRiYWNrIGFuZCBpbmZvcm1hdGlvbg0KPiAgIGFib3V0IHRoZSBwYXRoIGRpcmVj dGx5IHRvIHNlbmRpbmcgZW5kcG9pbnRzLCB1bmRlciBzZW5kaW5nIGVuZHBvaW50DQo+ICAgY29u dHJvbA0KPiANCj4gLSBhbGxvdyBkZXZpY2VzIG9uIHBhdGggdG8gcHJvdmlkZSB1bmVuY3J5cHRl ZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUNCj4gICBwYXRoIHRvIHJlY2VpdmluZyBlbmRwb2ludHMs IHdpdGggZW5jcnlwdGVkIGZlZWRiYWNrIHRvIHRoZQ0KPiAgIHNlbmRpbmcgZW5kcG9pbnQsIHVu ZGVyIHNlbmRpbmcgZW5kcG9pbnQgY29udHJvbA0KPiANCj4gVGhpcyBhcHByb2FjaCBleHBsaWNp dGx5IGdpdmVzIHRoZSBjb250cm9sIG9mIGluZm9ybWF0aW9uIGV4cG9zdXJlIGJhY2sgdGhlDQo+ IGFwcGxpY2F0aW9uIGFuZC9vciB0cmFuc3BvcnQgbGF5ZXIgcHJvdG9jb2wgb24gdGhlIGVuZCBo b3N0LiBJdCBpcyB0aGUgZ29hbCBvZg0KPiBQTFVTIHRvIG1pbmltaXplIHRoZSBpbmZvcm1hdGlv biBleHBvc2VkLCB0byBtYWtlIGluZm9ybWF0aW9uIGV4cG9zdXJlDQo+IHRyYW5zcGFyZW50LCBh bmQgdG8gbGltaXQgdGhlIGxldmVsIG9mIGRldGFpbCB0byB0aGF0IHVzZWZ1bCBmb3IgbmV0d29y aw0KPiB0cmVhdG1lbnQsIHdoaWxlIGVuY3J5cHRpbmcgZXZlcnl0aGluZyBlbHNlLiBFbmRwb2lu dCB2ZXJpZmljYXRpb24gb2Ygc2lnbmFsaW5nDQo+IGludGVncml0eSwgY2FyZWZ1bCBkZXNpZ24g b2YgbWluaW1hbCBkYXRhIHN0cnVjdHVyZXMsIGFuZCByZXN0cmljdGl2ZSBwb2xpY2llcyBmb3IN Cj4gcmVnaXN0cmF0aW9uIG9mIHNpZ25hbHMgY2FuIGhlbHAgdG8gbWVldCB0aGlzIGdvYWwuDQo+ IFRoaXMgaXMgaW1wb3J0YW50IHRvIGF2b2lkIGZ1dHVyZSBpbXBsaWNpdCB0cmVhdG1lbnQgYW5k IHJlc3VsdGluZyBvc3NpZmljYXRpb24sDQo+IGFzIHdlbGwgYXMgdG8gbWluaW1pemUgdGhlIHBy aXZhY3kgcmlza3MgcHJlc2VudGVkIGJ5IGV4cGxpY2l0IGNvb3BlcmF0aW9uLg0KPiANCj4gR2l2 ZW4gdGhhdCB0aGUgcHJpbWFyeSBnb2FsIG9mIFBMVVMgaXMgdG8gZW5hYmxlIHRoZSBkZXBsb3lt ZW50IG9mIHRyYW5zcG9ydA0KPiBwcm90b2NvbHMgd2l0aCBlbmNyeXB0ZWQgaGVhZGVycywgd2Ug YXNzdW1lIHRoYXQgdGhlIGhpZ2hlci1sYXllciBwcm90b2NvbA0KPiBjYW4gcHJvdmlkZSBhbiBl bmNyeXB0aW9uIGNvbnRleHQgdGhhdCBjYW4gYmUgdXNlZCBieSBQTFVTIHRvIHByb3ZpZGUNCj4g YXV0aGVudGljYXRpb24sIGludGVncml0eSwgYW5kIGVuY3J5cHRpb24gd2hlcmUgbmVlZGVkLiBU aGUgcHJpbWFyeSB0aHJlYXQNCj4gbW9kZWwgdG8gZGVmZW5kIGFnYWluc3Qgd2lsbCBiZSBtb2Rp ZmljYXRpb24gb3IgZGVsZXRpb24gb2YgZXhwb3NlZA0KPiBpbmZvcm1hdGlvbiBieSBtaWRkbGVi b3hlcyBhbmQgb3RoZXIgZGV2aWNlcyBvbiBwYXRoLCBieSBhbGxvd2luZyBhIHJlbW90ZQ0KPiBl bmRwb2ludCB0byBkZXRlY3QgbW9kaWZpY2F0aW9ucy4NCj4gDQo+IFRoZSB3b3JraW5nIGdyb3Vw IHdpbGwgc3RhcnQgd2l0aCBhbiBpbml0aWFsIHNldCBvZiB1c2UgY2FzZXMgKHNlZSBkcmFmdC0N Cj4ga3VlaGxld2luZC1zcHVkLXVzZS1jYXNlcykgYW5kIHJlcXVpcmVtZW50cyAoc2VlIGRyYWZ0 LXRyYW1tZWxsLXNwdWQtcmVxKSwNCj4gdGFrZW4gZnJvbSBleHBlcmllbmNlIHdpdGggdGhlIFN1 YnN0cmF0ZSBQcm90b2NvbCBmb3IgVXNlciBEYXRhZ3JhbXMgKFNQVUQpDQo+IHByb3RvdHlwZS4g VGhlIHdvcmtpbmcgZ3JvdXAncyBtYWluIG91dHB1dCB3aWxsIGJlIGFuIGV4cGVyaW1lbnRhbCBw cm90b2NvbA0KPiBzcGVjaWZpY2F0aW9uLCB0b2dldGhlciB3aXRoIGFuIGluaXRpYWwgcmVnaXN0 cnkgb2YgdHlwZXMgb2YgaW5mb3JtYXRpb24gdGhhdCBjYW4NCj4gYmUgZXhwb3NlZCB1c2luZyBQ TFVTLCBjbGVhcmx5IGFsaWduZWQgdG8gdGhlIHVzZSBjYXNlcyBkZXRlcm1pbmVkIGJ5IHRoZQ0K PiB3b3JraW5nIGdyb3VwLiBUaGlzIHNwZWNpZmljYXRpb24gd2lsbCBjb25zaWRlciBwb3RlbnRp YWwgYXR0YWNrcyBhZ2FpbnN0IHRoZQ0KPiBwcm90b2NvbCwgYm90aCBhcmlzaW5nIGZyb20gdGhl IGVuY2Fwc3VsYXRpb24gY2hvc2VuIGFzIHdlbGwgYXMgbmV3IGF0dGFja3MNCj4gbWFkZSBwb3Nz aWJsZSBieSB0aGUgcHJvdG9jb2wsIGFuZCBwcm9wb3NlIG1pdGlnYXRpb25zIGZvciB0aGVzZSBh dHRhY2tzLg0KPiANCj4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBjbG9zZSBpZiBpdCBpcyBub3Qg YWJsZSB0byBjb21lIHRvIGNvbnNlbnN1cyBvbiBhDQo+IHByb3RvY29sIGRlc2lnbiB0byBtZWV0 IHRoZXNlIHJlcXVpcmVtZW50cy4NCj4gDQo+IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkaXRp b25hbGx5IGFpbSB0byBpZGVudGlmeSBhbmQgd29yayB3aXRoIG90aGVyDQo+IHdvcmtpbmcgZ3Jv dXBzIHRoYXQgY291bGQgYWRkcmVzcyBwYXJ0cyBvZiB0aGVzZSByZXF1aXJlbWVudHMgd2l0aGlu IGV4aXN0aW5nDQo+IHByb3RvY29scywgZS5nLiBieSBzcGVjaWZ5aW5nIG5ldyBwcm90b2NvbCBl eHRlbnNpb25zLCBvciBhcyBpbnB1dCBmb3Igb24tIGdvaW5nDQo+IHN0YW5kYXJkaXphdGlvbiB3 b3JrLiBJdCB3aWxsIGFpbSB0byB3b3JrIHdpdGggd29ya2luZyBncm91cHMgZGVmaW5pbmcNCj4g ZW5jcnlwdGlvbiBwcm90b2NvbHMgKGUuZy4gRFRMUykgd2hpY2ggY291bGQgYmUgdXNlZCBmb3Ig ZW5jcnlwdGlvbiBvZg0KPiB0cmFuc3BvcnQgcHJvdG9jb2xzIHJ1bm5pbmcgb3ZlciBQTFVTLg0K PiANCj4gT3V0IG9mIHNjb3BlIGZvciB0aGUgd29ya2luZyBncm91cCBhcmU6DQo+IA0KPiAtIFRo ZSBkZXNpZ24gYW5kIHNwZWNpZmljYXRpb24gb2YgbmV3IHRyYW5zcG9ydCBwcm90b2NvbHMgcnVu bmluZyBvdmVyIFBMVVMuDQo+IC0gTWVjaGFuaXNtcyBmb3Igc2lnbmFsaW5nIGFtb25nIG11bHRp cGxlIGRldmljZXMgb24gcGF0aCBiZXR3ZWVuIHR3bw0KPiBlbmRwb2ludHMNCj4gLSBNZWNoYW5p c21zIGZvciBrZXkgZXhjaGFuZ2Ugb3IgY3J5cHRvZ3JhcGhpYyBjb250ZXh0IGVzdGFibGlzaG1l bnQNCj4gYmV0d2VlbiBlbmRwb2ludHMgYW5kIGRldmljZXMgb24gcGF0aA0KDQo= From nobody Fri Jun 24 09:01:21 2016 Return-Path: X-Original-To: spud@ietf.org Delivered-To: spud@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0904012DC56; Fri, 24 Jun 2016 09:00:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160039.10933.67496.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:39 -0700 Archived-At: Cc: spencerdawkins.ietf@gmail.com, spud@ietf.org Subject: [Spud] plus - Requested session has been scheduled for IETF 96 X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:39 -0000 Dear Cindy Morgan, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. plus Session 1 (2:30:00) Thursday, Morning Session I 1000-1230 Room Name: Potsdam I size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Path Layer UDP Substrate Area Name: Transport Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: rmcat maprg l4s quic uta lurk taps mptcp tcpinc tcpm iccrg tsvwg dispatch rtcweb tls saag tsvarea Special Requests: If possible, please schedule after QUIC BOF --------------------------------------------------------- From nobody Sat Jun 25 14:33: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 B7E4B12D181 for ; Sat, 25 Jun 2016 14:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0JRGZL_PHvI for ; Sat, 25 Jun 2016 14:32:56 -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 B42E312D151 for ; Sat, 25 Jun 2016 14:32:56 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id g13so118393842ioj.1 for ; Sat, 25 Jun 2016 14:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4AOgFMwrhTTvyu8wvT9gAKs+Cs0D+rYuLID6R1Y8bxA=; b=OTlXaZ78+HnKk9Vt1cCYtfu4EOyaYF6mdwZi/ODUyz0dqk8IT4MNDluBZmSgCxyH4h LvmOrtHMqFynvnp+u9ADAmGfAdZg9TpNSAOe0wHXGtYytbwe2YsijXbSHhIiej01qkL0 zP9SvhU5KoePshsXuqmCt89KEVw2Sx5y0sOQYb3F8zdA0sos/0fvE7MHZv2B/2cLMaHO MMvrm45WFOY7jBnJeg5Xn7jwgf7tDqY3Nu1nvlxPVWfsynLC+jvvNeXGbWQb3uo6Teys h1P+xxb00G8EZShUJNkgt+N/FUR+GHpm9kc4LSovNfJz+Jplcg/CH5WLmOND5SczzlJI y/lw== 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=4AOgFMwrhTTvyu8wvT9gAKs+Cs0D+rYuLID6R1Y8bxA=; b=BiStWkQ9bhezkQrecr9JbI3TsqaF5SB/c0Yp+Mxj3TDAmcpaNNtpO/PZtwH3Mx3wxP FuX3a1SDz2w25k9evv4oyJuj2WEE+3zx5gaQf5Ctz7TOw5RpJijaHXXfdWSN8mjwYvBH z1KgGeZJk3Y6yV2ZLUEKXd8hxckldUSKqDkNJY//wlzLMCHt/eyfmUHl3BxxqTcge50z FZi2VNOkqhIi44gnIKPZLl2xYhNhxn1c4thKxQcA+tmrriBwIlX54BREvEU+DGjZW6U4 DzETZJz3mgHFgjS4n9EmdyQYuYtb9OwgNqonNLRLjeefN9c4q0gHM+uBW3xMQj0kvbzk VEHw== X-Gm-Message-State: ALyK8tL8Lso05Tc7IUe6Fz94L3Oc84uYOoiJcwksKpq0/p7ueyzJOGr7aZNdIp7WUjLXW12fal4VWd2RpUO8KA== X-Received: by 10.107.162.12 with SMTP id l12mr10828552ioe.84.1466890375843; Sat, 25 Jun 2016 14:32:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Sat, 25 Jun 2016 14:32:54 -0700 (PDT) In-Reply-To: References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <57573DCF.1030402@isi.edu> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <57574C38.6070402@isi.edu> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> From: Tom Herbert Date: Sat, 25 Jun 2016 14:32:54 -0700 Message-ID: To: Ca By Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Trammell , Szilveszter Nadas , spud , Christian Huitema , Joe Touch Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 21:33:00 -0000 On Wed, Jun 15, 2016 at 5:17 AM, Ca By wrote: > > > On Tuesday, June 14, 2016, Brian Trammell wrote: >> >> hi Christian, >> >> > On 14 Jun 2016, at 21:47, Christian Huitema >> > wrote: >> > >> > On Tuesday, June 14, 2016 5:46 AM, Ca By wrote: >> > >> >> >> >> All my concerns with spud and quic would be solved by using a >> >> new protocol number since it would allow for the network to, >> >> at scale, identify good spud/quic traffic from the known bad udp ddos >> >> mess >> > >> > I think we need to dig a bit further there. Botnets could issue >> > spud/quic traffic just fine. Granted, it will take them some time to adapt, >> > but history shows that they will adapt. So, I don't see how painting a fixed >> > set of bits in the packets would help in the long run. Botnets engaged in >> > DOS will just set the same bits, be it a protocol number or a header field. >> >> Agreed. >> >> > There may be something specific to do about differentiation from UDP >> > reflection attacks. I am aware that a lot of these are DNS packets. There >> > may be some other UDP services as well. >> >> Reflection attacks tend to follow the amplification factor: more >> amplification, bigger win. NTP (due, I think, to a widely deployed >> configuration that was amplification-friendly) was the champion here; DNS >> with DNSSEC looms as the next one (see the work of Roland van Rijswijk-Deij, >> Anna Sperotto, and Aiko Pras here: [1, 2]). >> >> > But the general characteristic is that such attacks reuse a deployed >> > infrastructure to their benefits, and thus have specific markers. The >> > infrastructure is not going to change, so the markers will stay. The new >> > protocols should certainly try to differentiate from these existing attacks. >> >> This is the rationale behind the selection of the magic number in the SPUD >> prototype, and the presence of a magic number in the requirements derived >> therefrom. >> > > Magic numbers do no work on existing router. Just like the constraint you > have that we must work with the intall base so we must use udp. The solution > space is "no change" > >> >> I am also intrigued by Tom's earlier suggestion that using IPv6 DO headers >> might have reflection-reducing properties, given the installed base. We >> should look into that more deeply. >> >> None of this does *anything* against direct botnet attacks -- there are >> maybe things you could do in a world with ubiquitous PLUS-speaking >> middleboxes that distinguished a PLUS magic number flood from a bot from >> real PLUS-encapsulated traffic. >> >> > > Is there anyone from a middle box vendor here? Do you want to hear what PLUS > is telling you? Or will middleboxes keep doing what they want? > +1, these are very important questions to be answered for PLUS effort. > I am concerned plus is saying things nobody is listening to. > Unless somebody's listening, there's no reason to believe applications are going to bother to say anything. Tom >> >> >> But relying on both ubiquitous deployment (a decade out in the wildly >> optimistic case) and the kindness of strangers to actually deploy egress >> filtering (which has worked oh so well in the past) isn't what I'd call a >> security plan. >> >> >> >> This network operator concern has been repeatedly ignored since >> >> it is easier to access udp in userspace. >> > >> > As many said, user space is just one of the problems. The other is the >> > installed base of NATs that won't pass anything else than TCP and UDP. Do we >> > have studies indicating whether that changes with IPv6? >> >> No direct numbers, in part because the measurement infrastructures >> available to us give us much smaller population sizes for v6 measurement. >> Anecdotally, taken from analysis of the data in [3, 4, 5], I can say that >> the magnitude of brokenness on v6 in general is lower, but the kinds of >> brokenness you run into is weirder. Slide 9 in [5] is v4 only because we >> still haven't been able to explain anomalies in the MTU curve for UDP on >> IPv6; in both [3] and the detailed analysis linked from [4] we see ECN >> negotiation anomalies five times more often for v6 than v4. >> >> If I had to make up an explanation for that, I'd say that v6 traffic does >> indeed tend to pass through fewer middleboxes, but that the v6 functionality >> in those middleboxes is far less well tested. Happy eyeballs works so well >> because it quite effectively hides a multitude of sins. >> >> Cheers, >> >> Brian >> >> >> [1] DNSSEC and its potential for DDoS attacks at IMC '14 >> https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/imc101-vanrijswijk.pdf >> >> [2] Making the case for elliptic curves in DNSSEC in CCR, Oct '15 >> https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/ccr-ecdsa-2015.pdf >> >> [3] Enabling Internet-wide deployment of ECN, PAM '15 >> http://ecn.ethz.ch/ecn-pam15.pdf >> >> [4] 70% of popular Web sites support ECM, blog post >> >> https://mami-project.eu/index.php/2016/06/13/70-of-popular-web-sites-support-ecn/ >> >> [5] Can we run the Internet over UDP, MAPRG presentation >> https://www.ietf.org/proceedings/95/slides/slides-95-maprg-3.pdf > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Mon Jun 27 03:06: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 12D6412D108 for ; Mon, 27 Jun 2016 03:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, 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 fWP8RZG4XjwI for ; Mon, 27 Jun 2016 03:06:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F11012D0DB for ; Mon, 27 Jun 2016 03:06:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMS10071; Mon, 27 Jun 2016 10:06:13 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 27 Jun 2016 11:06:12 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 27 Jun 2016 18:06:07 +0800 From: Youjianjie To: Brian Trammell Thread-Topic: [Spud] endpoint control Thread-Index: AQHRzS/bRN19NbqlIka7EoUkg6mI1Z/9FsTw Date: Mon, 27 Jun 2016 10:06:07 +0000 Message-ID: References: <57690A66.3050502@trammell.ch> <095C2E5D-D235-4017-91E2-9B437D8DBDD0@trammell.ch> <4F02B71A-5F3F-4595-8661-51CE07E9F0E5@trammell.ch> <1D5C1BA4-4359-4DC9-B1BA-2DF576AD4A92@trammell.ch> In-Reply-To: <1D5C1BA4-4359-4DC9-B1BA-2DF576AD4A92@trammell.ch> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5770FA96.0091, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4528c470e0e55c4590a5eb6bb33f8e2b Archived-At: Cc: Aaron Falk , spud Subject: [Spud] =?utf-8?b?562U5aSNOiAgIGVuZHBvaW50IGNvbnRyb2w=?= 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, 27 Jun 2016 10:06:20 -0000 SGkgQnJpYW4sDQoNCkZ1cnRoZXIgY29tbWVudHMgYmVsb3c6DQoNClRoYW5rcywNCkppYW5qaWUN Cj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IEJyaWFuIFRyYW1tZWxsIFtt YWlsdG86aWV0ZkB0cmFtbWVsbC5jaF0NCj4g5Y+R6YCB5pe26Ze0OiAyMDE25bm0NuaciDIz5pel IDE3OjE2DQo+IOaUtuS7tuS6ujogWW91amlhbmppZQ0KPiDmioTpgIE6IEFhcm9uIEZhbGs7IHNw dWQNCj4g5Li76aKYOiBSZTogW1NwdWRdIGVuZHBvaW50IGNvbnRyb2wNCj4gDQo+IA0KPiA+IE9u IDIzIEp1biAyMDE2LCBhdCAxMDo1NSwgWW91amlhbmppZSA8eW91amlhbmppZUBodWF3ZWkuY29t PiB3cm90ZToNCj4gPg0KPiA+IEhpIEJyaWFuLA0KPiA+DQo+ID4gVGhhbmtzIGZvciB0aGUgcmVw bHkuDQo+ID4NCj4gPj4gSSB0aGluayBhdCB0aGlzIHBvaW50IG1lY2hhbmlzbXMgZm9yICplc3Rh Ymxpc2hpbmcqIHRoZXNlDQo+ID4+IHJlbGF0aW9uc2hpcHMgYXJlIG91dCBvZiBzY29wZSBmb3Ig YSBmdXR1cmUgUExVUyBXRyAoYXQgbGVhc3QsIHRoZXkNCj4gPj4gd2VyZSBsZWZ0IG91dCBvZiB0 aGUgY2hhcnRlciBkZWxpYmVyYXRlbHkpLCBzaW5jZSB3ZSdyZSByZWFsbHkNCj4gPj4gdGFsa2lu ZyBhYm91dCB0aGUgZGVzaWduIG9mIG5ldyBtdWx0aXBhcnR5IGNyeXB0b2dyYXBoaWMgcHJvdG9j b2xzLg0KPiA+PiBCdXQgSSBub3RpY2UgdGhhdCB0aGUgbWVjaGFuaXNtIHdlJ3JlIGRpc2N1c3Np bmcgaGVyZSB0d28gcHJpbWl0aXZlcw0KPiA+PiAocHJvdmlkZSBpbmZvcm1hdGlvbiB0byB0aGUg cGF0aCB0aGF0IGF0IGxlYXN0IHRoZSByZW1vdGUgZW5kcG9pbnQNCj4gPj4gY2FuIHZlcmlmeSBp cyBhdXRoZW50aWMsIHJldHJpZXZlIGluZm9ybWF0aW9uIGZyb20gdGhlIHBhdGggd2l0aCBzZW5k ZXINCj4gcGVybWlzc2lvbikgb24gdG9wIG9mIHdoaWNoIHN1Y2ggcHJvdG9jb2xzIGNvdWxkIGJl IGRlc2lnbmVkLg0KPiA+DQo+ID4gKDEpIElmIHRoZSBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCB0 byB0aGUgcGF0aCwgd2h5IHRoZSByZW1vdGUgZW5kcG9pbnQNCj4gbmVlZHMgdG8gdmVyaWZ5IGF1 dGhlbnRpYz8gSXMgdGhpcyBpbmZvcm1hdGlvbiBhbHNvIHVzZWZ1bCBmb3IgdGhlIHJlbW90ZQ0K PiBlbmRwb2ludD8NCj4gDQo+IEl0IG1heSBiZTsgb25lIGNvdWxkIGVudmlzaW9uIGZ1dHVyZSB0 cmFuc3BvcnRzIG92ZXIgUExVUyB3aGVyZSBwYXJ0IG9mIHRoZQ0KPiBoZWFkZXIgaXMgZXhwb3Nl ZCBidXQgaW50ZWdyaXR5IHByb3RlY3RlZCwgYW5kIHRoZSByZXN0IGlzIGVuY3J5cHRlZC4gSW50 ZWdyaXR5DQo+IHByb3RlY3Rpb24gb2YgdGhlIFBMVVMtZXhwb3NlZCBpbmZvcm1hdGlvbiByZWR1 Y2VzIHJlZHVuZGFuY3kgaW4gdGhlDQo+IGVuY3J5cHRlZCBoZWFkZXJzIGluIHRoaXMgY2FzZS4N Cj4gDQo+IFRoZSBvdGhlciByZWFzb24gdG8gZG8gdGhpcyBpcyB0byBkZXRlY3QgYW5kIHJlYWN0 IHRvIHVuYXV0aG9yaXplZCBtZWRkbGluZyBpbg0KPiB0aGUgUExVUyBoZWFkZXI6IHRoaXMgd291 bGQgYXBwZWFyIGFzIGFuIGVycm9yIHRvIHRoZSByZWNlaXZlcidzIHRyYW5zcG9ydCBsYXllciwN Cj4gd2hpY2ggY291bGQgdGhlbiByZXNldCB0aGUgY29ubmVjdGlvbi4gSW4gdGhpcyB3YXkgdGhl IHJlY2VpdmVyIGFjdHMgYXMgdGhlDQo+IHZlcmlmaWVyIG9uIGJlaGFsZiBvZiBhbGwgZGV2aWNl cyBvbiBwYXRoLg0KDQpIZXJlLCBkb2VzIHRoZSB1bmF1dGhvcml6ZWQgbWVkZGxpbmcgbWVhbnMg InR5cGUgb3IgbGVuZ3RoIiBvZiB0aGUgcmVzZXJ2ZWQgc3BhY2UgaW4gdGhlIFBMVVMgaGVhZGVy IGlzIG1vZGlmaWVkIGJ5IHRoZSBtaWRkbGUtYm94PyBIb3dldmVyIGlmICJjb250ZW50IiBvZiB0 aGUgcmVzZXJ2ZWQgc3BhY2UgaXMgbW9kaWZpZWQsIGl0IGlzIHJlYXNvbmFibGU/DQoNClNvIGlm IHRoZSBzZW5kZXIgd2FudHMgc29tZSBpbmZvcm1hdGlvbiBmcm9tIHBhdGgsIGl0IHNob3VsZCBz cGVjaWZ5IHRoZSB0eXBlIGFuZCBsZW5ndGggZmlyc3QgaW4gdGhlIGhlYWRlciwgdGhlbiBwYXRo IGZpbGxzIHRoZSBjb250ZW50IGFjY29yZGluZ2x5LiBJZiB0aGUgaW5mb3JtYXRpb24gaXMgdmVy aWZpZWQgYnkgdGhlIHJlY2VpdmVyLCBpdCB3aWxsIGJlIHNpZ25hbGVkIGJhY2sgdG8gdGhlIHNl bmRlciBieSB0aGUgcmVjZWl2ZXIuIA0KDQo+ID4gKDIpIEV2ZW4gaWYgdGhlIHJldHJpZXZlZCBp bmZvcm1hdGlvbiBmcm9tIHRoZSBwYXRoIHdpdGggc2VuZGVyIHBlcm1pc3Npb24sDQo+IHRoZSBy ZWNlaXZlciBjYW5ub3QgdmVyaWZ5IHRoZSBpbmZvcm1hdGlvbiAoaS5lLiBjb250ZW50KSBpcyBh dXRoZW50aWM/DQo+IA0KPiBDb3JyZWN0Lg0KPiANCj4gQ2hlZXJzLA0KPiANCj4gQnJpYW4NCj4g DQo+ID4gVGhhbmtzLA0KPiA+IEppYW5qaWUNCj4gPg0KPiA+PiAtLS0tLemCruS7tuWOn+S7ti0t LS0tDQo+ID4+IOWPkeS7tuS6ujogU3B1ZCBbbWFpbHRvOnNwdWQtYm91bmNlc0BpZXRmLm9yZ10g 5Luj6KGoIEJyaWFuIFRyYW1tZWxsDQo+ID4+IOWPkemAgeaXtumXtDogMjAxNuW5tDbmnIgyM+aX pSAxNjoxMQ0KPiA+PiDmlLbku7bkuro6IFlvdWppYW5qaWUNCj4gPj4g5oqE6YCBOiBBYXJvbiBG YWxrOyBzcHVkDQo+ID4+IOS4u+mimDogUmU6IFtTcHVkXSBlbmRwb2ludCBjb250cm9sDQo+ID4+ DQo+ID4+DQo+ID4+PiBPbiAyMyBKdW4gMjAxNiwgYXQgMTA6MDMsIFlvdWppYW5qaWUgPHlvdWpp YW5qaWVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gSGkgQnJpYW4sDQo+ID4+Pg0K PiA+Pj4gSSdtIHdvbmRlcmluZyBob3cgdGhlIGVuZHBvaW50IHZlcmlmaWVzIHRoZSBpbmZvcm1h dGlvbiBwcm92aWRlZCBieQ0KPiA+Pj4gdGhlDQo+ID4+IGRldmljZSBvbiBwYXRoPw0KPiA+Pg0K PiA+PiBJbiB0aGUgYmFzaWMgbWVjaGFuaXNtIEkndmUgb3V0bGluZWQgaGVyZSwgaXQgZG9lc24n dC4gSWYgdGhlcmUNCj4gPj4gZXhpc3RzIHNvbWUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGVu ZHBvaW50IGFuZCB0aGUgZGV2aWNlIG9uIHBhdGgsDQo+ID4+IHRoZW4gdGhlIGluZm9ybWF0aW9u IHByb3ZpZGVkIHdpdGggaW4gdGhlIFBMVVMgaGVhZGVyIGNhbiBpdHNlbGYgYmUNCj4gPj4gTUFD J2Qgd2l0aCBhIGtleSBleGNoYW5nZWQgd2hlbiB0aGF0IHJlbGF0aW9uc2hpcCBpcyBlc3RhYmxp c2hlZC4NCj4gPj4NCj4gPj4+IElzIGl0IGFsc28gYXNzdW1lZCB0aGF0IHRoZSBrZXkgaXMgcHJv dmlkZWQgYnkgdGhlIHN1cGVyc3RyYXRlDQo+ID4+PiB0cmFuc3BvcnQNCj4gPj4gYmV0d2VlbiB0 aGUgZGV2aWNlIG9uIHBhdGggYW5kIHRoZSBlbmRwb2ludD8NCj4gPj4NCj4gPj4gTm8sIHRoYXQg ZG9lc24ndCByZWFsbHkgbWFrZSBhbnkgc2Vuc2UsIGJlY2F1c2UgdGhlIHRyYW5zcG9ydCBpcw0K PiA+PiBlbmQtdG8tZW5kIChhcyB3YXMgdGhlIG9yaWdpbmFsIGludGVudCBvZiB0aGUgbmV0d29y ay90cmFuc3BvcnQgbGF5ZXINCj4gPj4gc2VwYXJhdGlvbikuIEFueSBrZXkgZm9yIGF1dGhlbnRp Y2F0aW5nIGFuZCB2ZXJpZnlpbmcNCj4gPj4gZW5kcG9pbnQtcHJvdmlkZWQgaW5mb3JtYXRpb24g d291bGQgaGF2ZSB0byByZXNpZGUgaW4gdGhlIFBMVVMgbGF5ZXIgb24NCj4gdGhlIGVuZHBvaW50 Lg0KPiA+Pg0KPiA+PiBJIHRoaW5rIGF0IHRoaXMgcG9pbnQgbWVjaGFuaXNtcyBmb3IgKmVzdGFi bGlzaGluZyogdGhlc2UNCj4gPj4gcmVsYXRpb25zaGlwcyBhcmUgb3V0IG9mIHNjb3BlIGZvciBh IGZ1dHVyZSBQTFVTIFdHIChhdCBsZWFzdCwgdGhleQ0KPiA+PiB3ZXJlIGxlZnQgb3V0IG9mIHRo ZSBjaGFydGVyIGRlbGliZXJhdGVseSksIHNpbmNlIHdlJ3JlIHJlYWxseQ0KPiA+PiB0YWxraW5n IGFib3V0IHRoZSBkZXNpZ24gb2YgbmV3IG11bHRpcGFydHkgY3J5cHRvZ3JhcGhpYyBwcm90b2Nv bHMuDQo+ID4+IEJ1dCBJIG5vdGljZSB0aGF0IHRoZSBtZWNoYW5pc20gd2UncmUgZGlzY3Vzc2lu ZyBoZXJlIHR3byBwcmltaXRpdmVzDQo+ID4+IChwcm92aWRlIGluZm9ybWF0aW9uIHRvIHRoZSBw YXRoIHRoYXQgYXQgbGVhc3QgdGhlIHJlbW90ZSBlbmRwb2ludA0KPiA+PiBjYW4gdmVyaWZ5IGlz IGF1dGhlbnRpYywgcmV0cmlldmUgaW5mb3JtYXRpb24gZnJvbSB0aGUgcGF0aCB3aXRoIHNlbmRl cg0KPiBwZXJtaXNzaW9uKSBvbiB0b3Agb2Ygd2hpY2ggc3VjaCBwcm90b2NvbHMgY291bGQgYmUg ZGVzaWduZWQuDQo+ID4+DQo+ID4+IENoZWVycywNCj4gPj4NCj4gPj4gQnJpYW4NCj4gPj4NCj4g Pj4+IFRoYW5rcywNCj4gPj4+IEppYW5qaWUNCj4gPj4+DQo+ID4+Pj4gLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0KPiA+Pj4+IOWPkeS7tuS6ujogQnJpYW4gVHJhbW1lbGwgW21haWx0bzppZXRmQHRy YW1tZWxsLmNoXQ0KPiA+Pj4+IOWPkemAgeaXtumXtDogMjAxNuW5tDbmnIgyMuaXpSAxODo0NQ0K PiA+Pj4+IOaUtuS7tuS6ujogWW91amlhbmppZQ0KPiA+Pj4+IOaKhOmAgTogQWFyb24gRmFsazsg c3B1ZA0KPiA+Pj4+IOS4u+mimDogUmU6IFtTcHVkXSBlbmRwb2ludCBjb250cm9sDQo+ID4+Pj4N Cj4gPj4+Pg0KPiA+Pj4+PiBPbiAyMiBKdW4gMjAxNiwgYXQgMTE6MzUsIFlvdWppYW5qaWUgPHlv dWppYW5qaWVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+IEhpIEJyaWFuLA0K PiA+Pj4+Pg0KPiA+Pj4+PiBUaGFua3MgZm9yIHlvdXIgcHJvbXB0IHJlcGx5LiBQbGVhc2Ugc2Vl IG15IGNvbW1lbnRzIGJlbG93Og0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS3pgq7ku7bljp/ku7Yt LS0tLQ0KPiA+Pj4+Pj4g5Y+R5Lu25Lq6OiBCcmlhbiBUcmFtbWVsbCBbbWFpbHRvOmlldGZAdHJh bW1lbGwuY2hdDQo+ID4+Pj4+PiDlj5HpgIHml7bpl7Q6IDIwMTblubQ25pyIMjLml6UgMTY6NTYN Cj4gPj4+Pj4+IOaUtuS7tuS6ujogWW91amlhbmppZQ0KPiA+Pj4+Pj4g5oqE6YCBOiBBYXJvbiBG YWxrOyBzcHVkDQo+ID4+Pj4+PiDkuLvpopg6IFJlOiBbU3B1ZF0gZW5kcG9pbnQgY29udHJvbA0K PiA+Pj4+Pj4NCj4gPj4+Pj4+IGhpIEppYW5qaWUsDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+IE9uIDIy IEp1biAyMDE2LCBhdCAwOTowOSwgWW91amlhbmppZSA8eW91amlhbmppZUBodWF3ZWkuY29tPg0K PiB3cm90ZToNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEhpIEJyaWFuLA0KPiA+Pj4+Pj4+DQo+ID4+ Pj4+Pj4gKDEpIEZvciBmb3J3YXJkIHNpZ25hbGluZywgdGhlIHNlbmRpbmcgZW5kcG9pbnQgbXVz dCBwbGFjZQ0KPiA+Pj4+Pj4+ICJzY3JhdGNoIHNwYWNlIiBpbg0KPiA+Pj4+Pj4gdGhlIHBhY2tl dCB3aXRoIGEgbGFiZWwgb24gaXQgc3RhdGluZyB0aGF0IGl0J3Mgb2theSB0byBtb2RpZnk7DQo+ ID4+Pj4+PiB0aGlzIG9rYXktdG8tbW9kaWZ5IHN0YXRlIGlzIGVuZm9yY2VkIGJ5IGEgTUFDIHdo aWNoIG9ubHkNCj4gPj4+Pj4+IHZlcmlmaWVzIHRoZSBsZW5ndGggYnV0IG5vdCB0aGUgY29udGVu dCBvZiB0aGUgc2NyYXRjaCBzcGFjZS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IENvdWxkIHlvdSBw bGVhc2UgZWxhYm9yYXRlIGhvdyBhIE1BQyBpcyB1c2VkIHRvIGVuZm9yY2UgdGhlDQo+ID4+Pj4+ Pj4gb2theS10by1tb2RpZnkNCj4gPj4+Pj4+IHN0YXRlPyBJcyBpdCBvbmx5IGFwcGxpY2FibGUg dG8gTDIgbmV0d29yaz8NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBTb3JyeSwgYWNyb255bSBjb2xsaXNp b24uIEhlcmUgTUFDID0gbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlLA0KPiA+Pj4+Pj4gbm90 IG1lZGl1bSBhY2Nlc3MgY29udHJvbC4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gSXMgaXQgYSBkZXNp Z25lZCBmaWVsZCBpbiB0aGUgUExVUyBoZWFkZXI/DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlcmUg aXNuJ3QgYSAiUExVUyBoZWFkZXIiIHlldDsgd2UncmUgb25seSB0YWxraW5nIGFib3V0DQo+ID4+ Pj4+PiBwb3RlbnRpYWwgbWVjaGFuaXNtcyB0aGF0IGNvdWxkIGJlIGltcGxlbWVudGVkIHdpdGhp biBvbmUuIEhlcmUsDQo+ID4+Pj4+PiB0aGUgaWRlYSBpcyB0aGF0IHlvdSBoYXZlIHNvbWUgZW5j b2RpbmcgdGhhdCBhbGxvd3MgeW91IHRvIHBsYWNlDQo+ID4+Pj4+PiBsYWJlbGVkIGRhdGEgaW4g dGhlIFBMVVMgaGVhZGVyIChmcm9tIHRoZSBTUFVEIHByb3RvdHlwZQ0KPiA+Pj4+Pj4gZXhwZXJp ZW5jZSwgd2UgbGlrZSBDQk9SLCBidXQgdGhpcyBpcyBhIHRlY2huaWNhbCBkZXRhaWwpLg0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+IFNvbWUgb2YgdGhlIHR5cGVzL2tleXMgaW4gdGhpcyBkYXRhIHN0cnVj dHVyZSBhcmUgZGVzaWduYXRlZA0KPiA+Pj4+Pj4gZW5kLXRvLWVuZCwgYW5kIHNvbWUgb2YgdGhl IHR5cGVzL2tleXMgYXJlIGRlc2lnbmF0ZWQNCj4gcGF0aC1tb2RpZmlhYmxlLg0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+IFRoZSBNQUMgaXMgZ2VuZXJhdGVkIGJ5IHRoZSBzZW5kaW5nIGVuZHBvaW50IHVz aW5nIGEgc2VjcmV0DQo+ID4+Pj4+PiBzaGFyZWQgYnkgYm90aCBlbmRwb2ludHMsIGFuZCBjb3Zl cnM6DQo+ID4+Pj4+DQo+ID4+Pj4+IEhvdyBpcyB0aGUgc2VjcmV0IHNoYXJlZCBiZXR3ZWVuIGJv dGggZW5kcG9pbnRzPyBUaGUgZW5kcG9pbnRzDQo+ID4+Pj4+IG5lZWQgdG8NCj4gPj4+PiBlc3Rh Ymxpc2ggYSBjb25uZWN0aW9uIHRvIGV4Y2hhbmdlIGtleXM/DQo+ID4+Pj4NCj4gPj4+PiBZZXMu IFRoaXMgaXMgYXNzdW1lZCB0byBiZSBwcm92aWRlZCBieSB0aGUgc3VwZXJzdHJhdGUgdHJhbnNw b3J0Lg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gKDEpIHRoZSBwcmVzZW5jZSBhbmQgY29udGVudCBvZiBl bmQtdG8tZW5kIFBMVVMgaGVhZGVyDQo+ID4+Pj4+PiBpbmZvcm1hdGlvbg0KPiA+Pj4+Pg0KPiA+ Pj4+PiBEbyB5b3UgbWVhbiB0aGF0IHRoaXMgaW5mb3JtYXRpb24gaXMgZW5jcnlwdGVkIHVzaW5n IHRoZSBzaGFyZWQgc2VjcmV0Pw0KPiA+Pj4+IE9ubHkgYm90aCBlbmRwb2ludHMgY2FuIGtub3cg dGhlIGNvbnRlbnQ/DQo+ID4+Pj4NCj4gPj4+PiBObywgdGhlIE1BQyBpcyBnZW5lcmF0ZWQgdXNp bmcgdGhlIHNoYXJlZCBzZWNyZXQsIHNvIHRoYXQgaXQgY2Fubm90DQo+ID4+Pj4gYmUgZm9yZ2Vk IGJ5IG9uLXBhdGggZGV2aWNlcy4gVGhlIGluZm9ybWF0aW9uIGl0c2VsZiBpcyBpbiB0aGUgY2xl YXIuDQo+ID4+Pj4NCj4gPj4+PiBDaGVlcnMsDQo+ID4+Pj4NCj4gPj4+PiBCcmlhbg0KPiA+Pj4+ DQo+ID4+Pj4+PiAoMikgdGhlIHByZXNlbmNlIGFuZCBsZW5ndGggb2YgcGF0aC1tb2RpZmlhYmxl IFBMVVMgaGVhZGVyDQo+ID4+Pj4+PiBpbmZvcm1hdGlvbiwgYnkgdHJlYXRpbmcgdGhlIGNvbnRl bnQgYXMgYSBsZW5ndGgtTiBieXRlIGFycmF5IG9mIHplcm9lcy4NCj4gPj4+Pj4NCj4gPj4+Pj4g SG93IGRvZXMgdGhlIG1pZGRsZS1ib3ggYWxvbmcgdGhlIHBhdGggaW50ZXJwcmV0IHRoZSBQTFVT IGhlYWRlcj8NCj4gPj4+Pj4gRG9lcw0KPiA+Pj4+IHRoZSBtaWRkbGUtYm94IGFsc28gbmVlZCB0 aGUgc2VjcmV0PyBJIHVzZWQgdG8gdGhpbmsgbWlkZGxlLWJveCBpcw0KPiA+PiB0cmFuc3BhcmVu dC4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhhbmtzLA0KPiA+Pj4+PiBKaWFuamllDQo+ID4+Pj4+DQo+ ID4+Pj4+PiBUaGlzIE1BQyBpcyB0aGVuIHRyYW5zbWl0dGVkIGZyb20gdGhlIHNlbmRlciB0byB0 aGUgcmVjZWl2ZXIgaW4NCj4gPj4+Pj4+IGVuY3J5cHRlZCBmb3JtLg0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+IEFkZGl0aW9uYWwgTUFDcyBtYXkgYWxzbyBwcm90ZWN0IGJpdHMgb2YgdGhlIElQIGFuZCBV RFAgaGVhZGVyLA0KPiA+Pj4+Pj4gaW4gb3JkZXIgdG8gZGV0ZWN0IE5BVCBhbmQgb3RoZXIgc3Vi LVBMVVMgbW9kaWZpY2F0aW9ucywgYnV0DQo+ID4+Pj4+PiB0aGVzZSBhcmUgb3V0c2lkZSB0aGUg c2NvcGUgb2YgdGhpcyBxdWVzdGlvbi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBDaGVlcnMsDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gQnJpYW4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+ Pj4+Pj4gVGhhbmtzLA0KPiA+Pj4+Pj4+IEppYW5qaWUNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IOWP keS7tuS6ujogU3B1ZCBbbWFpbHRvOnNwdWQtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEJyaWFu IFRyYW1tZWxsDQo+ID4+Pj4+Pj4g5Y+R6YCB5pe26Ze0OiAyMDE25bm0NuaciDIx5pelIDE3OjM2 DQo+ID4+Pj4+Pj4g5pS25Lu25Lq6OiBBYXJvbiBGYWxrDQo+ID4+Pj4+Pj4g5oqE6YCBOiBzcHVk DQo+ID4+Pj4+Pj4g5Li76aKYOiBSZTogW1NwdWRdIGVuZHBvaW50IGNvbnRyb2wNCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IGhpIEFhcm9uLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gMDYvMjAvMjAx NiAxMTozOCBQTSwgQWFyb24gRmFsayB3cm90ZToNCj4gPj4+Pj4+PiBIaSBCcmlhbi0NCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+IEluIHRoZSBjaGFydGVyIGFuZCB0aGUgZHJhZnQtdHJhbW1lbC1zcHVk LXJlcSBpdCBzYXlzDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBCb3RoIGVuZHBvaW50LXRvLXBhdGgg YW5kIHBhdGgtdG8tZW5kcG9pbnQgc2lnbmFsaW5nIGhhcHBlbg0KPiA+Pj4+Pj4+IGNvbXBsZXRl bHkgdW5kZXIgZW5kcG9pbnQgY29udHJvbC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFdpdGhvdXQg YWRkaXRpb25hbCBlbGFib3JhdGlvbiwgb25lIGNvdWxkIGNvbmNsdWRlIHRoYXQsIGUuZy4sDQo+ ID4+Pj4+Pj4gcGVybWlzc2lvbiBpcw0KPiA+Pj4+Pj4gcmVxdWlyZWQgYmVmb3JlIGEgcGF0aCBj b3VsZCBzaWduYWwgdG8gYW4gZW5kcG9pbnQuDQo+ID4+Pj4+PiBBbHRlcm5hdGl2ZWx5LCBpdCBj b3VsZCBiZSBpbXBseWluZyBhbiBlbmRwb2ludCBoYXMgdGhlIGZyZWVkb20NCj4gPj4+Pj4+IHRv IGlnbm9yZSBhbnkgc2lnbmFsaW5nDQo+ID4+Pj4gZnJvbSB0aGUgcGF0aC4NCj4gPj4+Pj4+IEkg aGF2ZSBiZWVuIGFzc3VtaW5nIHRoZSBsYXR0ZXIuICBCdXQgbm93IEkgd29uZGVyIGlmIHlvdSBh cmUNCj4gPj4+Pj4+IGludGVudGlvbmFsbHkgYXR0ZW1wdGluZyB0byBwZXJtaXQgdGhlIGZvcm1l ci4gIENvdWxkIHlvdSBjbGFyaWZ5Pw0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT3VyIGludGVudGlv biBpcyB0aGUgZm9ybWVyOiB0aGF0IHBlcm1pc3Npb24gaXMgcmVxdWlyZWQgYmVmb3JlDQo+ID4+ Pj4+Pj4gdGhlIHBhdGggY2FuDQo+ID4+Pj4+PiBzaWduYWwgdG8gdGhlIGVuZHBvaW50LiBXZSBo YXZlIHR3byBtZWNoYW5pc21zIHdlJ3ZlIGJlZW4NCj4gPj4+Pj4+IHRoaW5raW5nIGFib3V0IGZv ciB0aGlzOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gKDEpIEZvciBmb3J3YXJkIHNpZ25hbGluZywg dGhlIHNlbmRpbmcgZW5kcG9pbnQgbXVzdCBwbGFjZQ0KPiA+Pj4+Pj4+ICJzY3JhdGNoIHNwYWNl IiBpbg0KPiA+Pj4+Pj4gdGhlIHBhY2tldCB3aXRoIGEgbGFiZWwgb24gaXQgc3RhdGluZyB0aGF0 IGl0J3Mgb2theSB0byBtb2RpZnk7DQo+ID4+Pj4+PiB0aGlzIG9rYXktdG8tbW9kaWZ5IHN0YXRl IGlzIGVuZm9yY2VkIGJ5IGEgTUFDIHdoaWNoIG9ubHkNCj4gPj4+Pj4+IHZlcmlmaWVzIHRoZSBs ZW5ndGggYnV0IG5vdCB0aGUgY29udGVudCBvZiB0aGUgc2NyYXRjaCBzcGFjZS4NCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+ICgyKSBGb3IgZGlyZWN0IHJldmVyc2Ugc2lnbmFsaW5nLCBhIHBhdGggZWxl bWVudCBtYXkgbm90IHNlbmQgYQ0KPiA+Pj4+Pj4+IGRpcmVjdCByZXZlcnNlDQo+ID4+Pj4+PiBz aWduYWxpbmcgcGFja2V0IHRvIGEgc2VuZGVyIHVubGVzcyBpdCBoYXMgYWxzbyBkcm9wcGVkIGEg Zm9yd2FyZA0KPiA+Pj4+Pj4gcGFja2V0IGZyb20gdGhlIHNlbmRlciB0byByZWNlaXZlci4gVGhp cyBzZWNvbmQgbWVjaGFuaXNtIGlzIGxlc3MNCj4gPj4+Pj4+IGFib3V0IHBlcm1pc3Npb24gYW5k IG1vcmUgYWJvdXQgcmVkdWNpbmcgdGhlIGF0dHJhY3RpdmVuZXNzIG9mDQo+ID4+Pj4+PiBQTFVT IGZvciBhbXBsaWZpY2F0aW9uL3JlZmxlY3Rpb24gYXR0YWNrcy4NCj4gPj4+Pj4+Pg0KPiA+Pj4+ Pj4+IEluIGFueSBjYXNlLCBlbmRwb2ludHMgKGFuZCBwYXRoIGVsZW1lbnRzKSBjYW4gaWdub3Jl IHdoYXRldmVyDQo+ID4+Pj4+Pj4gdGhleSB3YW50IHRvDQo+ID4+Pj4+PiBmcm9tIHRoZSBQTFVT LWV4cG9zZWQgaW5mb3JtYXRpb247IGl0J3Mgd2hhdCdzIGluIHRoZSBlbmNyeXB0ZWQNCj4gPj4+ Pj4+IHRyYW5zcG9ydCBsYXllciBoZWFkZXJzIHRoYXQgbWF0dGVycyB0byB0aGUgdHJhbnNwb3J0 IHByb3RvY29sIG9uDQo+ID4+Pj4+PiB0aGUNCj4gPj4+PiBlbmRwb2ludC4NCj4gPj4+Pj4+Pg0K PiA+Pj4+Pj4+IENoZWVycywNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEJyaWFuDQo+ID4+Pj4+Pj4N Cj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoYW5rcywNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IOKAlGFh cm9uDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+Pj4+Pj4gU3B1ZCBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+PiBTcHVkQGlldGYub3Jn DQo+ID4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkDQo+ ID4+Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IFNwdWQgbWFpbGluZyBsaXN0DQo+ID4gU3B1 ZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3B1 ZA0KDQo= From nobody Mon Jun 27 03:13: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 BFCD312D0CE for ; Mon, 27 Jun 2016 03:13:00 -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 FZSYrtL19Y-t for ; Mon, 27 Jun 2016 03:12:57 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 82C5712D0C3 for ; Mon, 27 Jun 2016 03:12:57 -0700 (PDT) Received: from public-docking-cx-2967.ethz.ch (public-docking-pat-cx-mapped-0014.ethz.ch [195.176.111.15]) by trammell.ch (Postfix) with ESMTPSA id 71DEE1A0F78; Mon, 27 Jun 2016 12:12:56 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_447BC95B-9C95-4711-B451-F637B2CD922E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Mon, 27 Jun 2016 12:12:55 +0200 Message-Id: References: <57690A66.3050502@trammell.ch> <095C2E5D-D235-4017-91E2-9B437D8DBDD0@trammell.ch> <4F02B71A-5F3F-4595-8661-51CE07E9F0E5@trammell.ch> <1D5C1BA4-4359-4DC9-B1BA-2DF576AD4A92@trammell.ch> To: Youjianjie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Aaron Falk , spud Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 10:13:01 -0000 --Apple-Mail=_447BC95B-9C95-4711-B451-F637B2CD922E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 27 Jun 2016, at 12:06, Youjianjie wrote: >=20 > Hi Brian, >=20 > Further comments below: >=20 > Thanks, > Jianjie >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Brian Trammell [mailto:ietf@trammell.ch] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8823=E6=97=A5= 17:16 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Youjianjie >> =E6=8A=84=E9=80=81: Aaron Falk; spud >> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>=20 >>=20 >>> On 23 Jun 2016, at 10:55, Youjianjie wrote: >>>=20 >>> Hi Brian, >>>=20 >>> Thanks for the reply. >>>=20 >>>> I think at this point mechanisms for *establishing* these >>>> relationships are out of scope for a future PLUS WG (at least, they >>>> were left out of the charter deliberately), since we're really >>>> talking about the design of new multiparty cryptographic protocols. >>>> But I notice that the mechanism we're discussing here two = primitives >>>> (provide information to the path that at least the remote endpoint >>>> can verify is authentic, retrieve information from the path with = sender >> permission) on top of which such protocols could be designed. >>>=20 >>> (1) If the information is provided to the path, why the remote = endpoint >> needs to verify authentic? Is this information also useful for the = remote >> endpoint? >>=20 >> It may be; one could envision future transports over PLUS where part = of the >> header is exposed but integrity protected, and the rest is encrypted. = Integrity >> protection of the PLUS-exposed information reduces redundancy in the >> encrypted headers in this case. >>=20 >> The other reason to do this is to detect and react to unauthorized = meddling in >> the PLUS header: this would appear as an error to the receiver's = transport layer, >> which could then reset the connection. In this way the receiver acts = as the >> verifier on behalf of all devices on path. >=20 > Here, does the unauthorized meddling means "type or length" of the = reserved space in the PLUS header is modified by the middle-box? However = if "content" of the reserved space is modified, it is reasonable? The reserved space is in this case intended to be modified by on-path = devices. If we lived in a world in which it was reasonable to assume = that we could exchange keys with and maintain certificates for every = potential middlebox on path, we could use that cryptographic context to = verify this information. But we don't, so we can't. Building multiparty = cryptographic protocols that would be suited to this sort of thing is an = area of open research; once designed, such a thing could run on top of = this unprotected facility provided by PLUS. > So if the sender wants some information from path, it should specify = the type and length first in the header, then path fills the content = accordingly. If the information is verified by the receiver, it will be = signaled back to the sender by the receiver. Precisely. Cheers, Brian >=20 >>> (2) Even if the retrieved information from the path with sender = permission, >> the receiver cannot verify the information (i.e. content) is = authentic? >>=20 >> Correct. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>> Thanks, >>> Jianjie >>>=20 >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Spud [mailto:spud-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Brian Trammell >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8823=E6=97= =A5 16:11 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Youjianjie >>>> =E6=8A=84=E9=80=81: Aaron Falk; spud >>>> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>>>=20 >>>>=20 >>>>> On 23 Jun 2016, at 10:03, Youjianjie = wrote: >>>>>=20 >>>>> Hi Brian, >>>>>=20 >>>>> I'm wondering how the endpoint verifies the information provided = by >>>>> the >>>> device on path? >>>>=20 >>>> In the basic mechanism I've outlined here, it doesn't. If there >>>> exists some relationship between the endpoint and the device on = path, >>>> then the information provided with in the PLUS header can itself be >>>> MAC'd with a key exchanged when that relationship is established. >>>>=20 >>>>> Is it also assumed that the key is provided by the superstrate >>>>> transport >>>> between the device on path and the endpoint? >>>>=20 >>>> No, that doesn't really make any sense, because the transport is >>>> end-to-end (as was the original intent of the network/transport = layer >>>> separation). Any key for authenticating and verifying >>>> endpoint-provided information would have to reside in the PLUS = layer on >> the endpoint. >>>>=20 >>>> I think at this point mechanisms for *establishing* these >>>> relationships are out of scope for a future PLUS WG (at least, they >>>> were left out of the charter deliberately), since we're really >>>> talking about the design of new multiparty cryptographic protocols. >>>> But I notice that the mechanism we're discussing here two = primitives >>>> (provide information to the path that at least the remote endpoint >>>> can verify is authentic, retrieve information from the path with = sender >> permission) on top of which such protocols could be designed. >>>>=20 >>>> Cheers, >>>>=20 >>>> Brian >>>>=20 >>>>> Thanks, >>>>> Jianjie >>>>>=20 >>>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Brian Trammell = [mailto:ietf@trammell.ch] >>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8822=E6=97= =A5 18:45 >>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Youjianjie >>>>>> =E6=8A=84=E9=80=81: Aaron Falk; spud >>>>>> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>>>>>=20 >>>>>>=20 >>>>>>> On 22 Jun 2016, at 11:35, Youjianjie = wrote: >>>>>>>=20 >>>>>>> Hi Brian, >>>>>>>=20 >>>>>>> Thanks for your prompt reply. Please see my comments below: >>>>>>>=20 >>>>>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Brian Trammell = [mailto:ietf@trammell.ch] >>>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8822=E6= =97=A5 16:56 >>>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Youjianjie >>>>>>>> =E6=8A=84=E9=80=81: Aaron Falk; spud >>>>>>>> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>>>>>>>=20 >>>>>>>> hi Jianjie, >>>>>>>>=20 >>>>>>>>> On 22 Jun 2016, at 09:09, Youjianjie >> wrote: >>>>>>>>>=20 >>>>>>>>> Hi Brian, >>>>>>>>>=20 >>>>>>>>> (1) For forward signaling, the sending endpoint must place >>>>>>>>> "scratch space" in >>>>>>>> the packet with a label on it stating that it's okay to modify; >>>>>>>> this okay-to-modify state is enforced by a MAC which only >>>>>>>> verifies the length but not the content of the scratch space. >>>>>>>>>=20 >>>>>>>>> Could you please elaborate how a MAC is used to enforce the >>>>>>>>> okay-to-modify >>>>>>>> state? Is it only applicable to L2 network? >>>>>>>>=20 >>>>>>>> Sorry, acronym collision. Here MAC =3D message authentication = code, >>>>>>>> not medium access control. >>>>>>>>=20 >>>>>>>>> Is it a designed field in the PLUS header? >>>>>>>>=20 >>>>>>>> There isn't a "PLUS header" yet; we're only talking about >>>>>>>> potential mechanisms that could be implemented within one. = Here, >>>>>>>> the idea is that you have some encoding that allows you to = place >>>>>>>> labeled data in the PLUS header (from the SPUD prototype >>>>>>>> experience, we like CBOR, but this is a technical detail). >>>>>>>>=20 >>>>>>>> Some of the types/keys in this data structure are designated >>>>>>>> end-to-end, and some of the types/keys are designated >> path-modifiable. >>>>>>>>=20 >>>>>>>> The MAC is generated by the sending endpoint using a secret >>>>>>>> shared by both endpoints, and covers: >>>>>>>=20 >>>>>>> How is the secret shared between both endpoints? The endpoints >>>>>>> need to >>>>>> establish a connection to exchange keys? >>>>>>=20 >>>>>> Yes. This is assumed to be provided by the superstrate transport. >>>>>>>=20 >>>>>>>> (1) the presence and content of end-to-end PLUS header >>>>>>>> information >>>>>>>=20 >>>>>>> Do you mean that this information is encrypted using the shared = secret? >>>>>> Only both endpoints can know the content? >>>>>>=20 >>>>>> No, the MAC is generated using the shared secret, so that it = cannot >>>>>> be forged by on-path devices. The information itself is in the = clear. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>>> (2) the presence and length of path-modifiable PLUS header >>>>>>>> information, by treating the content as a length-N byte array = of zeroes. >>>>>>>=20 >>>>>>> How does the middle-box along the path interpret the PLUS = header? >>>>>>> Does >>>>>> the middle-box also need the secret? I used to think middle-box = is >>>> transparent. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Jianjie >>>>>>>=20 >>>>>>>> This MAC is then transmitted from the sender to the receiver in >>>>>>>> encrypted form. >>>>>>>>=20 >>>>>>>> Additional MACs may also protect bits of the IP and UDP header, >>>>>>>> in order to detect NAT and other sub-PLUS modifications, but >>>>>>>> these are outside the scope of this question. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Jianjie >>>>>>>>>=20 >>>>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Spud = [mailto:spud-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Brian Trammell >>>>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8821=E6= =97=A5 17:36 >>>>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Aaron Falk >>>>>>>>> =E6=8A=84=E9=80=81: spud >>>>>>>>> =E4=B8=BB=E9=A2=98: Re: [Spud] endpoint control >>>>>>>>>=20 >>>>>>>>> hi Aaron, >>>>>>>>>=20 >>>>>>>>> On 06/20/2016 11:38 PM, Aaron Falk wrote: >>>>>>>>> Hi Brian- >>>>>>>>>=20 >>>>>>>>> In the charter and the draft-trammel-spud-req it says >>>>>>>>>=20 >>>>>>>>> Both endpoint-to-path and path-to-endpoint signaling happen >>>>>>>>> completely under endpoint control. >>>>>>>>>=20 >>>>>>>>> Without additional elaboration, one could conclude that, e.g., >>>>>>>>> permission is >>>>>>>> required before a path could signal to an endpoint. >>>>>>>> Alternatively, it could be implying an endpoint has the freedom >>>>>>>> to ignore any signaling >>>>>> from the path. >>>>>>>> I have been assuming the latter. But now I wonder if you are >>>>>>>> intentionally attempting to permit the former. Could you = clarify? >>>>>>>>>=20 >>>>>>>>> Our intention is the former: that permission is required = before >>>>>>>>> the path can >>>>>>>> signal to the endpoint. We have two mechanisms we've been >>>>>>>> thinking about for this: >>>>>>>>>=20 >>>>>>>>> (1) For forward signaling, the sending endpoint must place >>>>>>>>> "scratch space" in >>>>>>>> the packet with a label on it stating that it's okay to modify; >>>>>>>> this okay-to-modify state is enforced by a MAC which only >>>>>>>> verifies the length but not the content of the scratch space. >>>>>>>>>=20 >>>>>>>>> (2) For direct reverse signaling, a path element may not send = a >>>>>>>>> direct reverse >>>>>>>> signaling packet to a sender unless it has also dropped a = forward >>>>>>>> packet from the sender to receiver. This second mechanism is = less >>>>>>>> about permission and more about reducing the attractiveness of >>>>>>>> PLUS for amplification/reflection attacks. >>>>>>>>>=20 >>>>>>>>> In any case, endpoints (and path elements) can ignore whatever >>>>>>>>> they want to >>>>>>>> from the PLUS-exposed information; it's what's in the encrypted >>>>>>>> transport layer headers that matters to the transport protocol = on >>>>>>>> the >>>>>> endpoint. >>>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>>=20 >>>>>>>>> =E2=80=94aaron >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=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 --Apple-Mail=_447BC95B-9C95-4711-B451-F637B2CD922E 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 iQIcBAEBCgAGBQJXcPwoAAoJEIoSt78L6kaj+IwQAJhCMfvpfsG01+lbNoTz8o5w CjPYYpqXOtL1edFp0y5JJpFF1b952YK8Ja72W8nHtEKuqP/MhceJZQSGkpQV2wnF eMjb5h92Zqdrr9EZLzXFm7Y6Nxj7ri1RS5KNaFoSuQew7RnJxV2T9yDdkjA5/KN6 JUg1Jwcmsk+stNDj5McPW3zZAj/urXL4BVTY/eA0z6l7g6LojDO74XrzRDgTrFeQ TqFpvlbL0tYLxMR8tcXb0D1+BcphPRIIYrBhKICMacNxoQFgxX810d79IiqjNYCQ 7jKn+zq7TQXoz4lvDjDCLwswY2iD00vhzYpPm+DJwtWxSIRTa/AZu3xrHq6lgADN Vouc9+wtfP81xdcfkVYC1XdFYecc9gB1zKWUYEpPU2euhqz3pcKjobMMDOU+SpHf 1TwLPydnzzvl/b4Pr4vQEe7lkXBxSfkdrCDyS9flZ6mX7VstC9DRdpfSqonakgC6 Y6FBGnwo7qecvG97/Dv1Agqm6CyBKH9rcqzoSbM3zX7EZJVWrmc2aAmo+iuuQsSK FRFdNL3PU5kF+iHZ95fpLJkokxjuyQAOhEIrWmuxjgqRuCZqEGH8KAcOsNOcoIJX L5O9mc6UbuhmyI65gUA+eq+DVe5DueEou1+9CKkS9KnZgl/j9nNPxsYgTuMYPrk1 MEsfIDCb9W4wTLIFBnk/ =dtaw -----END PGP SIGNATURE----- --Apple-Mail=_447BC95B-9C95-4711-B451-F637B2CD922E-- From nobody Mon Jun 27 12:31: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 A8D4312D797 for ; Mon, 27 Jun 2016 12:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJHomDyLh1OE for ; Mon, 27 Jun 2016 12:30:57 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4E9127071 for ; Mon, 27 Jun 2016 12:30:57 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id g127so73025564ith.0 for ; Mon, 27 Jun 2016 12:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2ZglpbH8gair9BelGYLvhlOIxkIdwufmdFKwPqRRN1k=; b=Zh9lZHxU/e9g4837e2SP+UMBJSihy7X964nyDFkAtQtXCmC0y+6Q4IODPB4b21/l+4 aG0DAksWpea17V3q5fwSGhUymfcMqe/BK1GNK6n85GzQhWoOQIIZjPQAL5nMdfLGtEOD QTDNmnwiyLOUFv7NSOp02RmjrwAEGACFYnzatCqQWXFHNbk1KFFTCeQY9szRtlTGNDgW yAIorjtUX+7deNXRaKNjBzGRMnnQgAykqHyEO3t1B9xnBiGibceckAijFoJHa7Edw1+j PNilPj/vbHqGw/vMUhpjnfxC0sk9DaUVe011mQbv/IcWaA1W/OO2pOV1nF4BCMJnc/n7 FltA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2ZglpbH8gair9BelGYLvhlOIxkIdwufmdFKwPqRRN1k=; b=FE3KPxbB83tzWjWMZjnYCFDjs6ED2x2rY8f7iLSNda+ijbPGLBA52tY+wAcH8OWgBW rOYLZ15Oq6ftpHBgPVK0+TtGyaj2vmzTB8w6eMnvyFmvshr7CxqpF07nUk5m4Fzw+wBk hsyxILQrcVbvRRWbLS8MW4rOiLeT++RYOUzac644apCcz0S2TVscugp+5xooeP6MU1uz zlRvQ8tnCN/cvebLIuQQCMa6y3I5WUM6QjwEy6Z174cHTJ72aeE8ntBzPCaWRG4xnX+P FtEX6YbcoEOVZIPa591beMXxD+9vfazsn04dEV1/u0rpWto6dteWqe6XDnSSXx1AJN1p fYKg== X-Gm-Message-State: ALyK8tLQW3GyEkJEkO2wo11jSarMLgdM0RsBjzIMFK0HArDYljVu2ZxDv28oyz2Rc+jLq8WufTCOmpgH2oP7kw== X-Received: by 10.36.73.219 with SMTP id e88mr10436251itd.88.1467055856996; Mon, 27 Jun 2016 12:30:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Mon, 27 Jun 2016 12:30:56 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Mon, 27 Jun 2016 12:30:56 -0700 Message-ID: To: Natasha Rooney Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: spud Subject: Re: [Spud] Details about PLUS BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 19:31:00 -0000 On Mon, Jun 20, 2016 at 9:58 AM, Natasha Rooney wrote: > Hi all, > > ***** Upcoming BoF ***** > I am sure you all know that there will be a PLUS BoF at IETF96! According= to > the current (preliminary) agenda the current slot is Thursday Morning > Session 1[1]. > > ***** Chairs Selected ***** > Aaron Falk and I (Natasha Rooney) are very happy to be your chairs for th= e > BoF! We=E2=80=99ll be working over the next few weeks with the BoF propon= ents and > presenters to make sure the BoF asks the right questions and everyone > involved is prepared to make the right decisions. > > ***** Mailing List and BoF Name ***** > Some of you may be confused with the naming of the BoF and this mailing > list. Between now and IETF96 please continue to use the SPUD mailing list > [2] for discussions about SPUD and the PLUS BoF. If the PLUS BoF agrees t= o > form a working group we will create a PLUS mailing list then, but this wi= ll > only be *after* IETF96. So (again just for clarity!), keep using the SPUD > mailing list for now. > > If you have any questions for the chairs or AD please feel free to post t= hem > to the SPUD list. > Hi, I've posted draft-herbert-transports-over-udp-00.txt on the spud list that describes methods to run transport protocols (like TCP) over UDP. This includes a "shim" UDP layer protocol. Is this the scope of the PLUS BOF for discussion? Thanks, Tom > Thanks! > > Natasha > > [1] https://datatracker.ietf.org/meeting/96/agenda.html > [2] spud@ietf.org > > Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | > nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: > nrooney@gsm.org > > > This email and its attachments are intended for the above named only and = may > be confidential. If they have come to you in error you must take no actio= n > based on them, nor must you copy or show them to anyone; please reply to > this email or call +44 207 356 0600 and highlight the error. > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Mon Jun 27 13:13:10 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0785212D19F for ; Mon, 27 Jun 2016 13:13:09 -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 K7m3vH7eQjJ2 for ; Mon, 27 Jun 2016 13:13:06 -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 43C5112D180 for ; Mon, 27 Jun 2016 13:13:06 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id u201so215921278oie.0 for ; Mon, 27 Jun 2016 13:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=98nQrSvPWW0GuBHj8HvNKDlRrnEHU6rS6G3riMBidxY=; b=fJAPjPwoopyPygmYxJwNKBRPYOi4z6IhKaayir6aQsFPgsmoSD7t5Yfs4/Mx38t2D8 i+De9dT0pbWRKOib5YtmHjVJH/arx601oV6JI7dMomUHl2lDOL2hhgotxRmCLIllZlZ2 s0qlufcF9KlNMfIMHUNmzmw55ERO6qAp9WDpB0UZ0TzSVMi64Hzruzu4nNVOQNyuU6On kmCmYgArbMf8Yvrs4wGWNasWr6fd9m9pw5450xz+Js4ftzIve7gMPigQHKpBopfUFjAt jWGDqlZws73rL6/TWjNQ7/UlyBAoLDDJnyzbeXlxUDHZKw1FiQF8031vepAAHTPPB7w3 DLPw== 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=98nQrSvPWW0GuBHj8HvNKDlRrnEHU6rS6G3riMBidxY=; b=VdzC7KQVDt1fZBXP1m/xDk5gdJhGfIspHsScgyupNNCw4TGxjE0HHVb6ElCy0eEEV0 /lLd5bDoXT7O8r8F3h9RXLYk473+tn4d79QwvQbJnRTnLhxlw9SZOWl+k7I5LhBFvUQJ L77Hr2APrpIdyfTHMe9Tce9VyIaSasyTgt0ch672m1Y9UO2xo57YzFOdtTbKR60Z/py/ 3qHGLyWhdHeP9D5wfwvF/VU19DT10472ktGAsp7pKRfAAyueB/O5Lqao0WCpSih5s3ML YDsaUWLzss6v8pv9ybDSPxd/33lafeUlyh3dSttK67OhtxzOFJWTs8JPhzpbTsqYnrT0 esBg== X-Gm-Message-State: ALyK8tJXQTA+zT9lh43b4yt8AL32C45Cbjde+fYtGpObzmewTz2Ylv4urWuzgggXyhVJGqKoj6KSs1FGkCW0Vg== X-Received: by 10.202.205.84 with SMTP id d81mr1887695oig.171.1467058385587; Mon, 27 Jun 2016 13:13:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Mon, 27 Jun 2016 13:12:46 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Mon, 27 Jun 2016 13:12:46 -0700 Message-ID: To: Tom Herbert Content-Type: multipart/alternative; boundary=001a1134ede2f012da05364825a8 Archived-At: Cc: Natasha Rooney , spud Subject: Re: [Spud] Details about PLUS BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 20:13:09 -0000 --001a1134ede2f012da05364825a8 Content-Type: text/plain; charset=UTF-8 Hi Tom, On Mon, Jun 27, 2016 at 12:30 PM, Tom Herbert wrote: > On Mon, Jun 20, 2016 at 9:58 AM, Natasha Rooney wrote: > > > > If you have any questions for the chairs or AD please feel free to post > them > > to the SPUD list. > > > Hi, > > I've posted draft-herbert-transports-over-udp-00.txt on the spud list > that describes methods to run transport protocols (like TCP) over UDP. > This includes a "shim" UDP layer protocol. Is this the scope of the > PLUS BOF for discussion? > > I've read draft-herbert-transports-over-udp, and my take was that it was an argument that the need for path layer was not proved. Two bits in particular stand out for this: This solution espouses a model that only the minimal necessary information about the packet is made visible to the network. This exposed information is sufficient to route the packet through the network and to demultiplex and decrypt the packet at the receiving end host. In particular, the encapsulated protocol and related connection state may be rendered invisible to the network. Additionally, this solution allows encapsulation of IPv6 extension headers, particularly destination options, which can then also be hidden from inspection in the network. and TOU implements a subset of the the SPUD architecture but expressly does not require or include provisions to leak end-to-end information for consumption in the network. The encapsulation protocol used in TOU (GUE) is extensible to optionally allow information exposure if this proves to be warranted. When a transport protocol's state machine is expressed in clear text, it can be interpreted by path elements and it thus creates a sort of implicit path layer. PLUS is arguing that the use of clear text should end, and that the path layer should be made explicit with the control over what is being said at that layer handed firmly to the end systems. They can choose to say nothing, of course, and that would result in something very similar to TOU, at least as I understand it. You appear to be saying that the eliminated implicit path layer simply should not be replaced in UDP encapsulations unless evidence comes through to define what information should be exposed. Do I have that approximately correct? If so, can you indicate what kind of evidence you are looking for and how we could gather it in a TOU-based encapsulation? Would it be deploy and see where it doesn't work? regards, Ted > > > Thanks, > Tom > > > Thanks! > > > > Natasha > > > > [1] https://datatracker.ietf.org/meeting/96/agenda.html > > [2] spud@ietf.org > > > > Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | > > nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: > > nrooney@gsm.org > > > > > > This email and its attachments are intended for the above named only and > may > > be confidential. If they have come to you in error you must take no > action > > based on them, nor must you copy or show them to anyone; please reply to > > this email or call +44 207 356 0600 and highlight the error. > > > > > > _______________________________________________ > > 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 > --001a1134ede2f012da05364825a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tom,
On Mon, Jun 27, 2016 at 12:30 PM, Tom Herbert <= tom@herbertland.co= m> wrote:
On Mon, Jun 20, 2016 at 9:58 AM, Natasha Rooney <nrooney@gsma.com> wrote:
>
> If you have any questions for the chairs or AD please feel free to pos= t them
> to the SPUD list.
>
Hi,

I've posted draft-herbert-transports-over-udp-00.txt on the spud list that describes methods to run transport protocols (like TCP) over UDP.
This includes a "shim" UDP layer protocol. Is this the scope of t= he
PLUS BOF for discussion?

=C2=A0
I've read draft-herbert-transports-over= -udp, and my take was that it was an argument that the need for path layer = was not proved.=C2=A0 Two bits in particular stand out for this:
   This solution espouses a model that only the minimal
   necessary information about the packet is made visible to the
   network. This exposed information is sufficient to route the packet
   through the network and to demultiplex and decrypt the packet at the
   receiving end host. In particular, the encapsulated protocol and
   related connection state may be rendered invisible to the network.
   Additionally, this solution allows encapsulation of IPv6 extension
   headers, particularly destination options, which can then also be
   hidden from inspection in the network.
and

   TOU implements a subset of the the SPUD architecture but expre=
ssly does 
   not require or include provisions to leak end-to-end infor=
mation for consumption
   in the network. The encapsulation protocol used in TOU (GUE) is
   extensible to optionally allow information exposure if this proves to
   be warranted.
When a transport protocol's state machine is expr= essed in clear text, it can be interpreted by path elements and it thus cre= ates a sort of implicit path layer.=C2=A0 PLUS is arguing that the use of c= lear text should end, and that the path layer should be made explicit with = the control over what is being said at that layer handed firmly to the end = systems.=C2=A0 They can choose to say nothing, of course, and that would re= sult in something very similar to TOU, at least as I understand it.=C2=A0 <= br>
You appear to be saying that the eliminated implicit path layer simp= ly should not be replaced in UDP encapsulations unless evidence comes throu= gh to define what information should be exposed.=C2=A0

D= o I have that approximately correct?=C2=A0 If so, can you indicate what kin= d of evidence you are looking for and how we could gather it in a TOU-based= encapsulation?=C2=A0 Would it be deploy and see where it doesn't work?=

regards,

Ted




Thanks,
Tom

> Thanks!
>
> Natasha
>
> [1] https://datatracker.ietf.org/meeting/96/= agenda.html
> [2] spud@ietf.org
>
> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA= |
> nrooney@gsma.com | +44 (0) 773= 0 219 765 | @thisNatasha | Skype:
> nrooney@gsm.org
>
>
> This email and its attachments are intended for the above named only a= nd may
> be confidential. If they have come to you in error you must take no ac= tion
> based on them, nor must you copy or show them to anyone; please reply = to
> this email or call +44 207 356 0600 and highlight the error.
>
>
> _______________________________________________
> 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

--001a1134ede2f012da05364825a8-- From nobody Mon Jun 27 14:16: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 1493812D94C for ; Mon, 27 Jun 2016 14:16:25 -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 OrVItPoRn9AA for ; Mon, 27 Jun 2016 14:16:23 -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 D315212D930 for ; Mon, 27 Jun 2016 14:16:19 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5RLEmVM013281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jun 2016 14:14:50 -0700 (PDT) To: spud From: Joe Touch Message-ID: <57719746.6030304@isi.edu> Date: Mon, 27 Jun 2016 14:14:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , nrooney@gsma.com Subject: [Spud] related draft in TSVWG 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, 27 Jun 2016 21:16:25 -0000 Hi, all, The following draft may be of potential utility in SPUD/PLUS: draft-touch-tsvwg-udp-options It describes an extension to UDP to allow for trailing options at the transport layer. NOTE: I'm not sure what space makes the most sense; for on-path info, IMO IP is a more appropriate location than transport, but IF there is info that is useful to exchange at the transport layer in the header, this might be useful for UDP. It will be briefly presented by the chairs in TSVWG. FYI. Joe From nobody Mon Jun 27 14:28:33 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5C712D977 for ; Mon, 27 Jun 2016 14:28:31 -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 nJjM36CNmEy4 for ; Mon, 27 Jun 2016 14:28:29 -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 3008D12D95F for ; Mon, 27 Jun 2016 14:28:29 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id g13so494867ioj.1 for ; Mon, 27 Jun 2016 14:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AuivmAafv/UBEmUIsbLO6FRqPVJC1ER0qguDAeZKqUc=; b=fzMd2UTwLTCxxlQYsE+VnDlP1FwBkWgnWzbbWiuePufEtniGl4JMxqgdqY1lCNX3M5 0RybeDOLK9K4Tnrwp2st3F+O4uHDDzVzvNEgafeXVlJ0TL4nkJ3xTgpS8xT8amAOP80u ALG89Fg1pFhSuIQ+3oEbHvwFpiKI2CEnvxJsonYQYDnD9dhUed2OwJLxC9oWMEVk1zoV +F/Bo98o3VYkF36ywW8gs/knDMJkVhFl5LiBhJ4k+AKvRjpvISFqLzd01jHx5QJZmPv0 oX9sQFRuAw6MJpX2VIAcNNYSS1pb5NAV4quvxP1Unvv7ioF4BZS7Aai7Sfww0O/QO1Ca A1AA== 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=AuivmAafv/UBEmUIsbLO6FRqPVJC1ER0qguDAeZKqUc=; b=guwU7v6broQkJOeSdKvnaY6DfUQ1O7Qb0IsOQqO4wwFdeDlgQyUClsMNGifrD6LW3M 3LznXdsbZjHXGz0THhc5ABxRw5tC902/OKvbLcTGnIeNpNW4z/ezeD925gacr9B5f8Gm 7B2Kcu6Ehg1tlXtrO7Epaj5mS4LiFlbEi/+21URVhITSHEpbKbelI42hMz0y/s5g+MS+ s6blbllQi31VZ+r3Z4NFpXVH8Am4lydDBsevVuy0uWMJ3uYq3gzQT9j+s6sYYiEg0xdv SN3qGKyzDjjUFRaqN3AhN70bwm/qh4bR54ylo2xvhdAaCcesdppt4H0hd8CAXQ6Iq4aS SR2g== X-Gm-Message-State: ALyK8tITiYqvc+xqVKxvj0uU/a+Q3uG3TvTuSNPnizpy+LtZroTFd5jYYUUjc5FdCETVccfElo5ifHHf/2UBqA== X-Received: by 10.107.11.26 with SMTP id v26mr3060821ioi.107.1467062908214; Mon, 27 Jun 2016 14:28:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Mon, 27 Jun 2016 14:28:27 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Mon, 27 Jun 2016 14:28:27 -0700 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Natasha Rooney , spud Subject: Re: [Spud] Details about PLUS BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 21:28:32 -0000 On Mon, Jun 27, 2016 at 1:12 PM, Ted Hardie wrote: > Hi Tom, > On Mon, Jun 27, 2016 at 12:30 PM, Tom Herbert wrote: >> >> On Mon, Jun 20, 2016 at 9:58 AM, Natasha Rooney wrote: >> > >> > If you have any questions for the chairs or AD please feel free to post >> > them >> > to the SPUD list. >> > >> Hi, >> >> I've posted draft-herbert-transports-over-udp-00.txt on the spud list >> that describes methods to run transport protocols (like TCP) over UDP. >> This includes a "shim" UDP layer protocol. Is this the scope of the >> PLUS BOF for discussion? >> > > I've read draft-herbert-transports-over-udp, and my take was that it was an > argument that the need for path layer was not proved. Two bits in > particular stand out for this: > > This solution espouses a model that only the minimal > necessary information about the packet is made visible to the > network. This exposed information is sufficient to route the packet > through the network and to demultiplex and decrypt the packet at the > receiving end host. In particular, the encapsulated protocol and > related connection state may be rendered invisible to the network. > Additionally, this solution allows encapsulation of IPv6 extension > headers, particularly destination options, which can then also be > hidden from inspection in the network. > > and > > TOU implements a subset of the the SPUD architecture but expressly does > not require or include provisions to leak end-to-end information for > consumption > in the network. The encapsulation protocol used in TOU (GUE) is > extensible to optionally allow information exposure if this proves to > be warranted. > > When a transport protocol's state machine is expressed in clear text, it can > be interpreted by path elements and it thus creates a sort of implicit path > layer. PLUS is arguing that the use of clear text should end, and that the > path layer should be made explicit with the control over what is being said > at that layer handed firmly to the end systems. They can choose to say > nothing, of course, and that would result in something very similar to TOU, > at least as I understand it. > > You appear to be saying that the eliminated implicit path layer simply > should not be replaced in UDP encapsulations unless evidence comes through > to define what information should be exposed. > Right. Consider that we want to deploy encrypted UDP-based transports in the near term and that no middlebox supports anything resembling PLUS. In the simplest model, either a network path forwards UDP packets without impediment or it doesn't. If it doesn't we will fallback to TCP and probably alert the user of that at some point. If PLUS does come on-line then it's worth using only if it provides some tangible benefit to our traffic or it "fixes" whatever networks are still blocking UDP. > Do I have that approximately correct? If so, can you indicate what kind of > evidence you are looking for and how we could gather it in a TOU-based > encapsulation? Would it be deploy and see where it doesn't work? > Deployability of TOU should be directly correlated to deployability of UDP. I think there's already good evidence in https://www.ietf.org/proceedings/95/slides/slides-95-maprg-3.pdf and some of the QUIC numbers. What is not reflected in those are some important use cases where the network provides valuable optimizations based specifically on TCP (maybe optimizations for 2G, 3G like in RFC3481). It might be interesting to see if ancillary data could be added to a packet get such optimizations for non-TCP or UDP-based transports, but again it doesn't seem like we can wait for such things to be defined in a standard and fully deployed before we start using encrypted UDP-based transports. Tom > regards, > > Ted > >> >> >> >> Thanks, >> Tom >> >> > Thanks! >> > >> > Natasha >> > >> > [1] https://datatracker.ietf.org/meeting/96/agenda.html >> > [2] spud@ietf.org >> > >> > Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | >> > nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: >> > nrooney@gsm.org >> > >> > >> > This email and its attachments are intended for the above named only and >> > may >> > be confidential. If they have come to you in error you must take no >> > action >> > based on them, nor must you copy or show them to anyone; please reply to >> > this email or call +44 207 356 0600 and highlight the error. >> > >> > >> > _______________________________________________ >> > 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 Mon Jun 27 15:53: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 B9FC112D124 for ; Mon, 27 Jun 2016 15:53:17 -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 QaFSVgAUg0Jy for ; Mon, 27 Jun 2016 15:53:15 -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 A561212DA42 for ; Mon, 27 Jun 2016 15:53:15 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id t74so2062667ioi.0 for ; Mon, 27 Jun 2016 15:53: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:from:date:message-id:subject:to :cc; bh=6QcQ22KTn8vInUUiM0anvGG2cSOzvy8+DkEEPkFXlFc=; b=oqZz3nrYIcry3IH53uno2qExV8zdc0jO+LA7J7DMhqF6tnnQi6+T9gsLvoZjba69YX 7f4mEoLY0j9JtmsOh8GYWOg3h6Qauq/94+t6u/yHveZvKmeBKw0ZJ7WMtvuj/vJsWD5B IRHxufqVnzXOBlPtzU2IDoSkEpbMQzR625WDKWWygw0W8bFUwJE/eEy072y9jiWj0kGu slN5n8g9DzyB03NeUfBA2s/ciDyIy8pGgKd5WyO+EbI95ttdyysCjMG4rjHqmGJFSd+A YILlT5SBqK3hNXFnuYYB4Bzy5+sa1t+lC0S5FzOVALFFTkoELzFjX39cIcEhVuFo+YIQ mRxA== 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=6QcQ22KTn8vInUUiM0anvGG2cSOzvy8+DkEEPkFXlFc=; b=StjRIsRfytznARTDDtsfg4DrA0O2V8XUQNQFMim82Y5dvf4CiXlinqCFGlFzHqoI88 FOCbYES0KT5H9XbLJIhTW3EIpmRE4yoAK15SdlQOgg0+WAZ3O+KsnI1+/lwyqQHQUTdF KHeTUfmRox8Jno7Lia6Z8lxJv6q6vrZeq893dcTtUMI3ykfQUg5BFc1iWOvjJ5EdeZM1 dhXcllZTWvgSA8h1YzOSxKqubTwnXutg5ivDtjWFUkpTQl/M9Oda66lxGvIu3krbLnCr 5ShSfFfybJzq3piurSTJRQgHzMBDWOXU0iO2Qx4RN/7vSM6TYxS7jG1mJxE1U/u5GBDA imZg== X-Gm-Message-State: ALyK8tLIiR7euCcMuem+yjnpFtgdiAcsaiPNaUn6VPpyTiz959Nwr4mIwHRCNUHWEtxMRqbriZyL7T98iJrCjg== X-Received: by 10.107.162.12 with SMTP id l12mr271419ioe.84.1467067994923; Mon, 27 Jun 2016 15:53:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Mon, 27 Jun 2016 15:53:14 -0700 (PDT) In-Reply-To: <57719746.6030304@isi.edu> References: <57719746.6030304@isi.edu> From: Tom Herbert Date: Mon, 27 Jun 2016 15:53:14 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Aaron Falk , Natasha Rooney , spud Subject: Re: [Spud] related draft in TSVWG 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, 27 Jun 2016 22:53:18 -0000 On Mon, Jun 27, 2016 at 2:14 PM, Joe Touch wrote: > Hi, all, > > The following draft may be of potential utility in SPUD/PLUS: > > draft-touch-tsvwg-udp-options > > It describes an extension to UDP to allow for trailing options at the > transport layer. > Hi Joe, >From the draft: "This length field is typically redundant with IP datagram length and header length information as follows: UDPlen = IPlen - IPhdrlen - 8 As a result of this redundancy, the UDP length field can be used in other ways." "typically" is a key word here; this is not a requirement of UDP. As long as the UDP length is less than or equal to IP payload length it would be a valid UDP packet. The draft exploits this characteristic, however that does not preclude that packets with smaller UDP length than IP payload length already exist (maybe even using the same trick to extend UDP!). Seems like that leads to a potential ambiguity? Tom > NOTE: I'm not sure what space makes the most sense; for on-path info, > IMO IP is a more appropriate location than transport, but IF there is > info that is useful to exchange at the transport layer in the header, > this might be useful for UDP. > > It will be briefly presented by the chairs in TSVWG. > > FYI. > > Joe > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon Jun 27 16:13: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 17BEF12DA6F for ; Mon, 27 Jun 2016 16:13:21 -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 QlbfMB_imLtq for ; Mon, 27 Jun 2016 16:13:19 -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 36D6312DA63 for ; Mon, 27 Jun 2016 16:13:19 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5RNChs1011732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jun 2016 16:12:44 -0700 (PDT) To: Tom Herbert References: <57719746.6030304@isi.edu> From: Joe Touch Message-ID: <5771B2E9.6030304@isi.edu> Date: Mon, 27 Jun 2016 16:12: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: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , Natasha Rooney , spud Subject: Re: [Spud] related draft in TSVWG 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, 27 Jun 2016 23:13:21 -0000 On 6/27/2016 3:53 PM, Tom Herbert wrote: > On Mon, Jun 27, 2016 at 2:14 PM, Joe Touch wrote: >> Hi, all, >> >> The following draft may be of potential utility in SPUD/PLUS: >> >> draft-touch-tsvwg-udp-options >> >> It describes an extension to UDP to allow for trailing options at the >> transport layer. >> > Hi Joe, > > >From the draft: > > "This length field is typically redundant with IP datagram length and > header length information as follows: > > UDPlen = IPlen - IPhdrlen - 8 > > As a result of this redundancy, the UDP length field can be used in other ways." > > "typically" is a key word here; this is not a requirement of UDP. As > long as the UDP length is less than or equal to IP payload length it > would be a valid UDP packet. The draft exploits this characteristic, > however that does not preclude that packets with smaller UDP length > than IP payload length already exist (maybe even using the same trick > to extend UDP!). Seems like that leads to a potential ambiguity? First, yes, if this were a strict requirement, than UDP implementations would discard UDP segments that were smaller than the IP payload -- in practice, they don't. The good news is that there are no known specs (at least none I've heard of yet or know of otherwise) that use this trick except: a) UDP-lite, which uses a different transport protocol number and has different semantics in UDP-lite, the entire IP payload is treated as the UDP payload, which isn't compatible with RFC768 i.e., it basically delivers both what UDP considers the payload AND the extended area to the app layer b) there's a defensive patent that talks about this, which we already know about but AFAIK never got beyond the though level (it's the typical patent with permissions compatible with IETF standards, again AFAIK) This does appear to be the first system that will spec this out. We do include the new OCS (option checksum), which might help avoid accidental ambiguous use (I.e., UDP OCS ought to help avoid processing these other uses as UDP checksum). We can add text to address this issue, though we would appreciate also knowing if anyone is aware of existing uses other than the two above. Joe > > Tom > >> NOTE: I'm not sure what space makes the most sense; for on-path info, >> IMO IP is a more appropriate location than transport, but IF there is >> info that is useful to exchange at the transport layer in the header, >> this might be useful for UDP. >> >> It will be briefly presented by the chairs in TSVWG. >> >> FYI. >> >> Joe >> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud From nobody Mon Jun 27 16:34: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 A71B412DA0D for ; Mon, 27 Jun 2016 16:34:51 -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 iOFmqS77Hv1z for ; Mon, 27 Jun 2016 16:34:50 -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 D6E0012D92B for ; Mon, 27 Jun 2016 16:34:49 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id g13so2644838ioj.1 for ; Mon, 27 Jun 2016 16:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/pXFWhEIBmUmij7VukjAjN2ff+fcXynodXuiAmaMOSU=; b=lfJlfKH0ZAFIH/qX12BadAGR1qded0gKZ/qOJzWaVZX20jyNg4gyp3OymjdNy0+p3o W6LGtRAXZsGkIbV3SChvo1/F8hePlEh7EXdVmx/KkgZ0wUtjZUJvewzHeB7aeWyYUFU5 2Q3FRqkC8umcz/pb93sb2ICyHv5r/+aOO6T/c4bVlIn5eKe3R6CgeE2oIRPMvYx+CKCU cQIJLxbLmOCZqgzWwe6DljL97dw+f1o+QpkhrUTBCT5M7tEnXTJk/3AvCxr/gNS9cThj +9VUgiQXJenvKjdilIGL+Bt74H+UviOl2A+0G8ttth+fh3aOXFVDukIThGSi79srhBqq NMyA== 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=/pXFWhEIBmUmij7VukjAjN2ff+fcXynodXuiAmaMOSU=; b=Yf5n737A3sguNhAwjdH0D7ZNmlvll5OSLZPJaVR8SukyNP6huMIH2hSPSX9N/gnwCq 5MzZ1rF4L4x5F+J4LY79vnVT34fbfJNt7DLiZ8YX6PmfeZ7/9YEXtLN8QiPIVVWYF2s0 nknZAvukJq7tVVPiLDj4F+dUsPv7EaBDXqibfOgRK6j5VWxWBV5Q4ZWQhgzwIgMG5ZPV kYsqTuOzA87/tTS9aY7prje30XXD8GJRDlT7ax1veRGLKcXALxZD2WCPoWtJaZTR5xjp /PI6Y+BzcSFW3xplBYJyXB9KS+H/zGVvoi2JfULopfgboYCv4BqHKSVVRAuwJVNiS6X5 YG9A== X-Gm-Message-State: ALyK8tLjmVpZ71MDXSaoUJdDaUbaCHUduOazSw+BuPHWrftwdAZ0uSMRHgvs9CNs3oE4IugDGcZIGpBp2KVU/A== X-Received: by 10.107.162.12 with SMTP id l12mr423938ioe.84.1467070489138; Mon, 27 Jun 2016 16:34:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Mon, 27 Jun 2016 16:34:48 -0700 (PDT) In-Reply-To: <5771B2E9.6030304@isi.edu> References: <57719746.6030304@isi.edu> <5771B2E9.6030304@isi.edu> From: Tom Herbert Date: Mon, 27 Jun 2016 16:34:48 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Aaron Falk , Natasha Rooney , spud Subject: Re: [Spud] related draft in TSVWG 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, 27 Jun 2016 23:34:52 -0000 > First, yes, if this were a strict requirement, than UDP implementations > would discard UDP segments that were smaller than the IP payload -- in > practice, they don't. > I would not be at all surprised if there are middle boxes that either drop such packets or truncate them to UDP length in the name of security. > The good news is that there are no known specs (at least none I've heard > of yet or know of otherwise) that use this trick except: > > a) UDP-lite, which uses a different transport protocol number and has > different semantics > in UDP-lite, the entire IP payload is treated as the UDP payload, > which isn't compatible with RFC768 > > i.e., it basically delivers both what UDP considers the payload AND > the extended area to the app layer > > b) there's a defensive patent that talks about this, which we already > know about but AFAIK never got beyond the though level > > (it's the typical patent with permissions compatible with IETF > standards, again AFAIK) > > This does appear to be the first system that will spec this out. We do > include the new OCS (option checksum), which might help avoid accidental > ambiguous use (I.e., UDP OCS ought to help avoid processing these other > uses as UDP checksum). > You might want to look at magic numbers for this purpose also. Unfortunately, similar to the idea of putting bits in UDP payload for interpretation in the network, protocol correctness in this method is only probabilistic. That is the best we could achieve is 99.999..% correctness, not 100%. > We can add text to address this issue, though we would appreciate also > knowing if anyone is aware of existing uses other than the two above. > Probably should also expressly forbid the network to modify options in flight, that is where things get really scary in the above ambiguous identification problem. Tom > Joe > >> >> Tom >> >>> NOTE: I'm not sure what space makes the most sense; for on-path info, >>> IMO IP is a more appropriate location than transport, but IF there is >>> info that is useful to exchange at the transport layer in the header, >>> this might be useful for UDP. >>> >>> It will be briefly presented by the chairs in TSVWG. >>> >>> FYI. >>> >>> Joe >>> >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud > From nobody Mon Jun 27 16:41: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 E461312DA89 for ; Mon, 27 Jun 2016 16:41:01 -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 og00oLpMqFe4 for ; Mon, 27 Jun 2016 16:41:00 -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 229D312D9EB for ; Mon, 27 Jun 2016 16:41:00 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5RNdjxp017864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jun 2016 16:39:46 -0700 (PDT) To: Tom Herbert References: <57719746.6030304@isi.edu> <5771B2E9.6030304@isi.edu> From: Joe Touch Message-ID: <5771B940.50003@isi.edu> Date: Mon, 27 Jun 2016 16:39:44 -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-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , Natasha Rooney , spud Subject: Re: [Spud] related draft in TSVWG 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, 27 Jun 2016 23:41:02 -0000 On 6/27/2016 4:34 PM, Tom Herbert wrote: >> First, yes, if this were a strict requirement, than UDP implementations >> would discard UDP segments that were smaller than the IP payload -- in >> practice, they don't. >> > I would not be at all surprised if there are middle boxes that either > drop such packets or truncate them to UDP length in the name of > security. We haven't done exhaustive tests, but so far we've seen good behavior. >> The good news is that there are no known specs (at least none I've heard >> of yet or know of otherwise) that use this trick except: >> >> a) UDP-lite, which uses a different transport protocol number and has >> different semantics >> in UDP-lite, the entire IP payload is treated as the UDP payload, >> which isn't compatible with RFC768 >> >> i.e., it basically delivers both what UDP considers the payload AND >> the extended area to the app layer >> >> b) there's a defensive patent that talks about this, which we already >> know about but AFAIK never got beyond the though level >> >> (it's the typical patent with permissions compatible with IETF >> standards, again AFAIK) >> >> This does appear to be the first system that will spec this out. We do >> include the new OCS (option checksum), which might help avoid accidental >> ambiguous use (I.e., UDP OCS ought to help avoid processing these other >> uses as UDP checksum). >> > You might want to look at magic numbers for this purpose also. A checksum is just a dynamic, context-sensitive magic number. There's a lot lower chance of a checksum being correct in a random sequence than a magic number. > Unfortunately, similar to the idea of putting bits in UDP payload for > interpretation in the network, protocol correctness in this method is > only probabilistic. That is the best we could achieve is 99.999..% > correctness, not 100%. That's true for everything. Anyone could have deployed an unassigned TCP option number in an unknown way too. > >> We can add text to address this issue, though we would appreciate also >> knowing if anyone is aware of existing uses other than the two above. >> > Probably should also expressly forbid the network to modify options in > flight, that is where things get really scary in the above ambiguous > identification problem. Oh, yes. FYI, the OCS is just over the option space, not over the UDP payload, UDP header, or IP pseudoheader. Joe From nobody Mon Jun 27 16:53: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 C2D2F12DAA3 for ; Mon, 27 Jun 2016 16:53:37 -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 Z4APUwig0Ea9 for ; Mon, 27 Jun 2016 16:53:36 -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 4DAA612DAA7 for ; Mon, 27 Jun 2016 16:53:36 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id f30so2857113ioj.2 for ; Mon, 27 Jun 2016 16:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k2M8VsCemH5fVPbtuo4LRTOcP1/ftti4y0oL1O6EgoA=; b=ZM9hLgJYrFx0rjXozzdzFnyCeaDWFnvSfmgunPWaSW6fRn5lbfnX9aWfsmqJ5RUOcR xbZXXe2gydLcd2C3qtyR6nNttTS9luP7TLpOvWAgb6Oqo2vjJUQgdfqN+bDM1icXl0A6 5kbyb8mCkOH0L9kQ7uY3JBDuk3Sok6NMeedoUAW35xjhQUn0mle5XwNxdlFWuN118Gs5 GYbLenrVbbaHUU/p00wMk1YybP3W1Vs+95uf0OdHBkN+WLdYQl2tTY4vSAo/qUTr3ciP GCdcwh+e12Cy4x9ffaPVFoyMZP+FRXhQNB4OP0Wa7pRyAJMf1kiM0eH2LmBLsdN+uSa8 vICg== 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=k2M8VsCemH5fVPbtuo4LRTOcP1/ftti4y0oL1O6EgoA=; b=IQFNZzx7Ajx2afetv17ZEspXGLp1F3R9aTr1Vu1sudt+nEruRQh689BM8BXl2fQohq QLs55jxUEk8C/JeRQbOg13m8BRRTGoBsoezuJRZ9DFR+gYDNg6Vb829ApCKLOlKWBpfx j7PMfaTpcB0FjiMlsqGdzIRmBAyT0ruonJDQ8/SxGjcA60mfS8cIxTNPk1qTb/bwITNt 30yirfbLY6UqkZYoXMust1FraZYNbxe8bYwsatq8Fu8uRKJ5T2Y/biuFDNxIegFsl3Pp E51VSE0jwhgJQ8mhmIXeMKHI7vERM1V8dlGli4HDzCmZl+1OJlYAf9htnIAeoKdrTXYY KnOQ== X-Gm-Message-State: ALyK8tKY/47mWkc/yUVdd3Yq7rcPES3YtbC7zzXYgf9cvbD7K0Xj0lzg5ru8njA5+WpSokwB3aFBR/wBGj4/nw== X-Received: by 10.107.162.12 with SMTP id l12mr488008ioe.84.1467071615495; Mon, 27 Jun 2016 16:53:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Mon, 27 Jun 2016 16:53:34 -0700 (PDT) In-Reply-To: <5771B940.50003@isi.edu> References: <57719746.6030304@isi.edu> <5771B2E9.6030304@isi.edu> <5771B940.50003@isi.edu> From: Tom Herbert Date: Mon, 27 Jun 2016 16:53:34 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Aaron Falk , Natasha Rooney , spud Subject: Re: [Spud] related draft in TSVWG 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, 27 Jun 2016 23:53:38 -0000 >> Unfortunately, similar to the idea of putting bits in UDP payload for >> interpretation in the network, protocol correctness in this method is >> only probabilistic. That is the best we could achieve is 99.999..% >> correctness, not 100%. > That's true for everything. Anyone could have deployed an unassigned TCP > option number in an unknown way too. Using an unassigned option number is non-standard, and if a non-standard use of protocol conflicts with the standard use then the non-standard case is in error. But, if a protocol allows for two alternate interpretations of the same data both of which claim to conform to the standard, then the protocol itself is incorrect. I'm sure there's a good analogy somewhere here involving a man wearing two watches ;-) Tom > >> >>> We can add text to address this issue, though we would appreciate also >>> knowing if anyone is aware of existing uses other than the two above. >>> >> Probably should also expressly forbid the network to modify options in >> flight, that is where things get really scary in the above ambiguous >> identification problem. > Oh, yes. FYI, the OCS is just over the option space, not over the UDP > payload, UDP header, or IP pseudoheader. > > Joe From nobody Mon Jun 27 17:12: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 978A712D8C1 for ; Mon, 27 Jun 2016 17:12: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 HR7xuPRrQgSq for ; Mon, 27 Jun 2016 17:12: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 59A0612D770 for ; Mon, 27 Jun 2016 17:12:49 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u5S0BdQe001754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jun 2016 17:11:40 -0700 (PDT) To: Tom Herbert References: <57719746.6030304@isi.edu> <5771B2E9.6030304@isi.edu> <5771B940.50003@isi.edu> From: Joe Touch Message-ID: <5771C0B9.4060100@isi.edu> Date: Mon, 27 Jun 2016 17:11:37 -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: u5S0BdQe001754 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , Natasha Rooney , spud Subject: Re: [Spud] related draft in TSVWG 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, 28 Jun 2016 00:12:50 -0000 On 6/27/2016 4:53 PM, Tom Herbert wrote: >>> Unfortunately, similar to the idea of putting bits in UDP payload for >>> interpretation in the network, protocol correctness in this method is >>> only probabilistic. That is the best we could achieve is 99.999..% >>> correctness, not 100%. >> That's true for everything. Anyone could have deployed an unassigned TCP >> option number in an unknown way too. > Using an unassigned option number is non-standard, and if a > non-standard use of protocol conflicts with the standard use then the > non-standard case is in error. But, if a protocol allows for two > alternate interpretations of the same data both of which claim to > conform to the standard, then the protocol itself is incorrect. I'm > sure there's a good analogy somewhere here involving a man wearing two > watches ;-) Sure - that's in some respects why this ID is intended to resolve that ambiguity. Note that it's also strictly OK per RFC768 to send an packet whose UDP payload indicates a length *longer* than the IP payload indicates too. This should also be resolved in an update to RFC1122, eventually. Joe From nobody Tue Jun 28 03:42: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 1CFA612DDD2 for ; Tue, 28 Jun 2016 03:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuvQNYJx_IJB for ; Tue, 28 Jun 2016 03:42:21 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C5212DDEF for ; Tue, 28 Jun 2016 03:42:03 -0700 (PDT) Received: from [85.158.136.83] by server-7.bemta-5.messagelabs.com id 66/A7-10476-97452775; Tue, 28 Jun 2016 10:42:01 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRWlGSWpSXmKPExsVy+MWXdt3KkKJ wgzkiFhtb3rFZLLrwlNGByWPJkp9MHk/2z2QJYIpizcxLyq9IYM34v9ql4A97xbbOj8wNjBfY uhi5OIQE9jJKHF3dwwLhrGSUOPBhBpSznEmif8YDVgjnCKNE440VUD2bGSWWTN8ClOHkYBNwl Ti66w57FyMHh4iAlUTTck2QMLOAssSMhbsYQcLCAgoSx/cUgoRFBFQl+nsnsEPYehIzn29hBr FZgOIHrjxiA7F5BUIl2ua9ArMZBWQlvjSuZoYYKS5x68l8JhBbQkBAYsme88wQtqjEy8f/WCF qdCQW7P7EBmFrSyxb+JoZYqagxMmZT1gmMIrMQjJqFpKWWUhaZiFpWcDIsopRozi1qCy1SNfQ QC+pKDM9oyQ3MTMHyDPVy00tLk5MT81JTCrWS87P3cQIjBUGINjBuGaq8yFGSQ4mJVHeBQxF4 UJ8SfkplRmJxRnxRaU5qcWHGGU4OJQkeP2DgXKCRanpqRVpmTnAqIVJS3DwKInwKoGkeYsLEn OLM9MhUqcYFaXEeTNBEgIgiYzSPLg2WKK4xCgrJczLCHSIEE9BalFuZgmq/CtGcQ5GJWFefpA pPJl5JXDTXwEtZgJazFqdD7K4JBEhJdXAGP7IWWvK+8kTLxXMyPOZ+bBSedcLroDtt5WeTtvG rdcdFK51ht2zLGXFPFuBlFdBZbsehHZP/XXL/cahOs6jUnWPMjav6WL6Y7Zne1Uk19QrU5d41 Dptfff7X2XCV4a24CPPp5339lko+G7RmZwdS6+ob6x03zvR51f04VdG91aY/BK0MCgwL1FiKc 5INNRiLipOBAAtqaMHDwMAAA== X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-16.tower-36.messagelabs.com!1467110520!42107333!1 X-Originating-IP: [195.232.244.135] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18329 invoked from network); 28 Jun 2016 10:42:00 -0000 Received: from mailout03.vodafone.com (HELO mailout03.vodafone.com) (195.232.244.135) by server-16.tower-36.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 28 Jun 2016 10:42:00 -0000 Received: from mailint02.vodafone.com (mailint02.vodafone.com [195.232.244.199]) by mailout03.vodafone.com (Postfix) with ESMTP id 3rf2Rr4XWpz17HLk; Tue, 28 Jun 2016 12:42:00 +0200 (CEST) Received: from mailint02.vodafone.com (localhost [127.0.0.1]) by mailint02.vodafone.com (Postfix) with ESMTP id 3rf2Rr3GrfzQyfr; Tue, 28 Jun 2016 12:42:00 +0200 (CEST) Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint02.vodafone.com (Postfix) with ESMTPS id 3rf2Rr2x09zQyfj; Tue, 28 Jun 2016 12:42:00 +0200 (CEST) Received: from AVOEXH03W.internal.vodafone.com (145.230.15.141) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 28 Jun 2016 12:41:58 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.75]) by AVOEXH03W.internal.vodafone.com ([145.230.15.141]) with mapi id 14.03.0224.002; Tue, 28 Jun 2016 12:41:53 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: "Brian Trammell (ietf@trammell.ch)" Thread-Topic: [Spud] endpoint control Thread-Index: AdHRKB6Rk1yBi0AtT2GnUMPMbLGi+g== Date: Tue, 28 Jun 2016 10:41:52 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 10:42:25 -0000 Hi Brian, I think Mobile Throughput Guidance would be a good candidate for PLUS path-= to-endpoint signalling. The latest (albeit expired) MTG draft [1] is bound = to TCP Options, and was considering use of TCP-AO for authentication; PLUS = could allow MTG for both TCP and UDP-based flows. However it seems that pro= posed PLUS mechanism: >(1) For forward signaling, the sending endpoint must place "scratch space"= in the packet with a label on it stating that it's okay to modify; this ok= ay-to-modify state is enforced by a MAC which only verifies the length but = not the content of the scratch space. ...may not provide the guarantee that (1) the MTG information was indeed in= jected by the cellular network and (2) that it has not been modified by ano= ther node. Have I got that right? Or would such an authentication/integrity= check applicable to path data be in scope of PLUS? Cheers, Kevin Vodafone R&D [1] https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance= -03.txt , expired From nobody Tue Jun 28 03:59: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 9089612D0DB for ; Tue, 28 Jun 2016 03:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTNyLOn04h40 for ; Tue, 28 Jun 2016 03:59: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 AE90C12DC8E for ; Tue, 28 Jun 2016 03:59:43 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id C4BADEB7C98B5; Tue, 28 Jun 2016 10:59:39 +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 u5SAxeOB009905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jun 2016 10:59:41 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5SAxJFR015252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jun 2016 12:59:39 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 28 Jun 2016 12:59:33 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "Smith, Kevin, (R&D) Vodafone Group" , "Brian Trammell (ietf@trammell.ch)" Thread-Topic: [Spud] endpoint control Thread-Index: AdHRKB6Rk1yBi0AtT2GnUMPMbLGi+v//90kA Date: Tue, 28 Jun 2016 10:59:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <236B7823AD8FCC49A93ED588383335E0@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 10:59:50 -0000 Hi Kevin, On 28/06/2016 11:41, "Spud on behalf of Smith, Kevin, (R&D) Vodafone Group" wrote: >>(1) For forward signaling, the sending endpoint must place "scratch >>space" in the packet with a label on it stating that it's okay to >>modify; this okay-to-modify state is enforced by a MAC which only >>verifies the length but not the content of the scratch space. > >...may not provide the guarantee that (1) the MTG information was indeed >injected by the cellular network and (2) that it has not been modified by >another node. Have I got that right? Yes, you are right. See also section 5.2 of [1]. Cheers, t [1] https://www.iab.org/wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_4.pdf From nobody Tue Jun 28 05:21:13 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4A412D13A for ; Tue, 28 Jun 2016 05:21:11 -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 8ErFTMdJK1WH for ; Tue, 28 Jun 2016 05:21:08 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 487EE12D133 for ; Tue, 28 Jun 2016 05:21:08 -0700 (PDT) Received: from public-docking-cx-2148.ethz.ch (public-docking-pat-cx-mapped-0020.ethz.ch [195.176.111.21]) by trammell.ch (Postfix) with ESMTPSA id 7A20B1A061D; Tue, 28 Jun 2016 14:20:36 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_952BA5A5-78C4-4F48-A4A6-8B666E1C34B6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Tue, 28 Jun 2016 14:20:35 +0200 Message-Id: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch> References: To: "Smith, Kevin, (R&D) Vodafone Group" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 12:21:11 -0000 --Apple-Mail=_952BA5A5-78C4-4F48-A4A6-8B666E1C34B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 28 Jun 2016, at 12:41, Smith, Kevin, (R&D) Vodafone Group = wrote: >=20 > Hi Brian, >=20 > I think Mobile Throughput Guidance would be a good candidate for PLUS = path-to-endpoint signalling. The latest (albeit expired) MTG draft [1] = is bound to TCP Options, and was considering use of TCP-AO for = authentication; PLUS could allow MTG for both TCP and UDP-based flows. = However it seems that proposed PLUS mechanism: >=20 >> (1) For forward signaling, the sending endpoint must place "scratch = space" in the packet with a label on it stating that it's okay to = modify; this okay-to-modify state is enforced by a MAC which only = verifies the length but not the content of the scratch space. >=20 > ...may not provide the guarantee that (1) the MTG information was = indeed injected by the cellular network and (2) that it has not been = modified by another node. Have I got that right? Correct. It doesn't provide that guarantee at all, by design. > Or would such an authentication/integrity check applicable to path = data be in scope of PLUS? As I see it now, not at first. The cases where the endpoint reliably has = an way to authenticate a middlebox are limited (though mobile access = networks are one such case), and IMO the mechanism should be as general = as possible. I will point out that integrity and authentication of information from a = middlebox where the sending endpoint can authenticate the middlebox can = trivially be implemented on top of this proposed mechanism: the = definition of the exposed information could be "content plus MAC", where = the MAC can be verified using the middlebox's certificate. But these can = be implemented in information elements atop PLUS, without requiring = additional support in the PLUS header. In a mobile access network, on the upstream path this would look like: user terminal --[ PLUS mobile-foo: 00000000 ]--> access network --[ PLUS = mobile-foo CCCCCCMM ]--> server (where mobile-foo is whatever you want the access network to be able to = say, 00000000 is scratch space, C is content and M is MAC.) The server can act on the throughput guidance (should it choose to, see = spud-req 5.9), but since it's the user terminal that has a relationship = with the access network, the server may need to feed the content and MAC = back to the user terminal (see spud-req 5.5 and 6.4) for verification. Cheers, Brian > Cheers, > Kevin > Vodafone R&D >=20 > [1] = https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance-03= .txt , expired >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_952BA5A5-78C4-4F48-A4A6-8B666E1C34B6 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 iQIcBAEBCgAGBQJXcmuUAAoJEIoSt78L6kajy0EQAJotWybvOp5DuT0Fa0HwTxZq bsz4csJ/VVD08gRFxHOdifGGQctXtdv2YH2DMoiWbsISmfBdMDFn4PJcEboy52VY HvKzVbx+YdYnx8xzS6m/QGGyyUrUzmGd/DDbdzDSHlqlA2HUz6FqxP/bs87lnjVb yAgubEBTA7kHYRJe1+GHNEBwMgQS+CBYUbOvXBN4pTYtUJGcWJ1Q19YFb9T9P8u7 3XLJRn3nRGHO/MEwB7bbI/VWA9hkd6jSzOEkeC+SH2vYkD771Llz4qh8xPmEFwFy jmQ2qkAAfHMdpdj+XztyMXRYXouNsMg8Gi6lvwNqBuqz0Vkjf32dyoMQ8GU61S2u BdFvQ1bENCYrTY0Lunot2rD6BEQLk9GspiiCVin+9DALBnZqJx9gCYpEL62fvcmB cbMIybUM2J1cCN8iVUc6lclLbzHz2o4M9PrcelEVKqBEKRbbgkXv5RqpawBrn7fK 0BMJK/i/BGEp04rzuoVrCgFwu2NTfVY5fRytm4t0fYdPEjg+OeHA7eqw5vdEZBvC RpTvPXygJhnamBz9M1okTNhCGSglFSRrmKD7A4ueoJBj7JOFR4HlcAR4gM82caaI oIbZ2bNlo1uNPShQI2ZChseucOE6SQ53pLL/4p7s9Sya+BhuIL8WIYmYUA2UMOw3 y2voKtbLJHr+QzNsC4ZJ =CP6p -----END PGP SIGNATURE----- --Apple-Mail=_952BA5A5-78C4-4F48-A4A6-8B666E1C34B6-- From nobody Tue Jun 28 09:19: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 4681912D0D3 for ; Tue, 28 Jun 2016 09:19:19 -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 0rfshMdw2Mkn for ; Tue, 28 Jun 2016 09:19:17 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2137612B055 for ; Tue, 28 Jun 2016 09:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4425; q=dns/txt; s=iport; t=1467130757; x=1468340357; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=sVsCjDo/hsRC9mpo3hpJVf4FPDwxs/mVH5VJh4toKLg=; b=L64Cn90iR6Tts7YADyF4UCleXjFQPe6EHRtPIFOYh1gsyxQGNbqRxTSk mQXhOI89HZCoau8KzIitynXQvQ1nHmZ+L5PE64MhElFf6T7ZKVVK8jvdQ zbiX+9/iAL5rG3Zp/R9BdEDHBXr6MLdL2HvE/iLXwiIHg/nHbfqos5T+x I=; X-Files: signature.asc : 842 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgAjonJX/4ENJK1bgz5Wfbo0gXsXD?= =?us-ascii?q?YV0AoEwOBQBAQEBAQEBZSeETAEBAQMBAQEBJEcEBwULCw4KLicwBhOIKAgOw2Y?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEOCQWGKIF3CIJOhBwOg0KCLwWIDoZhPolVg?= =?us-ascii?q?y6LDIlIhVyPfx42hBAcModsgUQBAQE?= X-IronPort-AV: E=Sophos;i="5.26,541,1459814400"; d="asc'?scan'208";a="291124433" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2016 16:19:16 +0000 Received: from [10.24.3.11] ([10.24.3.11]) (authenticated bits=0) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5SGJEMi016516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jun 2016 16:19:15 GMT Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_20D5D384-BA3F-4ABC-9FB5-13A2895C30CC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch> Date: Tue, 28 Jun 2016 09:19:10 -0700 Message-Id: <6B3B89C7-234E-4412-BD83-056A3C69483B@cisco.com> References: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.3124) X-Authenticated-User: dwing Archived-At: Cc: "Smith, Kevin, \(R&D\) Vodafone Group" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 16:19:19 -0000 --Apple-Mail=_20D5D384-BA3F-4ABC-9FB5-13A2895C30CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28-Jun-2016 05:20 am, Brian Trammell wrote: >=20 >> On 28 Jun 2016, at 12:41, Smith, Kevin, (R&D) Vodafone Group = wrote: >>=20 >> Hi Brian, >>=20 >> I think Mobile Throughput Guidance would be a good candidate for PLUS = path-to-endpoint signalling. The latest (albeit expired) MTG draft [1] = is bound to TCP Options, and was considering use of TCP-AO for = authentication; PLUS could allow MTG for both TCP and UDP-based flows. = However it seems that proposed PLUS mechanism: >>=20 >>> (1) For forward signaling, the sending endpoint must place "scratch = space" in the packet with a label on it stating that it's okay to = modify; this okay-to-modify state is enforced by a MAC which only = verifies the length but not the content of the scratch space. >>=20 >> ...may not provide the guarantee that (1) the MTG information was = indeed injected by the cellular network and (2) that it has not been = modified by another node. Have I got that right? >=20 > Correct. It doesn't provide that guarantee at all, by design. >=20 >> Or would such an authentication/integrity check applicable to path = data be in scope of PLUS? >=20 > As I see it now, not at first. The cases where the endpoint reliably = has an way to authenticate a middlebox are limited (though mobile access = networks are one such case), How so? -d > and IMO the mechanism should be as general as possible. >=20 > I will point out that integrity and authentication of information from = a middlebox where the sending endpoint can authenticate the middlebox = can trivially be implemented on top of this proposed mechanism: the = definition of the exposed information could be "content plus MAC", where = the MAC can be verified using the middlebox's certificate. But these can = be implemented in information elements atop PLUS, without requiring = additional support in the PLUS header. >=20 > In a mobile access network, on the upstream path this would look like: >=20 > user terminal --[ PLUS mobile-foo: 00000000 ]--> access network --[ = PLUS mobile-foo CCCCCCMM ]--> server >=20 > (where mobile-foo is whatever you want the access network to be able = to say, 00000000 is scratch space, C is content and M is MAC.) >=20 > The server can act on the throughput guidance (should it choose to, = see spud-req 5.9), but since it's the user terminal that has a = relationship with the access network, the server may need to feed the = content and MAC back to the user terminal (see spud-req 5.5 and 6.4) for = verification. >=20 > Cheers, >=20 > Brian >=20 >> Cheers, >> Kevin >> Vodafone R&D >>=20 >> [1] = https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance-03= .txt , expired >>=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 --Apple-Mail=_20D5D384-BA3F-4ABC-9FB5-13A2895C30CC 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 iQIcBAEBCgAGBQJXcqOCAAoJEA4QP55CjCAkU1EP/RrrLhFsxk/WczscyeouDwSt e4pwnQQUW7SMlTS4IEPttTBPc1PllFXFgnq5fhJkt/79BP0WZB5Y12psAYOBYz4C Ln8noIhRWbydIbZ0LuPmwuhs4K2NV6eDtL6Tewli7pyxUwoO0aeRP0L8p/YmS/ET MAD+kWeHwLhB/coxcvzKu172g4DPvHuIBZSvPzB3bCiV0qTC/k7HQ+yto0/lzmNe MAqQk4hp7f9tfhdZ39tD5WiXVBnWAVBQ0+1H8Js7+CZY5Vf5/vDUfLJoYVFrBUn1 BMmumk0qV1ZCI+iP1hbLTDy1zoskyWktFoQJejqiJzisyVqPIr9BsZwX0aqbTD+0 DxUssVVgMaVqSEGwaO7j5itG4zcksfd5yYTr/6zFLp6/UYAmmKEAhe0KsgjR4vjH PcJMuFkDW4lOiOkvbTTsfN8MqGGnufVEKRKj0hUlAgfuwCtYgzwI4z6bWoeDqLHG PvrfoSMYfjunN7UG3CT2ELBinutBhv69qGLidGynxwfx2lnTSRQixLy1NYJQvl6B FyHW4IGJG3Cq8BczcjQkqa2NEEWomcPUAwOer/ZzA8hPm+iT4bhyG4aCGlgKafSW 0AQG2uyCOdQRmL0u3GWf+i8AaQZHZn9XEAZf77LoTRUvX5et8eK+k0LmV5L+mJ0N yCo9bpt7QwlBptkdV38/ =+D5L -----END PGP SIGNATURE----- --Apple-Mail=_20D5D384-BA3F-4ABC-9FB5-13A2895C30CC-- From nobody Tue Jun 28 10:37: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 1742212D616 for ; Tue, 28 Jun 2016 10:37:09 -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 W8jPP666noJY for ; Tue, 28 Jun 2016 10:37: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 3B44E12D5E9 for ; Tue, 28 Jun 2016 10:37:07 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id g13so23263648ioj.1 for ; Tue, 28 Jun 2016 10:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BzCMREslIbuonXM5WctIL6nD2KK6XjjuHprbh7IECNw=; b=cOvfKOxIUXH3/8SBh9ut2vlUKvLJNCun/HiUbACjwB6igbbVKiw7cMlQLOqfCfMSKp lLb5pKXuFQ3mEQV3VxcdHAE25trO0v3fpGvEj3W7ggPYGF47l9L5O+IjBh91Z/l3wdvb YD0YOS/43EGUOCZFTdqRYOX6Wi+jRao1Sfu4B7N2QQIAclJuiVVKLcEcKDcMdDKUI6zm xeyj+avVZg9l7o5GTCZHYE5h7oGehi7rnklJx1riIvhXENqJ2ZDlXlmxSaASH+Mh3Rlw HAUQm0L1XXxsi1NFfVSpiUD3MbxlvYnayHQ0ZPGY+cTMEgje6YG1vFLny+4hg7K39T/S kryw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BzCMREslIbuonXM5WctIL6nD2KK6XjjuHprbh7IECNw=; b=Lch9dm2rXIRK7zOplrhZREkIGDbfTDnUdunjQ58vofmO0XdrqLDGmsijPKAYe5Rh5a pv1UPiB3i1PMaGX1/CEAI7nbLwf/l0j2LIAfn2BBziplb3tuUFv6f72OJSnp8FancGcn o4Kl97Aim66niYaJziNxNQLJEpWxUvNdcPNNVeSB4lscRZmjKDg29Nvlcj966F7uOTUS sv8DtwuJOXRO4G6F1a+1/f0kIJ+9pRXK+g6H+SGYFTfIyIIUvcXS10UwMba81ndkzN5t Kf/wE2YTXdgrejOo38S8TgjOkXO6kHJDdLs5znyDVrFHLiue6KkY8OWGTt1zOWjnvLtH OcZg== X-Gm-Message-State: ALyK8tLrk/11jVRFk7HzYeS/UH5n8naOqq7JpxBsAHGKZQzqesgdaVx7CFF3Wo3bIPIp7+/glrpI07CIHgYtpQ== X-Received: by 10.107.11.26 with SMTP id v26mr5410022ioi.107.1467135426574; Tue, 28 Jun 2016 10:37:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Tue, 28 Jun 2016 10:37:06 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Tue, 28 Jun 2016 10:37:06 -0700 Message-ID: To: "Smith, Kevin, (R&D) Vodafone Group" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Brian Trammell \(ietf@trammell.ch\)" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 17:37:09 -0000 On Tue, Jun 28, 2016 at 3:41 AM, Smith, Kevin, (R&D) Vodafone Group wrote: > Hi Brian, > > I think Mobile Throughput Guidance would be a good candidate for PLUS pat= h-to-endpoint signalling. The latest (albeit expired) MTG draft [1] is boun= d to TCP Options, and was considering use of TCP-AO for authentication; PLU= S could allow MTG for both TCP and UDP-based flows. However it seems that p= roposed PLUS mechanism: > >>(1) For forward signaling, the sending endpoint must place "scratch space= " in the packet with a label on it stating that it's okay to modify; this o= kay-to-modify state is enforced by a MAC which only verifies the length but= not the content of the scratch space. > > ...may not provide the guarantee that (1) the MTG information was indeed = injected by the cellular network and (2) that it has not been modified by a= nother node. Have I got that right? Or would such an authentication/integri= ty check applicable to path data be in scope of PLUS? > > Cheers, > Kevin > Vodafone R&D > > [1] https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidan= ce-03.txt , expired > Hi Kevin, That is an interesting use case. Do you see any reason (other than maybe current deployability) that these can't be done in HBH options instead of TCP options? Thanks, Tom > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Tue Jun 28 14:49: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 AD3E912D539 for ; Tue, 28 Jun 2016 14:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.325 X-Spam-Level: X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 GNSP_4uAaupO for ; Tue, 28 Jun 2016 14:49:27 -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 33B1F12D537 for ; Tue, 28 Jun 2016 14:49:25 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5SLmZaj003806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jun 2016 14:48:36 -0700 (PDT) To: Tom Herbert References: <57719746.6030304@isi.edu> <5771B2E9.6030304@isi.edu> <5771B940.50003@isi.edu> From: Joe Touch Message-ID: <5772F0B2.9090106@isi.edu> Date: Tue, 28 Jun 2016 14:48:34 -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: <5771B940.50003@isi.edu> Content-Type: multipart/alternative; boundary="------------050601000604050507000903" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , Natasha Rooney , spud Subject: Re: [Spud] related draft in TSVWG 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, 28 Jun 2016 21:49:29 -0000 This is a multi-part message in MIME format. --------------050601000604050507000903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 6/27/2016 4:39 PM, Joe Touch wrote: >> Probably should also expressly forbid the network to modify options in >> > flight, that is where things get really scary in the above ambiguous >> > identification problem. > Oh, yes. FYI, the OCS is just over the option space, not over the UDP > payload, UDP header, or IP pseudoheader. Thinking further on this, I have the following language in the update: >> UDP options are intended for use only by the transport endpoints. They are no more (or less) appropriate to be modified in-transit than any other portion of the transport datagram. UDP options are are transport options. Generally, transport datagrams are not intended to be modified in-transit. However, the UDP option mechanism provides no specific protection against in-transit modification of the UDP header, UDP payload, or UDP option area. I.e., I agree that these shouldn't be modified, but IMO neither should UDP ports. The only way that such mods make sense is when they are carried out "on behalf of" the transport endpoints, but again they key is that "this is no different than any other portion of the UDP datagram" IMO. Joe --------------050601000604050507000903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 6/27/2016 4:39 PM, Joe Touch wrote:
Probably should also expressly forbid the network to modify options in
> flight, that is where things get really scary in the above ambiguous
> identification problem.

Oh, yes. FYI, the OCS is just over the option space, not over the UDP
payload, UDP header, or IP pseudoheader.
Thinking further on this, I have the following language in the update:

>> UDP options are intended for use only by the transport endpoints. They are no more (or less) appropriate to be modified in-transit than any other portion of the transport datagram.

UDP options are are transport options. Generally, transport datagrams are not intended to be modified in-transit. However, the UDP option mechanism provides no specific protection against in-transit modification of the UDP header, UDP payload, or UDP option area.


I.e., I agree that these shouldn't be modified, but IMO neither should UDP ports. The only way that such mods make sense is when they are carried out "on behalf of" the transport endpoints, but again they key is that "this is no different than any other portion of the UDP datagram" IMO.

Joe

--------------050601000604050507000903-- From nobody Tue Jun 28 15:04: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 4DBE712D86D for ; Tue, 28 Jun 2016 15:04:50 -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 cjAjyZqcdHnX for ; Tue, 28 Jun 2016 15:04:48 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B73C12D8F2 for ; Tue, 28 Jun 2016 15:04:44 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id f30so29765465ioj.2 for ; Tue, 28 Jun 2016 15:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nXBAdJturEF2A5KbeIdrh7Hrun/hjJ5O1QjxXewvXwM=; b=vdIHT++GNm7oytVupUdplW+4+KKt9B/BL03i8toI7r/rQ2VOaWw4G6C8DeFnyUnE2r gOi7rRFP9mTyPFY3zp1V7iKgXHedaViZsvnyJujKdQmD1gSkomds/5rlm0B3KkBVbLFO uoyrhpf2zCcpBoK8bK7TLXQ/uEgyUknYph8TUDUJS+40fXmdRD50ir0xbjQgArAxl1y0 vhGLRlbPXbdsK9HzloJR+OxtNXXOqReeI4L0DOdJzIGMSpGb8qxbF7mZzM2fOcP6Z4be WEbU7k4/Gls0+q2htoAeUGx2pdCW4AQ+QLbXNFl9FTHrpRUJ39BavrSurLRvSEJNfNU1 s2Nw== 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=nXBAdJturEF2A5KbeIdrh7Hrun/hjJ5O1QjxXewvXwM=; b=KL84c9r59Csun61jn+fw1+2DB6opRFNwU1SXQUFuns5ADDyMrPqTfqBTyFv5eMzmIl LL7Vb1kubPG7ubkZEy17zNgwCJQV2OPU8WFxeJCO5Wovn7iwjIPPMyTkqWZMXFbCfbG5 h/HkT9Te9VvWT2qf+TOXnq/SbBQxyf3Fg5z1LrVNCMWvgjfnlEy+k5XTYeQKpVNTI6mo onYCccG27noQC4Nk4ACd/C8d0mGnYrByEpU1E9qN4+gaAyjIUpIQQUwgkp1BRnCs3OXI vkxGIPbHn2LohDjtc9jrlFDPtRMzUxwydv1pwvVwXKKJpLYh2rPRi4gfACcrUjBodgd8 MbHA== X-Gm-Message-State: ALyK8tJU8Ak+yZN/dX6HrAx236wCBlR0VBMTAjrAyfWa2DvKZMg1TncewdDq91XRNCHtijcmsNrV5LT9RR4Vxg== X-Received: by 10.107.39.149 with SMTP id n143mr6305606ion.50.1467151483357; Tue, 28 Jun 2016 15:04:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Tue, 28 Jun 2016 15:04:42 -0700 (PDT) In-Reply-To: <5772F0B2.9090106@isi.edu> References: <57719746.6030304@isi.edu> <5771B2E9.6030304@isi.edu> <5771B940.50003@isi.edu> <5772F0B2.9090106@isi.edu> From: Tom Herbert Date: Tue, 28 Jun 2016 15:04:42 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Aaron Falk , Natasha Rooney , spud Subject: Re: [Spud] related draft in TSVWG 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, 28 Jun 2016 22:04:50 -0000 On Tue, Jun 28, 2016 at 2:48 PM, Joe Touch wrote: > > > On 6/27/2016 4:39 PM, Joe Touch wrote: > > Probably should also expressly forbid the network to modify options in >> flight, that is where things get really scary in the above ambiguous >> identification problem. > > Oh, yes. FYI, the OCS is just over the option space, not over the UDP > payload, UDP header, or IP pseudoheader. > > Thinking further on this, I have the following language in the update: > >>> UDP options are intended for use only by the transport endpoints. They >>> are no more (or less) appropriate to be modified in-transit than any other >>> portion of the transport datagram. > > UDP options are are transport options. Generally, transport datagrams are > not intended to be modified in-transit. However, the UDP option mechanism > provides no specific protection against in-transit modification of the UDP > header, UDP payload, or UDP option area. > > > I.e., I agree that these shouldn't be modified, but IMO neither should UDP > ports. The only way that such mods make sense is when they are carried out > "on behalf of" the transport endpoints, but again they key is that "this is > no different than any other portion of the UDP datagram" IMO. > It is different because of the payload identification problem. Intermediate nodes modifying the UDP option area carries more risk of data corruption than if they modify the UDP header or TCP options. This probably would have less risk than modifying UDP payload itself though. Tom > Joe > From nobody Tue Jun 28 15:08: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 CC6BE12D8F9 for ; Tue, 28 Jun 2016 15:08:48 -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 5oTsH7sjYOtt for ; Tue, 28 Jun 2016 15:08:46 -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 9F81F12D887 for ; Tue, 28 Jun 2016 15:08:46 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5SM7xcC009500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jun 2016 15:08:00 -0700 (PDT) To: Tom Herbert References: <57719746.6030304@isi.edu> <5771B2E9.6030304@isi.edu> <5771B940.50003@isi.edu> <5772F0B2.9090106@isi.edu> From: Joe Touch Message-ID: <5772F53D.4070000@isi.edu> Date: Tue, 28 Jun 2016 15:07:57 -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-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , Natasha Rooney , spud Subject: Re: [Spud] related draft in TSVWG 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, 28 Jun 2016 22:08:49 -0000 On 6/28/2016 3:04 PM, Tom Herbert wrote: > On Tue, Jun 28, 2016 at 2:48 PM, Joe Touch wrote: >> >> On 6/27/2016 4:39 PM, Joe Touch wrote: >> >> Probably should also expressly forbid the network to modify options in >>> flight, that is where things get really scary in the above ambiguous >>> identification problem. >> Oh, yes. FYI, the OCS is just over the option space, not over the UDP >> payload, UDP header, or IP pseudoheader. >> >> Thinking further on this, I have the following language in the update: >> >>>> UDP options are intended for use only by the transport endpoints. They >>>> are no more (or less) appropriate to be modified in-transit than any other >>>> portion of the transport datagram. >> UDP options are are transport options. Generally, transport datagrams are >> not intended to be modified in-transit. However, the UDP option mechanism >> provides no specific protection against in-transit modification of the UDP >> header, UDP payload, or UDP option area. >> >> >> I.e., I agree that these shouldn't be modified, but IMO neither should UDP >> ports. The only way that such mods make sense is when they are carried out >> "on behalf of" the transport endpoints, but again they key is that "this is >> no different than any other portion of the UDP datagram" IMO. >> > It is different because of the payload identification problem. > Intermediate nodes modifying the UDP option area carries more risk of > data corruption than if they modify the UDP header or TCP options. > This probably would have less risk than modifying UDP payload itself > though. I agree they're all a little different, but I don't know if I'd take a bet on whether any of this is more or less likely to mess things up. E.g., changing ports affects in-band refs to port numbers too. Joe From nobody Wed Jun 29 01:47: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 6442812DABB for ; Wed, 29 Jun 2016 01:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, 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 caPReDxv9VWx for ; Wed, 29 Jun 2016 01:47:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA66912D0BF for ; Wed, 29 Jun 2016 01:47:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRT16825; Wed, 29 Jun 2016 08:47:34 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 29 Jun 2016 09:47:33 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 29 Jun 2016 16:47:25 +0800 From: Youjianjie To: Brian Trammell , "Smith, Kevin, (R&D) Vodafone Group" Thread-Topic: [Spud] endpoint control Thread-Index: AQHR0TeY1N76QbxLLUie4rcu/2LWS6AAGTeQ Date: Wed, 29 Jun 2016 08:47:25 +0000 Message-ID: References: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch> In-Reply-To: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.148] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.57738B26.01E5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9f873e2aaa8f87a5cbe1a80e61c2d3a1 Archived-At: Cc: "spud@ietf.org" Subject: [Spud] =?gb2312?b?tPC4tDogIGVuZHBvaW50IGNvbnRyb2w=?= 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, 29 Jun 2016 08:47:40 -0000 SGkgQnJpYW4sIEtldmluLA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IFNwdWQg W21haWx0bzpzcHVkLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQnJpYW4gVHJhbW1lbGwNCj4gt6LL zcqxvOQ6IDIwMTbE6jbUwjI4yNUgMjA6MjENCj4gytW8/sjLOiBTbWl0aCwgS2V2aW4sIChSJkQp IFZvZGFmb25lIEdyb3VwDQo+ILOty806IHNwdWRAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtTcHVk XSBlbmRwb2ludCBjb250cm9sDQo+IA0KPiANCj4gPiBPbiAyOCBKdW4gMjAxNiwgYXQgMTI6NDEs IFNtaXRoLCBLZXZpbiwgKFImRCkgVm9kYWZvbmUgR3JvdXANCj4gPEtldmluLlNtaXRoQHZvZGFm b25lLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBCcmlhbiwNCj4gPg0KPiA+IEkgdGhpbmsgTW9i aWxlIFRocm91Z2hwdXQgR3VpZGFuY2Ugd291bGQgYmUgYSBnb29kIGNhbmRpZGF0ZSBmb3IgUExV Uw0KPiBwYXRoLXRvLWVuZHBvaW50IHNpZ25hbGxpbmcuIFRoZSBsYXRlc3QgKGFsYmVpdCBleHBp cmVkKSBNVEcgZHJhZnQgWzFdIGlzIGJvdW5kDQo+IHRvIFRDUCBPcHRpb25zLCBhbmQgd2FzIGNv bnNpZGVyaW5nIHVzZSBvZiBUQ1AtQU8gZm9yIGF1dGhlbnRpY2F0aW9uOyBQTFVTDQo+IGNvdWxk IGFsbG93IE1URyBmb3IgYm90aCBUQ1AgYW5kIFVEUC1iYXNlZCBmbG93cy4gSG93ZXZlciBpdCBz ZWVtcyB0aGF0DQo+IHByb3Bvc2VkIFBMVVMgbWVjaGFuaXNtOg0KPiA+DQo+ID4+ICgxKSBGb3Ig Zm9yd2FyZCBzaWduYWxpbmcsIHRoZSBzZW5kaW5nIGVuZHBvaW50IG11c3QgcGxhY2UgInNjcmF0 Y2ggc3BhY2UiDQo+IGluIHRoZSBwYWNrZXQgd2l0aCBhIGxhYmVsIG9uIGl0IHN0YXRpbmcgdGhh dCBpdCdzIG9rYXkgdG8gbW9kaWZ5OyB0aGlzDQo+IG9rYXktdG8tbW9kaWZ5IHN0YXRlIGlzIGVu Zm9yY2VkIGJ5IGEgTUFDIHdoaWNoIG9ubHkgdmVyaWZpZXMgdGhlIGxlbmd0aCBidXQNCj4gbm90 IHRoZSBjb250ZW50IG9mIHRoZSBzY3JhdGNoIHNwYWNlLg0KPiA+DQo+ID4gLi4ubWF5IG5vdCBw cm92aWRlIHRoZSBndWFyYW50ZWUgdGhhdCAoMSkgdGhlIE1URyBpbmZvcm1hdGlvbiB3YXMgaW5k ZWVkDQo+IGluamVjdGVkIGJ5IHRoZSBjZWxsdWxhciBuZXR3b3JrIGFuZCAoMikgdGhhdCBpdCBo YXMgbm90IGJlZW4gbW9kaWZpZWQgYnkNCj4gYW5vdGhlciBub2RlLiBIYXZlIEkgZ290IHRoYXQg cmlnaHQ/DQo+IA0KPiBDb3JyZWN0LiBJdCBkb2Vzbid0IHByb3ZpZGUgdGhhdCBndWFyYW50ZWUg YXQgYWxsLCBieSBkZXNpZ24uDQo+IA0KPiA+IE9yIHdvdWxkIHN1Y2ggYW4gYXV0aGVudGljYXRp b24vaW50ZWdyaXR5IGNoZWNrIGFwcGxpY2FibGUgdG8gcGF0aCBkYXRhIGJlDQo+IGluIHNjb3Bl IG9mIFBMVVM/DQo+IA0KPiBBcyBJIHNlZSBpdCBub3csIG5vdCBhdCBmaXJzdC4gVGhlIGNhc2Vz IHdoZXJlIHRoZSBlbmRwb2ludCByZWxpYWJseSBoYXMgYW4gd2F5DQo+IHRvIGF1dGhlbnRpY2F0 ZSBhIG1pZGRsZWJveCBhcmUgbGltaXRlZCAodGhvdWdoIG1vYmlsZSBhY2Nlc3MgbmV0d29ya3Mg YXJlDQo+IG9uZSBzdWNoIGNhc2UpLCBhbmQgSU1PIHRoZSBtZWNoYW5pc20gc2hvdWxkIGJlIGFz IGdlbmVyYWwgYXMgcG9zc2libGUuDQoNCklJVUMsIGluIE1URyBjYXNlLCB0aGUgbWlkZGxlYm94 IChpLmUuIG1vYmlsZSBlZGdlIHNlcnZlcikgd2hpY2ggaW5zZXJ0cyB0aGUgdGhyb3VnaHB1dCBn dWlkYW5jZSBpbmZvcm1hdGlvbiBpcyBleHBsaWNpdGx5IGtub3duIHRvIHRoZSBlbmRwb2ludC4g VGhleSBuZWdvdGlhdGUgdGhlIGtleXMgaW4gYWR2YW5jZS4gVGhlIGNvbnRlbnQgZnJvbSBwYXRo IGlzIGVuY3J5cHRlZCBhbmQgcHJvdGVjdGVkIGJ5IGRlZmF1bHQuIA0KSW4gUExVUywgdGhlIGdl bmVyYWwgY2FzZSBpcyBmb3IgdHJhbnNwYXJlbnQgbWlkZGxlYm94ZXMuIE9ubHkgdHlwZSBhbmQg bGVuZ3RoIGFyZSBwcm90ZWN0ZWQuIA0KQnV0IFBMVVMgZG9lc24ndCBleGNsdWRlIGV4Y2hhbmdp bmcga2V5cyBmb3Igc29tZSBzcGVjaWZpYyBtaWRkbGVib3ggb24gcGF0aCB3aXRoIHRoZSBlbmRw b2ludCBzZXJ2ZXIuIFRvIHNvbWUgZXh0ZW50LCB0aGUgbGF0dGVyIGNhc2UgY291bGQgY29ycmVz cG9uZCB0byB0aGUgTVRHIGNhc2UsIGV4Y2VwdCB0aGF0IHRoZSBjb250ZW50IGluIHRoZSBQTFVT IGhlYWRlciBjYW4gYmUgb25seSB2ZXJpZmllZCAoY29udGVudCArIE1BQykgd2l0aG91dCBlbmNy eXB0aW9uLiANCg0KVGhhbmtzLA0KSmlhbmppZQ0KDQo+IEkgd2lsbCBwb2ludCBvdXQgdGhhdCBp bnRlZ3JpdHkgYW5kIGF1dGhlbnRpY2F0aW9uIG9mIGluZm9ybWF0aW9uIGZyb20gYQ0KPiBtaWRk bGVib3ggd2hlcmUgdGhlIHNlbmRpbmcgZW5kcG9pbnQgY2FuIGF1dGhlbnRpY2F0ZSB0aGUgbWlk ZGxlYm94IGNhbg0KPiB0cml2aWFsbHkgYmUgaW1wbGVtZW50ZWQgb24gdG9wIG9mIHRoaXMgcHJv cG9zZWQgbWVjaGFuaXNtOiB0aGUgZGVmaW5pdGlvbiBvZg0KPiB0aGUgZXhwb3NlZCBpbmZvcm1h dGlvbiBjb3VsZCBiZSAiY29udGVudCBwbHVzIE1BQyIsIHdoZXJlIHRoZSBNQUMgY2FuIGJlDQo+ IHZlcmlmaWVkIHVzaW5nIHRoZSBtaWRkbGVib3gncyBjZXJ0aWZpY2F0ZS4gQnV0IHRoZXNlIGNh biBiZSBpbXBsZW1lbnRlZCBpbg0KPiBpbmZvcm1hdGlvbiBlbGVtZW50cyBhdG9wIFBMVVMsIHdp dGhvdXQgcmVxdWlyaW5nIGFkZGl0aW9uYWwgc3VwcG9ydCBpbiB0aGUNCj4gUExVUyBoZWFkZXIu DQo+IA0KPiBJbiBhIG1vYmlsZSBhY2Nlc3MgbmV0d29yaywgb24gdGhlIHVwc3RyZWFtIHBhdGgg dGhpcyB3b3VsZCBsb29rIGxpa2U6DQo+IA0KPiB1c2VyIHRlcm1pbmFsIC0tWyBQTFVTIG1vYmls ZS1mb286IDAwMDAwMDAwIF0tLT4gYWNjZXNzIG5ldHdvcmsgLS1bIFBMVVMNCj4gbW9iaWxlLWZv byBDQ0NDQ0NNTSBdLS0+IHNlcnZlcg0KPiANCj4gKHdoZXJlIG1vYmlsZS1mb28gaXMgd2hhdGV2 ZXIgeW91IHdhbnQgdGhlIGFjY2VzcyBuZXR3b3JrIHRvIGJlIGFibGUgdG8gc2F5LA0KPiAwMDAw MDAwMCBpcyBzY3JhdGNoIHNwYWNlLCBDIGlzIGNvbnRlbnQgYW5kIE0gaXMgTUFDLikNCj4gDQo+ IFRoZSBzZXJ2ZXIgY2FuIGFjdCBvbiB0aGUgdGhyb3VnaHB1dCBndWlkYW5jZSAoc2hvdWxkIGl0 IGNob29zZSB0bywgc2VlDQo+IHNwdWQtcmVxIDUuOSksIGJ1dCBzaW5jZSBpdCdzIHRoZSB1c2Vy IHRlcm1pbmFsIHRoYXQgaGFzIGEgcmVsYXRpb25zaGlwIHdpdGggdGhlDQo+IGFjY2VzcyBuZXR3 b3JrLCB0aGUgc2VydmVyIG1heSBuZWVkIHRvIGZlZWQgdGhlIGNvbnRlbnQgYW5kIE1BQyBiYWNr IHRvIHRoZQ0KPiB1c2VyIHRlcm1pbmFsIChzZWUgc3B1ZC1yZXEgNS41IGFuZCA2LjQpIGZvciB2 ZXJpZmljYXRpb24uDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBCcmlhbg0KPiANCj4gPiBDaGVlcnMs DQo+ID4gS2V2aW4NCj4gPiBWb2RhZm9uZSBSJkQNCj4gPg0KPiA+IFsxXQ0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWZsaW5jay1tb2JpbGUtdGhyb3VnaHB1dC1ndWlk YW5jZS0wMy50eA0KPiB0ICwgZXhwaXJlZA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBTcHVkIG1haWxpbmcgbGlzdA0KPiA+IFNw dWRAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nw dWQNCg0K From nobody Wed Jun 29 03:46: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 A541D12DB74 for ; Wed, 29 Jun 2016 03:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjzInhOIlE99 for ; Wed, 29 Jun 2016 03:45:56 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.109]) (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 EF23112DB72 for ; Wed, 29 Jun 2016 03:45:55 -0700 (PDT) Received: from [193.109.255.99] by server-5.bemta-14.messagelabs.com id FF/ED-08132-1E6A3775; Wed, 29 Jun 2016 10:45:53 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRWlGSWpSXmKPExsVy+MWXVt2Hy4r DDSbuVLHY2PKOzWLRhaeMFpcvPWJ2YPbonTuN1WPJkp9MHk/2z2QJYI5izcxLyq9IYM24OOUU U8E8yYqp/46zNzB+kehi5OQQEtjDKNH+Ub6LkQvIXskocfL0IRYIZzmTxM32LawQzhFGiQMT7 zJDOJsZJTbdmc4K0s8m4CpxdNcddhBbREBV4sGE6ywgNrNAjMSMuQeZQGxhARWJmZeXscLU9P dOgKq3kthw8xPQUA4OFqD4+yXyIGFegVCJtrn72CB2zWaU+P7zIFg9p0CgxLy929hAbEYBWYk vjauZIXaJS9x6Mh9sl4SAgMSSPeeZIWxRiZeP/7GCzGcW0JRYv0sfolxRYkr3Q3aIXYISJ2c+ YZnAKDYLyaRZCB2zkHTMQtKxgJFlFaNGcWpRWWqRrqGBXlJRZnpGSW5iZo6uoaGJXm5qcXFie mpOYlKxXnJ+7iZGYMQxAMEOxnPLnA8xSnIwKYny6ucVhwvxJeWnVGYkFmfEF5XmpBYfYpTh4F CS4L2yFCgnWJSanlqRlpkDjH2YtAQHj5IIb+5ioDRvcUFibnFmOkTqFKOilDgvEzBhCAmAJDJ K8+DaYOnmEqOslDAvI9AhQjwFqUW5mSWo8q8YxTkYlYR534Js58nMK4Gb/gpoMRPQYuZSsMUl iQgpqQbGLkXJyav1zaXWpW3WMpr680zJ3mWvE5+ybLK/7ejgIm6Rr2Yl1/i82fZ9Y2iVy1WF4 PntfJeY3z1y0S1qUTC2uK4058zD6upAmRPurZ7MSltfTurjmB5/Z5VRY6PJXO2rTzkfZt/xXL vmkfUk/+mJkm1+mluDmpe3rf0gsoCj9JFpQ/OiktdKLMUZiYZazEXFiQBJ8d6XMgMAAA== X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-11.tower-48.messagelabs.com!1467197153!8962962!1 X-Originating-IP: [195.232.244.133] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13973 invoked from network); 29 Jun 2016 10:45:53 -0000 Received: from mailout01.vodafone.com (HELO mailout01.vodafone.com) (195.232.244.133) by server-11.tower-48.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 29 Jun 2016 10:45:53 -0000 Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout01.vodafone.com (Postfix) with ESMTP id 3rffTs18Srz1yG5; Wed, 29 Jun 2016 12:45:53 +0200 (CEST) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3rffTs02XVzxPZT; Wed, 29 Jun 2016 12:45:53 +0200 (CEST) Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3rffTr6n4hzxP8s; Wed, 29 Jun 2016 12:45:52 +0200 (CEST) Received: from AVOEXH03W.internal.vodafone.com (145.230.15.141) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 29 Jun 2016 12:45:52 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.75]) by AVOEXH03W.internal.vodafone.com ([145.230.15.141]) with mapi id 14.03.0224.002; Wed, 29 Jun 2016 12:45:52 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: Tom Herbert Thread-Topic: [Spud] endpoint control Thread-Index: AdHRKB6Rk1yBi0AtT2GnUMPMbLGi+gAKs4sAACVbQKA= Date: Wed, 29 Jun 2016 10:45:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Brian Trammell \(ietf@trammell.ch\)" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 10:45:58 -0000 SGkgVG9tLCANCg0KPiBEbyB5b3Ugc2VlIGFueSByZWFzb24gKG90aGVyIHRoYW4gbWF5YmUgY3Vy cmVudCBkZXBsb3lhYmlsaXR5KSB0aGF0IHRoZXNlIGNhbid0IGJlIGRvbmUgaW4gSEJIIG9wdGlv bnMgaW5zdGVhZCBvZiBUQ1Agb3B0aW9ucz8NCg0KUHJvYmFibHkgZG93biB0byBmb3J3YXJkaW5n IHBlcmZvcm1hbmNlIHRvbywgYXMgSG9wLWJ5LUhvcCBtdXN0IGJlIHByb2Nlc3NlZCBieSBhbGwg bmV0d29yayBkZXZpY2VzLiBBbmQgZGVwbG95YWJpbGl0eSBhcyB5b3Ugc2F5OyBiZWNhdXNlIElQ djYgaXMgdW5mb3J0dW5hdGVseSBub3QgcHJldmFsZW50IHlldCBpbiBtb2JpbGUgY29yZSBuZXR3 b3Jrcy4uLg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta3Jpc2huYW4taXB2 Ni1ob3BieWhvcC0wNSByZWNvbW1lbmRzIHVzaW5nIG90aGVyIGV4dGVuc2lvbiBoZWFkZXJzIGlu c3RlYWQsIGR1ZSB0byBhIGRlbmlhbCBvZiBzZXJ2aWNlIHRocmVhdC4gQnV0IHRoZXNlIGFyZSBp bnRlbmRlZCBmb3IgdGhlIGRlc3RpbmF0aW9uIGFuZCBub3QgaW50ZXJpbSBub2RlcywgYW5kIHdl J2QgbmVlZCB0byBjaGVjayB0aGF0IEVIIGFyZSBjb25zaXN0ZW50bHkgcGFzc2VkIGFjcm9zcyBh IHJhbmdlIG9mIHZlbmRvcnMnIHJvdXRlcnMuDQoNCk1hbnkgdGhhbmtzLA0KS2V2aW4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9tQGhl cmJlcnRsYW5kLmNvbV0gDQpTZW50OiAyOCBKdW5lIDIwMTYgMTg6MzcNClRvOiBTbWl0aCwgS2V2 aW4sIChSJkQpIFZvZGFmb25lIEdyb3VwDQpDYzogQnJpYW4gVHJhbW1lbGwgKGlldGZAdHJhbW1l bGwuY2gpOyBzcHVkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NwdWRdIGVuZHBvaW50IGNvbnRy b2wNCg0KT24gVHVlLCBKdW4gMjgsIDIwMTYgYXQgMzo0MSBBTSwgU21pdGgsIEtldmluLCAoUiZE KSBWb2RhZm9uZSBHcm91cCA8S2V2aW4uU21pdGhAdm9kYWZvbmUuY29tPiB3cm90ZToNCj4gSGkg QnJpYW4sDQo+DQo+IEkgdGhpbmsgTW9iaWxlIFRocm91Z2hwdXQgR3VpZGFuY2Ugd291bGQgYmUg YSBnb29kIGNhbmRpZGF0ZSBmb3IgUExVUyBwYXRoLXRvLWVuZHBvaW50IHNpZ25hbGxpbmcuIFRo ZSBsYXRlc3QgKGFsYmVpdCBleHBpcmVkKSBNVEcgZHJhZnQgWzFdIGlzIGJvdW5kIHRvIFRDUCBP cHRpb25zLCBhbmQgd2FzIGNvbnNpZGVyaW5nIHVzZSBvZiBUQ1AtQU8gZm9yIGF1dGhlbnRpY2F0 aW9uOyBQTFVTIGNvdWxkIGFsbG93IE1URyBmb3IgYm90aCBUQ1AgYW5kIFVEUC1iYXNlZCBmbG93 cy4gSG93ZXZlciBpdCBzZWVtcyB0aGF0IHByb3Bvc2VkIFBMVVMgbWVjaGFuaXNtOg0KPg0KPj4o MSkgRm9yIGZvcndhcmQgc2lnbmFsaW5nLCB0aGUgc2VuZGluZyBlbmRwb2ludCBtdXN0IHBsYWNl ICJzY3JhdGNoIHNwYWNlIiBpbiB0aGUgcGFja2V0IHdpdGggYSBsYWJlbCBvbiBpdCBzdGF0aW5n IHRoYXQgaXQncyBva2F5IHRvIG1vZGlmeTsgdGhpcyBva2F5LXRvLW1vZGlmeSBzdGF0ZSBpcyBl bmZvcmNlZCBieSBhIE1BQyB3aGljaCBvbmx5IHZlcmlmaWVzIHRoZSBsZW5ndGggYnV0IG5vdCB0 aGUgY29udGVudCBvZiB0aGUgc2NyYXRjaCBzcGFjZS4NCj4NCj4gLi4ubWF5IG5vdCBwcm92aWRl IHRoZSBndWFyYW50ZWUgdGhhdCAoMSkgdGhlIE1URyBpbmZvcm1hdGlvbiB3YXMgaW5kZWVkIGlu amVjdGVkIGJ5IHRoZSBjZWxsdWxhciBuZXR3b3JrIGFuZCAoMikgdGhhdCBpdCBoYXMgbm90IGJl ZW4gbW9kaWZpZWQgYnkgYW5vdGhlciBub2RlLiBIYXZlIEkgZ290IHRoYXQgcmlnaHQ/IE9yIHdv dWxkIHN1Y2ggYW4gYXV0aGVudGljYXRpb24vaW50ZWdyaXR5IGNoZWNrIGFwcGxpY2FibGUgdG8g cGF0aCBkYXRhIGJlIGluIHNjb3BlIG9mIFBMVVM/DQo+DQo+IENoZWVycywNCj4gS2V2aW4NCj4g Vm9kYWZvbmUgUiZEDQo+DQo+IFsxXSANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9p ZC9kcmFmdC1mbGluY2stbW9iaWxlLXRocm91Z2hwdXQtZ3VpZGFuYw0KPiBlLTAzLnR4dCAsIGV4 cGlyZWQNCj4NCkhpIEtldmluLA0KDQpUaGF0IGlzIGFuIGludGVyZXN0aW5nIHVzZSBjYXNlLiBE byB5b3Ugc2VlIGFueSByZWFzb24gKG90aGVyIHRoYW4gbWF5YmUgY3VycmVudCBkZXBsb3lhYmls aXR5KSB0aGF0IHRoZXNlIGNhbid0IGJlIGRvbmUgaW4gSEJIIG9wdGlvbnMgaW5zdGVhZCBvZiBU Q1Agb3B0aW9ucz8NCg0KVGhhbmtzLA0KVG9tDQoNCg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTcHVkIG1haWxpbmcgbGlzdA0KPiBTcHVkQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3B1ZA0K From nobody Wed Jun 29 10: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 EF0EC12DD42 for ; Wed, 29 Jun 2016 10:33:46 -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 Beeno9R-wrda for ; Wed, 29 Jun 2016 10:33:44 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 9D05B12DB48 for ; Wed, 29 Jun 2016 10:33:44 -0700 (PDT) Received: by mail-ob0-x234.google.com with SMTP id xn17so35847656obc.0 for ; Wed, 29 Jun 2016 10:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iTwHIm0JHkeQMyj1FcktfHK51JOAjbxO8ccsXFPirQk=; b=LyAHM7XLYMnsp2NfIifeNkpQ9kNhdK0V/nDSISuiaF9G4g4VXVGb/8rUYRlizL5FQW uYqik5cy0JtaLc+Hy8mCXjfe3/8AXJALY+NgPCUN7qOANuftFD/TSUSNBSfoQHcVUaVD cTppvyYKTLhduaHoIfNhNmASBsj4E4Sxj02RrRMMW826lG/VoQoPv+VLwGwSy4hC+vUy +NquPwGi2x0BtCkJuK/OJkqDb2foNhKEj5fazvB6KWi6SKmJ6Zbz7DmoXhi9lh8HjKSM qijSqxptz/w24nxrPgLfNUvZg9OJUA1uXbaeCSAQjaa88WYSdAwDzcVkNuyoSQjHwaY0 XNdQ== 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=iTwHIm0JHkeQMyj1FcktfHK51JOAjbxO8ccsXFPirQk=; b=F4/wfSMyLYj0HDivD8fnbnK6fAd345LLzAD+VZp21rxj0r4ZxN62wcwFpqbEMWLN+F KtlCMSdPlyBGpcKV31XT3ZkZn1wJqWI2QofRPZFt9PYwUCblK394Swte2BjCeVT1Naov y42Fs82X6WCQdgOkh8PCs9GerhSFYQAu6GOOrKcfEByeiq73Elg/ZYt6Fl7V3G84orow eoIJYYKnz5ad565nKAH66q/5EB6O+9W5tJ+q2Wwicve2+Wn/DAMbrSd6xYyWPnki4/yB tXqiKqf46pSIzRFdo1LFGe45ApNb5pctPkKSd9Ii72g5Tk8AqfR/SgGxtBPtptFXvU9b rv9w== X-Gm-Message-State: ALyK8tL6YWkdi6N8yEeZ9no4+CH7eGJrkBJ9OMaCL5rSZFCj+Ab+45he6LmmflRXV5qYQaH5ZzIhOZeO+1MpcQ== X-Received: by 10.157.58.52 with SMTP id j49mr6775149otc.118.1467221623786; Wed, 29 Jun 2016 10:33:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Wed, 29 Jun 2016 10:33:24 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Wed, 29 Jun 2016 10:33:24 -0700 Message-ID: To: Tom Herbert Content-Type: multipart/alternative; boundary=001a11471a08b1548305366e27ef Archived-At: Cc: Natasha Rooney , spud Subject: Re: [Spud] Details about PLUS BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 17:33:47 -0000 --001a11471a08b1548305366e27ef Content-Type: text/plain; charset=UTF-8 On Mon, Jun 27, 2016 at 2:28 PM, Tom Herbert wrote: > On Mon, Jun 27, 2016 at 1:12 PM, Ted Hardie wrote: > > > > > You appear to be saying that the eliminated implicit path layer simply > > should not be replaced in UDP encapsulations unless evidence comes > through > > to define what information should be exposed. > > > Right. Consider that we want to deploy encrypted UDP-based transports > in the near term and that no middlebox supports anything resembling > PLUS. In the simplest model, either a network path forwards UDP > packets without impediment or it doesn't. If it doesn't we will > fallback to TCP and probably alert the user of that at some point. If > PLUS does come on-line then it's worth using only if it provides some > tangible benefit to our traffic or it "fixes" whatever networks are > still blocking UDP. > > So, having the path forward UDP packets without impediment should be a consistent aim. The idea behind an explicit path layer is to move from "without impediment" to "with optimization". If an endpoint is is willing to inform the path of session start and stop for a UDP-based flow, for example, it may get the longer dwell times in NAT bindings that are currently available to flows that reveal that in an implicit path layer. That advantage might translate to avoiding heartbeat traffic, which is quite useful. To put this another way, the existence of a common PLUS substrate is not meant to imply that it will become a requirement for all UDP flows. regards, Ted --001a11471a08b1548305366e27ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 27, 2016 at 2:28 PM, Tom Herbert <tom@herbertland.com> wrote:
On Mon, Jun 27, 2016 at 1:12 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

>
> You appear to be saying that the eliminated implicit path layer simply=
> should not be replaced in UDP encapsulations unless evidence comes thr= ough
> to define what information should be exposed.
>
Right. Consider that we want to deploy encrypted UDP-based tran= sports
in the near term and that no middlebox supports anything resembling
PLUS. In the simplest model, either a network path forwards UDP
packets without impediment or it doesn't. If it doesn't we will
fallback to TCP and probably alert the user of that at some point. If
PLUS does come on-line then it's worth using only if it provides some tangible benefit to our traffic or it "fixes" whatever networks a= re
still blocking UDP.


So, having the path forward UDP packets without impediment should = be a consistent aim.=C2=A0 The idea behind an explicit path layer is to mov= e from "without impediment" to "with optimization".=C2= =A0 If an endpoint is is willing to inform the path of session start and st= op for a UDP-based flow, for example, it may get the longer dwell times in = NAT bindings that are currently available to flows that reveal that in an i= mplicit path layer.=C2=A0 That advantage might translate to avoiding heartb= eat traffic, which is quite useful.

To put this another way, the existence of a common PLUS substrate is not m= eant to imply that it will become a requirement for all UDP flows.

<= /div>
regards,

Ted




--001a11471a08b1548305366e27ef-- From nobody Wed Jun 29 11:26: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 115F312D5BE for ; Wed, 29 Jun 2016 11:26:28 -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 wZLMiRCRI9I7 for ; Wed, 29 Jun 2016 11:26:26 -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 1888E12D5A1 for ; Wed, 29 Jun 2016 11:26:26 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id f6so26960114ith.0 for ; Wed, 29 Jun 2016 11:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pC2tPjy5aAZN/w+W/YNdJbPDeFPPgTErAvWpr9W9Z9Y=; b=wxl0A6rx/ohhE6IfLq+iFpGB+sFpznWBvaF+yk/yLlxNrRflaNPZsoGnL3FBiX3MAw 5PX+GTf/4LyihT1C2C6az9OlApFYBftYNIpHxCHykflJVntuYiiaGJYipM9HjyYGErfy msg8Lhduy+N/O4TzRaEYTxI2xlursWLDZa8i8ihCXxtlvg3WbDu7w1NbyEb6WXuJ+e0l 3WlpwrTi2U7jm3mhPrjaKlIK4Slwmbz4AxkbiR1j5gGFN1ENEfktvI7PKSBJTWfRORYA WvHeET+jteNTcAncjxaZaGagPl6SnRwnSoFe5tc75ENUK6HxBOMyHsCcNG/zZPB3MGQZ oNdA== 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=pC2tPjy5aAZN/w+W/YNdJbPDeFPPgTErAvWpr9W9Z9Y=; b=lsxJ8Gw5fMMmobwgzOWPi2Kb8olVUR5jdwuT8yQKIPk1qyNak9N0M56DLGMHc3GoGM gnC6+Nf1wb8Q6tF+bak+68PKRw9s9Qay97yHwkTgTUurC7PvD6DxvmSkE5ak8s1puaRS J7vCA4cek54GRnHC2DbRyab8/MZ7gzcjlAxmls04zfOF/EJ9AA3nYrCFAZ6ve8C1G/Zg 5SB2vtEt0tWMPiw2D/1CuGot8IS/RPcfJZraGNAp9E2XyvYam/GJxqlmm7exFwu+Q4xP sjRuL5oxPs7KSaNNnjxY++myqqX4gHeuVIkIPThcoGB3QBEW7HgZnXZt0rYlKtOvu9/k zhkQ== X-Gm-Message-State: ALyK8tKwv8MljZdXHBrc5W4J95RasN5x+1H2+b/nIaP+UPVfNt2dJcqZW2zoBOynde7Nxv4D5HyqfBe9zNwZRA== X-Received: by 10.36.22.195 with SMTP id a186mr11873779ita.37.1467224785352; Wed, 29 Jun 2016 11:26:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Wed, 29 Jun 2016 11:26:24 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Wed, 29 Jun 2016 11:26:24 -0700 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Natasha Rooney , spud Subject: Re: [Spud] Details about PLUS BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 18:26:28 -0000 On Wed, Jun 29, 2016 at 10:33 AM, Ted Hardie wrote: > On Mon, Jun 27, 2016 at 2:28 PM, Tom Herbert wrote: >> >> On Mon, Jun 27, 2016 at 1:12 PM, Ted Hardie wrote: >> >> > >> > You appear to be saying that the eliminated implicit path layer simply >> > should not be replaced in UDP encapsulations unless evidence comes >> > through >> > to define what information should be exposed. >> > >> Right. Consider that we want to deploy encrypted UDP-based transports >> in the near term and that no middlebox supports anything resembling >> PLUS. In the simplest model, either a network path forwards UDP >> packets without impediment or it doesn't. If it doesn't we will >> fallback to TCP and probably alert the user of that at some point. If >> PLUS does come on-line then it's worth using only if it provides some >> tangible benefit to our traffic or it "fixes" whatever networks are >> still blocking UDP. >> > > So, having the path forward UDP packets without impediment should be a > consistent aim. The idea behind an explicit path layer is to move from > "without impediment" to "with optimization". If an endpoint is is willing > to inform the path of session start and stop for a UDP-based flow, for > example, it may get the longer dwell times in NAT bindings that are > currently available to flows that reveal that in an implicit path layer. > That advantage might translate to avoiding heartbeat traffic, which is quite > useful. > Ted, IMO the idea that the network should be tracking session state like that is a red herring because it presumes that the "path" of a flow is well defined and has some invariant hops. IP is a packet switched network architecture, not circuit switched. There has never been either a protocol nor architectural requirement that packets of any flow always go through the same intermediate device. In fact, I think we are going to see more cases of flows taking alternate paths within their lifetime. Consider that any smart phone is now typically multi-homed to both a mobile network and a WIFI network. It's pretty obvious that we'd like to seamlessly transition from using one network to the other without breaking established connections. In that world I'm not even sure what sort of PLUS state signaling would be meaningful (e.g. when transitioning do we need to send a PLUS 'FIN' into the old network, and a PLUS 'SYN' to the new one?). In any case, state signaling to the network seems at best to be a hint. Any intermediate devices that tracks tries to track stack must realize they could be completely wrong and need to take this fact into account. And if the network can't provide any assurances to the host given the signaled state, for instance a guarantee that NAT bindings are maintained for the duration of the connection, then the only recourse for the host has is to fallback to assuming network doesn't track state (e.g. still needs to send keepalives to maintain NAT). As for the NAT binding issue, I believe that IPv6 is supposed to obsolete the need for NAT in the first place. Thanks, Tom From nobody Wed Jun 29 16:14: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 0E19912D904 for ; Wed, 29 Jun 2016 16:14:23 -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 5VacXyD7Ker0 for ; Wed, 29 Jun 2016 16:14:21 -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 76FA112D8A6 for ; Wed, 29 Jun 2016 16:14:21 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u5TNE3nd010712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jun 2016 16:14:03 -0700 (PDT) To: "Smith, Kevin, (R&D) Vodafone Group" , Tom Herbert References: From: Joe Touch Message-ID: <57745639.7010303@isi.edu> Date: Wed, 29 Jun 2016 16:14:01 -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: u5TNE3nd010712 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "Brian Trammell \(ietf@trammell.ch\)" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 23:14:23 -0000 On 6/29/2016 3:45 AM, Smith, Kevin, (R&D) Vodafone Group wrote: > https://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05 recommends using other extension headers instead, due to a denial of service threat. It's not even a WG doc yet and it recommends some fairly severe changes to IPv6. Let's not assume its conclusions have been adopted just yet. Joe From nobody Wed Jun 29 16:26: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 416C612D87E for ; Wed, 29 Jun 2016 16:26:52 -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 Nns0m8FwWRAE for ; Wed, 29 Jun 2016 16:26:49 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 EC2AC12D76E for ; Wed, 29 Jun 2016 16:26:48 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id g127so133687807ith.0 for ; Wed, 29 Jun 2016 16:26: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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uK5YiBJjstTpmd1lUpQusojGpai29we9DuBpm4n4Epk=; b=nirKXXkYT0q6Ekjn1TTFqUgkrwibEO7YDU1Zi1cFJkUdL0EM3rnGw5uiWkrf86PfKg Ca9MQPHC3+WyxAORTle+XKgu9YkNe4IabZPvtF++v4rL6+FpEO7paOpgwiCrU18NiOYk zxN2brFg1QiaRS5WU3yMfoJkr4GWWXjGB9utRLoYzdPWqmoEP8BTWkQ/VIx/hrMvMzon xXgBCdi3lwxoAh8w5F5iBy7zeh6w5Te8pR4EM3X0VfALu6xntDmcD8+V9N+iFHzMK9ed AJ6qFkUzGw6RxGhmb7g0j9KiaibBQIDkhVFkpaX8Lt6Asbqshdzu3v1xD7NW9UdrQwYx 72Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uK5YiBJjstTpmd1lUpQusojGpai29we9DuBpm4n4Epk=; b=Owwmj7368HBP70eddUGmjktNSA9iWI/6FSJuQ12OUK3NQzNMbrGKJEeq/PdhGeGR1P XMt41dUdJHJq391mAzEa2la1iG/DbDnP36I0IkTXVJ4lS3AwYLyToAGoFu7eG+vyZ4ur eEML4+EdgOm8fwxYtCYfVpgdC6qumln9xIJF08LAofUKZUhEcNySjCMJMq4XiPVEUmRr Z4a1PL5ObfP3Fy/BAKjxxVCMhvjsKUmp1FuH04NQr6i+7egJQ45ykNYkEpvsGLEq+PeS y3YcLxZADkmT+GeVf1E+sB4n0JWEO6YAeY0PyFJsNG9MwWfadjXfJ4VKzMSK4J3z597H V90Q== X-Gm-Message-State: ALyK8tLtM1s/vczhpzZPFz8lCF7Os9P2LIrHzJYDjdKZVs2NyeySMpV/nE2CTZcSYKGLOfjacUOUU0d7q7bF9Q== X-Received: by 10.36.22.195 with SMTP id a186mr12982295ita.37.1467242808274; Wed, 29 Jun 2016 16:26:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Wed, 29 Jun 2016 16:26:47 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Wed, 29 Jun 2016 16:26:47 -0700 Message-ID: To: "Smith, Kevin, (R&D) Vodafone Group" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Brian Trammell \(ietf@trammell.ch\)" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 23:26:52 -0000 On Wed, Jun 29, 2016 at 3:45 AM, Smith, Kevin, (R&D) Vodafone Group wrote: > Hi Tom, > >> Do you see any reason (other than maybe current deployability) that thes= e can't be done in HBH options instead of TCP options? > > Probably down to forwarding performance too, as Hop-by-Hop must be proces= sed by all network devices. And deployability as you say; because IPv6 is u= nfortunately not prevalent yet in mobile core networks... > The first problem is being relaxed in 2460bis draft. It allows HBH to be ignored by network devices, which should cover the case where there are "too many options to parse" in a DOS attack. Tom > https://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05 recommends us= ing other extension headers instead, due to a denial of service threat. But= these are intended for the destination and not interim nodes, and we'd nee= d to check that EH are consistently passed across a range of vendors' route= rs. > > Many thanks, > Kevin > > -----Original Message----- > From: Tom Herbert [mailto:tom@herbertland.com] > Sent: 28 June 2016 18:37 > To: Smith, Kevin, (R&D) Vodafone Group > Cc: Brian Trammell (ietf@trammell.ch); spud@ietf.org > Subject: Re: [Spud] endpoint control > > On Tue, Jun 28, 2016 at 3:41 AM, Smith, Kevin, (R&D) Vodafone Group wrote: >> Hi Brian, >> >> I think Mobile Throughput Guidance would be a good candidate for PLUS pa= th-to-endpoint signalling. The latest (albeit expired) MTG draft [1] is bou= nd to TCP Options, and was considering use of TCP-AO for authentication; PL= US could allow MTG for both TCP and UDP-based flows. However it seems that = proposed PLUS mechanism: >> >>>(1) For forward signaling, the sending endpoint must place "scratch spac= e" in the packet with a label on it stating that it's okay to modify; this = okay-to-modify state is enforced by a MAC which only verifies the length bu= t not the content of the scratch space. >> >> ...may not provide the guarantee that (1) the MTG information was indeed= injected by the cellular network and (2) that it has not been modified by = another node. Have I got that right? Or would such an authentication/integr= ity check applicable to path data be in scope of PLUS? >> >> Cheers, >> Kevin >> Vodafone R&D >> >> [1] >> https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidanc >> e-03.txt , expired >> > Hi Kevin, > > That is an interesting use case. Do you see any reason (other than maybe = current deployability) that these can't be done in HBH options instead of T= CP options? > > Thanks, > Tom > > >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud From nobody Wed Jun 29 17:04: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 1346D12D95C for ; Wed, 29 Jun 2016 17:04:48 -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 3fYkQebIckkr for ; Wed, 29 Jun 2016 17:04: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 EBD7E12D4FB for ; Wed, 29 Jun 2016 17:04:46 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u5U04AGU020825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jun 2016 17:04:10 -0700 (PDT) To: Tom Herbert , "Smith, Kevin, (R&D) Vodafone Group" References: From: Joe Touch Message-ID: <577461F8.4000003@isi.edu> Date: Wed, 29 Jun 2016 17:04: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: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u5U04AGU020825 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "Brian Trammell \(ietf@trammell.ch\)" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 00:04:48 -0000 On 6/29/2016 4:26 PM, Tom Herbert wrote: > ... > Probably down to forwarding performance too, as Hop-by-Hop must be processed by all network devices. And deployability as you say; because IPv6 is unfortunately not prevalent yet in mobile core networks... > > The first problem is being relaxed in 2460bis draft. It allows HBH to > be ignored by network devices, which should cover the case where there > are "too many options to parse" in a DOS attack. That doc recognizes that many devices do this, not that this is OK. It only recommends not defining *new* HBH EHs - and not even in 2119 language. It does not deprecate existing HBH EHs. Joe From nobody Wed Jun 29 17:33: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 9CBE612D98D for ; Wed, 29 Jun 2016 17:33: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 Rhnys6OXWv9V for ; Wed, 29 Jun 2016 17:33:23 -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 C262C12D986 for ; Wed, 29 Jun 2016 17:33:23 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id s63so57995153ioi.3 for ; Wed, 29 Jun 2016 17:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=INMh2FAnf2oW6lPzgkty2pvqr3BMKaDcrTyjcYrCESQ=; b=DV8FO718T7zMvOLM53IKfe1jrGKGGlpkIxeUDWzCK6VaHDN7kT7raOGkD6qvQvTziy b7XFURkk5Iy+2egiOPnH9Nn0QLGKgHHFqsiptOuOQ1sMLfFGQY7Ar5rrVM/uybIzYGJP Gn8zucZO/cZBi+in+QH97jftUaNIZnDh+BVBXG7o83QEF+jBZ/jYT3tdWPc6he90ALR0 Bvi/gPKfIcIVWio1DWOmHvu1OX025m8I4HMKH9Wc0NI4bjyX2bnXl+pKV3uvwOhgCI9C IDP4itO7OgFTzf7G0+KVAKnkT5VFAIj7kYRQ92CRKATuqQwFtcbX261YPSfLocUB/vB1 BSzA== 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=INMh2FAnf2oW6lPzgkty2pvqr3BMKaDcrTyjcYrCESQ=; b=MSg2EeCxI3/n48p81oI0YP+LOBORcikYhKbKzKTPgouht4UW4/VHQg/Mg3JhEW9ipU rHsNj0eANsrc/Zj95a1oWd1Xo+EDRwwKkpNdhVvTQp/l+qT7eKtfAyPZDdemBUk7SQXd 4R9qxFMnv5BKMrLvbichHitZo0iLiryJ8i1+LwTwXb4fxxL/W8Y/Nvpkv1PM+4oIcBUU 2kKB+EnVpfqN9/IbRdGWKyLqWa0SOUUDY3Yv+xvsn4JWx2XuRkWdKU3rtAV9BalLf0VV ouCvyM4QS0HgPPKBjLZ5NbByjb1/YYfFCTfEH/g8sLmO5jDyMsEvfAySUF7+jfDVMSoG nr4g== X-Gm-Message-State: ALyK8tIIj90U/CUi5mMGCS+FxCTPvdY5vftmgwTHK+W5xWvXLM6+k4FCIcMXOv1er/OB31kaZ8gH4gNKETIK1w== X-Received: by 10.107.11.26 with SMTP id v26mr13555198ioi.107.1467246803010; Wed, 29 Jun 2016 17:33:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Wed, 29 Jun 2016 17:33:22 -0700 (PDT) In-Reply-To: <577461F8.4000003@isi.edu> References: <577461F8.4000003@isi.edu> From: Tom Herbert Date: Wed, 29 Jun 2016 17:33:22 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Brian Trammell \(ietf@trammell.ch\)" , "Smith, Kevin, \(R&D\) Vodafone Group" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 00:33:25 -0000 On Wed, Jun 29, 2016 at 5:04 PM, Joe Touch wrote: > > > On 6/29/2016 4:26 PM, Tom Herbert wrote: >> ... >> Probably down to forwarding performance too, as Hop-by-Hop must be processed by all network devices. And deployability as you say; because IPv6 is unfortunately not prevalent yet in mobile core networks... >> >> The first problem is being relaxed in 2460bis draft. It allows HBH to >> be ignored by network devices, which should cover the case where there >> are "too many options to parse" in a DOS attack. > > That doc recognizes that many devices do this, not that this is OK. > Here is the wording that I believed was agreed on in 6man for next version of the 2460bis draft: "NOTE: While RFC2460 required that all nodes must process the Hop-by-Hop Options header, it is now expected that nodes only process the Hop-by-Hop Options header if explicitly configured to do so. Nodes that do not process or examine the Hop-by-Hop Options header must ignore it, and it must be passed on unchanged if forwarded." As I understand it, the use of "expected" here instead of "SHOULD" or "MAY" is necessary since 2460 is being proposed to become a full standard and the protocol behavior can't change in that process. But for all practical purposes this allows nodes to ignore HBH. Without this allowance HBH would never be deployable. Tom From nobody Thu Jun 30 02:33: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 F307512D1B3 for ; Thu, 30 Jun 2016 02:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGeKtOIfp-mq for ; Thu, 30 Jun 2016 02:33:38 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) (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 529E612D178 for ; Thu, 30 Jun 2016 02:33:37 -0700 (PDT) Received: from [85.158.136.83] by server-3.bemta-5.messagelabs.com id E8/4D-01915-077E4775; Thu, 30 Jun 2016 09:33:36 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRWlGSWpSXmKPExsVy+MWXdt385yX hBut2WVhsbHnHZrHowlNGi8uXHjFbrPszl8WBxaN37jRWjyVLfjJ57H6/lcXjyf6ZLAEsUayZ eUn5FQmsGZcWbWMrWCNa0ddr2sDYIdrFyMUhJLCXUeJ//xVGCGclo8TRz5PZIJzlTBKdtx9BZ TYxSlx+38XSxcjJwSbgKnF01x12EFtEwEHi3d6JYHFmgRiJGXMPMoHYwgIqEjMvL2OFqFGV6O +dAFUfJrHy3wpGEJsFKD5lxSqwel6BUInDu1dAbe5jlujetgisiFMgUOLo1pdgCxgFZCW+NK5 mhlgmLnHryXywZgkBAYkle84zQ9iiEi8f/wNazAFUoymxfpc+RLmixJTuh+wQuwQlTs58wjKB UXQWkkmzEDpmIemYhaRjASPLKkaN4tSistQiXUNDvaSizPSMktzEzBxdQwNTvdzU4uLE9NScx KRiveT83E2MwGhjAIIdjCvbnQ8xSnIwKYnyLnxcEi7El5SfUpmRWJwRX1Sak1p8iFGGg0NJgv fGU6CcYFFqempFWmYOMO5h0hIcPEoivL9A0rzFBYm5xZnpEKlTjIpS4rwPQBICIImM0jy4Nli qucQoKyXMywh0iBBPQWpRbmYJqvwrRnEORiVhXtFnQFN4MvNK4Ka/AlrMBLSYubQYZHFJIkJK qoGx/0lQrmK3059XotwX5E/3eutHtjU/S56sFLHbxTjpnYsmi9GujSX7DW/lh/x5UMJvPfH67 p8sohYWrxrF7H7HMfQVLz4Tz/FkxqcDsyNfyzSmRR+XXhF/7n6hTlfbzAllNSUZj/lNpgYyy4 W8WPioqagyWGHmISuTroK5wQJuX/NyXFjNLJRYijMSDbWYi4oTAZfflR8wAwAA X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-4.tower-36.messagelabs.com!1467279215!42682975!1 X-Originating-IP: [195.232.244.135] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22604 invoked from network); 30 Jun 2016 09:33:35 -0000 Received: from mailout03.vodafone.com (HELO mailout03.vodafone.com) (195.232.244.135) by server-4.tower-36.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 30 Jun 2016 09:33:35 -0000 Received: from mailint02.vodafone.com (mailint02.vodafone.com [195.232.244.199]) by mailout03.vodafone.com (Postfix) with ESMTP id 3rgDqz2VHwz17HLt; Thu, 30 Jun 2016 11:33:35 +0200 (CEST) Received: from mailint02.vodafone.com (localhost [127.0.0.1]) by mailint02.vodafone.com (Postfix) with ESMTP id 3rgDqz1Kk9zQwPd; Thu, 30 Jun 2016 11:33:35 +0200 (CEST) Received: from VOEXC05W.internal.vodafone.com (voexc05w.dc-ratingen.de [145.230.101.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint02.vodafone.com (Postfix) with ESMTPS id 3rgDqz1CVTzQr6y; Thu, 30 Jun 2016 11:33:35 +0200 (CEST) Received: from VOEXM17W.internal.vodafone.com ([169.254.1.75]) by VOEXC05W.internal.vodafone.com ([145.230.101.25]) with mapi id 14.03.0224.002; Thu, 30 Jun 2016 11:33:34 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: Tom Herbert , Joe Touch Thread-Topic: [Spud] endpoint control Thread-Index: AdHRKB6Rk1yBi0AtT2GnUMPMbLGi+gAKs4sAACVbQKAAGSXEgAABTfAAAAEFXgAAFtMyoA== Date: Thu, 30 Jun 2016 09:33:33 +0000 Message-ID: References: <577461F8.4000003@isi.edu> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Brian Trammell \(ietf@trammell.ch\)" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 09:33:41 -0000 VGhhbmtzIGZvciB0aGUgcG9pbnRlcnMgVG9tIGFuZCBKb2UgLSBnb29kIHRvIHNlZSBtb3JlIGRp cmVjdGlvbiBvbiBIQkguIEkgaG9sZCB0byBteSBpbml0aWFsIHBvaW50IGZvciBwcmFjdGljYWwg cmVhc29uczogUExVUyBpcyBhIHdvcnRoeSByZXNlYXJjaCBvcHRpb24gdW50aWwgSEJIIG9wdGlv bnMgYXJlIHJlc3BlY3RlZCBwcm9wZXJseSwgYW5kIChtb3JlIGltcG9ydGFudGx5KSBvcGVyYXRv cnMgY2FuIHN1cHBvcnQgSEJIIHZpYSBJUHY2IGFkb3B0aW9uLg0KDQpBbGwgYmVzdCwNCktldmlu DQoNClBTIFRvbSdzIEhCSCB0aHJlYWQgZm9yIHJlZmVyZW5jZTogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9pcHY2L2N1cnJlbnQvbXNnMjQ3MjkuaHRtbCANCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21AaGVy YmVydGxhbmQuY29tXSANClNlbnQ6IDMwIEp1bmUgMjAxNiAwMTozMw0KVG86IEpvZSBUb3VjaA0K Q2M6IFNtaXRoLCBLZXZpbiwgKFImRCkgVm9kYWZvbmUgR3JvdXA7IEJyaWFuIFRyYW1tZWxsIChp ZXRmQHRyYW1tZWxsLmNoKTsgc3B1ZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTcHVkXSBlbmRw b2ludCBjb250cm9sDQoNCk9uIFdlZCwgSnVuIDI5LCAyMDE2IGF0IDU6MDQgUE0sIEpvZSBUb3Vj aCA8dG91Y2hAaXNpLmVkdT4gd3JvdGU6DQo+DQo+DQo+IE9uIDYvMjkvMjAxNiA0OjI2IFBNLCBU b20gSGVyYmVydCB3cm90ZToNCj4+IC4uLg0KPj4gUHJvYmFibHkgZG93biB0byBmb3J3YXJkaW5n IHBlcmZvcm1hbmNlIHRvbywgYXMgSG9wLWJ5LUhvcCBtdXN0IGJlIHByb2Nlc3NlZCBieSBhbGwg bmV0d29yayBkZXZpY2VzLiBBbmQgZGVwbG95YWJpbGl0eSBhcyB5b3Ugc2F5OyBiZWNhdXNlIElQ djYgaXMgdW5mb3J0dW5hdGVseSBub3QgcHJldmFsZW50IHlldCBpbiBtb2JpbGUgY29yZSBuZXR3 b3Jrcy4uLg0KPj4NCj4+IFRoZSBmaXJzdCBwcm9ibGVtIGlzIGJlaW5nIHJlbGF4ZWQgaW4gMjQ2 MGJpcyBkcmFmdC4gSXQgYWxsb3dzIEhCSCB0byANCj4+IGJlIGlnbm9yZWQgYnkgbmV0d29yayBk ZXZpY2VzLCB3aGljaCBzaG91bGQgY292ZXIgdGhlIGNhc2Ugd2hlcmUgDQo+PiB0aGVyZSBhcmUg InRvbyBtYW55IG9wdGlvbnMgdG8gcGFyc2UiIGluIGEgRE9TIGF0dGFjay4NCj4NCj4gVGhhdCBk b2MgcmVjb2duaXplcyB0aGF0IG1hbnkgZGV2aWNlcyBkbyB0aGlzLCBub3QgdGhhdCB0aGlzIGlz IE9LLg0KPg0KSGVyZSBpcyB0aGUgd29yZGluZyB0aGF0IEkgYmVsaWV2ZWQgd2FzIGFncmVlZCBv biBpbiA2bWFuIGZvciBuZXh0IHZlcnNpb24gb2YgdGhlIDI0NjBiaXMgZHJhZnQ6DQoNCiJOT1RF OiBXaGlsZSBSRkMyNDYwIHJlcXVpcmVkIHRoYXQgYWxsIG5vZGVzIG11c3QgcHJvY2VzcyB0aGUg SG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciwgaXQgaXMgbm93IGV4cGVjdGVkIHRoYXQgbm9kZXMg b25seSBwcm9jZXNzIHRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyIGlmIGV4cGxpY2l0bHkg Y29uZmlndXJlZCB0byBkbyBzby4gTm9kZXMgdGhhdCBkbyBub3QgcHJvY2VzcyBvciBleGFtaW5l IHRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyIG11c3QgaWdub3JlIGl0LCBhbmQgaXQgbXVz dCBiZSBwYXNzZWQgb24gdW5jaGFuZ2VkIGlmIGZvcndhcmRlZC4iDQoNCkFzIEkgdW5kZXJzdGFu ZCBpdCwgdGhlIHVzZSBvZiAiZXhwZWN0ZWQiIGhlcmUgaW5zdGVhZCBvZiAiU0hPVUxEIiBvciAi TUFZIiBpcyBuZWNlc3Nhcnkgc2luY2UgMjQ2MCBpcyBiZWluZyBwcm9wb3NlZCB0byBiZWNvbWUg YSBmdWxsIHN0YW5kYXJkIGFuZCB0aGUgcHJvdG9jb2wgYmVoYXZpb3IgY2FuJ3QgY2hhbmdlIGlu IHRoYXQgcHJvY2Vzcy4gQnV0IGZvciBhbGwgcHJhY3RpY2FsIHB1cnBvc2VzIHRoaXMgYWxsb3dz IG5vZGVzIHRvIGlnbm9yZSBIQkguIFdpdGhvdXQgdGhpcyBhbGxvd2FuY2UgSEJIIHdvdWxkIG5l dmVyIGJlIGRlcGxveWFibGUuDQoNClRvbQ0K From nobody Thu Jun 30 08:33: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 4708212B010 for ; Thu, 30 Jun 2016 08:33: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 TZCWnhPfAt0g for ; Thu, 30 Jun 2016 08:33:41 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC2126579 for ; Thu, 30 Jun 2016 08:33:41 -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 746931A19BD; Thu, 30 Jun 2016 17:33:40 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AD6DB764-C9BC-46B7-9FC9-3810F311EC35"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <6B3B89C7-234E-4412-BD83-056A3C69483B@cisco.com> Date: Thu, 30 Jun 2016 17:33:40 +0200 Message-Id: <3558A391-8B03-469E-BFA6-67F6D23C4188@trammell.ch> References: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch> <6B3B89C7-234E-4412-BD83-056A3C69483B@cisco.com> To: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Smith, Kevin, \(R&D\) Vodafone Group" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 15:33:44 -0000 --Apple-Mail=_AD6DB764-C9BC-46B7-9FC9-3810F311EC35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Dan, (sorry it took me a while to get back to you here; need better email = AQM)... > On 28 Jun 2016, at 18:19, =F0=9F=94=93Dan Wing = wrote: >=20 >=20 > On 28-Jun-2016 05:20 am, Brian Trammell wrote: >>=20 >>> On 28 Jun 2016, at 12:41, Smith, Kevin, (R&D) Vodafone Group = wrote: >>>=20 >>> Hi Brian, >>>=20 >>> I think Mobile Throughput Guidance would be a good candidate for = PLUS path-to-endpoint signalling. The latest (albeit expired) MTG draft = [1] is bound to TCP Options, and was considering use of TCP-AO for = authentication; PLUS could allow MTG for both TCP and UDP-based flows. = However it seems that proposed PLUS mechanism: >>>=20 >>>> (1) For forward signaling, the sending endpoint must place "scratch = space" in the packet with a label on it stating that it's okay to = modify; this okay-to-modify state is enforced by a MAC which only = verifies the length but not the content of the scratch space. >>>=20 >>> ...may not provide the guarantee that (1) the MTG information was = indeed injected by the cellular network and (2) that it has not been = modified by another node. Have I got that right? >>=20 >> Correct. It doesn't provide that guarantee at all, by design. >>=20 >>> Or would such an authentication/integrity check applicable to path = data be in scope of PLUS? >>=20 >> As I see it now, not at first. The cases where the endpoint reliably = has an way to authenticate a middlebox are limited (though mobile access = networks are one such case), >=20 > How so? >=20 > -d Well, you need the endpoint to know which and what kinds of middleboxes = its traffic is likely to encounter on the way to the other endpoint. = There are three cases I can think of here: 1. An enterprise device can authenticate the enterprise firewall and/or = VPN gateway. 2. A mobile handset can authenticate infrastructure in the mobile access = network. 3. A server in a data center can authenticate infrastructure in the data = center network. (You could extend 1 to include home access networks as well, but getting = the in-home devices and the gateways to authenticate each other reliably = is an area that still needs some work to keep from being a giant = support-call generator.) In all three of these cases, the authentication relationship doesn't = cross an administrative domain boundary. In an Internet context, this is = what I mean by "limited". Note that it *doesn't* cover the case where a = data center server says something to the mobile access network, or the = handset and the server cooperate to say something to the same network, = because as soon as you cross the admin domain boundary the = device-to-device authentication problem quickly becomes intractable. Building a common framework for making this kind of authentication work = is a very interesting problem, and if PLUS designs a protocol correctly = this framework can run on top of PLUS. But I think it's a different = problem than the one PLUS is trying to solve. Cheers, Brian >> and IMO the mechanism should be as general as possible. >>=20 >> I will point out that integrity and authentication of information = from a middlebox where the sending endpoint can authenticate the = middlebox can trivially be implemented on top of this proposed = mechanism: the definition of the exposed information could be "content = plus MAC", where the MAC can be verified using the middlebox's = certificate. But these can be implemented in information elements atop = PLUS, without requiring additional support in the PLUS header. >>=20 >> In a mobile access network, on the upstream path this would look = like: >>=20 >> user terminal --[ PLUS mobile-foo: 00000000 ]--> access network --[ = PLUS mobile-foo CCCCCCMM ]--> server >>=20 >> (where mobile-foo is whatever you want the access network to be able = to say, 00000000 is scratch space, C is content and M is MAC.) >>=20 >> The server can act on the throughput guidance (should it choose to, = see spud-req 5.9), but since it's the user terminal that has a = relationship with the access network, the server may need to feed the = content and MAC back to the user terminal (see spud-req 5.5 and 6.4) for = verification. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>> Cheers, >>> Kevin >>> Vodafone R&D >>>=20 >>> [1] = https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance-03= .txt , expired >>>=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 >=20 --Apple-Mail=_AD6DB764-C9BC-46B7-9FC9-3810F311EC35 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 iQIcBAEBCgAGBQJXdTvUAAoJEIoSt78L6kajcGoP/2BJmhk1ffpoF3jGwRbHEOll /4kn+uXXIMFQ+C7pMuD7+usXB6OCDTjylA+TnHwkJboYC+2awD6+OiXnta8bVY+n ayGiJLigJoo0XOpCYxX7M7RaEmtGARJ8o/q72qGBttrWZZ+hUBSADtel7t6UqbeR S5+f2s5xMFr+05s9qyVIrhuFjXEnn+ILbyQoA8rlPrI4yrfFctFuX1XIVVrMIkuR OSia126XayaxKBCOtJiBUdTChG8eYnG8xXE/B9B2JqN2XWLxy2H6xDQkfBiRuInP Ouz+UotfclNBdbBcU8km+T1mDL4eeJSwFe9pU8dwYF+QpcstU/9Ovd+xzn+VIn4F 5GiZnMpa9himPT2ywX05MTwttaci1z4LngFxlPyPUH4lOqjWsUgOtuQhpewvaL8K q/D1vETAKkfpWeUmvoB+ocpG+wRyx5Vm8drZI6fbRJ/TwOaNpeRE5EklwV/U5Cr8 TBUM9zTQAnNA4+j0S0GpuZ507ld7y5ESQJVCSU4LQTmRy64+X0FuvWrhB034ori5 FgOppcs15uYfzLBsZ9i6FUxlHsxRclyvBtgL9qU29zO3sV2TMl11o763Tfvz20O9 cYuaImZ7vOmS/g9lap94ofPR2zKqkGM93pcKn1JYoCE7KuO9HwpEp1WKqV4AafgA wTINqQsci97udzwk0bqq =Cu32 -----END PGP SIGNATURE----- --Apple-Mail=_AD6DB764-C9BC-46B7-9FC9-3810F311EC35-- From nobody Thu Jun 30 10:41: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 E62AD12D935 for ; Thu, 30 Jun 2016 10:41: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 TqFeEgzjdZ-i for ; Thu, 30 Jun 2016 10:41:54 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F70012D1B9 for ; Thu, 30 Jun 2016 10:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6524; q=dns/txt; s=iport; t=1467308513; x=1468518113; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=WCPj3Cc3Zqp0vrlZgtz83OwGyUcA5yzh3VNyxdVk3ms=; b=fpcDx4q0cCDutxNojV2iyMmIot5apEl5+4PunyLpakpJGKREG3EufhRX OCyGhhMRR1S/ShTJu5SNnPv5wiG37+SlnW3oyeHh5JzXU80SvExc34TNz 4aPMmJTfwvnkpNXoZj9iSWf1XTwRKO3mPXAiA/uvPON+nA1oknspdPtSo A=; X-Files: signature.asc : 842 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUBQDVWHVX/4cNJK1bgz5WfblNgXwXD?= =?us-ascii?q?YVzAoE8ORMBAQEBAQEBZSeETAEBAQMBAQEBIARHBAcFCwkCDgoqAgInMAYTG4g?= =?us-ascii?q?NCA6WH50dkBEBAQEBAQEBAQEBAQEBAQEBAQEBAQEOCQWGKIF3CIJOhBIKBwEGg?= =?us-ascii?q?xcrgi8FiA+GZT6JWYMuixOJS4VfkAUfATSCDReBbBwyh30PF4EeAQEB?= X-IronPort-AV: E=Sophos;i="5.26,553,1459814400"; d="asc'?scan'208";a="291412942" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jun 2016 17:41:52 +0000 Received: from [10.41.56.88] ([10.41.56.88]) (authenticated bits=0) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5UHfpda015040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jun 2016 17:41:52 GMT Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C51A7F9D-2AD8-4091-BB9B-3141CB22B5D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <3558A391-8B03-469E-BFA6-67F6D23C4188@trammell.ch> Date: Thu, 30 Jun 2016 10:41:48 -0700 Message-Id: <2D94CFA8-0C4E-4167-86D8-2D36EF239B12@cisco.com> References: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch> <6B3B89C7-234E-4412-BD83-056A3C69483B@cisco.com> <3558A391-8B03-469E-BFA6-67F6D23C4188@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.3124) X-Authenticated-User: dwing Archived-At: Cc: "Smith, Kevin, \(R&D\) Vodafone Group" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 17:41:56 -0000 --Apple-Mail=_C51A7F9D-2AD8-4091-BB9B-3141CB22B5D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 30-Jun-2016 08:33 am, Brian Trammell wrote: >=20 > hi Dan, >=20 > (sorry it took me a while to get back to you here; need better email = AQM)... >=20 >> On 28 Jun 2016, at 18:19, =F0=9F=94=93Dan Wing = wrote: >>=20 >>=20 >> On 28-Jun-2016 05:20 am, Brian Trammell wrote: >>>=20 >>>> On 28 Jun 2016, at 12:41, Smith, Kevin, (R&D) Vodafone Group = wrote: >>>>=20 >>>> Hi Brian, >>>>=20 >>>> I think Mobile Throughput Guidance would be a good candidate for = PLUS path-to-endpoint signalling. The latest (albeit expired) MTG draft = [1] is bound to TCP Options, and was considering use of TCP-AO for = authentication; PLUS could allow MTG for both TCP and UDP-based flows. = However it seems that proposed PLUS mechanism: >>>>=20 >>>>> (1) For forward signaling, the sending endpoint must place = "scratch space" in the packet with a label on it stating that it's okay = to modify; this okay-to-modify state is enforced by a MAC which only = verifies the length but not the content of the scratch space. >>>>=20 >>>> ...may not provide the guarantee that (1) the MTG information was = indeed injected by the cellular network and (2) that it has not been = modified by another node. Have I got that right? >>>=20 >>> Correct. It doesn't provide that guarantee at all, by design. >>>=20 >>>> Or would such an authentication/integrity check applicable to path = data be in scope of PLUS? >>>=20 >>> As I see it now, not at first. The cases where the endpoint reliably = has an way to authenticate a middlebox are limited (though mobile access = networks are one such case), >>=20 >> How so? >>=20 >> -d >=20 > Well, you need the endpoint to know which and what kinds of = middleboxes its traffic is likely to encounter on the way to the other = endpoint. There are three cases I can think of here: >=20 > 1. An enterprise device can authenticate the enterprise firewall = and/or VPN gateway. >=20 > 2. A mobile handset can authenticate infrastructure in the mobile = access network. >=20 > 3. A server in a data center can authenticate infrastructure in the = data center network. >=20 > (You could extend 1 to include home access networks as well, but = getting the in-home devices and the gateways to authenticate each other = reliably is an area that still needs some work to keep from being a = giant support-call generator.) >=20 > In all three of these cases, the authentication relationship doesn't = cross an administrative domain boundary. In an Internet context, this is = what I mean by "limited". Note that it *doesn't* cover the case where a = data center server says something to the mobile access network, or the = handset and the server cooperate to say something to the same network, = because as soon as you cross the admin domain boundary the = device-to-device authentication problem quickly becomes intractable. >=20 > Building a common framework for making this kind of authentication = work is a very interesting problem, Yes. I was hoping you had a solution. If we can solve that, we can = achieve secure DHCP, among other things. -d > and if PLUS designs a protocol correctly this framework can run on top = of PLUS. But I think it's a different problem than the one PLUS is = trying to solve. >=20 > Cheers, >=20 > Brian >=20 >>> and IMO the mechanism should be as general as possible. >>>=20 >>> I will point out that integrity and authentication of information = from a middlebox where the sending endpoint can authenticate the = middlebox can trivially be implemented on top of this proposed = mechanism: the definition of the exposed information could be "content = plus MAC", where the MAC can be verified using the middlebox's = certificate. But these can be implemented in information elements atop = PLUS, without requiring additional support in the PLUS header. >>>=20 >>> In a mobile access network, on the upstream path this would look = like: >>>=20 >>> user terminal --[ PLUS mobile-foo: 00000000 ]--> access network --[ = PLUS mobile-foo CCCCCCMM ]--> server >>>=20 >>> (where mobile-foo is whatever you want the access network to be able = to say, 00000000 is scratch space, C is content and M is MAC.) >>>=20 >>> The server can act on the throughput guidance (should it choose to, = see spud-req 5.9), but since it's the user terminal that has a = relationship with the access network, the server may need to feed the = content and MAC back to the user terminal (see spud-req 5.5 and 6.4) for = verification. >>>=20 >>> Cheers, >>>=20 >>> Brian >>>=20 >>>> Cheers, >>>> Kevin >>>> Vodafone R&D >>>>=20 >>>> [1] = https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance-03= .txt , expired >>>>=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 >>=20 >=20 --Apple-Mail=_C51A7F9D-2AD8-4091-BB9B-3141CB22B5D4 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 iQIcBAEBCgAGBQJXdVngAAoJEA4QP55CjCAkte4P/2/X8+C+T9SStPCA+6NKc4y5 o+MH5ke552sDziNFgt1+/E7XZZBOxMVIB+2P0RsTrvnDEeqXujAPrpLmMewTGVVU Jkn5A8rwv+awRWsOtSTzELuRcVhdlUIrE9Z8t1mtveFecnMlAmXmtUiG+itZsPNT qdOVRmWYV4a1jZESWFrhV2Wd0c/T4QGX4frrwOI4pQAmakDttlcCQo8X2eFS9Mr7 y59TrWTRKrVbvg9y8+cqAXNnQuVF5XQGwcwI4ofv3GSzvJQ7kebWjSnz4zxcAa29 vZdbyhym4mRZ8yRfN22da/Y5C2oI2PRK7vfjDp6N+/MdI2y3uVURTxqRmjMwbw1d v8yIWY2ifwy8eoTR6EWnbgzEMbPTpHnNbBHpekDmIpILEtLxMkGcCBwaC1mTgIxM nxtKRrvTevYMgBiL2U2HEC19PotcNlgnG1dgbDxxOVturhrnHH8rJ2TCRzT39gnX U31w0ooiBSegmfUxtvcwO3ewr3B9lHQOCK1NClpcfbIiuB+pguKt7FutMnPkuAQ9 iGQ8fJZgeRK+0oNSrC6QlQSqr0bf6QM+0hkS1Wvy0n55QxLuAzL3Ix6cWHM+ivyi qD7Dv7BJG0uyQ9QhcJ+8k/5+LV7Z7mI3l/1yp2iDDhqN9Jywmw4fwBUTmj/huxX1 lQfkSallYo3owD74o9mU =qNcs -----END PGP SIGNATURE----- --Apple-Mail=_C51A7F9D-2AD8-4091-BB9B-3141CB22B5D4-- From nobody Thu Jun 30 11:11: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 31E7212D95E for ; Thu, 30 Jun 2016 11:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XdJYQMUlJyR for ; Thu, 30 Jun 2016 11:11:32 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 BB95E12D94A for ; Thu, 30 Jun 2016 11:11:32 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id a5so157296881ita.1 for ; Thu, 30 Jun 2016 11:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mVNdVaCFokQHEK1tmjk//SVx6S/wWC1F8ULChYLWSkY=; b=Hkq5SUY2npuMW9pUncHUgCoVZCa55mBq1BZ4rqeXlJKWeLpKbay8w04BHzA8tN9i4D t+UYGUVZHUNkynnQsjw/WwqI+2LrrmMycqy5jB8t0caPsKyRSoygXAAP5P6bmAJ6lxhu UioLWPTY+Vn4+ODeLs1g6xzI02YTiEX6qy2iEDwaJ+bKDuRaHGfwvmiYC2Ra9rxqZb4k Zrl4h5YNPznJYyHMZgncIOHgFZliEriwoD3Tvg6hQ/Lo7HVD30uaHJJAJA7AXi11Cwj0 zicy8Cohb+XP0aHhbNk32fbz5miWmroaKGlha7G7Q4ifp8DeNvs7RUYakblxlH2NJzMN GByQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mVNdVaCFokQHEK1tmjk//SVx6S/wWC1F8ULChYLWSkY=; b=AtIACjPhueVkTZS9PzbbyTme9hSYssyWx7Cy1SE6k6Xfk7A6m/y1LsSzPFvoywt8F8 pyiQMYrDOtmzfteFfTPGeQ8t+UT9s9EwdvtoGbZhoKX0CXyfZvFi5ssDmFZdE7ImwSBF gZkID+zAoE5GXI5aauLIrEi3P3Wvt3NJvBAyTWqRIneCQ0fkPFVMyzO9N9A7wnjoOBtD 5ir/HQolHd7vEV7rQzW8UbOFOTWeo7FMyGyc8pE3wBNJCXEH7TBWUhxKug2VvpxpSfeS IZ20vST1YTgdIAYPClS4KPFNRRI3npHzaOS8IudUWcxHE0K0P87OyMk+Ba6L+pAdW807 z3Jg== X-Gm-Message-State: ALyK8tLw3vbyxjZs97LBAJ8MHRkqEw03gg8QL6h6q/J2s4f1ZXMygcy1nVApmVh2Mbxbyy2H9MP0E5rEUNe7rg== X-Received: by 10.36.22.195 with SMTP id a186mr17512086ita.37.1467310291859; Thu, 30 Jun 2016 11:11:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Thu, 30 Jun 2016 11:11:31 -0700 (PDT) In-Reply-To: <2D94CFA8-0C4E-4167-86D8-2D36EF239B12@cisco.com> References: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch> <6B3B89C7-234E-4412-BD83-056A3C69483B@cisco.com> <3558A391-8B03-469E-BFA6-67F6D23C4188@trammell.ch> <2D94CFA8-0C4E-4167-86D8-2D36EF239B12@cisco.com> From: Tom Herbert Date: Thu, 30 Jun 2016 11:11:31 -0700 Message-ID: To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Trammell , "Smith, Kevin, \(R&D\) Vodafone Group" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 18:11:35 -0000 On Thu, Jun 30, 2016 at 10:41 AM, =F0=9F=94=93Dan Wing wr= ote: > > On 30-Jun-2016 08:33 am, Brian Trammell wrote: >> >> hi Dan, >> >> (sorry it took me a while to get back to you here; need better email AQM= )... >> >>> On 28 Jun 2016, at 18:19, =F0=9F=94=93Dan Wing wrote: >>> >>> >>> On 28-Jun-2016 05:20 am, Brian Trammell wrote: >>>> >>>>> On 28 Jun 2016, at 12:41, Smith, Kevin, (R&D) Vodafone Group wrote: >>>>> >>>>> Hi Brian, >>>>> >>>>> I think Mobile Throughput Guidance would be a good candidate for PLUS= path-to-endpoint signalling. The latest (albeit expired) MTG draft [1] is = bound to TCP Options, and was considering use of TCP-AO for authentication;= PLUS could allow MTG for both TCP and UDP-based flows. However it seems th= at proposed PLUS mechanism: >>>>> >>>>>> (1) For forward signaling, the sending endpoint must place "scratch = space" in the packet with a label on it stating that it's okay to modify; t= his okay-to-modify state is enforced by a MAC which only verifies the lengt= h but not the content of the scratch space. >>>>> >>>>> ...may not provide the guarantee that (1) the MTG information was ind= eed injected by the cellular network and (2) that it has not been modified = by another node. Have I got that right? >>>> >>>> Correct. It doesn't provide that guarantee at all, by design. >>>> >>>>> Or would such an authentication/integrity check applicable to path da= ta be in scope of PLUS? >>>> >>>> As I see it now, not at first. The cases where the endpoint reliably h= as an way to authenticate a middlebox are limited (though mobile access net= works are one such case), >>> >>> How so? >>> >>> -d >> >> Well, you need the endpoint to know which and what kinds of middleboxes = its traffic is likely to encounter on the way to the other endpoint. There = are three cases I can think of here: >> >> 1. An enterprise device can authenticate the enterprise firewall and/or = VPN gateway. >> >> 2. A mobile handset can authenticate infrastructure in the mobile access= network. >> >> 3. A server in a data center can authenticate infrastructure in the data= center network. >> >> (You could extend 1 to include home access networks as well, but getting= the in-home devices and the gateways to authenticate each other reliably i= s an area that still needs some work to keep from being a giant support-cal= l generator.) >> >> In all three of these cases, the authentication relationship doesn't cro= ss an administrative domain boundary. In an Internet context, this is what = I mean by "limited". Note that it *doesn't* cover the case where a data cen= ter server says something to the mobile access network, or the handset and = the server cooperate to say something to the same network, because as soon = as you cross the admin domain boundary the device-to-device authentication = problem quickly becomes intractable. >> >> Building a common framework for making this kind of authentication work = is a very interesting problem, > The also would be a nice way to define domains of information exposure. For instance, in the case of a mobile client talking to its network there seems to be a case for beneficial, granular, possibly domain specific signaling. But as packets leave the trusted domain I don't believe we arbitrarily want to expose such localized information to the outside world. Even if it's authenticated this still would be exposing potentially sensitive information to untrusted parties. For example, if my mobile carrier gives me a deal on optimizing cat videos I might trust them enough and believe there is enough benefit to mark packets as carrying cat videos; but I wouldn't want to do this if it means blabbing to the whole Internet that I'm watching cat videos. Tom > Yes. I was hoping you had a solution. If we can solve that, we can achi= eve secure DHCP, among other things. > > -d > > >> and if PLUS designs a protocol correctly this framework can run on top o= f PLUS. But I think it's a different problem than the one PLUS is trying to= solve. >> >> Cheers, >> >> Brian >> >>>> and IMO the mechanism should be as general as possible. >>>> >>>> I will point out that integrity and authentication of information from= a middlebox where the sending endpoint can authenticate the middlebox can = trivially be implemented on top of this proposed mechanism: the definition = of the exposed information could be "content plus MAC", where the MAC can b= e verified using the middlebox's certificate. But these can be implemented = in information elements atop PLUS, without requiring additional support in = the PLUS header. >>>> >>>> In a mobile access network, on the upstream path this would look like: >>>> >>>> user terminal --[ PLUS mobile-foo: 00000000 ]--> access network --[ PL= US mobile-foo CCCCCCMM ]--> server >>>> >>>> (where mobile-foo is whatever you want the access network to be able t= o say, 00000000 is scratch space, C is content and M is MAC.) >>>> >>>> The server can act on the throughput guidance (should it choose to, se= e spud-req 5.9), but since it's the user terminal that has a relationship w= ith the access network, the server may need to feed the content and MAC bac= k to the user terminal (see spud-req 5.5 and 6.4) for verification. >>>> >>>> Cheers, >>>> >>>> Brian >>>> >>>>> Cheers, >>>>> Kevin >>>>> Vodafone R&D >>>>> >>>>> [1] https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-gu= idance-03.txt , expired >>>>> >>>>> _______________________________________________ >>>>> Spud mailing list >>>>> Spud@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spud >>>> >>>> _______________________________________________ >>>> Spud mailing list >>>> Spud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spud >>> >>> >> > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Thu Jun 30 13:56: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 954EF12D0A5 for ; Thu, 30 Jun 2016 13:56:15 -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 yYbLYtMOqkah for ; Thu, 30 Jun 2016 13:56:13 -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 B7BA312B017 for ; Thu, 30 Jun 2016 13:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6872; q=dns/txt; s=iport; t=1467320172; x=1468529772; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZTj8ICL1CrgFrDWjg8i0+O2MANtyiwVvK7AFSOBaYWo=; b=F3Mlp0/a54RQZlaF6Z3Hf6RyK8w5hOs9n441WkKhU0ZC53pkbY0xcZhr koTzG+J/tVcaSJyuFwDPEJwwLRGZ1wkUPUQwspgxDkXHHYNunZbLcrLO1 eUwxvSrBqX58d3jDFj4G2J7jRBxKOVkSPtai12ME840PP6cNYRJMzj4LR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEBQBShnVX/4UNJK1bgz5WfblNgXwXD?= =?us-ascii?q?YVzAoE8OhIBAQEBAQEBZSeETAEBAQMBAQEBIARABwQHEAkCGAICJgICJzAGExu?= =?us-ascii?q?IDQgOlladHZAXAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYUngXcIgk6EEgoHA?= =?us-ascii?q?QYWgwErgi8FiA+GZT6JWY5BCo8gkAUlCCeCDReBbBwyh30PF4EeAQEB?= X-IronPort-AV: E=Sophos;i="5.26,553,1459814400"; d="scan'208";a="292237528" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jun 2016 20:56:11 +0000 Received: from dhcp-10-155-84-125.cisco.com (dhcp-10-155-84-125.cisco.com [10.155.84.125]) (authenticated bits=0) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5UKuA40009526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jun 2016 20:56:11 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Thu, 30 Jun 2016 13:56:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch> <6B3B89C7-234E-4412-BD83-056A3C69483B@cisco.com> <3558A391-8B03-469E-BFA6-67F6D23C4188@trammell.ch> <2D94CFA8-0C4E-4167-86D8-2D36EF239B12@cisco.com> To: Tom Herbert X-Mailer: Apple Mail (2.3124) X-Authenticated-User: dwing Archived-At: Cc: Brian Trammell , "Smith, Kevin, \(R&D\) Vodafone Group" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 20:56:15 -0000 On 30-Jun-2016 11:11 am, Tom Herbert wrote: >=20 > On Thu, Jun 30, 2016 at 10:41 AM, =F0=9F=94=93Dan Wing = wrote: >>=20 >> On 30-Jun-2016 08:33 am, Brian Trammell wrote: >>>=20 >>> hi Dan, >>>=20 >>> (sorry it took me a while to get back to you here; need better email = AQM)... >>>=20 >>>> On 28 Jun 2016, at 18:19, =F0=9F=94=93Dan Wing = wrote: >>>>=20 >>>>=20 >>>> On 28-Jun-2016 05:20 am, Brian Trammell wrote: >>>>>=20 >>>>>> On 28 Jun 2016, at 12:41, Smith, Kevin, (R&D) Vodafone Group = wrote: >>>>>>=20 >>>>>> Hi Brian, >>>>>>=20 >>>>>> I think Mobile Throughput Guidance would be a good candidate for = PLUS path-to-endpoint signalling. The latest (albeit expired) MTG draft = [1] is bound to TCP Options, and was considering use of TCP-AO for = authentication; PLUS could allow MTG for both TCP and UDP-based flows. = However it seems that proposed PLUS mechanism: >>>>>>=20 >>>>>>> (1) For forward signaling, the sending endpoint must place = "scratch space" in the packet with a label on it stating that it's okay = to modify; this okay-to-modify state is enforced by a MAC which only = verifies the length but not the content of the scratch space. >>>>>>=20 >>>>>> ...may not provide the guarantee that (1) the MTG information was = indeed injected by the cellular network and (2) that it has not been = modified by another node. Have I got that right? >>>>>=20 >>>>> Correct. It doesn't provide that guarantee at all, by design. >>>>>=20 >>>>>> Or would such an authentication/integrity check applicable to = path data be in scope of PLUS? >>>>>=20 >>>>> As I see it now, not at first. The cases where the endpoint = reliably has an way to authenticate a middlebox are limited (though = mobile access networks are one such case), >>>>=20 >>>> How so? >>>>=20 >>>> -d >>>=20 >>> Well, you need the endpoint to know which and what kinds of = middleboxes its traffic is likely to encounter on the way to the other = endpoint. There are three cases I can think of here: >>>=20 >>> 1. An enterprise device can authenticate the enterprise firewall = and/or VPN gateway. >>>=20 >>> 2. A mobile handset can authenticate infrastructure in the mobile = access network. >>>=20 >>> 3. A server in a data center can authenticate infrastructure in the = data center network. >>>=20 >>> (You could extend 1 to include home access networks as well, but = getting the in-home devices and the gateways to authenticate each other = reliably is an area that still needs some work to keep from being a = giant support-call generator.) >>>=20 >>> In all three of these cases, the authentication relationship doesn't = cross an administrative domain boundary. In an Internet context, this is = what I mean by "limited". Note that it *doesn't* cover the case where a = data center server says something to the mobile access network, or the = handset and the server cooperate to say something to the same network, = because as soon as you cross the admin domain boundary the = device-to-device authentication problem quickly becomes intractable. >>>=20 >>> Building a common framework for making this kind of authentication = work is a very interesting problem, >>=20 > The also would be a nice way to define domains of information > exposure. For instance, in the case of a mobile client talking to its > network there seems to be a case for beneficial, granular, possibly > domain specific signaling. But as packets leave the trusted domain I > don't believe we arbitrarily want to expose such localized information > to the outside world. Even if it's authenticated this still would be > exposing potentially sensitive information to untrusted parties. For > example, if my mobile carrier gives me a deal on optimizing cat videos > I might trust them enough and believe there is enough benefit to mark > packets as carrying cat videos; but I wouldn't want to do this if it > means blabbing to the whole Internet that I'm watching cat videos. Yep, agreed that is all good and useful. Could be achieved "as easily = as" (1) a new DHCP option that indicates the key for that communication = with the local network. But that is a different trust model than what I = understood Brian was mentioning originally, though. (1) as in, this isn't the only piece missing. -d >=20 > Tom >=20 >=20 >=20 >> Yes. I was hoping you had a solution. If we can solve that, we can = achieve secure DHCP, among other things. >>=20 >> -d >>=20 >>=20 >>> and if PLUS designs a protocol correctly this framework can run on = top of PLUS. But I think it's a different problem than the one PLUS is = trying to solve. >>>=20 >>> Cheers, >>>=20 >>> Brian >>>=20 >>>>> and IMO the mechanism should be as general as possible. >>>>>=20 >>>>> I will point out that integrity and authentication of information = from a middlebox where the sending endpoint can authenticate the = middlebox can trivially be implemented on top of this proposed = mechanism: the definition of the exposed information could be "content = plus MAC", where the MAC can be verified using the middlebox's = certificate. But these can be implemented in information elements atop = PLUS, without requiring additional support in the PLUS header. >>>>>=20 >>>>> In a mobile access network, on the upstream path this would look = like: >>>>>=20 >>>>> user terminal --[ PLUS mobile-foo: 00000000 ]--> access network = --[ PLUS mobile-foo CCCCCCMM ]--> server >>>>>=20 >>>>> (where mobile-foo is whatever you want the access network to be = able to say, 00000000 is scratch space, C is content and M is MAC.) >>>>>=20 >>>>> The server can act on the throughput guidance (should it choose = to, see spud-req 5.9), but since it's the user terminal that has a = relationship with the access network, the server may need to feed the = content and MAC back to the user terminal (see spud-req 5.5 and 6.4) for = verification. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> Cheers, >>>>>> Kevin >>>>>> Vodafone R&D >>>>>>=20 >>>>>> [1] = https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance-03= .txt , expired >>>>>>=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 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >>=20 From nobody Thu Jun 30 14:05: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 CA37A12D0FD for ; Thu, 30 Jun 2016 14:05: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 jgmF9g--Dxxd for ; Thu, 30 Jun 2016 14:05:27 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 80F4D12D0F1 for ; Thu, 30 Jun 2016 14:05:27 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id DBEDC1A19C4; Thu, 30 Jun 2016 23:05:25 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4A827CD2-0CF5-4D1E-B979-19CB4C4C8EFF"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <2D94CFA8-0C4E-4167-86D8-2D36EF239B12@cisco.com> Date: Thu, 30 Jun 2016 23:05:25 +0200 Message-Id: <93BB2C6A-B3B1-4322-8047-F3FF67D16692@trammell.ch> References: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch> <6B3B89C7-234E-4412-BD83-056A3C69483B@cisco.com> <3558A391-8B03-469E-BFA6-67F6D23C4188@trammell.ch> <2D94CFA8-0C4E-4167-86D8-2D36EF239B12@cisco.com> To: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Smith, Kevin, \(R&D\) Vodafone Group" , "spud@ietf.org" Subject: Re: [Spud] endpoint control X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 21:05:30 -0000 --Apple-Mail=_4A827CD2-0CF5-4D1E-B979-19CB4C4C8EFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30 Jun 2016, at 19:41, =F0=9F=94=93Dan Wing = wrote: >=20 >=20 > On 30-Jun-2016 08:33 am, Brian Trammell wrote: >>=20 >> hi Dan, >>=20 >> (sorry it took me a while to get back to you here; need better email = AQM)... >>=20 >>> On 28 Jun 2016, at 18:19, =F0=9F=94=93Dan Wing = wrote: >>>=20 >>>=20 >>> On 28-Jun-2016 05:20 am, Brian Trammell wrote: >>>>=20 >>>>> On 28 Jun 2016, at 12:41, Smith, Kevin, (R&D) Vodafone Group = wrote: >>>>>=20 >>>>> Hi Brian, >>>>>=20 >>>>> I think Mobile Throughput Guidance would be a good candidate for = PLUS path-to-endpoint signalling. The latest (albeit expired) MTG draft = [1] is bound to TCP Options, and was considering use of TCP-AO for = authentication; PLUS could allow MTG for both TCP and UDP-based flows. = However it seems that proposed PLUS mechanism: >>>>>=20 >>>>>> (1) For forward signaling, the sending endpoint must place = "scratch space" in the packet with a label on it stating that it's okay = to modify; this okay-to-modify state is enforced by a MAC which only = verifies the length but not the content of the scratch space. >>>>>=20 >>>>> ...may not provide the guarantee that (1) the MTG information was = indeed injected by the cellular network and (2) that it has not been = modified by another node. Have I got that right? >>>>=20 >>>> Correct. It doesn't provide that guarantee at all, by design. >>>>=20 >>>>> Or would such an authentication/integrity check applicable to path = data be in scope of PLUS? >>>>=20 >>>> As I see it now, not at first. The cases where the endpoint = reliably has an way to authenticate a middlebox are limited (though = mobile access networks are one such case), >>>=20 >>> How so? >>>=20 >>> -d >>=20 >> Well, you need the endpoint to know which and what kinds of = middleboxes its traffic is likely to encounter on the way to the other = endpoint. There are three cases I can think of here: >>=20 >> 1. An enterprise device can authenticate the enterprise firewall = and/or VPN gateway. >>=20 >> 2. A mobile handset can authenticate infrastructure in the mobile = access network. >>=20 >> 3. A server in a data center can authenticate infrastructure in the = data center network. >>=20 >> (You could extend 1 to include home access networks as well, but = getting the in-home devices and the gateways to authenticate each other = reliably is an area that still needs some work to keep from being a = giant support-call generator.) >>=20 >> In all three of these cases, the authentication relationship doesn't = cross an administrative domain boundary. In an Internet context, this is = what I mean by "limited". Note that it *doesn't* cover the case where a = data center server says something to the mobile access network, or the = handset and the server cooperate to say something to the same network, = because as soon as you cross the admin domain boundary the = device-to-device authentication problem quickly becomes intractable. >>=20 >> Building a common framework for making this kind of authentication = work is a very interesting problem, >=20 > Yes. I was hoping you had a solution. Sadly, no. I do believe the problem can be scoped in such a way that a = useful solution is possible... but I don't know what it looks like. > If we can solve that, we can achieve secure DHCP, among other things. Yep. I think this is an entirely different problem, very much worth = tackling. A solution would mesh nicely with PLUS, but also be applicable = in situations where PLUS doesn't buy you anything (such as, as you say, = secure DHCP). Given that, I think it makes sense to carve out a facility in PLUS that = use this other solution to authenticate network elements would use. And = there, I think protected-presence, unprotected-content scratch space, = with encrypted feedback in case it's the wrong endpoint listening, is = the right way to go. Cheers, Brian > -d >=20 >=20 >> and if PLUS designs a protocol correctly this framework can run on = top of PLUS. But I think it's a different problem than the one PLUS is = trying to solve. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>>> and IMO the mechanism should be as general as possible. >>>>=20 >>>> I will point out that integrity and authentication of information = from a middlebox where the sending endpoint can authenticate the = middlebox can trivially be implemented on top of this proposed = mechanism: the definition of the exposed information could be "content = plus MAC", where the MAC can be verified using the middlebox's = certificate. But these can be implemented in information elements atop = PLUS, without requiring additional support in the PLUS header. >>>>=20 >>>> In a mobile access network, on the upstream path this would look = like: >>>>=20 >>>> user terminal --[ PLUS mobile-foo: 00000000 ]--> access network --[ = PLUS mobile-foo CCCCCCMM ]--> server >>>>=20 >>>> (where mobile-foo is whatever you want the access network to be = able to say, 00000000 is scratch space, C is content and M is MAC.) >>>>=20 >>>> The server can act on the throughput guidance (should it choose to, = see spud-req 5.9), but since it's the user terminal that has a = relationship with the access network, the server may need to feed the = content and MAC back to the user terminal (see spud-req 5.5 and 6.4) for = verification. >>>>=20 >>>> Cheers, >>>>=20 >>>> Brian >>>>=20 >>>>> Cheers, >>>>> Kevin >>>>> Vodafone R&D >>>>>=20 >>>>> [1] = https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance-03= .txt , expired >>>>>=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 >>>=20 >>=20 >=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_4A827CD2-0CF5-4D1E-B979-19CB4C4C8EFF 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 iQIcBAEBCgAGBQJXdYmVAAoJEIoSt78L6kajteUP/jdj+cTY9oXDO0bhNKJEsX27 Rv4XwZf5xIxTKMy+ooqPe9N8Y2QEMhWcZIbgWyxJOgwyR3s4ESFGOfehOqMunQt6 MqdxLFiNh+hXPwyGfVKKNF1t1WcmLwgRRicRBG5vmvVTP6j1IgEdqPaaZvmVBhmi 72ADFjoeojT0GSOq3PiB4O+b7gcuT2K8pZ27vkC4EjkLC30xeuPK0lzn8YhXWIFV 3j6nD1EIKiLW8Qfiy8iQoyKhqkX/5ebuO32QdJC12SNwCWtwB067YiNsAabsYAZe jjkjQtNytrgDtCXj1CLe81C+0LUxPsOttpuzjmaUF1wthM5m7ymthrGPIjLcwbfn PCvZxm0Qk0m7DuuVHvtt2DFGeAAhsUCqXmNlGh+HyL965vvuJmJ9Slc+uPuMdVg8 n8BKnKDYSCmQxQs/tlLDsP8vCXsflPW7ckgiAnUHZdSrfV2MpgCGIQC74j91eQqF FSvVnnF7Y2hh07rPw2C2G5TTy8+GKh+OeO80PDkK/ZiEHy6zP+2XUiSN0gQIUJnQ BNcJyP3QZO6n2hkUJO8gZ0zIjkZLMRR4bRjYDNewoaUMeEY308SECdmYO3OheY5/ LoJ2/J9PMuoGHJdMmzGiSL55kq3H65NmqrYJxU4hWusXE714yc8Zl9GqDV/mNSGr tlFxJhA6AblUgAYbh1Xq =qVFp -----END PGP SIGNATURE----- --Apple-Mail=_4A827CD2-0CF5-4D1E-B979-19CB4C4C8EFF--