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

[Caitlin Bestler <cait at asomi.com>]

On Sep 24, 2009, at 12:07 PM, Melinda Shore wrote:
> this is not that much like tunnel endpoint discovery.
>
> I like the idea of having some sort of in-band
> discovery mechanism but I'm not sure about tying
> it to TCP (although there's an implied requirement
> for a response, which you can't guarantee with, say,
> UDP or some other transports) and I'm really not
> sure about v4.
>
> Melinda


Doing the discovery in a TCP packet is the only way to
ensure that the packet will be routed/forwarded on the
same path as the actual TCP traffic.

Consider that A is sending a connection request into
cloud B for IP X, TCP Port Y.

Now suppose there is a middle-box guarding cloud B
which will divert connection requests for IP X:Port Y
to IP Z. Even without knowing of this special discovery
option, the B-entry middle-box will still divert the SYN
packet to IP Z. If either the endpoint or a later middle-box
understands the option there will be a Response.

But if you tried doing a non-TCP probe then the packet
will just continue on to the probably non-existent IP X,
or perhaps be diverted to a different catchall internal box.

This is actually true for *each* transport that wants to do
middle-box discovery, since the set of middle-boxes can
be different for each transport. Of course TCP middle-boxes
are far more worthy of discovery because historically they
tend to do more mischief/provide more services. By contrast,
if middle-boxes do anything with SCTP packets it is typically
to drop them or forward all of them to a default DMZ machine.


I think the key issue here is whether a mechanism can be
defined that will allow for discovery of any and all middle-boxes
that have support for the newly defined probe, even if there
are other forwarding nodes along the way that do not understand
the new option.

The OUI approach seems optimized for individual middle-box
vendors to do custom probing for their boxes. I do not think that
is a suitable strategy to be adopted as an RFC.



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