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

"Eddy, Wesley M. (GRC-MS00)[Verizon]" <> Thu, 13 August 2009 20:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AED3D3A67B6 for <>; Thu, 13 Aug 2009 13:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.369
X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ynqBqaVBBzok for <>; Thu, 13 Aug 2009 13:53:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 868493A6972 for <>; Thu, 13 Aug 2009 13:53:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BB8FF328563; Thu, 13 Aug 2009 15:23:40 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id n7DKNeuv002167; Thu, 13 Aug 2009 15:23:40 -0500
Received: from ([]) by ([]) with mapi; Thu, 13 Aug 2009 15:23:40 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <>
To: Andrew Knutsen <>
Date: Thu, 13 Aug 2009 15:23:38 -0500
Thread-Topic: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery
Thread-Index: AcocUIYfE3fVWiemRBKzsgBai+Q3PgAAQUdA
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-08-13_15:2009-08-11, 2009-08-13, 2009-08-13 signatures=0
Cc: Jamshid Mahdavi <>, Ron Frederick <>, Qing Li <>, "" <>, Wei Jen Yeh <>
Subject: Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Aug 2009 20:53:22 -0000

Ok; just a couple easy follow-up questions:

>-----Original Message-----
>From: Andrew Knutsen []
>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 ( for one example. This
>assignment will not change the basic operation of these WAN Optimization

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.

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

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

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

It seems reasonable to do so.

>    We can add some information to section 7 if desired, but middleboxes
>typically run proprietary operating systems and thus the APIs are not

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?

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?

>  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: (216) 433-6682