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

Versions: 01

AFT Working Group                                          D. Chouinard
Internet Draft                                        Intel Corporation
Expires in six months                                 November 20, 1997


                SOCKS V5 UDP and Multicast Extensions to
                Facilitate Multicast Firewall Traversal

                draft-ietf-aft-mcast-fw-traversal-01.txt


Status of this Memo

   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.

   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).

Abstract

   This proposal creates a mechanism for managing the ingress or egress
   of IP multicast through a firewall.  It does this by defining
   extensions to the existing SOCKS V5 protocol [RFC-1928], which
   provides a framework for doing user-level, authenticated firewall
   traversal of unicast TCP and UDP traffic.  However, because the
   current UDP support in SOCKS V5 has scalability problems as well as
   other deficiencies -- and these need to be addressed before
   multicast support can be achieved -- the extensions are defined in
   two parts: Base-level UDP extensions, and Multicast UDP extensions.

   Using the SOCKS framework for managing multicast flows in/out of an
   organization, offers numerous security advantages over what is
   possible with a conventional firewall approach.  These are spelled
   out in the draft.



 Chouinard                                                    [Page 1]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997


Table of Contents

1.   Conventions used in this document................................3
2.   Introduction.....................................................3
3.   Use of Feature Discovery.........................................4
4.   Base-level UDP Extensions........................................5
4.1. SOCKS Requests...................................................6
     4.1.1. ENHANCED_UDP_MODE........................................6
4.2. SOCKS Replies....................................................7
4.3. UDP Control Channel..............................................8
     4.3.1. UDP BIND.................................................9
     4.3.2. UDP RELEASE.............................................11
4.4. Procedure for TCP-Encapsulation.................................11
4.5. Procedure for UDP-based Clients.................................12
5.   Multicast Extensions............................................13
5.1. Assumptions and Requirements....................................14
5.2. UDP Control Commands and Flags..................................16
     5.2.1. Receiving From a Multicast Group........................16
     5.2.2. Sending to a Multicast Group............................18
     5.2.3. Releasing a Multicast Association.......................19
     5.2.4. Setting the TTL.........................................19
6.   Security Considerations.........................................20
7.   Acknowledgments.................................................21
8.   References......................................................21
9.   Disclaimer......................................................21
10.  Authors' Address................................................21


What’s Changed

   This revision contains the following changes from the version 00,
   dated July 23, 1997.

       @ The title was modified to include "to Facilitate Multicast
          Firewall Traversal."

       @ The document name was changed to draft-ietf-aft-mcast-fw-
          traversal-01.txt to better reflect the purpose of the
          document.

       @ The abstract was shortened.

       @ The Introduction section was added to provide background on
          the security issues with multicast and firewalls, and how
          SOCKS can solve them.

       @ Clarification was added indicating that addressing
          information must be included in UDP BIND messages for an
          existing association.

       @ Clarification was added on how non-proxy-based SOCKS servers
          respond to UDP BIND commands.

       @ The section on Multicast Assumptions and Requirements
          (Section 5.1) was supplemented with a discussion about non-
          proxy-based multicast-capable SOCKS servers.

Chouinard                                                      [Page 2]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997


1.   Conventions used in this document

   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 [RFC-2119].

2.   Introduction

   The main impetus for writing this draft is to provide a solution to
   getting multicast safely through firewalls.  This section presents
   the case why an augmented SOCKS protocol provides such a solution.

   Following are some of the security concerns that come to mind when
   considering allowing multicast through a firewall:

       1.Prevent users from inadvertently sending stuff out (i.e.,
          limit who can send content out, and with what scope)

       2.Limit who can bring multicast content into an organization

       3.Limit what groups can be joined

       4.Provide protection to internal users who have joined an
          external multicast group (consistent with the protection
          defined by the unicast security policy)

       5.Provide a detailed log of all multicast session activity (who
          was listening/sending and for how long)

       6.Limit how much bandwidth is consumed by flows (which could by
          user dependent) to prevent over-utilization of an
          organization’s network.


   Nearly all of these concerns require that the firewall know the
   identity of the user and what they are attempting to do.  While the
   same argument could be made for unicast protocols, it is actually a
   more pervasive argument for multicast.  The reasons are:

       @ Most multicast applications have no formal control protocol
          that a firewall can monitor in order to dynamically modify
          filtering rules for UDP flows

       @ The only real "control protocol" a firewall can always
          monitor is the IGMP messages that carry multicast routing
          protocol information (DVMRP, PIM, etc.).  However, since
          these messages are router-to-router, they do not contain
          anything about the original initiator of the message.  What’s
          more, only the first IGMP join for a given group will even
          traverse the firewall; subsequent joins for the same group
          will be assimilated into the routing tree formed inside the
          firewall.


   The end result is that without some light-weight “out-of-band”
   control protocol that authenticates a multicast client to the



