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
September 23, 2009
TCP Option for Transparent Middlebox Discovery
<draft-knutsen-tcpm-middlebox-discovery-01.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 September 23, 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. Option Format ..............................................5
5.2. Initiating Discovery Request ...............................6
5.3. Responding to Discovery Request ............................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 ......................................................8
11.1. Normative References .......................................8
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 September 23, 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 a node on
the initiating path of a TCP connection to request a response from a
particular type of middlebox closer to the destination host. In
addition, it allows the source node to provide information to the
middlebox which it may need to decide whether to respond. The
response may take the form of acknowledging 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
Knutsen et al Expires February 2010 [Page 3]
Internet Draft middlebox-discovery September 23, 2009
number of products to pursue the approach outlined in this
specification. Middleboxes which perform transparent interception are
often inserted in the path by means of layer 4 redirection. 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 September 23, 2009
5. Operation
The Middlebox Discovery Option is implemented as a TCP Option. This
TCP Option is included in the TCP connection handshake. A Request
option to discover middleboxes is sent in the TCP SYN packet, and a
Response option may be present in the TCP SYN-ACK packet.
It should be noted that a common use of middleboxes is to set up
tunnels, for example to implement a compression protocol. In these
cases, the option is used by the device nearer the client to discover
a possible device nearer the server. Thus, the client and server
applications are not aware of the option.
Since this option is expected to be used exclusively in client-server
transactions, simultaneous opens are not expected.
5.1. 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 target data to option length |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(One tick mark represents one bit.)
Figure 1: Format of the Middlebox Discovery Option
The "R" bit indicates whether this option is a Request or Response.
If the bit is 0, the option is a Request; otherwise it is a Response.
Some TCP implementations reflect unknown options received in a TCP
SYN back in their SYN-ACK response. The "R" bit can be used to
distinguish these invalid responses from actual Middlebox Discovery
Responses.
The "P" bit indicates if the device type is defined by IANA or by
another organization. If the bit is 1, a 3-byte IEEE Organizational
Unit Identifier (OUI) indicating which organization defined the type
follows the Device Type field.
If the option length is greater than the total length of the option
kind, length, device type and optional OUI, the remaining data
Knutsen et al Expires February 2010 [Page 5]
Internet Draft middlebox-discovery September 23, 2009
("target 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. 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
limited to packets with the SYN bit set.
5.2. 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.3. Responding to Discovery Request
Devices MUST NOT respond to requests which have not been validated
using the target data, if required by the device type.
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.
All further transactions on the connection are outside the scope of
this document.
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
Knutsen et al Expires February 2010 [Page 6]
Internet Draft middlebox-discovery September 23, 2009
device re-originates a connection. Some firewalls also strip TCP
options. Discovery Requests and Responses cannot be expected to
traverse such devices.
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).
7. Programming and Manageability Considerations
Network analysis tools and firewalls MAY interpret this option for
management purposes.
If this option is detected by an application which is not prepared to
interpret it, it MUST be ignored.
8. Security Considerations
Since this option is in the TCP header, it will be protected by IP
Security [RFC4301]. This may prevent detection of, or response to,
the option.
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
Knutsen et al Expires February 2010 [Page 7]
Internet Draft middlebox-discovery September 23, 2009
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.
[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",
Knutsen et al Expires February 2010 [Page 8]
Internet Draft middlebox-discovery September 23, 2009
<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
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]