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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 788093A6D59 for <>; Thu, 13 Aug 2009 12:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.34
X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JR4BXZgcWghg for <>; Thu, 13 Aug 2009 12:40:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9794A3A6D53 for <>; Thu, 13 Aug 2009 12:40:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 785A82D8172; Thu, 13 Aug 2009 14:40:33 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id n7DJeX4V002953; Thu, 13 Aug 2009 14:40:33 -0500
Received: from ([]) by ([]) with mapi; Thu, 13 Aug 2009 14:40:33 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <>
To: Andrew Knutsen <>, "" <>
Date: Thu, 13 Aug 2009 14:40:31 -0500
Thread-Topic: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery
Thread-Index: AcocRzAqllodToj0QIynnblhzNXSRwAAraPQ
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 19:40:36 -0000

>-----Original Message-----
>From: [] On Behalf Of
>Andrew Knutsen
>Sent: Thursday, August 13, 2009 2:52 PM
>    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: (216) 433-6682