Chouinard                                                      [Page 3]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

   firewall and makes requests of the firewall, it is not possible to
   address most of the security concerns mentioned above.

   Given that such a protocol is needed, ideally it should be
   implementable in such a way that it is transparent to, and
   independent of, the multicast application running on the client.
   Because SOCKS is implemented at the session layer, and provides the
   same kinds of capabilities for unicast applications, it is ideally
   situated to provide these services for multicast applications;
   indeed, even more so for multicast applications because of the
   inherent challenges with IP multicast!

   Using a multicast SOCKS solution offers the following advantages
   over a conventional firewall that provides class D address filtering
   as well as IGMP monitoring and filtering:

       @ The Multicast SOCKS Server (MSS) knows the identity of the
          user who has asked to a join a group (due to user
          authentication).  In a conventional approach, simply
          monitoring the IGMP only reveals that somebody issued a join
          of a particular group.

       @ The MSS not only knows the group address that a client wishes
          to join, it also knows the port.  This enables the MSS to
          filter traffic specific to that group address and port, and
          block traffic to the group address that is for other ports
          (where unsuspecting unicast services may be listening on).
          This enables better protection of clients that have joined an
          external group.  In a conventional approach where the
          firewall monitors IGMP, only the group address is specified;
          not the port.

       @ A proxy-based SOCKS server can convert multicast to unicast,
          and in doing so, can provide enhanced security
          (authentication, integrity, and privacy).


   The remainder of the document discusses how the aforementioned
   extensions are manifested into the SOCKS V5 protocol.

3.   Use of Feature Discovery

   Using the SOCKS feature discovery extension documented in [Van97], a
   SOCKS client MAY query a SOCKS server to see if it supports the UDP
   and/or Multicast extensions.  In Feature Description List (FDL)
   syntax, the tag-subtag used by the SOCKS server to indicate this
   support is COMMAND-ENHANCED_UDP_MODE (04 04 in hexadecimal).  Note,
   ENHANCED_UDP_MODE is a new command which is described in Section
   4.1.1.

   The values are:

   Value   Description
   --------------------------------------------------------
   X'01'   Base-level UDP extensions (covered in Section 4)


Chouinard                                                      [Page 4]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

   X'02'   Multicast UDP extensions (covered in Section 5)

   SOCKS servers that support *only* the Base-level UDP extensions do
   so only for unicast addresses.

   SOCKS servers that support *only* the Multicast UDP extensions still
   support the base-level UDP extensions, but only in the context of
   providing the services described in Section 5.

   SOCKS servers that support both extensions (i.e., for unicast and
   multicast) must explicitly indicate both values in the tag-subtag
   for enhanced UDP mode (e.g., 04 04 02 01 02 in hexadecimal).

4.   Base-level UDP Extensions

   The base-level UDP extensions augment the current SOCKS UDP support
   by increasing efficiency and scalability, as well as providing the
   foundation for the multicast extensions (discussed in Section 5).

   The base-level UDP extensions provide the following new
   functionality:

       * Ability to control multiple UDP sockets over one control
          connection

       * Reduced overhead on UDP datagram handling (by reducing the
          size of the SOCKS UDP datagram header).

       * Ability for SOCKS client to send and *receive* TCP-
          encapsulated UDP.

       * Correct handling of fragmentation.

   In order to provide these extensions, new commands are added, as
   well as changes to some of the existing SOCKS V5 packet structures
   and procedures.  These changes are done in a way to maintain
   compatibility between a SOCKS client or server that does not support
   the extensions.

   The following is a summary of the changes:

       * The packet structure for both the UDP control channel packets
          and the reply packet changes after the SOCKS client and
          server enter "UDP enhanced-mode" (described below).

       * All UDP-related commands are done on the UDP control channel
          and, among other new fields, include an Association
          IDentifier (AID) that uniquely identifies a particular UDP
          session (association) between an address/port on the SOCKS
          client and an address/port on a remote host.

       * The following new UDP commands are added:



Chouinard                                                      [Page 5]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

          * UDP Bind: Establishes a UDP association for sending and/or
            receiving (replaces the UDP Associate command as well as
            the INTERFACE DATA subcommand specified in [SOCKS5])
          * UDP Release: Releases a previously established association.

       * Support for TCP-encapsulation of UDP data is supported by
          first establishing a UDP send and/or receive association for
          TCP-encapsulation, and then sending a new packet type (SOCKS-
          UDP-DATA-REQUEST) specifically for encapsulating UDP over
          TCP.

       * The TCP control connection is not terminated when a command
          for a particular socket cannot be satisfied (since multiple
          UDP sessions can be controlled over the connection)

       * The SOCKS UDP data header is reduced in size by using the
          association identifier instead of the actual destination
          address.  Further, a Datagram Identifier field is added to
          this header to address problems with fragmentation.

   The details of these extensions are spelled out in the following
   sections (in a manner consistent with that used in RFC 1928).

   4.1. SOCKS Requests

   The SOCKS Request message has not changed, however, a new command
   (ENHANCED_UDP_MODE) is added.

       * CMD
          Existing commands:
          * CONNECT X'01' (used only for TCP)
          * BIND X'02' (used only for TCP)
          * UDP ASSOCIATE X'03' (not supported once Enhanced UDP Mode
            is achieved)

          New command:
          * ENHANCED_UDP_MODE X'04'

   4.1.1.  ENHANCED_UDP_MODE

   4.1.1.1. Request

   Providing the SOCKS server advertises support for the base-level UDP
   extensions (or even the multicast extensions), the client may send
   this command to the server, indicating its desire to use the base-
   level UDP extensions.  The message is populated as follows:

       VER: X'05'
       CMD: ENHANCED_UDP_MODE (X'04')

       All other fields are unused and SHOULD be 0s.

   4.1.1.2. Reply


