Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063EB28C1F3 for ; Thu, 13 Aug 2009 12:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Naz7v6UO48e1 for ; Thu, 13 Aug 2009 12:59:23 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 6633928C121 for ; Thu, 13 Aug 2009 12:59:04 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7DJvDN9020089; Thu, 13 Aug 2009 12:58:54 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 12:58:08 -0700 Message-ID: <4A847050.7080007@bluecoat.com> Date: Thu, 13 Aug 2009 12:58:08 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" References: <4A775C60.7030204@bluecoat.com> <4A8460BE.1060105@bluecoat.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080701030009040807020407" X-OriginalArrivalTime: 13 Aug 2009 19:58:08.0013 (UTC) FILETIME=[60C783D0:01CA1C50] Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh Subject: Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery X-BeenThere: tcpm@ietf.org 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:59:25 -0000 This is a multi-part message in MIME format. --------------080701030009040807020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >> Andrew Knutsen >> Sent: Thursday, August 13, 2009 2:52 PM >> To: tcpm@ietf.org >> >> 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 > --------------------------- > --------------080701030009040807020407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    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: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
Andrew Knutsen
Sent: Thursday, August 13, 2009 2:52 PM
To: tcpm@ietf.org

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

--------------080701030009040807020407--