TCP Maintenance and Minor A. Knutsen
Extensions (tcpm) R. Frederick
Internet Draft J. Mahdavi
Intended Category: Informational Q. Li
Expires: November 2010 W.J. Yeh
Blue Coat Systems
May 3, 2010
TCP Option for Transparent Middlebox Discovery
<draft-knutsen-tcpm-middlebox-discovery-04.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 (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.
Knutsen et al Expires November 2010 [Page 1]
Internet Draft middlebox-discovery May 3, 2010
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 .....................................7
6. Interoperability Issues .........................................7
7. Programming and Manageability Considerations ....................7
7.1. TCP User Interface .........................................7
8. Security Considerations .........................................8
9. IANA Considerations .............................................8
10. Acknowledgments .................................................8
11. References ......................................................8
11.1. Normative References .......................................8
11.2. Informative References .....................................9
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:
Knutsen et al Expires November 2010 [Page 2]
Internet Draft middlebox-discovery May 3, 2010
"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.
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 Middlebox Discovery option is intended to allow a
node on the initiating path of a TCP connection to request a response
from middleboxes with a particular capability 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 the 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
Knutsen et al Expires November 2010 [Page 3]
Internet Draft middlebox-discovery May 3, 2010
discovery, there are several specific requirements which have led a
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 November 2010 [Page 4]
Internet Draft middlebox-discovery May 3, 2010
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.
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 Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Device Capability identifies the targetted devices. The "P" bit
indicates if the device capability 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 capability
MUST follow the Device Capability field.
If the option length is greater than the total length of the option
kind, length, device capability and optional OUI, the remaining data
("target data") MUST be interpreted according to the device
capability. The expected use for this data is to allow the targeted
Knutsen et al Expires November 2010 [Page 5]
Internet Draft middlebox-discovery May 3, 2010
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
capability should be the same.
Options with length less than 4 with the P bit clear, or 7 with the P
bit set, MUST be ignored.
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.
Since this option is expected to be used exclusively in client-server
transactions, simultaneous opens are not expected and no provision is
being made to support use of this option with them at this time.
5.2. Initiating Discovery Request
The request MUST have the "R" bit to 0.
The device capability specifies what target data MUST be present in
the option, if any.
Requests are only valid in SYN packets. They MUST NOT appear in other
segments and MUST be ignored when found outside of a SYN.
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 capability.
Responses MUST have the "R" bit set to 1.
The device capability specifies what target data MUST be present in
the option, if any.
Responses are only valid in valid SYN-ACK packets. They MUST NOT
appear in other segments and MUST be ignored when found outside of a
SYN-ACK.
All further transactions on the connection are outside the scope of
this document.
Knutsen et al Expires November 2010 [Page 6]
Internet Draft middlebox-discovery May 3, 2010
5.4. Reserved Option Values
Device capabilities 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 capability. In this case, this ID
defines the interpretation of the device capability, providing each
organization with its own private device capability space.
6. Interoperability Issues
TCP options generally are not preserved when a proxy or tunneling
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).
There may be situations where other options are required in the SYN
packet which do not leave enough room for all of the target data
necessary for the desired device capability to be advertised. In
these cases, a shorter alternate device capability may be defined
which signals the request to further negotiate the capability after
the handshake completes. This will impact performance by introducing
an extra round-trip during connection set-up, but this may be the
only way to perform the negotiation within the limited TCP option
space available.
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.
7.1. TCP User Interface
RFC 793 [RFC793] defines an example user interface for TCP,
Knutsen et al Expires November 2010 [Page 7]
Internet Draft middlebox-discovery May 3, 2010
consisting of active and passive OPEN, SEND, RECEIVE, CLOSE, STATUS
and ABORT commands. This option affects the following commands:
The active OPEN command MUST be augmented so the device capability
and target data can be specified, if requests will be sent.
The passive OPEN command MAY be augmented so the response can be
specified. However a different API, where the OPEN returns before
the response is sent, and an additional OPEN-RESPONSE command is
used to complete the open, may be more suitable. This API is
outside the scope of this document.
The STATUS command MAY be augmented to return the response data.
8. Security Considerations
Since this option is in the TCP header, it will be protected by IP
Security [RFC4301], the MD5 Signature option [RFC2385], and the TCP
Authentication Option [TCP-AO]. IP Security with privacy will
prevent detection of the option; all may prevent responses.
When transport-level security, such as TLS [RFC5246], is used, the
option will be visible. The "target data" MAY be separately
protected, as defined by the device capability.
9. IANA Considerations
This section is to be interpreted according to [RFC5226].
This document defines a new namespace of standard discoverable device
capabilities (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.
Knutsen et al Expires November 2010 [Page 8]
Internet Draft middlebox-discovery May 3, 2010
[RFC793] USC ISI, "Transmission Control Protocol", STD0007, RFC 793,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option," RFC-2385, Proposed Standard, August 1998.
[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",
<draft-lear-middlebox-discovery-requirements-00.txt>, April 2001
Knutsen et al Expires November 2010 [Page 9]
Internet Draft middlebox-discovery May 3, 2010
[TCP-AO] Touch, J., et. al., "The TCP Authentication Option", <draft-
ietf-tcpm-tcp-auth-opt-05.txt>, July 3, 2009
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 November 2010 [Page 10]