Chouinard                                                      [Page 6]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

   The reply message is the same as that used in SOCKS V5, however the
   version number will contain the version of the UDP extension instead
   of the SOCKS version number.  The current version is X'01'.

   Upon receiving a successful reply, the TCP control channel has
   achieved "Enhanced UDP Mode," and subsequently, can only be used for
   the UDP commands defined in Section 4.3.

   4.2. SOCKS Replies


   Once "Enhanced UDP Mode" has been established, the format of all
   subsequent SOCKS Reply messages is as follows:

    +------------+--------+----------+--------+--------+-------+------+
    | PKT TYPE(1)| SIZE(2)| REPLY(1) |FLAGS(2)| RSVD(1)| TID(2)|AID(4)|
    +------------+--------+----------+--------+--------+-------+------+
    | LOCAL ADDR TYPE (1) |  LOCAL ADDR (var) |   LOCAL PORT (2)      |
    +---------------------+-------------------+-----------------------+
    | REMOTE ADDR TYPE(1) | REMOTE ADDR (var) |   REMOTE PORT (2)     |
    +---------------------+-------------------+-----------------------+

   The fields in the Reply packet are as follows:

       * PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02')
       * SIZE: Total size (in octets) of this message, in network
          order.
       * REPLY:
       Existing return codes (SOCKS V5):
          * X'00' succeeded
          * X'01' general SOCKS server failure
          * X'02' connection not allowed by ruleset
          * X'03' Network unreachable
          * X'04' Host unreachable
          * X'05' Connection refused
          * X'06' TTL expired
          * X'07' Command not supported
          * X'08' Address type not supported
       New return codes:
          * X'10' Bad Association ID
          * X'11' Multicast Receive not allowed by ruleset
          * X'12' Multicast Send not allowed by ruleset
          * X'13' Bad Association context
          * X'14' Bad multicast address
          * X'15' TTL value not allowed by ruleset
       * FLAGS: Command-dependent flag
       * RSVD: Reserved.
       * TID:  A 2-byte opaque Transaction Identifier that is set by
          the client in the request and is returned by the server in a
          response to a particular request.  The server does not use or
          interpret this value in any way; it merely returns it in the
          response to a particular request.
       * AID:  A 4-byte opaque Association Identifier that identifies
          a particular association.


Chouinard                                                      [Page 7]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

       * LOC ADDR TYPE/ADDR/PORT: Addressing information on the local
          side of the SOCKS server; that is, on the same side as the
          SOCKS client.  The ADDR TYPEs and the format of the ADDR are
          the same as those in SOCKS V5.
       * REM ADDR TYPE/ADDR/PORT: Addressing information on the remote
          side of the SOCKS server. The ADDR TYPEs and the format of
          the ADDR are the same as those in SOCKS V5.

   4.3. UDP Control Channel

   Once "Enhanced UDP Mode" has been established, the format of all
   subsequent SOCKS UDP Control messages is as follows:

    +------------+--------+----------+--------+--------+-------+------+
    | PKT TYPE(1)| SIZE(2)| UDPCMD(1)|FLAGS(2)| RSVD(1)| TID(2)|AID(4)|
    +------------+--------+----------+--------+--------+-------+------+
    | LOCAL ADDR TYPE (1) |  LOCAL ADDR (var) |   LOCAL PORT (2)      |
    +---------------------+-------------------+-----------------------+
    | REMOTE ADDR TYPE(1) | REMOTE ADDR (var) |   REMOTE PORT (2)     |
    +---------------------+-------------------+-----------------------+

   The fields in the CONTROL CHANNEL packet are as follows:

       * PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01')
       * SIZE: Total size (in octets) of this message, in network
          order.
       * UDP CMD: UDP command
          * UDP BIND:  X'05'  (new)
          * UDP RELEASE:  X'06'  (new)
          (Note: additional commands are defined in the Multicast
          extensions section of this document)
       * FLAGS:  A command-dependent bit-mask.  These values are bit-
          wise ORed to form the actual flag.
          Valid flags are:
          * RECEIVE-FROM: X'0001'
          * SEND-TO: X’0002’
          * UDP-UNICAST: X’0004’
          * TCP-ENCAPSULATED: X’0008’ – Indicates that datagrams will
            be encapsulated in TCP using the procedures in Section 4.4.
          (Note: additional commands are defined in the Multicast
          extensions section of this document)
       * RSVD: Reserved.
       * TID:  2-byte opaque Transaction Identifier - client sets in
          request, server returns in response.  Enables client to
          couple replies to requests.
       * AID:  4-byte opaque Association Identifier
       * LOC ADDR TYPE/ADDR/PORT: Local (source) address information
          on the SOCKS client. The ADDR TYPEs and the format of the
          ADDR are the same as those in SOCKS V5.
       * REM ADDR TYPE/ADDR/PORT: Remote address information (for the
          ultimate destination). The ADDR TYPEs and the format of the
          ADDR are the same as those in SOCKS V5.



