Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt

[Brian Trammell <[e-mail]>]

hi Patrick, all,

...in the hopes the conversation has not overtaken me, see inline below...

> On 10 Mar 2015, at 21:18, Patrick McManus <[e-mail]> wrote:
> 
> On Mon, Mar 9, 2015 at 6:05 PM, Ted Hardie <[e-mail]> wrote:
> So, I may need a whiteboard here, because the way I see this use case sharing a tube-id seems like a loss.
> 
> What I think you're saying is Client A (from 192.0.2.1) sends traffic toward service Z (at 203.0.113.1) .  The packet goes from A across a path until it reaches middlebox L (at 198.51.100.1) which dispatches​ it toward a backend server Z-15 (at 203.0.113.15) which would currently spoof 203.0.113.1.  This often forces L to maintain a map for the tuple in A's packets to the correct backend.  A tube-id would simplify this (since L could use it instead of a tuple).
> 
> ​What I hear you saying is that you'd prefer to allow Z-15 to emit a packet using its own IP address, rather than Z's, and have it be understood to be in the same flow by dint of it sharing the same tube-id.    This gives the tube-id some serious security requirements that it doesn't currently (as an advisory bit) have.  Have I misunderstood you?   Do you want something different here?
> 
> "want" is such a strong word :) I'm just brainstorming.
> 
> There is a case where L doesn't want to be part of the flow after Z-15 is selected, but obviously it needs to be in a TCP scenario if for no other reason than to forward the ack traffic to Z-15 - the fact that it continues to be involved is really an artifact of the protocol - L isn't a typical on path middlebox; but spuds is still interesting here for its interaction with something like a client side NAT. This is an ordered flow (a tube?) with 3 end points.
> 
> I don't really know that the tube-id itself takes on security requirements here, the transport running in the tube might have a totally self defined security and identification model independent of the tube-id - mobility leads you down that path naturally. (but yes - that's a hard problem :)). Is there a reason that gets bumped up to the spuds wrapper?

If we scope a tube ID to a five tuple, then it has some very nice properties. Since we're probably multiplexing significantly less than 2**64 tubes over a five tuple, the currently-active tube ID space is extremely sparse, and if the tube ID is sufficiently random, it is hard enough to guess them that we can presume that anyone that has the ID of a given tube is one of the endpoints, is on path, or is cooperating with a device on path. This is a property we need in any case in which we're requiring middleboxes to spoof endpoints, which itself will be necessary for NAT traversal.

Further, the five tuple has really become the state lookup key in each domain of routability in which its IP addresses are valid. So if the session ID is scoped to this key, it never has to be rewritten or otherwise handled by the middleboxes *other* than to bind a group of packets together so some common properties can be assigned to them.

If you use the tube ID for mobility -- i.e., to cover the "my endpoint address changed, but my session is the same" case, which I very much wanted to use it for when kicking this idea around much earlier -- now the scope is different, and all this gets much messier. The tube ID has to be chosen by the initiating endpoint, which in a mobile-client world is often the endpoint whose address may change, so scoping to the three-tuple of the fixed-address side of the connection brings with it a coordination problem -- and negotiation / decollision of tube IDs adds complexity and roundtrips, both of which are to be avoided.

Of course you could fix that problem by scoping the tube ID to the entire Internet, but this would (1) need way more bits, (2) probably need decollision anyway, and (3) has less than optimal (read: "terrifying") privacy implications for trackability etc.

What I can see being useful here is a facility built in to the "core" spud vocabulary that says "this tube is related to some other tube, here's the ID", for a small set of values of "related". This is more a signal to the remote endpoint than the path, though, so it's not clear it needs to be exposed in SPUD. One tube ID linkage that would need to be exposed to the path is "prefer to drop packets in this tube before packets in tube ID x" or "prefer to forward packets in tube ID x before packets in this tube", which gives you a nice simple vocabulary for expressing almost everything you need to for differential QoS from a given source without allowing global marking with all its attendant mark inflation problems.

Of course, since everything along the path and everything cooperating with everything along the path knows the tube id, any tube linkage features probably have implications for spoofing we'll need to be careful about.

Cheers,

Brian