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

[Ted Hardie <[e-mail]>]

On Mon, Mar 9, 2015 at 2:37 PM, Joe Hildebrand (jhildebr) <
[e-mail]> wrote:

> On 3/6/15, 1:52 PM, "Patrick McManus" <[e-mail]> wrote:
>
> >
>
> >Fifthly, on the topic of whether tube-ids need a consistent 5 tuple, I
> think there are several cases where it would be nice if they didn't..  load
> balancers are a good example - a request is sent to a central service that
> parses it and dispatches it to
> > the best back end server.. historically that server needs to lie about
> its address somehow when sending the reply (either via proxy or more likely
> via spoofing - and if spoofed you need to figure out the ack traffic). It
> would be cool to have that all in one
> > tube with real addresses so the transport could decide how to deal with
> those issues.
>
>
I like the use case.
>
>

​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?

Ted​