Chouinard                                                      [Page 8]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

   The use of these fields is command dependent and is further
   described below.

   4.3.1.  UDP BIND

   4.3.1.1. Request

   The SOCKS client sends the UDP BIND command each time a new binding
   (or association) is made between the SOCKS client and a UDP source
   or destination, enabling the SOCKS Server to establish a "UDP Relay"
   for the association.

   The client MUST populate the following fields:

       PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01')
       SIZE: Total size (in octets) of this message, in network order.
       UDP CMD: UDP BIND (X'05')
       FLAGS: A bit-wise OR of the various flags defined in Section
            4.3.

        Examples:
          RECEIVE-FROM | SEND-TO | UDP-UNICAST - client wants to send
          and receive using the unicast UDP method.

          RECEIVE-FROM | UDP-UNICAST - client wants to only receive
          using the unicast UDP method.

          RECEIVE-FROM | SEND-TO | TCP-ENCAPSULATED-UDP - client wants
          to send and receive using the TCP-encapsulated method.  The
          client must do a UDP BIND with the SEND and TCP-ENCAPSULATED-
          UDP flags set, and get a successful response before following
          the procedures in Section 4.4.

          Other combinations are also possible, however, UDP-UNICAST
          are TCP-ENCAPSULATED-UDP are mutually exclusive.

       RSVD: Unused (X’00’).
       TID: Contains a unique value (chosen by the client) that enables
            the client to identify the reply to this particular
            request.
       AID: Contains an existing association ID if a send or receive
            association already exists on this same socket to the
            destination address or X'00000000'.
       LOCAL ADDR TYPE/ADDR/PORT: Contains the address and port that
            the client will use to send the UDP datagrams on for this
            association.
       REMOTE ADDR TYPE/ADDR/PORT: Contains the remote (destination)
            address and port that the client wishes to send to or
            receive from.

   It is permissible for a SOCKS client to establish a send or receive
   association to the same remote address in one UDP BIND operation, or
   by sending a another UDP BIND.  Subsequent UDP BINDs SHOULD include
   the existing AID rather than establishing an entirely new AID for

Chouinard                                                      [Page 9]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

   the reverse direction, though the addressing information MUST still
   be included.

   SOCKS client implementations are free to choose how many and which
   UDP sockets they control over a single TCP control connection.  For
   example, a SOCKS client may control all UDP sockets for the entire
   client over a single control connection.  Alternatively, it could
   group only those UDP sockets being used by a given process over a
   single control connection.  It could even degenerate into the SOCKS
   V5 model of creating a control channel for each UDP socket, though
   this practice is not recommended.

   4.3.1.2. Reply Processing

   The reply to a UDP BIND will contain the following information:

       PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02')
       SIZE: Total size (in octets) of this message, in network order.
       REPLY: succeeded (X'00') or specific failure.  Note: if the
            SOCKS server cannot entirely satisfy the request, it MUST
            fail the request, and send back an appropriate failure
            code.
       FLAGS: Contains a bit-wise OR of the parts of the request that
            the SOCKS server could satisfy (even if the entire request
            is failed due to parts that could not be satisfied).
       RSVD: Unused (X’00’).
       TID: Will contain the same value as that used in the
            corresponding request.

       If the REPLY is a failure, then the remaining fields are not
       populated and SHOULD be 0s.  If REPLY is succeeded, then the
       remaining fields MUST be populated as follows:

       AID: The AID will contain a unique identifier (the SOCKS server
            determines the extent of the uniqueness) that the client
            must use in subsequent UDP commands referring to this
            association.  The AID must also be used in the SOCKS header
            on the UDP datagrams (discussed below).
       LOCAL ADDR TYPE/ADDR/PORT: The Address on the SOCKS server that
            the SOCKS client must send to for UDP datagrams to be
            forwarded.  This is also the address that the SOCKS server
            will send from when forwarding datagrams to the SOCKS
            client.  Note: non-proxy-based SOCKS servers would fill
            this field in with the destination address specified by the
            client in the REMOTE ADDR fields in the UDP BIND.
       REMOTE ADDR TYPE/ADDR/PORT: The address information, specific to
            the interface, that the SOCKS server will send (or receive)
            on, on behalf of the SOCKS client for this particular
            association.  On a multi-homed SOCKS server, this address
            is usually not reachable by the SOCKS client, but is
            reachable by the host on the remote side of the SOCKS
            server. Note: non-proxy-based SOCKS servers would fill this
            field in with the client’s local address specified by the
            client in the LOCAL ADDR fields in the UDP BIND.

Chouinard                                                     [Page 10]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997


   If a UDP Control Channel is closed, the SOCKS Server MUST release
   all associations established on that control channel.  Thus,
   implementations should not necessarily close the control connection
   if a UDP BIND fails (as was common practice in SOCKS V5 when a UDP
   ASSOCIATE failed), unless there are no other UDP associations active
   or the implementation desires this behavior.

   4.3.2.  UDP RELEASE

   4.3.2.1. Request

   The SOCKS client sends the UDP RELEASE command when a previously
   established association is to be terminated.  The UDP RELEASE must
   contain the AID for the particular UDP association to be terminated.
   It MUST also contain the appropriate flag(s) for which the
   association is to be released.

       PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01')
       SIZE: Total size (in octets) of this message, in network order.
       UDP CMD: UDP RELEASE (X'06')
       FLAGS: Contains a bit-wise OR of one or more of the following:
            RECEIVE-FROM (X’0001’)
            SEND-TO (X’0002’)
            Note: it is permissible for an implementation to send X’03’
            (an OR of RECEIVE-FROM and SEND-TO) even if it had
            previously only established a send or receive association,
            but not both.
       RSVD: Unused (X’00’).
       TID: contains a unique value (chosen by the client) that enables
            the client to identify the reply to this particular
            request.
       AID: Association Identifier that identifies the UDP association
            to be released.

   4.3.2.2. Reply Processing

   The SOCKS Server will send a REPLY to a UDP RELEASE with the
   following fields populated:

       PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02')
       SIZE: Total size (in octets) of this message, in network order.
       REPLY: succeeded (X'00') or specific failure
       FLAGS: Same as those specified in the request.
       RSVD: Unused (X’00’).
       TID: Will contain the same value as that used in the
            corresponding request.
       AID: Association Identifier contained in the UDP RELEASE

   4.4. Procedure for TCP-Encapsulation

   Once a client has established an association ID for TCP-encapsulated
   data transmission, then it must send the encapsulated data over the
   UDP control channel using the following packet structure:

