Transport WG A. Knutsen Internet-Draft Blue Coat Systems Intended status: Informational A. Ramaiah Expires: September 1, 2012 Cisco February 29, 2012 TCP option for transparent Middlebox discovery draft-ananth-middisc-tcpopt-00.txt Abstract This document describes a TCP option for use by middleboxes to facilitate transparent detection of other middleboxes along the path of the TCP connection during the connection initiation phase. The option has no effect if an appropriate middlebox is not present on the path. The TCP end hosts are unaware of this option and its usage is strictly for use by TCP middleboxes. Multiple vendors of WAN optimization products have used similar (but incompatible and proprietary) mechanisms since at least 2004. Those existing vendor systems use multiple TCP option code points, all of which are officially unassigned by IANA. The goal of this memo is to standardize a single TCP option code point for this functionality. This memo is the product of discussion among some of the vendors currently using incompatible proprietary TCP options for middlebox discovery. It is a non-goal of this memo to achieve interoperability of middlebox discovery between multiple vendors. It needs to be noted that an earlier document [I-D.knutsen-tcpm-middlebox-discovery], is re-written as the current document after agreement from multiple vendors. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 1, 2012. Knutsen & Ramaiah Expires September 1, 2012 [Page 1] Internet-Draft TCP middlebox discovery February 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements of the TCP-MDO . . . . . . . . . . . . . . . . . 5 4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. TCP-MDO option format . . . . . . . . . . . . . . . . . . . . 7 6. TCP option interoperability . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Knutsen & Ramaiah Expires September 1, 2012 [Page 2] Internet-Draft TCP middlebox discovery February 2012 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] Middlebox "Middleboxes: Taxonomy and Issues" [RFC3234] defines a middlebox as follows: "A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host." Proxy HTTP1.1 [RFC2616] defines a proxy as follows: "An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients." Proxies exist for many protocols, such as HTTP, CIFS, MAPI and streaming. Since they act as both server and client, they have separate TCP connections to the original client and the actual server (also referred to as the "Original Content Server"). Proxies are often implemented on middleboxes. Proxies fall into two general categories: "Explicit" and "Transparent". The client must be configured to connect to an explicit proxy; it then passes the server address to it using an application protocol, such as HTTP. Transparent proxies require no client configuration; they intercept the client connection to the server, speaking to the client on its behalf, and make a separate connection to the server without the knowledge of the client. This memo deals exclusively with cooperating transparent proxies. Peer Two or more middleboxes with an effective association or relationship are peers. For example, one middlebox might compress data while another middlebox decompresses; neither middlebox can correctly manipulate traffic unless they both establish the existence of the other and coordinate their actions. The most common peering relationships are two-way (like the compression example) in which one middlebox performs a transformation that the other middlebox inverts. However, two-way peering that does not involve an invertible transformation is also found, as are n-way peering relationships where the "intermediate" peers are simply operating in a pass-through or failover mode. Knutsen & Ramaiah Expires September 1, 2012 [Page 3] Internet-Draft TCP middlebox discovery February 2012 2. Introduction For middleboxes that operate on TCP-based application protocols, it is highly desirable for discovery information to be carried within packets containing valid TCP protocol data. One significant kind of service offered by such middleboxes is application acceleration, in which there is an intrinsic requirement to be efficient and avoid network round trips. A middlebox-discovery mechanism that imposes additional round trips could defeat the purpose of such middleboxes. Middlebox discovery on a per-connection basis allows for significant advantages in scale and flexibility. Middlebox-based services can be invoked dynamically, using the appropriate peers, without any need for statically identifying middleboxes to end hosts or identifying middleboxes to each other. Dynamic discovery means that there is no overlay routing required for middlebox-based services, where such overlay routing could potentially clash with the underlying IP routing. For all of these reasons, multiple vendors have implemented TCP-option-based discovery mechanisms; and for similar reasons, this memo requests a TCP option for middle box discovery. The TCP middlebox discovery option (TCP-MDO) allows a source node (initiating middlebox) on the initiating path of a TCP connection to request a response from other middleboxes with a matching capability closer to the destination host. In addition, it allows the initiating middlebox to provide information to the other middleboxes which they may need to decide whether to respond to this request. A middlebox MAY examine TCP packets with the SYN bit set to determine if the associated TCP connection qualifies for the middlebox-provided service. If so, the middlebox MAY insert the TCP-MDO into the packet header before sending it on. A middlebox MAY examine packets containing the TCP-MDO to determine if the associated TCP connection qualifies for the middlebox-provided service. If so, the middlebox MAY take additional actions to coordinate with the initiating middlebox. Such actions MAY include acknowledging the SYN packet to intercept the connection; originating a separate connection to the client; or perhaps notifying a management station. Knutsen & Ramaiah Expires September 1, 2012 [Page 4] Internet-Draft TCP middlebox discovery February 2012 3. Requirements of the TCP-MDO The following are the requirements of TCP-MDO : 1) The TCP-MDO MUST be variable length to accommodate multiple vendor option formats. 2) The TCP-MDO MUST have a vendor ID which can identify the specific vendor as implied by 1) 3) The TCP option space limitation puts a burden on how flexible the option can be. Please refer section 6 below. 4) TCP option numbers already in use by proprietary systems SHOULD NOT be reused for TCP-MDO since it would create confusion. (These option numbers would get eventually retired when all vendors migrate to the newly allocated TCP-MDO option) 5) The TCP-MDO SHOULD be used for middleboxes only. The hosts are expected to silently ignore this option. Knutsen & Ramaiah Expires September 1, 2012 [Page 5] Internet-Draft TCP middlebox discovery February 2012 4. Description The TCP-MDO MAY be included in the TCP handshake (SYN and SYN+ ACKpackets). The TCP-MDO contained in the SYN packet is used to discover peer middleboxes along the path to the server. The TCP-MDO option MAY be present in the TCP SYN+ACK and other TCP data packets as well. It should be noted that a common use of middleboxes is to set up cooperating peer proxies. One example is to implement a feature which optimizes the WAN traffic, like a compression protocol. In these cases, the option is used by the device nearer to the client to discover a possible device nearer to the server. Thus the client and server application are not aware of the option. Figure 1 illustrates the text above. CLIENT ----- Middlebox1 ================ Middlebox2 ------ SERVER WAN link ------SYN------->|---- SYN, TCP-MDO ----->|----SYN---> <---SYN+ACK---|<---SYN+ACK, TCP-MDO----|<---SYN+ACK---- Figure 1: TCP-MDO option insertion during TCP handshake Knutsen & Ramaiah Expires September 1, 2012 [Page 6] Internet-Draft TCP middlebox discovery February 2012 5. TCP-MDO option format The following is the agreed-upon option format for TCP-MDO. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind = xx | Length | Vendor = YY | Vendor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Payload data dependent on Vendor typecode | | | | (Variable Length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (One tick mark represents one bit) Figure 2 : Format of TCP-MDO Even after 8 years of commercial development, there are only a handful of vendors with different option-based discovery schemes. Accordingly, 8 bits is likely to be more than sufficient for vendor identification. Ideally, future work would define a single interoperable middlebox discovery scheme to replace the multiple vendor-specific schemes. The PEN (32 bit Private Enterprise numbers) is an existing mechanism which could be used to identify various vendors (http://www.iana.org/assignments/enterprise-numbers). Because of the very limited amount of TCP option space, using 32 bits for an enterprise number is impractical. The next section talks more about the TCP option space issue. Other formats for TCP-MDO have been previously considered, including an approach in which the option contains a Type code followed by Vendor ID. That design had the advantage of supporting an extension into 32-bit enterprise numbers. But no meaningful commonality could be identified among the different vendor schemes; at any level beyond the use of a TCP option, each functions quite differently and there was no clear basis for choosing a standardized type scheme. Knutsen & Ramaiah Expires September 1, 2012 [Page 7] Internet-Draft TCP middlebox discovery February 2012 6. TCP option interoperability This section touches upon the interoperability issues of TCP-MDO with other TCP options. It needs to be noted that the TCP-MDO can be inserted only if the TCP option space permits. Given that there is a maximum of 40 bytes for TCP options, A SYN (with MSS, window scale, SACK permitted, and timestamp options) leaves 16 bytes spare (if the options are word- aligned) or 21 bytes spare (if the options are not word-aligned) which may just make it. In particular, it is not typically possible to insert TCP-MDO if a vendor-proprietary option has already been inserted, nor vice-versa. Strictly speaking, this conflict is not a new problem but the attempt at standardization may mean it occurs more often. It is already true in most cases that it is not possible to insert vendor A's option if vendor B's option has previously been inserted. This memo does not attempt to define rules on precedence or priority of such options, nor does it define circumstances in which a proprietary option may safely be replaced by TCP-MDO. Multipath TCP ([I-D.ietf-mptcp-multiaddressed]) would have more options sent in the SYN, therby restricting the TCP option space that can be used for TCP-MDO. The TCP-MDO option is incompatible with TCP options which aim to protect the integrity of the TCP SYN. An example of such an option is the TCP MD5 signature option[RFC2385]. Such TCP options are not commonly seen by current WAN optimization systems, so the restriction should not pose any worries. Knutsen & Ramaiah Expires September 1, 2012 [Page 8] Internet-Draft TCP middlebox discovery February 2012 7. IANA Considerations This section is interpreted according to [RFC5226]) This document needs a new TCP option to be allocated by IANA for the TCP-MDO option from the "TCP Option Kind Numbers" registry maintained at http://www.iana.org IANA is also requested to assign an 8 bit vendor code that can be used to differentiate multiple vendors and to maintain an associated registry. It needs to be noted that at the time of writing this document, the following vendors have used the following TCP option numbers for TCP middlebox auto-discovery. Vendor TCP option number -------------------------------------- Bluecoat 253 Cisco 33 Figure 3: Current TCP auto-discovery option numbers used by various vendors. Knutsen & Ramaiah Expires September 1, 2012 [Page 9] Internet-Draft TCP middlebox discovery February 2012 8. Security Considerations The TCP-MDO option is incompatible with any TCP option which aims to protect the integrity of the TCP SYN, such as the TCP MD5 signature option[RFC2385]. In addition, this memo's approach to middlebox discovery introduces two security issues. First, the option-based paradigm intrinsically involves modifying traffic. Some traffic may be modified even though it cannot or should not receive the middlebox-based service. Secondly, there is no authentication mechanism defined in this memo to ensure that middleboxes communicate only with well-behaved and trusted potential peers. A rogue middlebox can potentially insert itself into a functioning community of middleboxes, disrupting the service provided. Knutsen & Ramaiah Expires September 1, 2012 [Page 10] Internet-Draft TCP middlebox discovery February 2012 9. Contributors The following individuals contributed immensely to this document : Ron Fredrick, Blue Coat. Mani Ramaswamy, Cisco. Knutsen & Ramaiah Expires September 1, 2012 [Page 11] Internet-Draft TCP middlebox discovery February 2012 10. Acknowledgements Thanks to Lars Eggert for forming the middisc alias which was responsible for discussions leading to the current document. Thanks to Wes Eddy and David Harrington for the constant encouragement in getting this document written. Knutsen & Ramaiah Expires September 1, 2012 [Page 12] Internet-Draft TCP middlebox discovery February 2012 11. References 11.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 11.2. Informative References [I-D.ietf-mptcp-multiaddressed] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", draft-ietf-mptcp-multiaddressed-06 (work in progress), January 2012. [I-D.knutsen-tcpm-middlebox-discovery] Knutsen, A., Frederick, R., Mahdavi, J., Li, Q., and W. Yeh, "TCP Option for Transparent Middlebox Discovery", draft-knutsen-tcpm-middlebox-discovery-04 (work in progress), May 2010. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. Knutsen & Ramaiah Expires September 1, 2012 [Page 13] Internet-Draft TCP middlebox discovery February 2012 Authors' Addresses Andrew Knutsen Blue Coat Systems 420 North Mary Ave Sunnyvale, CA 94085-4121 USA Phone: +1 (408) 220-2250 Email: andrew.knutsen@bluecoat.com Anantha Ramaiah Cisco 170 Tasman Drive San Jose, CA 95134 USA Phone: +1 (408) 525-6486 Email: ananth@cisco.com Knutsen & Ramaiah Expires September 1, 2012 [Page 14]