TCP Maintenance and Minor A. Knutsen Extensions (tcpm) R. Frederick Internet Draft J. Mahdavi Intended Category: Informational Q. Li Expires: February 2010 W.J. Yeh Blue Coat Systems August 3, 2009 TCP Option for Transparent Middlebox Discovery Status of this Memo Distribution of this memo is unlimited. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire February, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Knutsen et al Expires February 2010 [Page 1] Internet Draft middlebox-discovery August 3, 2009 Abstract This document describes a TCP option intended to facilitate transparent detection of middleboxes (or services playing that role) along the path of a TCP connection as the connection is made. The option has no effect if an appropriate middlebox is not on the path. Table of Contents 1. Terminology .....................................................2 2. Introduction ....................................................3 3. Survey of Existing Technology ...................................4 3.1. LAN Discovery Protocols ....................................4 3.2. IP-based protocols .........................................4 3.3. Resource Reservation / QoS Protocols .......................4 3.4. Requirements Documents .....................................4 4. Conventions .....................................................4 5. Operation .......................................................5 5.1. Initiating Connection with Discovery Request ...............5 5.2. Responding to Discovery Request ............................5 5.3. Option Format ..............................................6 5.4. Reserved Option Values .....................................6 6. Interoperability Issues .........................................6 7. Programming and Manageability Considerations ....................7 8. Security Considerations .........................................7 9. IANA Considerations .............................................7 10. Acknowledgments .................................................7 11. References ......................................................7 11.1. Normative References .......................................7 11.2. Informative References .....................................8 1. Terminology Client This is the original initiator of a request. The request is generally directed to a server. Server A host providing services to clients. Middlebox "Middleboxes: Taxonomy and Issues" [RFC3234] defines a middlebox as follows: "A middlebox is defined as any intermediary device performing Knutsen et al Expires February 2010 [Page 2] Internet Draft middlebox-discovery August 3, 2009 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. Tunnel A Tunnel can be viewed as two middleboxes (or software acting in that role) acting in concert to provide a service, such as security or compression. They will generally create a TCP connection between themselves, in addition to the client and server connections. 2. Introduction The TCP Transparent Intercept option is intended to allow the source host of a TCP connection to request a response from a particular type of middlebox on the path to the destination host. In addition, it allows the source host to provide information to the middlebox which it may need to decide whether to respond. This response may take the form of ACK'ing a SYN packet and intercepting the connection or some other response, such as originating a separate connection to the client, or perhaps notifying a management station. While there are numerous other technologies related to resource discovery, there are several specific requirements which have led a number of products to pursue the approach outlined in this Knutsen et al Expires February 2010 [Page 3] Internet Draft middlebox-discovery August 3, 2009 specification. Middleboxes which perform transparent interception are often inserted in the path using routing based on layer 4 information. For middleboxes which operate on TCP-based application protocols, this means that it is highly desirable for discovery information to be carried within packets containing valid TCP protocol data. In addition, one significant class of service offered by such middleboxes is application acceleration; solutions which impose additional round trips may defeat the purpose of such middleboxes. Section 3 considers a number of existing discovery protocols and their potential suitability for transparent middlebox discovery. 3. Survey of Existing Technology 3.1. LAN Discovery Protocols These protocols, such as the Service Location Protocol [RFC2608], Link-Local Multicast Name Resolution [RFC4795], and Universal Plug and Play over UDP HTTP [HTTPU] [SSDP], are unsuited to the purpose of this option because they are limited to LAN scope (or require multicast infrastructure). 3.2. IP-based protocols IP-based protocols, such as the ICMP ECHO request [RFC792], are not suitable for two reasons: they may not follow the TCP connection path if there is layer 4 redirection (such as WCCP [WCCP]) taking place; and they require an extra round trip time. 3.3. Resource Reservation / QoS Protocols The NSIS framework [RFC4080] solves a similar problem. However it also adds delay, and may not work in the presence of L4 redirection. 3.4. Requirements Documents "Requirements for Discovering Middleboxes" [LEAR01] discusses requirements for a class of problems similar to the one addressed here. 4. Conventions 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]. Knutsen et al Expires February 2010 [Page 4] Internet Draft middlebox-discovery August 3, 2009 5. Operation Two alternatives are provided for specifying the type of middlebox targeted. Following the option length is a two-byte "device type". The most significant bit of this field indicates whether the rest of the type is a "standard" or "private" type. The standard types are defined by the IANA. The private types are defined by the organization specified by the IEEE Organizational Unit Identifier (OUI) [OUI] in the three bytes following the device type. The OUI is only present if the most significant bit of the device type indicates "private". If the option length is greater than the total length of the option kind, length, device type and optional OUI, the remaining data is interpreted according to the device type. The expected use for this data is to allow the targeted device to determine how it should respond to the request. An example of this would be identification of the client, to allow the target to respond to some clients and not others. Discovery is a request-response exchange. In general, the "target data" will be different in the request and response, but the device type should be the same. Because reliable delivery of options on mid-stream packets is problematic at the present time, and all present uses of this mechanism occur at connection establishment, use of this option is presently limited to packets with the SYN bit set. 5.1. Initiating Discovery Request The request MUST have the "R" bit to 0. The request MUST contain target data as required by the device type. Requests MUST be in a SYN packet. 5.2. Responding to Discovery Request Devices MUST NOT respond to requests which have not been validated using the target data. Responses MUST have the "R" bit set to 1. The response MUST contain target data as required by the device type. Responses MUST be in a SYN-ACK packet. Knutsen et al Expires February 2010 [Page 5] Internet Draft middlebox-discovery August 3, 2009 All further transactions on the connection are outside the scope of this document. 5.3. Option Format 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 |R|P| Device type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IEEE OUI if P == 1 | Optional | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional target data to option length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (One tick mark represents one bit.) Figure 1: Format of the Middlebox Discovery Option If the "P" bit is 0, the optional data may begin immediately after the device type in place of the IEEE OUI. 5.4. Reserved Option Values Device types with the P (private) bit set to 0 are reserved for assignment by the IANA. If the "P" bit is set to 1, a 3-byte IEEE Organizational Unit Identifier follows the device type. In this case, this ID defines the interpretation of the device type, providing each organization with its own private device type space. 6. Interoperability Issues TCP options generally are not preserved when a proxy or tunneling device re-originates a connection. Thus a discovery request cannot be expect to traverse such a device. Implementers should be aware that in some cases packets originated by a middlebox may be routed back through it. If a middlebox can both accept incoming Middlebox Discovery Options and generate outgoing Middlebox Discovery options, it is important that some measures be taken to prevent interception of connections initiated by oneself. This can be accomplished either explicitly (via data included within the Middlebox Discovery Option that identifies the middlebox) or implicitly (via the middlebox maintaining a table of all connection 4-tuples it has originated so as to not re-intercept them). Knutsen et al Expires February 2010 [Page 6] Internet Draft middlebox-discovery August 3, 2009 Some TCP implementations reflect unknown options received in a TCP SYN back in their SYN-ACK response. The "R" bit can be used in such cases to distinguish a real response from this blind reflection of the original request. Real responses would have the "R" bit set to 1, while reflected requests would have the "R" bit still set to 0. 7. Programming and Manageability Considerations 8. Security Considerations Since this option is in the TCP header, it will be protected by IP Security [RFC4301]. However it will not be visible to middleboxes while so protected. When transport-level security, such as TLS [RFC5246], is used, the option will be visible. The "target data" should be separately protected. 9. IANA Considerations This section is to be interpreted according to [RFC5226]. This document defines a new namespace of standard discoverable device types (when the "P" bit is set to 0). This space is 14 bits wide. It is expected that this namespace will be administered by the IANA. IANA will need to allocate a new 8-bit TCP option number for this option from the "TCP Option Kind Numbers" registry maintained at http://www.iana.org. 10. Acknowledgments 11. References 11.1. Normative References [RFC792] J. Postel, "Internet Control Message Protocol", STD0005, RFC 792, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2608] E. Guttman, C. Perkins, J. Veizades, and M. Day., "Service Location Protocol, Version 2", RFC 2608, June 1999. [RFC4080] R. Hancock, G. Karagiannis, J. Loughney, and S. Van den Bosch., "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. Knutsen et al Expires February 2010 [Page 7] Internet Draft middlebox-discovery August 3, 2009 [RFC4301] S. Kent and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4795] B. Aboba, D. Thaler, and L. Esibov, "Link-Local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007. [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5246] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [OUI] "IEEE OUI and Company_id Assignments", [WCCP] "Web Cache Control Protocol Feature Module", 11.2. Informative References [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002 [HTTPU] Goland, Y., "Multicast and Unicast UDP HTTP Messages", , June 1999. [SSDP] Cai, T., Y. Gu, Y. Goland, S. Albright, "Simple Service Discovery Protocol/1.0", , April 1999. [LEAR01] Lear, E., "Requirements for Discovering Middleboxes", , April 2001 Authors' Addresses Andrew Knutsen Tel: (408) 220-2250 andrew.knutsen@bluecoat.com Ron Frederick Tel: (408) 220-2006 ron.frederick@bluecoat.com Jamshid Mahdavi Tel: (408) 220-2313 jamshid.mahdavi@bluecoat.com Qing Li Knutsen et al Expires February 2010 [Page 8] Internet Draft middlebox-discovery August 3, 2009 Tel: (408) 220-2369 qing.li@bluecoat.com Wei Jen Yeh Tel: (408) 220-2098 weijen.yeh@bluecoat.com Blue Coat Systems Inc. 420 North Mary Ave. Sunnyvale, CA 94085-4121 Knutsen et al Expires February 2010 [Page 9]