Chouinard                                                     [Page 11]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997


      +-------------+----------+---------+-----------------+
      |PKT TYPE (1) | SIZE (2) | AID (4) | DATA (variable) |
      +-------------+----------+---------+-----------------+

       PKT TYPE: SOCKS-UDP-DATA-REQUEST (X'03')
       SIZE: Total size (in octets) of this message, in network order.
       AID: Association ID
       DATA: Application data.  Note: The size of the application data
            is SIZE – 7.

   There is no reply to a SOCKS-UDP-DATA-REQUEST.  The SOCKS server
   either silently relays the request or discards the packet if it
   cannot or will not relay it.

   The programming interface MUST report an available buffer space for
   UDP datagrams that is no more than 65,529 decimal (2^16 – 7) since
   the two-byte size field in the header includes the 7-byte header
   itself.

   It is permissible for a client to establish and control multiple UDP
   associations (TCP-encapsulated or otherwise) over a single control
   channel.  Thus, SOCKS clients and servers that support TCP-
   encapsulation MUST support receiving SOCKS-UDP-DATA-REQUEST and
   SOCKS-UDP-CONTROL-REQUEST packets on the same control connection.

   4.5. Procedure for UDP-based Clients

   In a manner similar to SOCKS V5, a UDP-based client operating in
   enhanced UDP mode MUST send its datagrams to the UDP relay server at
   the UDP port indicated by LOCAL ADDR and PORT in the reply to the
   UDP BIND request.  If the selected authentication method provides
   encapsulation for the purposes of authenticity, integrity, and/or
   confidentiality, the datagram MUST be encapsulated using the
   appropriate encapsulation.

   Each UDP datagram carries a UDP request header with it (note this
   request header differs significantly from that used in SOCKS V5).

      +---------+----------+----------+---------+-----------------+
      | RSV (1) | FRAG (1) | DGID (2) | AID (4) | DATA (variable) |
      +---------+----------+----------+---------+-----------------+

   The fields in the UDP Data header are:

       RSV:  Reserved X'00'
       FRAG: Current fragment number
          00 = standalone (not fragmented)
          1-127 = fragment # specific to this DGID
          MSB set (128-255) = End of fragment
       DGID: Datagram Identifier – opaque Identifier that uniquely
            identifies the fragments of a specific datagram
       AID: Association Identifier
       DATA: user data

Chouinard                                                     [Page 12]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997


   As in SOCKS V5, when a UDP relay server decides to relay a UDP
   datagram, it does so silently, without any notification to the
   requesting client.   Similarly, it will drop datagrams it cannot or
   will not relay.

   Furthermore, when a UDP relay server receives a reply datagram from
   a remote host, it MUST encapsulate that datagram using the above UDP
   request header and any authentication-method-dependent
   encapsulation.

   The SOCKS server must ensure that only datagrams originated from the
   expected remote host (i.e., the one designated in the REMOTE ADDR
   information in the UDP BIND) are relayed to the SOCKS client.  Any
   datagrams arriving from a source IP address other than the one
   recorded for the particular association MUST be dropped.

   The programming interface on the SOCKS client MUST report an
   available buffer space for UDP datagrams that is 8-Bytes smaller
   that the actual space provided by the operating system.  This allows
   for the SOCKS UDP data header.

   Fragmentation is optional and is handled the same as that documented
   in [RFC-1928], with the following exception:

       * When fragmentation is supported and a datagram is fragmented,
          the DGID field MUST be populated with a unique value that
          remains constant for all fragments of the particular datagram
          on the particular association.  Note: DGID MUST be unique to
          the degree that no other SOCKS data header with the same AID
          uses the same value until the last fragment of a given
          datagram is transmitted.  Implementations are encouraged to
          preserve the uniqueness longer by using a monotonically
          increasing counter for each datagram that is fragmented.  The
          receiving end of the fragments can use the DGID to ensure
          that all fragments of the *same* datagram are received
          properly before passing the datagram up to the application
          layer.

5.   Multicast Extensions

   If during feature discovery (described in Section 3), a SOCKS server
   advertises support for the Multicast UDP extensions, then the SOCKS
   client and server must follow the guidelines set forth in this
   section as well as support the base-level UDP extensions specified
   in Section 4 (for multicast usage).  The procedure for the SOCKS
   client to indicate to the SOCKS server that it wants to use the
   multicast extensions is the same as that described in Section 4.1.1
   and is summarized below.

       1. SOCKS client does feature discovery to the SOCKS server and
          learns whether or not Multicast UDP extensions are supported
       2. If so, the SOCKS client may send ENHANCED_UDP_MODE command


