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
Whats 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
organizations 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. Whats
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: X0002
* UDP-UNICAST: X0004
* TCP-ENCAPSULATED: X0008 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 (X00).
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 (X00).
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 clients 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 (X0001)
SEND-TO (X0002)
Note: it is permissible for an implementation to send X03
(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 (X00).
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 (X00).
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: X0010 (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
MSCs preference of the mode. If both flags are included
or excluded, the client has no preference. The MSS is not
obligated to honor the MSCs preference, but SHOULD if
possible (i.e., it doesnt 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 (X00).
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:
* X00 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 (X00).
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 MSCs
preference of the mode. If both flags are included or
excluded, the client has no preference. The MSS is not
obligated to honor the MSCs preference, but SHOULD if
possible (i.e., it doesnt 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 (X00).
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]
