Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available

[Andrew Knutsen <andrew.knutsen at bluecoat.com>]

Caitlin Bestler wrote:
> TCP options are a limited resource. There is a strong rationale for 
> their use here, because there is no other mechanism
> that ensures that the probe packet will follow the same path as the 
> TCP flow. But limiting the standardization to only the
> basic wrapper makes no sense.
>
> Why not also define a "common" OUI which would have standard 
> vendor-independent queries, such as a basic TTL
> dependent probe that can at least enumerate what all of the 
> option-aware middle boxes are?

   Thats the purpose of the form with the P (Private) bit set to 0, 
where the device type is IANA registered and there is no OUI.  Or am I 
missing something here?

> > > 1) Why not simply probe for "first middlebox that sees this once the 
> > > TTL is less than or equal to X"?
> > >     That would enable discovering all middleboxes that understood 
> > > this option, no matter who
> > >     made them. Once identified SNMP can be used to obtain vendor 
> > > specific information.
> >
> >   - Generally, you want to probe for a specific type of device, which 
> > will pair with the originator.
>
> That may be your usage, but I think a more common usage would be to 
> probe what if any middle-boxes are involved on a path
> to help diagnose a probleem or perform a security audit.

   Then perhaps that would be a good first "standard" device type, 
basically "any device", with an action to both respond and forward.  No 
"target data" would be required in the request, and the response might 
contain an SNMP public community string or whatever.

> >   - Performance is a very important factor here.  SNMP adds delay, 
> > just like the other existing alternates mentioned in the draft.
>
> Exactly how can discovery of a middle-box be time critical? How many 
> times a second does a path change?

   The usual, current case is when you're trying to set up a 
compression tunnel.  In this topology, you have four devices: client, 
edge, core and server (the middle two are middleboxes). The edge 
intercepts a connection from the client, and wants to see if there is a 
core box in the path to the server.  However, if there isn't, the 
connection should not be delayed.

  This is described in the "terminology" section, and referenced later. 
We didn't want to go too far into use cases, but if the consensus is 
that the draft needs more in this area we'll add it.

> In any event, once a middle-box is discovered, is there any need to 
> continue to use the TCP-piggy-back to
> communicate with it?

  I'm not sure what your question is here.  After discovery the option 
is no longer used -- just regular connections.

Andrew