Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery
"Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov> Thu, 13 August 2009 20:53 UTC
Return-Path: <wesley.m.eddy@nasa.gov>
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 AED3D3A67B6 for <tcpm@core3.amsl.com>; Thu, 13 Aug 2009 13:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.369
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynqBqaVBBzok for <tcpm@core3.amsl.com>; Thu, 13 Aug 2009 13:53:21 -0700 (PDT)
Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 868493A6972 for <tcpm@ietf.org>; Thu, 13 Aug 2009 13:53:21 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id BB8FF328563; Thu, 13 Aug 2009 15:23:40 -0500 (CDT)
Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n7DKNeuv002167; Thu, 13 Aug 2009 15:23:40 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Thu, 13 Aug 2009 15:23:40 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: Andrew Knutsen <andrew.knutsen@bluecoat.com>
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: <C304DB494AC0C04C87C6A6E2FF5603DB476E50BB5D@NDJSSCC01.ndc.nasa.gov>
References: <4A775C60.7030204@bluecoat.com> <4A8460BE.1060105@bluecoat.com> <C304DB494AC0C04C87C6A6E2FF5603DB476E50BAD9@NDJSSCC01.ndc.nasa.gov> <4A847050.7080007@bluecoat.com>
In-Reply-To: <4A847050.7080007@bluecoat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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 <jamshid.mahdavi@bluecoat.com>, Ron Frederick <ron.frederick@bluecoat.com>, Qing Li <qing.li@bluecoat.com>, "tcpm@ietf.org" <tcpm@ietf.org>, Wei Jen Yeh <weijen.yeh@bluecoat.com>
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=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 [mailto:andrew.knutsen@bluecoat.com] >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 (www.bluecoat.com) for one example. This >assignment will not change the basic operation of these WAN Optimization >products. 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 >standard... 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 ---------------------------
- [tcpm] New ID available: TCP Option for Transpare… Andrew Knutsen
- Re: [tcpm] New ID available: TCP Option for Trans… Andrew Knutsen
- Re: [tcpm] New ID available: TCP Option for Trans… Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [tcpm] New ID available: TCP Option for Trans… Andrew Knutsen
- Re: [tcpm] New ID available: TCP Option for Trans… Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [tcpm] New ID available: TCP Option for Trans… Andrew Knutsen
- Re: [tcpm] New ID available: TCP Option for Trans… Mahdavi, Jamshid