home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-aft-socks-ext-00.txt < prev    next >
Text File  |  1997-07-23  |  8KB  |  223 lines
  1.  
  2. INTERNET-DRAFT                                           M. VanHeyningen
  3. <draft-ietf-aft-socks-ext-00>                       Aventail Corporation
  4. Expires in six months                                       22 July 1997
  5.  
  6.   Feature Discovery: A Generic Extension Mechanism for SOCKS Version 5
  7.  
  8. Status of this Memo
  9.  
  10.       This document is an Internet-Draft.  Internet-Drafts are working
  11.       documents of the Internet Engineering Task Force (IETF), its
  12.       areas, and its working groups.  Note that other groups may also
  13.       distribute working documents as Internet-Drafts.
  14.  
  15.       Internet-Drafts are draft documetns valid for a maximum of six
  16.       months and may be updated, replaced, or obsoleted by other
  17.       documents at any time.  It is inappropriate to use Internet-Drafts
  18.       as reference material or to cite them othr than as ``work in
  19.       progress.''
  20.  
  21.       To learn the current status of any Internet-Draft, please check
  22.       the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
  23.       Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
  24.       (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  25.       Coast), or ftp.isi.edu (US West Coast).
  26.  
  27. Abstract
  28.  
  29.    This document specifies a command extension to the SOCKS Version 5
  30.    protocol which enables compliant clients to discover features
  31.    supported by the server.  After discovering the support of such
  32.    features, the client may use them in subsequent connections to that
  33.    server.  This mechanism does not provide for negotiation; it is a way
  34.    of instructing the client what features the server supports, not
  35.    establishing which features the client supports or wishes to use.
  36.  
  37. LIST-FEATURES Command
  38.  
  39.    LIST-FEATURES is a new SOCKS V5 command, with an identifier of X'10'
  40.    (16 decimal.)  This command is formatted as a standard command, per
  41.    section 4 of [SOCKS5].  Servers which do not support the LIST-
  42.    FEATURES command should respond with the "Command not supported"
  43.    error.
  44.  
  45.    The client may set DST.ADDR and DST.PORT to the destination host and
  46.    port of interest, or may send an IPv4 address of 0.0.0.0 to indicate
  47.    the query is not for any specific host.  The server may use this
  48.    information, along with the address of the client, to customize the
  49.    reply.
  50.  
  51.  
  52.  
  53. VanHeyningen              Expires January 1998                  [Page 1]
  54.  
  55. INTERNET-DRAFT       Feature Discovery for SOCKS V5         22 July 1997
  56.  
  57.  
  58.    The client may request that the server hold the connection after the
  59.    LIST-FEATURES command is completed to perform another SOCKS5 command
  60.    by sending a FLAG field of X'01'.
  61.  
  62.    The reply to the command is also formatted as a standard reply
  63.    [SOCKS5, sec 6.]  If the client has requested a persistent connection
  64.    and the server chooses to grant that request, it returns a FLAG of
  65.    X'01'.  The address returned should be an IPv4 address of 0.0.0.0.
  66.  
  67.    After the reply to the command is sent, the server sends a structure
  68.    called the Feature Description List described below.  After sending
  69.    the FDL, the server holds the connection open for another command if
  70.    it has granted a persistent connection; otherwise it closes it.
  71.  
  72. The Feature Description List
  73.  
  74.    The structure passed by the server which advertises its full set of
  75.    features is called the Feature Description List (FDL).
  76.  
  77.  Terminology and syntax
  78.  
  79.    The FDL is a tag-length-value (TLV) structure.  Tags consist of a
  80.    main tag and a subtag.  These are written as separated by a hyphen,
  81.    with the value following parentheses.  For example:
  82.  
  83.      TAG-SUBTAG("Hello.")
  84.  
  85.    When encoded into the structure, the tag and subtag each map to one
  86.    byte in the tag table.  The length of the value is a single byte,
  87.    followed by the value itself.
  88.  
  89.    For example, if TAG is X'07' and SUBTAG is X'13, the above example
  90.    would be encoded in hexidecimal as follows:
  91.  
  92.       07 13 06 48 65 6c 6c 6f 2e
  93.  
  94.    An FDL consists of zero or more of these associations concatenated
  95.    together, and is terminated by a TVL with a TAG of END (X'FF').
  96.  
  97.  FDL Meta-information
  98.  
  99.    The tag FDL (X'00') is used to describe information about the FDL
  100.    itself, rather than about the server.
  101.  
  102.    At this time only one subtag, SCOPE (X'10') is defined.  It defines
  103.    the scope of the FDL, and advises whether a client which made a
  104.    different FDL request would have been advertised the same feature
  105.    set.  Servers may provide this information, and clients may use it to
  106.  
  107.  
  108.  
  109. VanHeyningen              Expires January 1998                  [Page 2]
  110.  
  111. INTERNET-DRAFT       Feature Discovery for SOCKS V5         22 July 1997
  112.  
  113.  
  114.    determine when the FDL must be re-fetched.
  115.  
  116.    The following bytes may be included in the value field, and indicate
  117.    the following restrictions on scope:
  118.  
  119.       Value   Scope restriction
  120.       -----------------------------
  121.       X'01'   Client address
  122.       X'02'   Authentication method used
  123.       X'03'   Destination host specified in request
  124.  
  125.  SOCKS version support
  126.  
  127.    The tag SOCKS (X'01') is used to advertise versions of the SOCKS
  128.    protocol this server will support.  The subtags are versions, as
  129.    defined by the VER field.  No semantics are currently defined for the
  130.    value field.
  131.  
  132.  Address type support
  133.  
  134.    The tag ADDR (X'02') is used to advertise address types supported by
  135.    this client.  The subtags are ATYP values as defined in [SOCKS5].  No
  136.    semantics are currently defined for the value field.
  137.  
  138.  Authentication method support
  139.  
  140.    The tag AUTH (X'03') is used to advertise authentication methods the
  141.    server will support.  The subtags are individual authentication
  142.    METHOD identifiers.  The semantics associated with the value are
  143.    authentication-method specific; none are defined at this time.
  144.  
  145.  Command support
  146.  
  147.    The tag COMMAND (X'04') is used to advertise commands the server will
  148.    support.  The subtags are the CMD identifiers.
  149.  
  150.    The semantics associated with the value are command-specific.  For
  151.    the LIST-FEATURES command, a value containing X'01' indicates the
  152.    server supports persistent connections with this command.
  153.  
  154.  
  155.  Server information
  156.  
  157.    The tag SERVER (X'10') is used to advertise information about the
  158.    server.  Several subtags are defined:
  159.  
  160.       Subtag   Byte  Contents
  161.       ------------------------------------------------------------
  162.  
  163.  
  164.  
  165. VanHeyningen              Expires January 1998                  [Page 3]
  166.  
  167. INTERNET-DRAFT       Feature Discovery for SOCKS V5         22 July 1997
  168.  
  169.  
  170.       HOSTNAME X'01' Preferred hostname of the server
  171.       URL      X'02' URL with info on this server (policy, config...)
  172.       OPAQUE   X'03' Opaque identifier for this server
  173.       LOAD     X'04' Current server load (in ASCII floating point)
  174.  
  175. Security Considerations
  176.  
  177.    Since LIST-FEATURES is a SOCKS5 command, it may be performed only
  178.    after authentication has taken place.  Servers may wish to restrict
  179.    access to this command to users who have already authenticated
  180.    successfully, although that would also serve to limit its use in
  181.    automating configuration for users who may not yet be able to
  182.    authenticate successfully.
  183.  
  184.    Servers may prefer not to advertise all the features they support,
  185.    particualrly with regard to authentication methods supported.
  186.  
  187. References
  188.  
  189.    [RFC 1928] Leech, M. et al, "SOCKS Protocol V5," April 1996
  190.  
  191.    [SOCKS5] Leech, M. et al, "SOCKS Protocl V5," Internet Draft draft-
  192.    ietf-aft-socks-pro-v5-00, March 1997, work in progress.
  193.  
  194.  
  195. Author's Address
  196.  
  197.    Marc VanHeyningen
  198.    Aventail Corporation
  199.    117 South Main Street; Suite 400
  200.    Seattle, WA  98104  USA
  201.  
  202.    Phone: +1 (206) 777-5600
  203.    Email: marcvh@aventail.com
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221. VanHeyningen              Expires January 1998                  [Page 4]
  222.  
  223.