draft-ietf-aft-socks-protocol-v5-01.txt   draft-ietf-aft-socks-protocol-v5-02.txt 
Socks Protocol Version 5 Socks Protocol Version 5
INTERNET-DRAFT INTERNET-DRAFT
Expires: In Six Months M. Leech Expires: In Six Months M. Leech
<draft-ietf-aft-socks-protocol-v5-01.txt> M. Ganis <draft-ietf-aft-socks-protocol-v5-02.txt> M. Ganis
Y. Lee Y. Lee
R. Kuris R. Kuris
D. Koblas D. Koblas
L. Jones L. Jones
SOCKS Protocol Version 5 SOCKS Protocol Version 5
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft document valid for a maximum of six months Internet-Drafts are draft document valid for a maximum of six
and may be updated, replaced or obsoleted by other documents at any months and may be updated, replaced or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress". reference material or to cite them other than as "work in
progress".
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
Acknowledgments Acknowledgments
This memo describes a protocol that is an evolution of the previous This memo describes a protocol that is an evolution of the previous
version of the protocol, version 4 [1]. This new protocol stems from version of the protocol, version 4 [1]. This new protocol stems
active discussions and prototype implementations. The key from active discussions and prototype implementations. The key
contributors are: Marcus Leech: Bell-Northern Research, David Koblas: contributors are: Marcus Leech: Bell-Northern Research, David
Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont Koblas: Independent Consultant, Ying-Da Lee: NEC Systems
Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt Laboratory, LaMont Jones: Hewlett-Packard Company, Ron Kuris: Unify
Ganis: International Business Machines. Corporation, Matt Ganis: International Business Machines.
1. Introduction 1. Introduction
The use of network firewalls, systems that effectively isolate an The use of network firewalls, systems that effectively isolate an
organizations internal network structure from an exterior network, organizations internal network structure from an exterior network,
such as the INTERNET is becoming increasingly popular. These firewall such as the INTERNET is becoming increasingly popular. These
systems typically act as application-layer gateways between networks, firewall systems typically act as application-layer gateways
usually offering controlled TELNET, FTP, and SMTP access. With the between networks, usually offering controlled TELNET, FTP, and SMTP
emergence of more sophisticated application layer protocols designed access. With the emergence of more sophisticated application layer
to facilitate global information discovery, there exists a need to protocols designed to facilitate global information discovery,
provide a general framework for these protocols to transparently and there exists a need to provide a general framework for these
securely traverse a firewall. protocols to transparently and securely traverse a firewall.
There exists, also, a need for strong authentication of such There exists, also, a need for strong authentication of such
traversal in as fine-grained a manner as is practical. This traversal in as fine-grained a manner as is practical. This
requirement stems from the realization that client-server requirement stems from the realization that client-server
relationships emerge between the networks of various organizations, relationships emerge between the networks of various organizations,
and that such relationships need to be controlled and often strongly and that such relationships need to be controlled and often
authenticated. strongly authenticated.
The protocol described here is designed to provide a framework for The protocol described here is designed to provide a framework for
client-server applications in both the TCP and UDP domains to client-server applications in both the TCP and UDP domains to
conveniently and securely use the services of a network firewall. conveniently and securely use the services of a network firewall.
The protocol is conceptually a "shim-layer" between the application
layer and the transport layer, and as such does not provide
network-layer gateway services, such as forwarding of ICMP
messages.
2. Existing practice 2. Existing practice
There currently exists a protocol, SOCKS Version 4, that provides for There currently exists a protocol, SOCKS Version 4, that provides
unsecured firewall traversal for TCP-based client-server for unsecured firewall traversal for TCP-based client-server
applications, including TELNET, FTP and the popular information- applications, including TELNET, FTP and the popular information-
discovery protocols such as HTTP, WAIS and GOPHER. discovery protocols such as HTTP, WAIS and GOPHER.
This protocol extends the SOCKS Version 4 model to include UDP, and This new protocol extends the SOCKS Version 4 model to include UDP,
extends the protocol to include provisions for generalized strong and extends the framework to include provisions for generalized
authentication schemes, and extends the addressing scheme to strong authentication schemes, and extends the addressing scheme to
encompass domain-name and V6 IP addresses. The implementation of the encompass domain-name and V6 IP addresses.
SOCKS protocol typically involves the recompilation or relinking of
TCP-based client applications to use the appropriate encapsulation The implementation of the SOCKS protocol typically involves the
routines in the SOCKS library. recompilation or relinking of TCP-based client applications to use
the appropriate encapsulation routines in the SOCKS library.
3. Procedure for TCP-based clients 3. Procedure for TCP-based clients
When a TCP-based client wishes to establish a connection to an object When a TCP-based client wishes to establish a connection to an
that is reachable only via a firewall (such determination is left up object that is reachable only via a firewall (such determination is
to the implementation), it must open a TCP connection to the left up to the implementation), it must open a TCP connection to
appropriate SOCKS port on the SOCKS server system. The SOCKS service the appropriate SOCKS port on the SOCKS server system. The SOCKS
is conventionally located on TCP port 1080. If the connection request service is conventionally located on TCP port 1080. If the
succeeds, the client enters a negotiation for the authentication connection request succeeds, the client enters a negotiation for
method to be used, authenticates with the chosen method, then sends a the authentication method to be used, authenticates with the chosen
relay request. The SOCKS server evaluates the request, and either method, then sends a relay request. The SOCKS server evaluates the
establishes the appropriate connection or denies it. request, and either establishes the appropriate connection or
denies it.
The client connects to the server, and sends a version The client connects to the server, and sends a version
identifier/method selection packet: identifier/method selection message:
+----+----------+----------+------+ +----+----------+----------+
|VER | NMETHODS | METHODS | MACS | |VER | NMETHODS | METHODS |
+----+----------+----------+------+ +----+----------+----------+
| 1 | 1 | 1 to 255 | 1 | | 1 | 1 | 1 to 255 |
+----+----------+----------+------+ +----+----------+----------+
The VER field is set to X'05' for this version of the The VER field is set to X'05' for this version of the
protocol. The NMETHODS field contains the number of protocol. The NMETHODS field contains the number of
method identifier octets that appear in the METHODS method identifier octets that appear in the METHODS
field. field.
The server selects from one of the methods given in METH- The server selects from one of the methods given in
ODS, and a MAC algorithm, then sends a selection indica- METHODS, and sends a METHOD selection message:
tor:
+----+--------+--------+ +----+--------+
|VER | METHOD | MACSEL | |VER | METHOD |
+----+--------+--------+ +----+--------+
| 1 | 1 | 1 | | 1 | 1 |
+----+--------+--------+ +----+--------+
If the selection indicator is X'FF', none of the METHODS If the selected METHOD is X'FF', none of the methods
listed by the client are acceptable, and the server MUST listed by the client are acceptable, and the client
close the connection. MUST close the connection.
The values currently defined for METHOD are: The values currently defined for METHOD are:
o X'00' NO AUTHENTICATION REQUIRED o X'00' NO AUTHENTICATION REQUIRED
o X'01' BNR-1 o X'01' GSSAPI
o X'02' GSSAPI o X'02' USERNAME/PASSWORD
o X'03' IKMP
o X'04' KERBEROS4
o X'05' KERBEROS5
o X'06' USERNAME/PASSWORD
o X'07' SECURE TOKEN TYPE 1 (NO CHALLENGE/RESPONSE)
o X'08' SECURE TOKEN TYPE 2 (CHALLENGE/RESPONSE)
o X'09' S/KEY
o X'0A' to X'FE' RESERVED
o X'FF' NO ACCEPTABLE METHODS
The client and server then enter a method-specific subne- o X'03' to X'7F' IANA ASSIGNED
gotiation.
Descriptions of the method-dependant subnegotiations o X'80' to X'FE' RESERVED FOR PRIVATE METHODS
appear in separate drafts.
The MACS field contains a bit-vector indicating the MAC o X'FF' NO ACCEPTABLE METHODS
algorithms available to the client. Bits are labelled
from most-significant (0) to least significant (7):
o 0 - MD5 with 64-bit compression [2] The client and server then enter a method-specific sub-
o 1 - MD5 with no compression (complete digest of 128 bits) negotiation. Descriptions of the method-dependent sub-
o 2 - SHA with 80-bit compression [3] negotiations appear in separate drafts.
o 3 - SHA with no compression (complete digest of 160 bits)
The MACSEL field indicates which MAC algorithm that the Developers of new METHOD support for this protocol
server wishes the client to use during computation of the should contact IANA for a METHOD number. The ASSIGNED
MAC field for UDP relay requests. A compliant implementa- NUMBERS document should be referred to for a current
tion MUST support both compressed and uncompressed MD5. list of METHOD numbers and their corresponding proto-
cols.
Compliant implementations MUST support both GSSAPI and
USERNAME/PASSWORD authentication methods.
4. Requests 4. Requests
Once the method-dependant subnegotiation has completed, Once the method-dependent subnegotiation has completed,
the client sends the request details. If the negotiated the client sends the request details. If the negoti-
method includes encapsulation for purposes of integrity ated method includes encapsulation for purposes of
checking/and or confidentiality, these requests MUST be integrity checking and/or confidentiality, these
encapsulated in the method-dependant encapsulation. requests MUST be encapsulated in the method-dependent
encapsulation.
The SOCKS request is formed as follows: The SOCKS request is formed as follows:
+----+-----+-------+------+----------+----------+ +----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT | |VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+ +----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 | | 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+ +----+-----+-------+------+----------+----------+
Where: Where:
o VER protocol version: X'05' o VER protocol version: X'05'
o CMD o CMD
o CONNECT X'01' o CONNECT X'01'
o BIND X'02' o BIND X'02'
o UDP ASSOCIATE X'03' o UDP ASSOCIATE X'03'
o UDP DESTROY X'04'
o RSV RESERVED o RSV RESERVED
o ATYP address type of following address o ATYP address type of following address
o IP V4 address: X'01' o IP V4 address: X'01'
o DOMAINNAME: X'03' o DOMAINNAME: X'03'
o IP V6 address: X'04' o IP V6 address: X'04'
o DST.ADDR desired destination address o DST.ADDR desired destination address
o DST.PORT desired destination port in network octet order o DST.PORT desired destination port in network octet order
The SOCKS server will evaluate the request based on The SOCKS server will typically evaluate the request
source and destination addresses, and return one or more based on source and destination addresses, and return
reply packets, as appropriate for the request type. one or more reply messages, as appropriate for the
request type.
5. Addressing 5. Addressing
In an address field (DST.ADDR, BND.ADDR), the ATYP
In an address field (DST.ADDR, BND.ADDR), the ATYP field field specifies the type of address contained within
specifies the type of address contained within the field: the field:
o X'01' o X'01'
the address is a version-4 IP address, with a length of 4 the address is a version-4 IP address, with a length of
octets 4 octets
o X'03' o X'03'
the address field contains a DNS-style domain name. The the address field contains a DNS-style domain name.
first octet of the address field contains the length of The first octet of the address field contains the
the domain name. length of the domain name.
o X'04' o X'04'
the address is a version-6 IP address, with a length of the address is a version-6 IP address, with a length of
16 octets. 16 octets.
6. Replies 6. Replies
The SOCKS request information is sent by the client as The SOCKS request information is sent by the client as
soon as it has established a connection to the SOCKS soon as it has established a connection to the SOCKS
server, and completed the authentication negotiations. server, and completed the authentication negotiations.
The server evaluates the request, and returns a reply The server evaluates the request, and returns a reply
formed as follows: formed as follows:
+----+-----+-------+------+----------+----------+--------+ +----+-----+-------+------+----------+----------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT | COOKIE | |VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+--------+ +----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 | 8 | | 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+--------+ +----+-----+-------+------+----------+----------+
Where: Where:
o VER protocol version: X'05' o VER protocol version: X'05'
o REP Reply field: o REP Reply field:
o X'00' succeeded o X'00' succeeded
o X'01' general SOCKS server failure o X'01' general SOCKS server failure
o X'02' connection not allowed by ruleset o X'02' connection not allowed by ruleset
o X'03' Network unreachable o X'03' Network unreachable
o X'04' Host unreachable o X'04' Host unreachable
o X'05' Connection refused o X'05' Connection refused
o X'06' TTL expired o X'06' TTL expired
o X'07' to X'FF' unassigned o X'07' to X'FF' unassigned
o RSV RESERVED o RSV RESERVED
o ATYP address type of following address o ATYP address type of following address
o IP V4 address: X'01' o IP V4 address: X'01'
o DOMAINNAME: X'03' o DOMAINNAME: X'03'
o IP V6 address: X'04' o IP V6 address: X'04'
o BND.ADDR server bound address o BND.ADDR server bound address
o BND.PORT server bound port in network octet order o BND.PORT server bound port in network octet order
o COOKIE extra data used by UDP ASSOCIATE
Fields marked RESERVED (RSV) must be set to X'00'. Fields marked RESERVED (RSV) must be set to X'00'.
If the chosen method includes encapsulation for purposes If the chosen method includes encapsulation for pur-
of authentication, integrity and or confidentiality, the poses of authentication, integrity and/or confidential-
replies are encapsulated in the method-dependant encapsu- ity, the replies are encapsulated in the method-
lation. dependent encapsulation.
In a reply, the BND.ADDR and BND.PORT fields are the CONNECT
SOCKS server address and port number of the outbound con-
nection for a CONNECT request, and contain the SOCKS In the reply to a CONNECT, BND.PORT contains the port
server bind() address for a BIND request. number that the server assigned to connect to the tar-
get host, while BND.ADDR contains the associated IP
address. The supplied BND.ADDR is often different from
the IP address that the client uses to reach the SOCKS
server, since such servers are often multi-homed. It
is expected that the SOCKS server will use DST.ADDR and
DST.PORT, and the client-side source address and port
in evaluating the CONNECT request.
BIND
The BIND request is used in protocols which require the The BIND request is used in protocols which require the
client to accept connections from the server. FTP is a client to accept connections from the server. FTP is a
well-known example, which uses the primary client-to- well-known example, which uses the primary client-to-
server connection for commands and status reports, but server connection for commands and status reports, but
may use a server-to-client connection for transferring may use a server-to-client connection for transferring
data on demand (e.g. LS, GET, PUT). data on demand (e.g. LS, GET, PUT).
It is expected that the client side of an application It is expected that the client side of an application
protocol will use the BIND request only to establish sec- protocol will use the BIND request only to establish
ondary connections after a primary connection is estab- secondary connections after a primary connection is
lished using CONNECT. In is expected that a SOCKS server established using CONNECT. In is expected that a SOCKS
will use DST.ADDR and DST.PORT in evaluating the BIND server will use DST.ADDR and DST.PORT in evaluating the
request. BIND request.
Two replies are sent from the SOCKS server to the client Two replies are sent from the SOCKS server to the
during a BIND operation. The first is sent after the client during a BIND operation. The first is sent
server creates and binds a new socket. The BND.PORT field after the server creates and binds a new socket. The
contains the port number that the SOCKS server assigned BND.PORT field contains the port number that the SOCKS
to listen for an incoming connection. The BND.ADDR field server assigned to listen for an incoming connection.
contains the associated IP address. The client will typi-
cally use these pieces of information to notify (via the
primary or control connection) the application server of
the `rendezvous point'. The second reply occurs only
after the anticipated incoming connection succeeds or
fails. In the second reply, the BND.PORT and BND.ADDR
fields contain the address and port number of the
connecting host.
In the reply to a CONNECT, BND.PORT contains the port The BND.ADDR field contains the associated IP address.
number that the server assigned to connect to the target The client will typically use these pieces of informa-
host, while BND.ADDR contains the associated IP address. tion to notify (via the primary or control connection)
The supplied BND.ADDR is often different from the IP the application server of the rendezvous address. The
address that the client uses to reach the SOCKS server, second reply occurs only after the anticipated incoming
since such servers are often multi-homed. connection succeeds or fails.
The UDP ASSOCIATE request is used to establish an associ- In the second reply, the BND.PORT and BND.ADDR fields
ation within the UDP relay process to handle UDP data- contain the address and port number of the connecting
grams. In the reply to a UDP ASSOCIATE request, the host.
BND.PORT and BND.ADDR fields indicate the port num-
ber/address where the client may send UDP request packets UDP ASSOCIATE
to be relayed. The DST.ADDR and DST.PORT fields are
ignored in a UDP ASSOCIATE request. Once a UDP ASSOCIATE The UDP ASSOCIATE request is used to establish an asso-
request has been processed, the SOCKS server MUST termi- ciation within the UDP relay process to handle UDP
nate the connection. The COOKIE field is used in the com- datagrams. The DST.ADDR field is ignored in a UDP
putation of a Message Authentication Code by the UDP ASSOCIATE request, while the DST.PORT field contains
relay server. The SOCKS server MUST set this field to a the idle-timeout time, in minutes, that an association
random value. The association created by the UDP ASSOCI- is allowed to exist without explicit client-side activ-
ATE request has a specific and site or implementation ity. If DST.PORT is zero, the SOCKS server SHOULD use
dependant lifetime. an administrator-defined default.
In the reply to a UDP ASSOCIATE request, the BND.PORT
and BND.ADDR fields indicate the port number/address
where the client may send UDP request messages to be
relayed. Once a UDP ASSOCIATE request has been pro-
cessed, the SOCKS client MUST terminate the connection.
UDP DESTROY
The UDP DESTROY request is used to destroy an existing
association within the UDP relay process. The DST.ADDR
and DST.PORT fields contain the address and port number
of the UDP relay process corresponding to the associa-
tion to destroy. Once a UDP ASSOCIATE request has been
processed, the SOCKS client MUST terminate the connec-
tion.
When a reply (REP value other than X'00') indicates a When a reply (REP value other than X'00') indicates a
failure, the SOCKS server MUST terminate the TCP connec- failure, the SOCKS server MUST terminate the TCP con-
tion shortly after sending the reply. This must be no nection shortly after sending the reply. This must be
more than 10 seconds after detecting the condition that no more than 10 seconds after detecting the condition
caused a failure. that caused a failure.
If the reply code (REP value of X'00') indicates a suc- If the reply code (REP value of X'00') indicates a suc-
cess, and the request was either a BIND or a CONNECT, the cess, and the request was either a BIND or a CONNECT,
client may now start passing data. If the selected the client may now start passing data. If the selected
authentication method supports encapsulation for the pur- authentication method supports encapsulation for the
poses of integrity, authentication and or confidential- purposes of integrity, authentication and/or confiden-
ity, the data are encapsulated using the method-dependent tiality, the data are encapsulated using the method-
encapsulation. Similarly, when data arrives at the SOCKS dependent encapsulation. Similarly, when data arrives
server for the client, the server MUST encapsulate the at the SOCKS server for the client, the server MUST
data as appropriate for the authentication method in use. encapsulate the data as appropriate for the authentica-
tion method in use.
7. Procedure for UDP-based clients 7. Procedure for UDP-based clients
A UDP-based client must send its datagrams to the UDP A UDP-based client MUST send its datagrams to the UDP
relay server at the UDP port indicated by BND.PORT in the relay server at the UDP port indicated by BND.PORT in
reply to the UDP ASSOCIATE request. Each UDP datagram the reply to the UDP ASSOCIATE 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: carries a UDP request header with it:
+-----+------+----------+----------+---------+----------+ +----+------+------+----------+----------+----------+
|FRAG | ATYP | DST.ADDR | DST.PORT | MAC | DATA | |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+-----+------+----------+----------+---------+----------+ +----+------+------+----------+----------+----------+
| 1 | 1 | Variable | 2 | 8 to 20 | Variable | | 1 | 2 | 1 | Variable | 2 | Variable |
+-----+------+----------+----------+---------+----------+ +----+------+------+----------+----------+----------+
The fields in the UDP request header are: The fields in the UDP request header are:
o RSV Reserved X'0000'
o FRAG Current fragment number o FRAG Current fragment number
o ATYP address type of following addresses: o ATYP address type of following addresses:
o IP V4 address: X'01' o IP V4 address: X'01'
o DOMAINNAME: X'03' o DOMAINNAME: X'03'
o IP V6 address: X'04' o IP V6 address: X'04'
o DST.ADDR desired destination address o DST.ADDR desired destination address
o DST.PORT desired destination port o DST.PORT desired destination port
o MAC Message Authentication Code o DATA user data
When a UDP relay server decides to relay a UDP datagram, When a UDP relay server decides to relay a UDP data-
it does so silently, without any notification to the gram, it does so silently, without any notification to
requesting client. Similarly, it will drop datagrams it the requesting client. Similarly, it will drop data-
cannot or will not relay. When a UDP relay server grams it cannot or will not relay. When a UDP relay
receives a reply datagram from a remote host, it MUST server receives a reply datagram from a remote host, it
encapsulate that datagram using the above UDP request MUST encapsulate that datagram using the above UDP
header. request header, and any authentication-method-dependent
encapsulation.
The UDP relay server MUST acquire from the SOCKS server The UDP relay server MUST acquire from the SOCKS server
the expected IP address of the client that will send the expected IP address of the client that will send
datagrams to the BND.PORT given in the reply to UDP ASSO- datagrams to the BND.PORT given in the reply to UDP
CIATE. It MUST drop any datagrams arriving from any ASSOCIATE. It MUST drop any datagrams arriving from
source IP address other than the one recorded for the any source IP address other than the one recorded for
particular association. the particular association.
Related to each UDP association is a pair of unsigned
32-bit counters. These counters are used to assist in
computing the current value of the MAC field. The MAC
(Message Authentication Code) field contains a message-
digest computation of:
o the XCOOKIE digest
o the counter
o the ATYP
o the DST.ADDR (in network octet order)
o the DST.PORT (in network octet order)
o the DATA
o the XCOOKIE digest
Each algorithm uses a different length of residue after
computing the digest function. For MD5 with 8-octet
compression, the residue is formed by taking octets
0,2,4,6,8,10,12,14 of the digest, and concatenating them
into an 8-octet string. Similarly for SHA, octets
0,2,4,6,8,10,12,14,16,18 are concatenated to form a
10-octet string. For algorithms that don't specify a
compression, the complete digest is used.
The value for the XCOOKIE digest is determined by a mes-
sage-digest consisting of:
o the method-dependant authentication key material
(if any, else 8 octets of X'AA')
o the COOKIE from the UDP ASSOCIATE request
o the method-dependant authentication key material
(if any, else 8 octets of X'AA')
The method-dependant authentication key material MUST be
at least 8 octets in length.
The sender increments its counter after sending the data-
gram, while the receiver increments its counter after
receipt. The receiver MUST be prepared to accept data-
grams whose counter value is several units ahead of the
expected value, due to datagram loss. This is typically
implemented by the receiver looking for a MAC match by
repeatedly incrementing its counter value, and looking
for a match. The receiver does this until either there is
a MAC match, or the tolerance has been exceeded The rec-
ommended counter mismatch tolerance is 7 units.The coun-
ters start at zero.
The FRAG field indicates whether or not this datagram is
one of a number of fragments. The high-order bit indi-
cates end-of-fragment sequence, while a value of X'00'
indicates that this datagram is standalone. Values
between 1 and 127 indicate the fragment position within a
fragment sequence. The implicit counter value increments
on every fragment. Each receiver will have a REASSEMBLY
QUEUE and a REASSEMBLY TIMER associated with these frag-
ments. The reassembly queue must be reinitialized and
the associated fragments abandoned whenever the REASSEM-
BLY TIMER expires, or a new datagram arrives carrying a
FRAG field whose value is less than the highest FRAG
value processed for this fragment sequence. The reassem-
bly timer MUST be no less than 5 seconds. It is strongly
recommended that fragmentation be avoided by applications
wherever possible.
Implementation of fragmentation is optional; an implemen- The FRAG field indicates whether or not this datagram
tation that does not support fragmentation MUST drop any is one of a number of fragments. The high-order bit
datagram whose FRAG field is other than X'00'. indicates end-of-fragment sequence, while a value of
X'00' indicates that this datagram is standalone. Val-
ues between 1 and 127 indicate the fragment position
within a fragment sequence. Each receiver will have a
REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with
these fragments. The reassembly queue must be reini-
tialized and the associated fragments abandoned when-
ever the REASSEMBLY TIMER expires, or a new datagram
arrives carrying a FRAG field whose value is less than
the highest FRAG value processed for this fragment
sequence. The reassembly timer MUST be no less than 5
seconds. It is recommended that fragmentation be
avoided by applications wherever possible.
The UDP relay server MUST drop any datagrams for which Implementation of fragmentation is optional; an imple-
the MAC value is outside of the acceptable range. mentation that does not support fragmentation MUST drop
Repeated occurrences of invalid MAC values should cause any datagram whose FRAG field is other than X'00'.
the UDP relay server to destroy the association.
The programming interface for a SOCKS-aware UDP MUST The programming interface for a SOCKS-aware UDP MUST
report an available buffer space for UDP datagrams that report an available buffer space for UDP datagrams that
is smaller than the actual space provided by the operat- is smaller than the actual space provided by the oper-
ing system: ating system:
o if ATYP is X'01' - 16 octets smaller o if ATYP is X'01' - 10+method_dependent octets smaller
o if ATYP is X'03' - 272 octets smaller o if ATYP is X'03' - 262+method_dependent octets smaller
o if ATYP is X'04' - 28 octets smaller o if ATYP is X'04' - 20+method_dependent octets smaller
The ASSOCIATION established with a UDP ASSOCIATE request The ASSOCIATION established with a UDP ASSOCIATE
has a specific lifetime. It is strongly recommended that request has a specific lifetime. The UDP server SHOULD
this lifetime be extended by the lifetime value every refresh the lifetime every time a valid datagram
time a valid datagram arrives from the client at the UDP arrives from the client at the UDP relay server.
relay server.
8. Security Considerations 8. Security Considerations
This document describes a protocol for the application- This document describes a protocol for the application-
layer traversal of IP network firewalls. The security of layer traversal of IP network firewalls. The security
such traversal is highly dependant on the particular of such traversal is highly dependent on the particular
authentication and encapsulation methods used in a par- authentication and encapsulation methods provided in a
ticular implementation. particular implementation, and selected during negotia-
tion between SOCKS client and SOCKS server.
The protection for relayed UDP data when an authentica- Careful consideration should be given by the adminis-
tion method doesn't supply suitable keying material is trator to the selection of authentication methods.
quite weak. Careful consideration should be given to
selection of authentication methods when a firewall is
expected to relay UDP data using this protocol.
9. References 9. References
[1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Secu- [1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Secu-
rity Symposium rity Symposium
[2] Rivest, Ron. RFC1321, "The MD5 Message-Digest Algo-
rithm"
[3] FIPS180-1, "Secure Hash Standard", NIST Publication
Authors Address Authors Address
Marcus Leech Marcus Leech
Bell-Northern Research Bell-Northern Research
P.O. Box 3511, Stn. C, P.O. Box 3511, Stn. C,
Ottawa, ON Ottawa, ON
CANADA K1Y 4H7 CANADA K1Y 4H7
Email: mleech@bnr.ca Email: mleech@bnr.ca
Phone: (613) 763-9145 Phone: (613) 763-9145
 End of changes. 51 change blocks. 
276 lines changed or deleted 238 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/