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

[Andrew Knutsen <[e-mail]>]

    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.

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

    The "R" bit is to detect hosts which misbehave, and reflect options 
back to the sender.  This does happen.

    Simultaneous opens have never been an issue because this is 
client/server technology. We can make this explicit.

    I can't comment on the security aspects right now because its not my 
area, but I'm sure we can add more info there. Perhaps one of my 
colleagues will answer ;-).

    We can add some information to section 7 if desired, but middleboxes 
typically run proprietary operating systems and thus the APIs are not 
standard...  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...

Andrew

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Andrew Knutsen
>> Sent: Thursday, August 13, 2009 2:52 PM
>> To: [e-mail]
>>
>>    Are there any comments on this draft?  We'd like to proceed ASAP, so
>> we can begin working the new option assignments into our protocols.
>>
>>     
>
>
> Here are some comments ...
>
> First, it's definitely good to see this kind of thing being brought for a
> proper number assignment rather than simply silently poaching one.
>
> Just from the abstract, I wasn't sure what "transparent detection" meant ...
> or if it should've been "detection of transparent middleboxes".  To me,
> "transparent detection" sounds like the detection itself is undetectable :).
>
> In terminology, should client and server really be described in terms of
> request/response or should it be based on TCP concepts like sending a SYN
> or being in LISTEN?
>
> Requests MUST have the "R" bit set to 0, and Responses MUST have the "R" bit
> set to 1 ... but Requests MUST be in a SYN packet ... so I guess I don't see
> what the R-bit is accomplishing that the ACK bit doesn't already.  If SYN-ACK
> is set, it's a response, and if SYN (but not ACK), then it's a request, right,
> or am I missing something?
>
> Does this need to think about simultaneous open at all ... it's probably a
> non-issue, but worth mentioning just to make sure the bases are covered.
>
> The security considerations isn't quite right specifically, as it doesn't
> distinguish between different modes or ESP/AH in IPsec that affect the
> option's visibility and protection.
>
> My biggest question, simply because I'm totally naive about these things is
> who will use it, and if they already have something like it that this is just
> formalizing and standardizing on.  Further, I'm guessing that there's some
> way that the data from this option gets shared outside the TCP implementation
> with the app, but I don't totally understand what the app is going to do with
> this knowledge.  I guess maybe section 7 (empty, currently) will discuss that?
> Sorry if everyone else knows this already and I'm just late to the party :).
>
> My overall take-away from a quick read is that it seems a bit like this is
> hacking something into TCP to assist applications in creating layer violations,
> and I don't quite understand the driving requirement or the benefits that can
> be gained by having it.  Maybe there are some references or further discussion
> to be included to motivate the mechanism?
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: [phone]
> ---------------------------
>