AFT Working Group D. Chouinard Internet Draft Intel Corporation Expires on January 23, 1998 July 23, 1997 SOCKS V5 UDP and Multicast Extensions draft-chouinard-aft-socksv5-mult-00.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 describes extensions to the SOCKS v5 protocol [RFC- 1928] that make it more useful for networked-multimedia applications that use UDP and multicast services. The extensions are broken into two parts: Base-level UDP extensions, and Multicast UDP extensions. The Base-level UDP extensions augment SOCKS V5 by addressing current deficiencies in [RFC-1928] (such as supporting multihomed-SOCKS servers and properly supporting fragmentation) and by adding several performance enhancements, including the ability to control multiple UDP associations over a single SOCKS TCP control connection The Multicast extensions build on the foundation provided by the base-level UDP extensions, and allow a Multicast-capable SOCKS Client (MSC) to send and/or receive datagrams to/from one or more multicast groups through a Multicast-capable SOCKS Server (MSS). These protocol extensions effectively enable the MSS to become a Chouinard [Page 1] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 generic multicast proxy server -- allowing it to enforce security policies relating to who can send multicast traffic out, or bring multicast traffic into, an organization. Table of Contents 1. Conventions used in this document................................2 2. Use of Feature Discovery.........................................2 3. Base-level UDP Extensions........................................3 3.1. SOCKS Requests...................................................4 3.1.1.ENHANCED_UDP_MODE.........................................4 3.2. SOCKS Replies....................................................5 3.3. UDP Control Channel..............................................6 3.3.1.UDP BIND..................................................7 3.3.2.UDP RELEASE...............................................9 3.4. Procedure for TCP-Encapsulation..................................9 3.5. Procedure for UDP-based Clients.................................10 4. Multicast Extensions............................................11 4.1. Assumptions and Requirements....................................11 4.2. UDP Control Commands and Flags..................................13 4.2.1.Receiving From a Multicast Group.........................14 4.2.2.Sending to a Multicast Group.............................15 4.2.3.Releasing a Multicast Association........................17 4.2.4.Setting the TTL..........................................17 5. Security Considerations.........................................18 6. Acknowledgments.................................................18 7. References......................................................18 8. Disclaimer......................................................19 9. Authors' Address................................................19 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. 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 3.1.1. The values are: Value Description -------------------------------------------------------- X'01' Base-level UDP extensions (covered in Section 3) X'02' Multicast UDP extensions (covered in Section 4) Chouinard [Page 2] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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 4. 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). 3. 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 4). 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: * 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]) Chouinard [Page 3] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 * 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). 3.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' 3.1.1. ENHANCED_UDP_MODE 3.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. 3.1.1.2. Reply 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'. Chouinard [Page 4] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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 3.3. 3.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. * LOC ADDR TYPE/ADDR/PORT: Addressing information on the local side of the SOCKS server; that is, on the same side as the Chouinard [Page 5] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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. 3.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 3.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. The use of these fields is command dependent and is further described below. Chouinard [Page 6] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 3.3.1. UDP BIND 3.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 3.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 3.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 the reverse direction. Chouinard [Page 7] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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. 3.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. 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. 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. Chouinard [Page 8] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 3.3.2. UDP RELEASE 3.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. 3.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 3.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: +-------------+----------+---------+-----------------+ |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. Chouinard [Page 9] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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. 3.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 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. Chouinard [Page 10] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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. 4. Multicast Extensions If during feature discovery (described in Section 2), 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 3 (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 3.1.1 and is summarized below. 1. SOCKS client does feature discovery to SOCKS server and learns whether or not Multicast UDP extensions are supported 2. If so, the SOCKS client may send ENHANCED_UDP_MODE command 3. After a successful reply, the SOCKS client may use the multicast extensions. 4.1. Assumptions and Requirements The following list provides some assumptions and requirements about the deployment and usage of SOCKS in a multicast environment. The Chouinard [Page 11] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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 4, 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 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 Chouinard [Page 12] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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. 4.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 Chouinard [Page 13] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 (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 3.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. 4.2.1. Receiving From a Multicast Group 4.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. 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). Chouinard [Page 14] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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. 4.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’). 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 4.2.2. 4.2.2. Sending to a Multicast Group 4.2.2.1. Request Chouinard [Page 15] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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. 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. 4.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 Chouinard [Page 16] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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. 4.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 3.3.2. 4.2.4. Setting the TTL 4.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') 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. 4.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 Chouinard [Page 17] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 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. 5. 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 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. 6. Acknowledgments This document benefited from the thoughtful insights and comments from Marc Vanheyningen, Wei Lu, Jamie Jason, and Kira Attwood. 7. References Chouinard [Page 18] Internet Draft SOCKS V5 UDP and Multicast Extensions July 23, 1997 [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. 8. 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. 9. Authors' Address Dave Chouinard Intel Corporation MS JF3-206 2111 NE 25th Ave. Hillsboro, OR, USA 97124 +1(503)264-7481 dchouinard@ibeam.intel.com Chouinard [Page 19]