Chouinard                                                     [Page 13]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

       3. After a successful reply, the SOCKS client may use the
          multicast extensions.

   5.1. Assumptions and Requirements

   The following list provides some assumptions and requirements about
   the deployment and usage of SOCKS in a multicast environment.  The
   actual protocol details in the next section are in large part
   derived from these assumptions.


       * A Multicast-capable SOCKS Server (MSS) is a SOCKS server that
          supports the multicast extensions defined below.  It MAY also
          support all of the SOCKS V5 capabilities defined in [RFC-
          1928], including TCP services.  However, a MSS could be
          dedicated for multicast usage only.
       * A Multicast-capable SOCKS Client (MSC) configuration will
          specify the MSS address, as well as the range of class D IP
          addresses and TTL for which it must use the MSS.
       * The MSS is not required to have the capabilities of a
          multicast router (mrouter) built into it.  A MSS could
          coexist with a mrouter, collectively forming a barrier
          between an internal and external multicast network (e.g.,
          Mbone) through which all multicast traffic must pass in order
          to enter or leave the internal network.  See Figure 1 below
          for an example of such an arrangement.

                  _________         ______         ____________
                 |         |       |      |       /  Internal  \
         ========| Mrouter |-------| MSS  |------|    Network   |
                 |_________|       |______|       \____________/
         tunnel to                                      |
        external net                                  __|___
         (mbone)                                     |      |
                                                     | MSC  |
                                                     |______|

             Figure 1: Example Usage of a SOCKS Multicast Server

          Other possibilities exist where perhaps the MSC exists on the
          "external" network.  However, for the purpose of the
          discussion in Section 5, the MSC is assumed to be on the
          "internal" network, and internal and external are relative to
          Figure 1.

       * The MSS SHOULD support two different modes of operation for
          multicast:

          * Multicast-to-Unicast Mode (MU-mode) - the MSS receives
            packets from an external multicast group and unicasts them
            to internal MSCs who have established a receive association
            to that group.  Similarly, any packets received from an
            internal MSC are multicast externally, as well as unicast



Chouinard                                                     [Page 14]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

            to the other MSCs that have a receive association to the
            particular multicast group address.

          * Multicast-to-Multicast Mode (MM-mode) - the MSS receives
            packets from an external multicast group and multicasts
            them to internal MSCs on the same multicast group address.
            Similarly, packets received by the MSS from an internal MSC
            on a particular multicast address are multicast externally
            on the same address.

            MM-mode provides less control than MU-mode in that non-SMCs
            could listen to a group address once it's allowed in.
            However, MM-mode significantly increases efficiency and
            scalability since it needs only to multicast a given
            datagram once rather than unicasting a copy to each SMC
            with an association to the multicast group.

            When operating in MM-mode, no UDP data headers will be used
            on datagrams since authentication-method-dependent
            encapsulation is not currently possible for a group; hence,
            handling fragmentation is not an issue.  Note: in order to
            support encapsulation, an authentication-method-dependent
            procedure is needed to securely distribute shared security
            parameters to each of the members of a particular group.
            This mechanism is currently not defined, and is for further
            study.

          How the mode is configured on the MSS, and whether it applies
          globally, on a user basis, or a multicast group basis, is
          implementation dependent.

       * In both modes, the MSS MUST NOT forward packets from internal
          hosts that have not authenticated themselves to the MSS and
          received permission to receive from or send to a multicast
          group.

       * MSSs SHOULD support filtering/blocking of externally
          originated multicast datagrams based on a configurable list
          of source addresses. This allows an MSS to be aware of other
          MSSs that share the same border between the two networks
          (e.g., corporate network and the Internet), enabling it to
          filter potential duplicate packets that originated from one
          of the other MSSs.

       * The implementation of a MSS may or may not be based on a
          proxy architecture.  Typically, SOCKS servers have been
          implemented as a proxy; in such case, the UDP streams are
          received by a process on the MSS and then retransmitted (in
          either MU-MODE or MM-MODE fashion).  Alternatively, an MSS
          could be implemented in such a way that the UDP datagrams are
          not proxied at the application layer, but routed at the
          network layer.  In this case, SOCKS acts as a control
          protocol to a mrouter-like device in order to dynamically
          modify the multicast UDP filter rules.

Chouinard                                                     [Page 15]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997


   5.2. UDP Control Commands and Flags

   In order to support multicast, the following functionality is needed
   between the MSC and MSS:

       * Start/stop receiving datagrams from a multicast group
       * Start/stop allowing the sending of datagrams to a multicast
          group
       * Change the multicast scope (TTL) that the MSS uses when
          sending (relaying) the datagrams to a multicast group

   To provide these capabilities, the following additions are made to
   the usage of the base-level UDP extensions:

       * Flags are added to the UDP BIND command and reply (UDP-
          MULTICAST, MM-MODE, MU-MODE), which allow the MSC to
          establish a multicast-receive or multicast-send association
          (or both) using a single association ID (AID), as well as to
          request and learn the multicast mode from the MSS.
       * A new UDP command (SET-MCAST-TTL) has been added to control
          the changing of the multicast scope.


   The values for the new command and the command flags are defined as
   follows:

   UDP Command:
       * UDP BIND:
          * command flags
            * UDP-MULTICAST: X’0010’ (16 Decimal) - acts as a modifier
               to the other flags defined in defined in Section 4.3.
            * Multicast-to-Unicast Mode (MU-MODE): X'0020' (32
               Decimal)
            * Multicast-to-multicast Mode (MM-MODE): X'0040' (64
               Decimal)
       * SET TTL:  X'07'

   The details of the new multicast commands/flags follow below.

   5.2.1.  Receiving From a Multicast Group

   5.2.1.1. Request

   A UDP BIND command containing both the RECEIVE-FROM and UDP-
   MULTICAST FLAGs set, indicates the MSC's desire to receive packets
   from a particular multicast group.  If the MSC has already
   established an association to this multicast group on the same
   socket (via the SEND-TO/UDP-MULTICAST flags), then the MSC SHOULD
   include the existing AID.  Note: while it is possible for the SMC to
   create an entirely new AID, it is potentially more wasteful on the
   MSS, and is not recommended.




