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
<draft-knutsen-tcpm-middlebox-discovery-00.txt>
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",
<http://standards.ieee.org/regauth/oui/index.shtml>
[WCCP] "Web Cache Control Protocol Feature Module",
<http://www.cisco.com/en/US/docs/ios/11_2/feature/guide/wccp.html>
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",
<draft-goland-http-udp-00.txt>, June 1999.
[SSDP] Cai, T., Y. Gu, Y. Goland, S. Albright, "Simple Service
Discovery Protocol/1.0", <draft-cai-ssdp-v1-01.txt>, April 1999.
[LEAR01] Lear, E., "Requirements for Discovering Middleboxes",
<draft-lear-middlebox-discovery-requirements-00.txt>, 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]