[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

AFT Working Group                                     Marc VanHeyningen
draft-ietf-aft-socks-v6-req-00.txt                    Aventail Corp.
Expires six months from -->                           September 1, 1999

                      SOCKS successor requirements

   Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      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/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

      This document is a submission to the IETF Authenticated Firewall
      Traversal (AFT) Working Group. Comments are solicited and should
      be addressed to the working group mailing list (aft@socks.nec.com)
      or to the editor.

   Abstract

      The SOCKS protocol version 5 has been deployed and seen use as a
      mechanism for authenticated firewall traversal.  Experience with
      the use of this protocol and its limitations has led to the desire
      for a new firewall traversal protocol; we tentatively name this
      new protocol SOCKS version 6.

1.  Introduction

   SOCKS5 has enjoyed wide use in a variety of network environments as a
   protocol for traversing trust boundaries in heterogenous network
   environments.  Its support for various authentication methods,
   specification of destinations by name rather than by IP address, and
   UDP proxy support have provided much benefit; however, there are new

VanHeyningen             Expires March 1, 2000                  [Page 1]


INTERNET-DRAFT        SOCKS successor requirements     September 1, 1999

   features required, and the existing protocol was not designed to be
   sufficiently extensible such that an easy retrofit is possible.

   Proposed here is a set of new top-level requirements for the protocol
   as a whole, along with a set of specific new functionality desired in
   this new version.  As a base requirement, SOCKS v6 should be able to
   do everything currently done by compliant SOCKS v5 implementations.

2.  General protocol features

   Experience with SOCKS5 has indicated some fundamental aspects of the
   protocol which do not provide the level of flexibilty desired for
   wide use and enhancement.  Thus, the successor should minimally
   include:

      o Major and minor version numbers, to allow for revisions which do
        not break backward compatibility
      o A general mechanism for negotiating the support of new
        protocol features.
      o Authentication methods (and, if possible, the authentication
        framework) should leverage existing standards rather than re-invent
        them.
      o A "control channel" may exist which allows multiple proxy
        operations to be conducted without incurring the overhead of
        re-authentication.  This control flow should persist throughout
        the lifetime of the connection(s).

3.  TCP-BIND features

   The BIND command as defined in SOCKS5 is designed primarily for cases
   in which a server must make a "back-connect" to a client, as is the
   case in FTP.  For this purpose the command as defined is sufficient;
   however, there are protocols which require multiple back-connects to
   a single listening address/port, and some require a specific port be
   used when accepting this connection.

   The TCP BIND functionality shall include:

      o The ability to support multiple connections, not just one, to
        the proxy's listening port
      o The ability of the client to request a specific port be used
        by the server when listening on its behalf

4. UDP-BIND features

   UDP was a new feature for SOCKS v5, and the initial support was very

VanHeyningen             Expires March 1, 2000                  [Page 2]


INTERNET-DRAFT        SOCKS successor requirements     September 1, 1999

   limited in its capabilities.  The model envisioned was that of
   applications like archie; a client sending data and a response being
   received.  Many UDP applications have different requirements, such as
   receiving UDP data without sending any, using a specific port, and
   requiring IP address information.

   The UDP BIND functionality shall include:

      o The ability to establish the connection and receive address
        information about the proxy via a reliable channel
      o The ability to send or receive UDP first
      o The ability for the client to control the port used on its behalf
      o Support for sending and receiving multicast UDP traffic, in a
        multicast or non-multicast environment.
      o Support for tunneling UDP inside a reliable channel, at a
        performance penalty, if needed.

5.  References

   [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., &
              Jones, L., "SOCKS Protocol V5," April 1996.

Author's Address

   Marc VanHeyningen
   Aventail Corporation
   808 Howell Streeet; Suite 200
   Seattle, WA  98101

   Phone: +1 (206) 215-1111
   Email: marcvh@aventail.com

VanHeyningen             Expires March 1, 2000                  [Page 3]


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