Chouinard                                                     [Page 16]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

   As in the base-level UDP extensions, a client implementation MAY
   establish both a send and receive association in one or two UDP BIND
   operations.  If the MSC groups the send and receive request together
   and the MSS can not satisfy the entire request, the reply to the UDP
   BIND will fail with an appropriate failure and the FLAGS SHOULD be
   set with what the MSC is permitted to do (relative to what was
   requested).

   The MSC MUST populate the following fields:

       PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01')
       SIZE: Total size (in octets) of this message, in network order.
       UDP CMD: UDP BIND (X'05')
       FLAGS: Bitwise OR of RECEIVE-FROM and UDP-MULTICAST.  May
            optionally include MM-MODE and/or MU-MODE to indicate the
            MSC’s preference of the mode.  If both flags are included
            or excluded, the client has no preference.  The MSS is not
            obligated to honor the MSC’s preference, but SHOULD if
            possible (i.e., it doesn’t violate security policy).
            Additionally, the use of TCP-ENCAPSULATED-UDP is allowed
            with RECEIVE-FROM and UDP-MULTICAST, and is mutually
            exclusive with the MM-MODE flag.
       RSVD: Unused (X’00’).
       TID: Unique Transaction ID generated by the MSC.
       AID: Contains an existing association ID if a send-association
            already exists on this same socket to the same multicast
            group or X'00000000'.
       LOCAL ADDR TYPE/ADDR/PORT: contains the unicast address and port
            (on the MSC) that the MSS will use if MU-mode is employed.
       REMOTE ADDR TYPE/ADDR/PORT: contains the multicast group address
            that the MSC desires to join.

   5.2.1.2. Reply Processing

   The successful response to this command will contain the following
   fields populated by the MSS:

       PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02')
       SIZE: Total size (in octets) of this message, in network order.
       REPLY: one of:
          * X’00’ Succeeded
          * X'10' Bad Association ID
          * X'11' Multicast Receive not allowed by ruleset
          * X'12' Multicast Send not allowed by ruleset
          * X'14' Bad multicast address
          Note: if the SOCKS server cannot entirely satisfy the
               request, it MUST fail the request, and send back an
               appropriate failure code.
       FLAGS: Contains a bit-wise OR of the parts of the request that
            the SOCKS server could satisfy (even if the entire request
            is failed due to parts that could not be satisfied)
            including selection of the multicast mode.
       RSVD: Unused (X’00’).


Chouinard                                                     [Page 17]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

       TID: Contains the MSC-generated transaction ID in the
            corresponding request.
       AID: Unique Identifier for this association.
       LOCAL ADDR TYPE/ADDR/PORT: If MU-Mode is used, these fields
            contain the unicast address and port on the MSS that the
            MSC will receive datagrams from.
       REMOTE ADDR TYPE/ADDR/PORT: Contains the multicast group address
            that the MSC requested to join.

   Upon receiving a successful reply, a multicast receive association
   has been established between the MSC and MSS, and the MSC may begin
   receiving any traffic generated to the group address.  However,
   before the MSC can send to the group, it must establish a "send
   association" by following the procedure in Section 5.2.2.

   5.2.2.  Sending to a Multicast Group

   5.2.2.1. Request

   A UDP BIND command containing both the SEND-TO and UDP-MULTICAST
   FLAGs set indicates the MSC's desire to send to a particular
   multicast group.  This command must be issued by the MSC regardless
   if the MSC has already established a receive-association (by using
   UDP BIND with the RECEIVE-FROM/UDP-MULTICAST flags). If the MSC has
   already established a receive association to this multicast group on
   the same socket, then the MSC SHOULD include the existing AID.
   Note: while it is possible for the SMC to create an entirely new
   AID, it is potentially more wasteful on the MSS, and is not
   recommended.

   The MSC MUST populate the following fields:

       PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01')
       SIZE: Total size (in octets) of this message, in network order.
       UDP CMD: UDP BIND (X'05')
       FLAGS: Bitwise OR of SEND-TO and UDP-MULTICAST.  May optionally
            include MM-MODE and/or MU-MODE to indicate the MSC’s
            preference of the mode.  If both flags are included or
            excluded, the client has no preference.  The MSS is not
            obligated to honor the MSC’s preference, but SHOULD if
            possible (i.e., it doesn’t violate security policy).
            Additionally, the use of TCP-ENCAPSULATED-UDP is allowed
            with SEND-TO and UDP-MULTICAST, and is mutually exclusive
            with the MM-MODE flag.
       RSVD: Contains the TTL value (1-255) the MSS should use during
            transmission to the multicast group.
       TID: Unique Transaction ID generated by the MSC.
       AID: Contains an existing association ID if a receive-
            association already exists on this same socket to the same
            multicast group or X'00000000'.
       LOCAL ADDR TYPE/ADDR/PORT: Contains the unicast address and port
            (on the MSC) that the MSS will receive from if MU-mode is
            employed.


