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

[Patrick McManus <[e-mail]>]

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?