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

[Caitlin Bestler <cait at asomi.com>]

On Sep 24, 2009, at 6:19 PM, Andrew Knutsen wrote:

>   I'll try to respond to all the issues raised today in this message:
>
> Caitlin Bestler wrote:
> > What is not clear is why the probe is based on OUI-specific secret  
> > handshakes.
>
>   This draft represents an effort to move technology which is  
> currently shipping from at least three vendors toward  
> standardization. The handshakes are currently not only "secret", but  
> use invalid option kinds.  This draft allows movement away from the  
> invalid kinds; getting all vendors to disclose and agree on the rest  
> is future effort, which would result in the OUI-less IANA-registered  
> types.  We could have put this "history" in the draft, but it didn't  
> seem appropriate.  I did include it in the last announcement.

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?

> > 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.

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

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?



--
Caitlin Bestler
cait at asomi.com
http://www.asomi.com/CaitlinBestlerResume.html