Re: [Stackevo] [Spud] Fwd: New Version Notification for draft-trammell-spud-req-01.txt

On Tue, Oct 20, 2015 at 12:58 PM, Brian Trammell <ietf@trammell.ch> wrote:
> 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?
>

>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" <mirja.kuehlewind@tik.ee.ethz.ch>, "Brian Trammell" <ietf@trammell.ch>
>>
>>
>> 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 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=draft-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 submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>