Re: [middisc] TCP middlebox option requirements
"Anantha Ramaiah (ananth)" <ananth@cisco.com> Wed, 26 May 2010 05:59 UTC
Return-Path: <ananth@cisco.com>
X-Original-To: middisc@core3.amsl.com
Delivered-To: middisc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCDF23A685B for <middisc@core3.amsl.com>; Tue, 25 May 2010 22:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 fWRAg3TrCSkB for <middisc@core3.amsl.com>; Tue, 25 May 2010 22:59:34 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 847B63A6872 for <middisc@ietf.org>; Tue, 25 May 2010 22:59:34 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEdV/EurRN+K/2dsb2JhbACeGnGlUplyglmCOgSDQh8
X-IronPort-AV: E=Sophos; i="4.53,302,1272844800"; d="scan'208,217"; a="135087676"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 May 2010 05:59:25 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o4Q5xPGh007169; Wed, 26 May 2010 05:59:26 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 May 2010 22:59:25 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAFC98.9826477A"
Date: Tue, 25 May 2010 22:59:24 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5809C77A99@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [middisc] TCP middlebox option requirements
Thread-Index: Acr8dtwZm6a9SYuNT1C+otsk46jC2AAIJ3NQ
References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADAB3597@MAILBOXES2.nbttech.com><4BFC6B29.1080706@bluecoat.com> <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: Ron Frederick <ronf@bluecoat.com>, Andrew Knutsen <andrew.knutsen@bluecoat.com>
X-OriginalArrivalTime: 26 May 2010 05:59:25.0687 (UTC) FILETIME=[987A7070:01CAFC98]
Cc: Ron Frederick <ron.frederick@bluecoat.com>, middisc@ietf.org
Subject: Re: [middisc] TCP middlebox option requirements
X-BeenThere: middisc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussions on TCP option for middlebox discovery." <middisc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/middisc>, <mailto:middisc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/middisc>
List-Post: <mailto:middisc@ietf.org>
List-Help: <mailto:middisc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/middisc>, <mailto:middisc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 05:59:37 -0000
OUI as exists today is standardized and managed and provides unquiness. If we were to define a 1 byte vendor it, it has all issues which Ron mentioned below + the need for standardizing that space, I don't know who is going to manage allocation and maintenance of that field. I don't think IANA would do that. I also wanted to understand the use case of having this option sent in the middle of the connection. FWIW TCP options as exisits today are either "negotiated" one time in the initial 3 way handshake (MSS, Window scale, SACK permitted etc.,) or sent on every packet (TCP MD5, TIMESTAMP etc.,) On demand sendind of the option is something new, so is the concept of variable length TCP option (with the exception of SACK, which itself needs to agreed upon using SACK PERMITTED option during the 3 way HS. -Anantha ________________________________ From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Ron Frederick Sent: Tuesday, May 25, 2010 5:52 PM To: Andrew Knutsen Cc: Ron Frederick; middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements On May 25, 2010, at 5:28 PM, Andrew Knutsen wrote: It seems to me that if we do limit our goal here to agreeing on an option number and vendor ID scheme, we haven't really limited ourselves to autodiscovery except in the requirements we state for getting a vendor ID (ie, agreements on use). Mostly this would involve removing the requirement that the option only be present with the SYN bit. We added this requirement primarily due to concerns about reliable transmission, but in later discussions we came up with a midstream discovery requirement and mechanism where that isn't an issue, so I don't think we're particularly attached to it. Also, we probably don't have to require everyone to encode the vendor-specific type information in the same way. Another implication of that goal is that we wouldn't be making a standard per se; rather we'd be making a first step towards a set of standards. Thats the purpose of the "P" bit in the current proposal, and the "standard vendor" codes in the proposal for removing the OUI in my message below. The idea is that as the technology matures, we can move towards a standard mechanism. I'm not familiar with IPv6 options, but at this point what we're doing sounds so simple it should work. I'm getting the impression that to make this alternate option useful to everyone here, we have to change the proposal in a few ways, including: 1) Removing the OUI, and having a single byte of vendor code. The option format would be vendor-specific. 2) Replacing the P bit with a "standard" vendor code or codes -- perhaps one code per interoperable option format. 3) Removing the requirement that the option only be present with the SYN bit set. 4) It sounds like the R bit may be redundant with other, more complex schemes already implemented by some vendors. This would mean the option format would only specify a single byte of vendor ID after the option length. We would need some stipulations on the option's use (making and maintaining tunnels, perhaps). Vendors would have to agree to these stipulations to get a code, so we aren't making a "catch-all" option. Opinions? [Ron] A single byte for vendor ID clearly will not scale. There can easily be more than 256 vendors our there who may eventually want to use this option. I don't see any obvious way to do better space-wise than what we proposed with the OUI if we want this to be truly extensible to support all possible vendors. Regarding the P bit, I don't really understand what you mean. We could have a single vendor code value for all the standard extensions, but we'd still need another byte for which option it was. If we burn a vendor code point for each interoperable option, we'd have even fewer code points left to allow vendor extensibility. If we think we can live with only 127 possible options (both for standard options and for each vendor), we could potentially shorten the type field from 2 bytes to 1 byte, which would then become 4 bytes when you add the OUI when the P bit is set, but I'm not sure the single byte of savings we get from that is really worth the flexibility we lose by dropping from 32K options per vendor to 127. Both of these numbers drop by a factor of 2 if we keep the R bit, which makes it even more of a poor choice. I'm ok with dropping the requirement that these options are only sent on the SYN and SYN-ACK, but I would prefer to see an example of sending such an option mid-stream and some text which describes the known issues with trying to send an option in such an unsyncrhonized way. Regarding the R bit, I could potentially see folding that into the vendor-specific data, but I would expect pretty much everyone to need to deal with this issue, so it seems like it would be best if we had a single general mechanism which did so. Mark Day wrote: Two additional issues seem worth clarifying since I'm not sure how others would view them. 1. Are we concerned strictly with autodiscovery options, or are we attempting to understand the requirements for options usage generally among current symmetric middleboxes? For example, Riverbed uses a different option for some forms of addressing information in situations after the two communicating peers have been established by autodiscovery. It wouldn't surprise me to learn that other vendors have other similar schemes. 2. Don't we also need to consider requirements for autodiscovery options in IPv6 environments? In both cases, I can see a pragmatic argument for focusing narrowly vs. an architectural argument for considering broader issues. IPv4 autodiscovery is the clear existing interoperability/coexistence problem and may be solvable by simply agreeing on an option number and vendor id scheme, while the other areas might not yet have enough experience and implementations to justify a standard. And yet it feels to me like we might solve one option-related problem just to trip across another similar one soon afterward. --Mark -----Original Message----- From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Andrew Knutsen Sent: Friday, May 21, 2010 2:23 PM To: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements Thanks Ananth. One possibility that Jamshid and I talked about addresses concerns about using 3 bytes for the OUI. We could skip it (and the P bit), and break up the 15 bits or so of "device capability" into an IANA-assigned vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific type. There could be one or more "standard" vendor codes for multi-vendor interoperability (ie, IANA-assigned types), and an extension code if we run out of room. Perhaps we also need to define the requirements for getting a vendor code or a standard type -- for instance, we might not want any individual to be able to get a vendor code, since they are limited; and the standard types would need some documentation, but perhaps not as widely reviewed as for a top-level option kind. Andrew Anantha Ramaiah (ananth) wrote: Hi, I am just taking the liberty to post the first email on this mailing list. During our last call there was talk about the requirements of this TCP option. From our pov, the following would be the general requirements of the TCP option. Reason for TCP option : - A standard TCP option is needed because every vendor cannot have one option for the same purpose of auto-discovery and capability exchange. By standardizing the TCP option, firewalls etc., are aware of this option and problems can be avoided. Requirements of this TCP option : - There has to be a vendor ID (OUI) which would identify the specific vendor. This is needed because every vendors option format is going to be different. - Already existing non-standardized option numbers (TCP option 33, riverbed's options no's) for doing auto discovery should not be allocated for this new TCP option. This is to prevent any confusion. - The TCP option needs to be variable length to permit multiple option formats since the option size may vary depending on the vendor. - This TCP option should be advocated for use only by middleboxes. My guess is that these requirements may be common for all the vendors or there may be some additional requirements not covered by this post. In either case we can continue the discussion and come to some conclusions. -Anantha -- Ron Frederick ronf@bluecoat.com
- [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Mark Day
- Re: [middisc] TCP middlebox option requirements Mark Day
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Mark Day
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Ron Frederick
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Mark Day
- Re: [middisc] TCP middlebox option requirements Ron Frederick
- Re: [middisc] TCP middlebox option requirements Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
- Re: [middisc] TCP middlebox option requirements Knutsen, Andrew
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Ron Frederick
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Mark Day
- Re: [middisc] TCP middlebox option requirements Lars Eggert
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Ron Frederick
- Re: [middisc] TCP middlebox option requirements Ron Frederick
- Re: [middisc] TCP middlebox option requirements David Harrington
- Re: [middisc] TCP middlebox option requirements Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen
- Re: [middisc] TCP middlebox option requirements Frederick, Ron
- [middisc] TCP middlebox option requirements Knutsen, Andrew
- Re: [middisc] TCP middlebox option requirements Anantha Ramaiah (ananth)
- Re: [middisc] TCP middlebox option requirements Frederick, Ron
- Re: [middisc] TCP middlebox option requirements Andrew Knutsen