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

["Eddy, Wesley M. (GRC-MS00)[Verizon]" <[e-mail]>]

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