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

[Andrew Knutsen <[e-mail]>]

    I'll put my responses inline this time... 

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> Ok; just a couple easy follow-up questions:
>
>   
>> -----Original Message-----
>> From: Andrew Knutsen [mailto:[e-mail]]
>> Sent: Thursday, August 13, 2009 3:58 PM
>>
>>    To answer your fundamental question, yes this is existing
>> technology, implemented by at least three companies for several years.
>> You can check our website (www.bluecoat.com) for one example. This
>> assignment will not change the basic operation of these WAN Optimization
>> products.
>>     
>
>
> Ok; so what option number do they use?  Do they all use the same one,
> or does each company pick its own?  How was the option format arrived
> at (is it just Bluecoat's or do all the vendors use their own variation)?
> I guess that's all just background information that's needed to put the
> effort in context.
>
>
>   
    We use one of the "experimental" numbers, 0xFD.  Cisco uses 0x21, 
and Riverbed uses both 0x4C and 0x4E. You can draw your own conclusions 
on how they were picked ;-). Although this info can be easily "sniffed", 
its probably not appropriate to put it in the draft. In fact, I'm not 
making any promises or representations about BlueCoats, or anyone 
else's, use or non-use of any of these or any other numbers in the 
future or the past.  I hope that keeps the lawyers happy.
>>    "Transparent detection" refers to the fact that there is no explicit
>> detection protocol; instead the detection is piggybacked on the TCP
>> connection transaction, which goes through to the OCS (as we say;
>> Original Content Server, the host explicitly addresses by the SYN
>> packet) if the connection is not intercepted.  Again, this is existing
>> multivendor practice, used for the reasons mentioned in the draft.
>>     
>
>
> Ah; so there's terminology confusion between calling a middlebox
> transparent (meaning without end-application/transport knowledge) and calling
> the detection transparent (meaning no extra packets sent).  I guess it would
> be more clear as "in-band detection"?
>
>
>   
    Well, our implementation is transparent in both ways..  although 
another vendor uses a slightly different transparent exchange, where 
extra packets are sent if a peer is detected.  The current proposal 
could be used for many of these mechanisms.  "In-band" doesn't really 
imply that the connection works if the middlebox is not present, does it?

    The word "transparent" is used fairly widely in the sense of no 
explicit configuration, although it can also refer to use of the same 
addresses on a tunnel connection as on the client and server connections 
(see below).

    Also, the "no extra packets" isn't a common use of the word, 
although one might consider it "transparent in time" ;-). Its just a 
real-world requirement.

>>    The "R" bit is to detect hosts which misbehave, and reflect options
>> back to the sender.  This does happen.
>>     
>
>
> Ick!  That makes sense, but it should be explicitly stated in the discussion
> of the R-bit if that's its full reason for existing, rather than only mentioned
> in passing in the interoperability issues section.
>
>   
    We felt that it is an interoperability issue, and discussing it 
earlier would detract from the discussion of the primary purpose.

>>    Simultaneous opens have never been an issue because this is
>> client/server technology. We can make this explicit.
>>     
>
>
> It seems reasonable to do so.
>   
    Will do.
>
>   
>>    We can add some information to section 7 if desired, but middleboxes
>> typically run proprietary operating systems and thus the APIs are not
>> standard...
>>     
>
>
> Right, but (correct this if I'm wrong ...) you have to also modify the
> TCP and application on the endpoints that initiate communications, right?
> Or will this only be intended for middlebox-to-middlebox?  I'm still
> trying to understand what an application does now that it knows something
> about the middlebox(es), what changes about its behavior?
>   
    Our use for this, which I think is the most common, if not the only 
use at present, is to set up "tunnels" as described in section 1. Since 
this draft is not a protocol spec, we didn't add detail about how these 
work.  However for the purpose of this discussion:

     There are usually four "boxes" involved when a tunnel (as described 
here) is used: the client and the server, which don't know anything 
about this option, and two middleboxes, which we may call the "edge" 
(near the client) and the "core" (near the server). However, it is 
possible for the edge function to be implemented in the client box. It 
is also possible to have multiple tunnels along a path, so one box is 
both edge and core. Server and core are less likely to be combined 
because that would add load to the server.

    Both the client and the edge can use either explicit or transparent 
connection methods. The simplest, and currently most common, use of this 
option is transparent detection of the core by the edge (ie to see if 
the server is fronted by a core box), for the purpose of setting up a 
tunnel between two middleboxes.

    Note that there are other kinds of "tunnels" which are really more 
like relays, in that there is only one middebox.  There are also tunnels 
where transparency is not appropriate, such as VPN tunnels. The tunnels 
I'm talking about are most often used for compression (aka WAN 
Optimization).

    I could add a lot of pictures to this, but at this level they're 
just series of boxes with lines between them ;-).

    Again, we didn't feel this level of background was appropriate for 
the draft, partly because we don't want to prejudice any future efforts 
towards protocol-level interoperability in this area, and partly for 
legal reasons (I haven't compromised myself here, I don't think, but if 
I went into more detail I might). However perhaps we could add a 
sentence saying "tunnels", as defined in the draft, are a primary use case.

> The draft is pretty good in explaining the format of the option itself,
> but doesn't really speak to how the knowledge the option conveys gets
> used productively.  As the application-writer, now that a know
> company X's gizmo 123 is in my path, how does that affect me versus
> not knowing it, or knowing that company Y's doohickey 456 is on the path?
>   
    In order to request interception by company X, you'd want to find 
out how they registered their option (OUI or IANA), and what particular 
info they want in the option. Then you'd need to know what to do if they 
responded. Also, you wouldn't really need this if you knew what was in 
the path (you'd likely use an explicit arrangement).

    However, if you were writing a server-side app and looking at all 
the options received, you'd at least know to ignore this option. Or, if 
you were writing a network monitoring tool, you could keep track of 
interception requests and responses. If you were writing a firewall, you 
could do policy on it.  Etc...

Andrew

>
>   
>>  And yes, WAN Optimization can be considered a layering
>> violation, along with most other security and load-balancing
>> middleboxes, but that won't make them go away...
>>     
>
>
> Fully understood and I don't disagree :).
>
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: [phone]
> ---------------------------
>