INTERNET-DRAFT                                              Ari Luotonen
Expires: February 1999               Netscape Communications Corporation
<draft-luotonen-web-proxy-tunneling-01.txt>                  August 1998


        Tunneling TCP based protocols through Web proxy servers


Status of this Memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Currently, this draft is stable and only waiting for its referenced
   documents to become RFC's, so this draft can become an RFC as well.


Abstract

   This document specifies a generic tunneling mechanism for TCP based
   protocols through Web proxy servers.  This tunneling mechanism was
   initially introduced for the SSL protocol [SSL] to allow secure Web
   traffic to pass through firewalls, but its utility is not limited to
   SSL.  Earlier drafts of this specification were titled "Tunneling SSL
   through Web Proxy Servers" <draft-luotonen-ssl-tunneling-XX.txt>.
   Implementations of this tunneling feature are commonly referred to as
   "SSL tunneling", although, again, it can be used for tunneling any
   TCP based protocol.

   A wide variety of existing client and proxy server implementations
   conform to this specification.  The purpose of this specification is
   to describe the current practice, to propose some good practices for
   implementing this specification, and to document the security
   considerations that are involved with this protocol.





 
TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT   August 1998


Table of Contents

     1.  Overview ................................................. 2
     2.  General Considerations ................................... 3
     3.  Functional Specification ................................. 3
     3.1.  Request ................................................ 3
     3.2.  Proxy Response ......................................... 4
     3.2.1.  Response Content-Type Field .......................... 5
     3.3.  Data Pipelining ........................................ 6
     4.  Extensibility ............................................ 7
     5.  Multiple Proxy Servers ................................... 7
     6.  Security Considerations .................................. 8
     7.  References ............................................... 8
     8.  Author's Address ......................................... 9


1. Overview

   The wide success of the SSL (Secure Sockets Layer) protocol made it
   vital for Web proxy servers to be able to tunnel requests performed
   over SSL.  The easiest, and perhaps the most elegant, way to
   accomplish this is to extend the HTTP/1.x protocol [HTTP/1.0,
   HTTP/1.1] in such a way that it will be able to intiate a tunnel
   through the proxy server.

   This document specifies the HTTP/1.x extension to implement the
   generic TCP protocol tunneling on Web proxy servers.  This extension
   may be used between clients and proxy servers, and between two
   proxies (in the case of daisy-chained proxies -- proxies that contact
   other proxies to perform requests).  This document focuses on the
   differences and additions to HTTP/1.x; refer to the HTTP/1.x
   specifications for a full specification of HTTP/1.x.

   Note that the HTTPS protocol, which is just HTTP on top of SSL, could
   alternatively be proxied in the same way that other protocols are
   handled by the proxies: to have the proxy (instead of the client)
   initiate the secure session with the remote HTTPS server, and then
   perform the HTTPS transaction on the client's part.  The response
   will be received and decrypted by the proxy, and sent to the client
   over (insecure) HTTP.  This is the way FTP and Gopher get handled by
   proxies.  However, this approach has several disadvantages and
   complications:

     * The connection between the client and the proxy is normal HTTP,