[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/