Chouinard                                                     [Page 18]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

       REMOTE ADDR TYPE/ADDR/PORT: Contains the multicast group address
            that the MSC desires to send to.

   Upon receiving a successful reply, a multicast send-association has
   been established between the MSC and MSS.

   5.2.2.2. Reply Processing

   The response to this command will contain the following fields
   populated:

       PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02')
       SIZE: Total size (in octets) of this message, in network order.
       REPLY: one of:
          * X'10' Bad Association ID
          * X'11' Multicast Receive not allowed by ruleset
          * X'12' Multicast Send not allowed by ruleset
          * X'14' Bad multicast address
       FLAGS: if REPLY is succeeded, then contains a bit mask
            containing the mode selected by the MSS
            Multicast-to-Unicast Mode (MU-MODE): X'0020'
            or
            Multicast-to-multicast Mode (MM-MODE): X'0040'
       RSVD: Unused (X’00’).
       TID: Contains the MSC-generated transaction ID in the
            corresponding request.
       AID: Unique Identifier for this association.
       LOCAL ADDR TYPE/ADDR/PORT: If REPLY is succeeded and FLAGS is
            MU-Mode, these fields contain the unicast address and port
            on the MSS that the MSC MUST send datagrams to for them to
            be relayed to the multicast group.
       REMOTE ADDR TYPE/ADDR/PORT: If REPLY is succeeded and FLAGS is
            MM-Mode, these fields contain the multicast address and
            port that the MSC MUST send datagrams to for them to be
            relayed to the multicast group specified in the request.
            Typically this would be the same as that specified in the
            request.

   5.2.3.  Releasing a Multicast Association

   Releasing a multicast send or receive association (or both) is
   identical to the procedure described for the base-level UDP
   extensions in Section 4.3.2.

   5.2.4.  Setting the TTL

   5.2.4.1. Request

   The SOCKS MSC uses the SET TTL command to instruct the MSS of the
   TTL (Time-to-Live) value that it SHOULD use when sending datagrams
   to a particular multicast group.  This command is only valid for an
   established multicast send association.

       PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01')


Chouinard                                                     [Page 19]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

       SIZE: Total size (in octets) of this message, in network order.
       UDP CMD: SET TTL (X'07')
       FLAGS:  unused (X'0000')
       RSVD: Contains the TTL value (1-255) the MSS should use during
            transmission to the multicast group.
       TID: Unique Transaction ID generated by the MSC.
       AID: Contains an existing association ID.

   5.2.4.2. Reply Processing

   The reply to a SET TTL will be populated as follows:

       PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02')
       SIZE: Total size (in octets) of this message, in network order.
       REPLY: one of:
          succeeded (X'00')
          Bad Association ID (X'10')
          Bad Association context (X'13') - No send association is
          established
          TTL value not allowed by ruleset (X'15') – TTL value is too
          high
       TID: Contains the MSC-generated transaction ID in the
            corresponding request.
       FLAGS: Unused (X'0000')
       AID: Unique Identifier for this association.

6.   Security Considerations

   This document describes extensions to [RFC-1928] which itself is a
   security protocol for the session-layer traversal of IP network
   firewalls.  As in [RFC-1928], the security of firewall traversal is
   highly dependent on the authentication and encapsulation methods
   provided by a particular implementation, and selected during the
   negotiation between the SOCKS client and SOCKS server.

   Multicast-specific considerations include:

       * MM-Mode vs. MU-Mode: MU-Mode is more secure than MM-Mode for
          two reasons:
          1.) Packets are specifically unicast from the SOCKS server to
              the SOCKS client, and vice-versa, making them harder
              (than MM-Mode) to intercept for eavesdroppers;
          2.)  Authentication-method-dependent encapsulation is
               supported in MU-Mode, but not MM-Mode.  Thus, in MU-
               Mode, it is possible for the SOCKS server to use packet-
               level authentication in determining whether to forward a
               packet, whereas in MM-Mode, it must resort to inspecting
               the source IP address.
          For many environments, the added performance and scalability
          offered by MM-Mode may outweigh the additional security
          offered by MU-Mode.  Administrators should carefully
          understand the tradeoffs.
       * SOCKS client implementations SHOULD optionally support
          getting user confirmation upon attempting to send multicast

Chouinard                                                     [Page 20]


Internet Draft  SOCKS V5 UDP and Multicast Extensions    Nov 17, 1997

          traffic through a SOCKS server.  This helps prevent the
          unintentional multicasting of data beyond an organizational
          boundary.
       * SOCKS Server implementations MAY perform content filtering in
          cases where, based on addressing or other means, the server
          knows what the content should be.  For example, since the
          class D addresses in the range of 224.2.*.* are reserved for
          conferencing, a SOCKS server could ensure the UDP traffic is
          encapsulated in RTP/RTCP headers.

7.   Acknowledgments

   This document benefited from the thoughtful insights and comments
   from Marc Vanheyningen, Wei Lu, Jamie Jason, and Kira Attwood.

8.   References

   [RFC-2119] Bradner, S, "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, Harvard University, March
               1997.
   [RFC-1928] Leech, M., et. al., "SOCKS Protocol Version 5", RFC
               1928, March 1996.
   [SOCKS5]   Leech, M., et. al., "SOCKS Protocol Version 5", March
               1997, work in progress.
   [Van97]    VanHeyningen, M., "Feature Discovery: A Generic
               Mechanism for SOCKS Version 5", July 1997, work in
               progress.
9.   Disclaimer

   The views and specification herein are those of the author and are
   not necessarily those of his employer.  The author and his employer
   specifically disclaim responsibility for any problems arising from
   correct or incorrect implementation or use of this specification.

10.  Authors' Address

   Dave Chouinard
   Intel Corporation
   MS JF3-206
   2111 NE 25th Ave.
   Hillsboro, OR, USA  97124
   +1(503)264-7481
   dave_chouinard@mail.intel.com













Chouinard                                                     [Page 21]


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