From nobody Wed Oct 14 12:17:04 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9411A1B74 for ; Wed, 14 Oct 2015 12:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXu0CsTkRZ5j for ; Wed, 14 Oct 2015 12:17:01 -0700 (PDT) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) (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 7684B1A21BA for ; Wed, 14 Oct 2015 12:17:01 -0700 (PDT) Received: by iodv82 with SMTP id v82so66395393iod.0 for ; Wed, 14 Oct 2015 12:17:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=z7uQVHbtwEu6wOGYUE+SzBRdeiASCVhp8IFg4R4Xf1U=; b=iaeLh6V5zCxioVo9pndgC/i37dhcM/nazqqrTFchzF8/KYjY03XdwqfsqmKWuBa87l k+a774ZmgLVmWXzk7eZhlJw5HSZHleeUNXauYpM3Z7L1iSLzyWP2M9Wl0ayHvi+YvVhR dK/gSLqgtYkmJ7sXPz2WjDSva9e10h5bgT1mMO9FD5iR5jU586XCWILpDx0FmW5uNkN2 Tq1RmO6aE45H8GhdOBMs+oPtimKsQLJSB9gCWKmKfmSkHT4A+jsDqFC215z3Bi+jSQtx nePwg0cohXMcRjJOal948mazywXvgfmIBMc4BvS2RhawIB+bji8Aj+3u6jYwyp3GMjHr ln8w== X-Gm-Message-State: ALoCoQl7PiYswoyS+/B+trTZsw1/2MqZVu9JmVWTXu9Fb8kbQqT3bSD8D+xt8kKoJb4QYlZ9LYJo MIME-Version: 1.0 X-Received: by 10.107.31.148 with SMTP id f142mr2873530iof.84.1444850220734; Wed, 14 Oct 2015 12:17:00 -0700 (PDT) Received: by 10.107.25.74 with HTTP; Wed, 14 Oct 2015 12:17:00 -0700 (PDT) Date: Wed, 14 Oct 2015 12:17:00 -0700 Message-ID: From: Tom Herbert To: spud@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Spud] SPUD meeting in Yokohama? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 19:17:02 -0000 Hello, Will there be a SPUD meeting of some sort in Yokohama? Thanks, Tom From nobody Thu Oct 15 02:17:05 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C46F1A8901 for ; Thu, 15 Oct 2015 02:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c86en9T2UxsP for ; Thu, 15 Oct 2015 02:17: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 418611A8920 for ; Thu, 15 Oct 2015 02:17:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D5152D930A; Thu, 15 Oct 2015 11:17:00 +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 F2MqHrjTjmmR; Thu, 15 Oct 2015 11:17:00 +0200 (MEST) Received: from [192.168.43.60] (unknown [93.49.252.64]) (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 8186ED9305; Thu, 15 Oct 2015 11:16:59 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 15 Oct 2015 09:41:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Herbert X-Mailer: Apple Mail (2.2102) Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD meeting in Yokohama? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 09:17:04 -0000 Hi Tom, we are currently working on updating the spud regs doc based on the = questions/discussions we had. We did not plan for a meeting at the = moment but if there is interest in discussing the reqs or anything else, = we can for sure set up a side meeting. Please let me know if there is = any interest by anybody in a meeting! The reason why we are currently not pushing this too much is that we do = not plan for a BoF in Yokohama nor Buenos Aires.=20 Mirja > Am 14.10.2015 um 21:17 schrieb Tom Herbert : >=20 > Hello, >=20 > Will there be a SPUD meeting of some sort in Yokohama? >=20 > Thanks, > Tom >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon Oct 19 06:30:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D271A1B1B for ; Mon, 19 Oct 2015 06:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsI510dzuJK4 for ; Mon, 19 Oct 2015 06:30:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0461A1AFC for ; Mon, 19 Oct 2015 06:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1131; q=dns/txt; s=iport; t=1445261423; x=1446471023; h=date:from:to:subject:message-id:references:mime-version: in-reply-to; bh=tj8/KZpHa5UR8FN+qTsiyL8gIHGLwovwUUAPMhr9xpA=; b=XNDATmoLgBr47KKAtRNHca+Y3oMgfDy3Ka15eHPRmj/zdl9fJwIcfTug n7P9a5sH2tPtLZ6vIlUdUaSeKyN7LLoVgWIySziE1aqxTl+bEnvHIUOG6 jBYpGo5taEYrh7ValDoQrR8MunNzYTx4tFzryObmMS/4Xmrb9vo0yFRoR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D8AQAg8CRW/4sNJK1egzZUb74OAQ2BWhcKhX0CgTc4FAEBAQEBAQGBCoQuAQEEAQEBNzQbCxgJJQ8FE0mIMA3DFQEBAQEBAQQBAQEBAQEBGASLdYUUF4QXBY4HiByNFQiBWIQ8jTuISR8BAUKCER2BdR40hWcBAQE X-IronPort-AV: E=Sophos;i="5.17,702,1437436800"; d="scan'208";a="42725916" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2015 13:30:22 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t9JDUMiO029301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Oct 2015 13:30:22 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t9JDULVg031768 for ; Mon, 19 Oct 2015 06:30:21 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t9JDULMF031767 for spud@ietf.org; Mon, 19 Oct 2015 06:30:21 -0700 Date: Mon, 19 Oct 2015 06:30:21 -0700 From: Toerless Eckert To: spud@ietf.org Message-ID: <20151019133021.GI14847@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Subject: Re: [Spud] SPUD meeting in Yokohama? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 13:30:24 -0000 An update would be nice, in whatever form during IETF week. On Thu, Oct 15, 2015 at 09:41:44AM +0200, Mirja K?hlewind wrote: > Hi Tom, > > we are currently working on updating the spud regs doc based on the questions/discussions we had. We did not plan for a meeting at the moment but if there is interest in discussing the reqs or anything else, we can for sure set up a side meeting. Please let me know if there is any interest by anybody in a meeting! > > The reason why we are currently not pushing this too much is that we do not plan for a BoF in Yokohama nor Buenos Aires. > > Mirja > > > > Am 14.10.2015 um 21:17 schrieb Tom Herbert : > > > > Hello, > > > > Will there be a SPUD meeting of some sort in Yokohama? > > > > Thanks, > > Tom > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Tue Oct 20 12:59:23 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F2F1AD378 for ; Tue, 20 Oct 2015 12:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqFEI0_a14OX for ; Tue, 20 Oct 2015 12:59:13 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 624451AD0EA for ; Tue, 20 Oct 2015 12:59:13 -0700 (PDT) Received: from [10.0.27.109] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 9254C1A030B; Tue, 20 Oct 2015 21:58:42 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_FEBDB6C7-5DD0-47B4-B6FC-1E6630A9AB00"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell Date: Tue, 20 Oct 2015 21:58:41 +0200 Message-Id: <0243038A-FE56-417D-AE71-0DA46A5A2FEB@trammell.ch> References: <20151019202940.26420.35311.idtracker@ietfa.amsl.com> To: spud@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Stackevo , stackevo-discuss@iab.org Subject: [Spud] Fwd: New Version Notification for draft-trammell-spud-req-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 19:59:15 -0000 --Apple-Mail=_FEBDB6C7-5DD0-47B4-B6FC-1E6630A9AB00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've submitted a new revision -01 of the SPUD requirements document, = following discussion in Prague and on the list in August (yes, it's = taken us quite a while to get back to this). We seem to be... slowly... = converging on a set of requirements here. In addition, we're collecting general architectural issues that would = effect *any* attempt to build explicit cooperation between endpoints and = on-path devices into a potential future IAB document, = draft-trammell-stackevo-explicit-coop. Our intention is that these two = documents evolve together, with explicit-coop being input to = architectural guidance and this requirements document input to future = protocol engineering efforts. One section (on in- versus out-of-band = signaling) which was pretty general has been largely moved into = explicit-coop. Otherwise, have a look at the diff to see what has = changed. There is one big open issue from the discussion in August, not really = addressed differently in -01 than in -00, which I'd like to try to = summarize (my view of) and see if we can converge on, related to the = scope of tube identifiers in multipath, multicast, and anycast = environments. For unicast on a single path without mobility, it seems pretty clear (to = me, at least) that tube identifiers should be scoped to a unidirectional = 5-tuple; i.e., that the reverse side of a flow has a different tube ID, = and that tube IDs need not be global. Unidirectional scope is made = necessary by asymmetric routing -- the set of devices relevant to a tube = in one direction is not the same as the set in the other. Local scope is = made necessary by privacy requirements -- the tube ID should not expose = information about the identity of the user unless the path actually = needs it, and global tube IDs would do that. There should be a facility for truly unidirectional traffic to expose = that one side of a bidirectional tube is related to the other side, but = this would be an explicit app to path declaration on tube setup. For multipath/mobility, obviously there is a need for there to be a = connection/session identifier to link 5-tuples to each other. But this = is clearly a different thing than the tube ID, for a couple of reasons: = (1) different paths of a multipath session might want to expose = different declarations to their paths; and (2) path declarations are = scoped to a tube as well, and the different paths of a multipath session = will themselves have different properties. What I think we need here is a separate session ID concept, which spans = multiple flows and indeed might span multiple tubes, and could be = exposed to the path using SPUD depending on whether or not it's in the = endpoint's interest to make the service quality vs. linkability = tradeoff. (Of course, multipath transports supporting mobility this way = could also use such a session ID inside the crypto veil, if there's no = win to sharing with the path. But they can't decide to do this if SPUD = mandates they use the tube ID in this way.) Multicast is a related problem. The simple solution seems to be to = pretend there *is* no problem, keep tube IDs scoped to the uni-5-tuple, = and simply say that path to application declarations are of limited = utility when the destination address is multicast. App to path still = works in this case. Making tube IDs unidirectional simplifies this. = Indeed, the main reason I don't advocate the "pretend there is no = problem" solution with multicast is that we tend to get into trouble = when we do so. The thread briefly touched on what SPUD can do for anycast -- letting = the path know that one particular tube setup "won" for instance. I think = this could definitely be a SPUD application, implemented with = application declarations and paths that take info from the tube ACK to = route that tube back along the path it came from, but enough needs to = happen to all the middleboxes and routers along the path in order to = make sessions "anycast-stable", that it's probably not a "core" feature. Thoughts? Thanks, cheers, Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-trammell-spud-req-01.txt > Date: 19 Oct 2015 22:29:40 CEST > To: "Mirja Kuehlewind" , "Brian = Trammell" >=20 >=20 > A new version of I-D, draft-trammell-spud-req-01.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Name: draft-trammell-spud-req > Revision: 01 > Title: Requirements for the design of a Substrate = Protocol for User Datagrams (SPUD) > Document date: 2015-10-19 > Group: Individual Submission > Pages: 16 > URL: = https://www.ietf.org/internet-drafts/draft-trammell-spud-req-01.txt > Status: = https://datatracker.ietf.org/doc/draft-trammell-spud-req/ > Htmlized: https://tools.ietf.org/html/draft-trammell-spud-req-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-trammell-spud-req-01 >=20 > Abstract: > The Substrate Protocol for User Datagrams (SPUD) BoF session at the > IETF 92 meeting in Dallas in March 2015 identified the potential = need > for a UDP-based encapsulation protocol to allow explicit cooperation > with middleboxes while using new, encrypted transport protocols. > This document proposes an initial set of requirements for such a > protocol, and discusses tradeoffs to be made in further refining > these requirements. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_FEBDB6C7-5DD0-47B4-B6FC-1E6630A9AB00 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 iQIcBAEBCgAGBQJWJpzyAAoJEIoSt78L6kaj0FUP/3kF9W/E+1ezq6gC+ufbKQ+Z PH5gnWNDqtCcepw2BQzcBjuFnG2QXS4yyJCU6SG5rAz6vJGH+58hjHVxwtt7beyN ardsO5I+usrF6k1TlLlwYOX5gJCfBCNiYjwD83m/L5SFPLoG0dB2Zf2/qr5gNov5 cQmz3eySRwemLaxVTZ4+HApdVhXw3bbenGbzYfn4Ttqkg9SzYx/LdowTvw9n39n9 Xt51PpX/2nG+cxAESTagwD0/9Dodc/sg8FqwFNr/YhziF2JB8iAYSGf22m8f01RB l7HAyOYJRY0bWfTPOe6TDq+dZqm4/IeXqGhoZehJ0yru6xLMHo+11JkhFrciSidB m3jmorvLYTRRqisRlA0tfxj1HYaBXFRnjrVwkIe26NqCj/Jr56g/M/RJB4cIU6TC GMis6dCOzePsTJvxU/KKi/BfriXR5WCDMBeGzxxyva98vB5p5vG9xvTY6rH/6gU8 mc6E8yBHHxUnLtE5cytxPMeK/W0U4Jf0yqVFFOMvKaQrRrIMH7NdT8Li8ysADxRP 736vYY3mdAkFo3udZ6buRKA/7+TkTNpg2XJFmIbMf/WfgoJSMBQ2KCjARfzydjDB sF0fEPK9bzzRXwxOWI9RDATprNEmc492Vs/yxD5KJkEoZ2klVQIHTv7qFXjSh8Eh Z1FP+nn9mrqNsfbVG0OX =WFot -----END PGP SIGNATURE----- --Apple-Mail=_FEBDB6C7-5DD0-47B4-B6FC-1E6630A9AB00-- From nobody Wed Oct 21 09:25:06 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358E91A1B21 for ; Wed, 21 Oct 2015 09:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xZ0d4tLjpVM for ; Wed, 21 Oct 2015 09:25:01 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (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 0953B1A6EE0 for ; Wed, 21 Oct 2015 09:24:59 -0700 (PDT) Received: by igbhv6 with SMTP id hv6so41524631igb.0 for ; Wed, 21 Oct 2015 09:24:58 -0700 (PDT) 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-type :content-transfer-encoding; bh=VtTmVtiit99BjEVlwTSjI41FpkSFwREvlCdFJEnuTWo=; b=jM9hF32/78HdOw/L/RPYvncmx7HWO5SZj/5TRcktOINqW1TYA2vsQwLIg6O1VZX4lh QoqllGLcMaZ7YIjxidzregVsVtHzIMoEzocZVZsGflLuf5G9m4JCJcGOaSaxcQyb+soL 1XdcaqabgtqJlpT1dNUUD83nKqyNQO2Lm/b9VsLVksrzd5JK5peMhZ9p5jIFJ+tkV7YI 7hWjGtlQsMFw6r/V7g8Z1pyPQak0Q9ltORTjz6BUf8ePg5ZxqmyvyovmrZJzn3BIHqtB wKZExajBq8AusfVoUKXXxlRNS10XsbgN721eP9XNeVZ8B21lLRT5Ya/qEJXYuZCfqAeQ iThw== X-Gm-Message-State: ALoCoQmx8OmvqaJiV5X2rB8lLQkSvO9PFhJul329bZ9B46vrMVQFkvwPngc7cLpF7jet74m/oimG MIME-Version: 1.0 X-Received: by 10.50.56.113 with SMTP id z17mr10929917igp.65.1445444698215; Wed, 21 Oct 2015 09:24:58 -0700 (PDT) Received: by 10.107.41.83 with HTTP; Wed, 21 Oct 2015 09:24:58 -0700 (PDT) In-Reply-To: <0243038A-FE56-417D-AE71-0DA46A5A2FEB@trammell.ch> References: <20151019202940.26420.35311.idtracker@ietfa.amsl.com> <0243038A-FE56-417D-AE71-0DA46A5A2FEB@trammell.ch> Date: Wed, 21 Oct 2015 09:24:58 -0700 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Stackevo , stackevo-discuss@iab.org, spud@ietf.org Subject: Re: [Spud] Fwd: New Version Notification for draft-trammell-spud-req-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 16:25:03 -0000 On Tue, Oct 20, 2015 at 12:58 PM, Brian Trammell wrote: > Greetings, all, > > We've submitted a new revision -01 of the SPUD requirements document, fol= lowing discussion in Prague and on the list in August (yes, it's taken us q= uite a while to get back to this). We seem to be... slowly... converging on= a set of requirements here. > > In addition, we're collecting general architectural issues that would eff= ect *any* attempt to build explicit cooperation between endpoints and on-pa= th devices into a potential future IAB document, draft-trammell-stackevo-ex= plicit-coop. Our intention is that these two documents evolve together, wit= h explicit-coop being input to architectural guidance and this requirements= document input to future protocol engineering efforts. One section (on in-= versus out-of-band signaling) which was pretty general has been largely mo= ved into explicit-coop. Otherwise, have a look at the diff to see what has = changed. > > There is one big open issue from the discussion in August, not really add= ressed differently in -01 than in -00, which I'd like to try to summarize (= my view of) and see if we can converge on, related to the scope of tube ide= ntifiers in multipath, multicast, and anycast environments. > > For unicast on a single path without mobility, it seems pretty clear (to = me, at least) that tube identifiers should be scoped to a unidirectional 5-= tuple; i.e., that the reverse side of a flow has a different tube ID, and t= hat tube IDs need not be global. Unidirectional scope is made necessary by = asymmetric routing -- the set of devices relevant to a tube in one directio= n is not the same as the set in the other. Local scope is made necessary by= privacy requirements -- the tube ID should not expose information about th= e identity of the user unless the path actually needs it, and global tube I= Ds would do that. > > There should be a facility for truly unidirectional traffic to expose tha= t one side of a bidirectional tube is related to the other side, but this w= ould be an explicit app to path declaration on tube setup. > > For multipath/mobility, obviously there is a need for there to be a conne= ction/session identifier to link 5-tuples to each other. But this is clearl= y a different thing than the tube ID, for a couple of reasons: (1) differen= t paths of a multipath session might want to expose different declarations = to their paths; and (2) path declarations are scoped to a tube as well, and= the different paths of a multipath session will themselves have different = properties. > > What I think we need here is a separate session ID concept, which spans m= ultiple flows and indeed might span multiple tubes, and could be exposed to= the path using SPUD depending on whether or not it's in the endpoint's int= erest to make the service quality vs. linkability tradeoff. (Of course, mul= tipath transports supporting mobility this way could also use such a sessio= n ID inside the crypto veil, if there's no win to sharing with the path. Bu= t they can't decide to do this if SPUD mandates they use the tube ID in thi= s way.) > > Multicast is a related problem. The simple solution seems to be to preten= d there *is* no problem, keep tube IDs scoped to the uni-5-tuple, and simpl= y say that path to application declarations are of limited utility when the= destination address is multicast. App to path still works in this case. Ma= king tube IDs unidirectional simplifies this. Indeed, the main reason I don= 't advocate the "pretend there is no problem" solution with multicast is th= at we tend to get into trouble when we do so. > > The thread briefly touched on what SPUD can do for anycast -- letting the= path know that one particular tube setup "won" for instance. I think this = could definitely be a SPUD application, implemented with application declar= ations and paths that take info from the tube ACK to route that tube back a= long the path it came from, but enough needs to happen to all the middlebox= es and routers along the path in order to make sessions "anycast-stable", t= hat it's probably not a "core" feature. > > Thoughts? > >From the introduction: "By notifying the path that a particular transport using UDP maintains session state and explicitly signals session start and stop using the substrate, the using protocol may reduce or avoid the need for heartbeat traffic." I think an important question might be rather 2WHS is sufficient, or 3WHS is going to be needed to mitigate DDOS attacks on stateful middleboxes (i.e. to avoid the SPUD equivalent of a SYN attack). Tom > Thanks, cheers, > > Brian > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-trammell-spud-req-01.txt >> Date: 19 Oct 2015 22:29:40 CEST >> To: "Mirja Kuehlewind" , "Brian Trammel= l" >> >> >> A new version of I-D, draft-trammell-spud-req-01.txt >> has been successfully submitted by Brian Trammell and posted to the >> IETF repository. >> >> Name: draft-trammell-spud-req >> Revision: 01 >> Title: Requirements for the design of a Substrate Protoco= l for User Datagrams (SPUD) >> Document date: 2015-10-19 >> Group: Individual Submission >> Pages: 16 >> URL: https://www.ietf.org/internet-drafts/draft-trammell-spud= -req-01.txt >> Status: https://datatracker.ietf.org/doc/draft-trammell-spud-req= / >> Htmlized: https://tools.ietf.org/html/draft-trammell-spud-req-01 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-trammell-spud-= req-01 >> >> Abstract: >> The Substrate Protocol for User Datagrams (SPUD) BoF session at the >> IETF 92 meeting in Dallas in March 2015 identified the potential need >> for a UDP-based encapsulation protocol to allow explicit cooperation >> with middleboxes while using new, encrypted transport protocols. >> This document proposes an initial set of requirements for such a >> protocol, and discusses tradeoffs to be made in further refining >> these requirements. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud >