< draft-ietf-aft-socks-protocol-v5-04.txt   draft-ietf-aft-socks-protocol-v5-05.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-04.txt> M. Ganis <draft-ietf-aft-socks-protocol-v5-05.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
skipping to change at line 35 skipping to change at page 1, line 37
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 version of the protocol, version 4 [1]. This new protocol stems
from active discussions and prototype implementations. The key from active discussions and prototype implementations. The key
contributors are: Marcus Leech: Bell-Northern Research, David contributors are: Marcus Leech: Bell-Northern Research, David
Koblas: Independent Consultant, Ying-Da Lee: NEC Systems Koblas: Independent Consultant, Ying-Da Lee: NEC Systems
Laboratory, LaMont Jones: Hewlett-Packard Company, Ron Kuris: Unify Laboratory, LaMont Jones: Hewlett-Packard Company, Ron Kuris: Unify
Corporation, Matt 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 such as the INTERNET is becoming increasingly popular. These
skipping to change at line 89 skipping to change at page 2, line 45
The implementation of the SOCKS protocol typically involves the The implementation of the SOCKS protocol typically involves the
recompilation or relinking of TCP-based client applications to use recompilation or relinking of TCP-based client applications to use
the appropriate encapsulation routines in the SOCKS library. 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 When a TCP-based client wishes to establish a connection to an
object that is reachable only via a firewall (such determination is object that is reachable only via a firewall (such determination is
left up to the implementation), it must open a TCP connection to left up to the implementation), it must open a TCP connection to
the appropriate SOCKS port on the SOCKS server system. The SOCKS the appropriate SOCKS port on the SOCKS server system. The SOCKS
service is conventionally located on TCP port 1080. If the service is conventionally located on TCP port 1080. If the
connection request succeeds, the client enters a negotiation for connection request succeeds, the client enters a negotiation for
the authentication method to be used, authenticates with the chosen the authentication method to be used, authenticates with the chosen
method, then sends a relay request. The SOCKS server evaluates the method, then sends a relay request. The SOCKS server evaluates the
request, and either establishes the appropriate connection or request, and either establishes the appropriate connection or
denies it. 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 message: identifier/method selection message:
tab(~) center box; c|c|c. VER~NMETHODS~METHODS = 1~1~1 to 255 +----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 to 255 |
+----+----------+----------+
The VER field is set to X'05' for this version of the protocol. The VER field is set to X'05' for this version of the
The NMETHODS field contains the number of method identifier octets protocol. The NMETHODS field contains the number of
that appear in the METHODS field. method identifier octets that appear in the METHODS
field.
The server selects from one of the methods given in METHODS, and The server selects from one of the methods given in
sends a METHOD selection message: METHODS, and sends a METHOD selection message:
center tab(~) box; c|c. VER~METHOD = 1~1 +----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
If the selected METHOD is X'FF', none of the methods listed by the If the selected METHOD is X'FF', none of the methods
client are acceptable, and the client MUST close the connection. listed by the client are acceptable, and the client
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' GSSAPI o X'01' GSSAPI
o X'02' USERNAME/PASSWORD o X'02' USERNAME/PASSWORD
o X'03' to X'7F' IANA ASSIGNED o X'03' to X'7F' IANA ASSIGNED
o X'80' to X'FE' RESERVED FOR PRIVATE METHODS o X'80' to X'FE' RESERVED FOR PRIVATE METHODS
o X'FF' NO ACCEPTABLE METHODS o X'FF' NO ACCEPTABLE METHODS
The client and server then enter a method-specific subnegotiation. The client and server then enter a method-specific sub-
Descriptions of the method-dependent subnegotiations appear in negotiation. Descriptions of the method-dependent sub-
separate drafts. negotiations appear in separate drafts.
Developers of new METHOD support for this protocol should contact Developers of new METHOD support for this protocol
IANA for a METHOD number. The ASSIGNED NUMBERS document should be should contact IANA for a METHOD number. The ASSIGNED
referred to for a current list of METHOD numbers and their NUMBERS document should be referred to for a current
corresponding protocols. list of METHOD numbers and their corresponding proto-
cols.
Compliant implementations MUST support GSSAPI and SHOULD support Compliant implementations MUST support GSSAPI and
USERNAME/PASSWORD authentication methods. SHOULD support USERNAME/PASSWORD authentication meth-
ods.
4. Requests 4. Requests
Once the method-dependent subnegotiation has completed, the client Once the method-dependent subnegotiation has completed,
sends the request details. If the negotiated method includes the client sends the request details. If the negoti-
encapsulation for purposes of integrity checking and/or ated method includes encapsulation for purposes of
confidentiality, these requests MUST be encapsulated in the integrity checking and/or confidentiality, these
method-dependent encapsulation. requests MUST be encapsulated in the method-dependent
encapsulation.
The SOCKS request is formed as follows: The SOCKS request is formed as follows:
center box tab(~); c|c|c|c|c|c. VER~CMD~RSV~ATYP~DST.ADDR~DST.PORT +----+-----+-------+------+----------+----------+
= 1~1~X'00'~1~Variable~2 |VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 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 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 typically evaluate the request based on The SOCKS server will typically evaluate the request
source and destination addresses, and return one or more reply based on source and destination addresses, and return
messages, 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 specifies field specifies the type of address contained within
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 octets the address is a version-4 IP address, with a length of
4 octets
o X'03' o X'03'
the address field contains a DNS-style domain name. The first the address field contains a fully-qualified domain
octet of the address field contains the number of octets that name. The first octet of the address field contains
follow. the number of octets of name that follow, there is no
terminating NUL octet.
o X'04' o X'04'
the address is a version-6 IP address, with a length of 16 octets. the address is a version-6 IP address, with a length of
16 octets.
6. Replies 6. Replies
The SOCKS request information is sent by the client as soon as it The SOCKS request information is sent by the client as
has established a connection to the SOCKS server, and completed the soon as it has established a connection to the SOCKS
authentication negotiations. The server evaluates the request, and server, and completed the authentication negotiations.
returns a reply formed as follows: The server evaluates the request, and returns a reply
formed as follows:
center tab(~) box; c|c|c|c|c|c. VER~REP~RSV~ATYP~BND.ADDR~BND.PORT +----+-----+-------+------+----------+----------+
= 1~1~X'00'~1~Variable~2 |VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 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' Command not supported o X'07' Command not supported
o X'08' Address type not supported o X'08' Address type not supported
o X'09' to X'FF' unassigned o X'09' 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
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 of If the chosen method includes encapsulation for pur-
authentication, integrity and/or confidentiality, the replies are poses of authentication, integrity and/or confidential-
encapsulated in the method-dependent encapsulation. ity, the replies are encapsulated in the method-
dependent encapsulation.
CONNECT CONNECT
In the reply to a CONNECT, BND.PORT contains the port number that In the reply to a CONNECT, BND.PORT contains the port
the server assigned to connect to the target host, while BND.ADDR number that the server assigned to connect to the tar-
contains the associated IP address. The supplied BND.ADDR is often get host, while BND.ADDR contains the associated IP
different from the IP address that the client uses to reach the address. The supplied BND.ADDR is often different from
SOCKS server, since such servers are often multi-homed. It is the IP address that the client uses to reach the SOCKS
expected that the SOCKS server will use DST.ADDR and DST.PORT, and server, since such servers are often multi-homed. It
the client-side source address and port in evaluating the CONNECT is expected that the SOCKS server will use DST.ADDR and
request. DST.PORT, and the client-side source address and port
in evaluating the CONNECT request.
BIND BIND
The BIND request is used in protocols which require the client to The BIND request is used in protocols which require the
accept connections from the server. FTP is a well-known example, client to accept connections from the server. FTP is a
which uses the primary client-to-server connection for commands and well-known example, which uses the primary client-to-
status reports, but may use a server-to-client connection for server connection for commands and status reports, but
transferring data on demand (e.g. LS, GET, PUT). may use a server-to-client connection for transferring
data on demand (e.g. LS, GET, PUT).
It is expected that the client side of an application protocol will It is expected that the client side of an application
use the BIND request only to establish secondary connections after protocol will use the BIND request only to establish
a primary connection is established using CONNECT. In is expected secondary connections after a primary connection is
that a SOCKS server will use DST.ADDR and DST.PORT in evaluating established using CONNECT. In is expected that a SOCKS
the BIND request. server will use DST.ADDR and DST.PORT in evaluating the
BIND request.
Two replies are sent from the SOCKS server to the client during a Two replies are sent from the SOCKS server to the
BIND operation. The first is sent after the server creates and client during a BIND operation. The first is sent
binds a new socket. The BND.PORT field contains the port number after the server creates and binds a new socket. The
that the SOCKS server assigned to listen for an incoming BND.PORT field contains the port number that the SOCKS
connection. The BND.ADDR field contains the associated IP address. server assigned to listen for an incoming connection.
The client will typically use these pieces of information to notify The BND.ADDR field contains the associated IP address.
(via the primary or control connection) the application server of The client will typically use these pieces of informa-
the rendezvous address. The second reply occurs only after the tion to notify (via the primary or control connection)
anticipated incoming connection succeeds or fails. the application server of the rendezvous address. 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 In the second reply, the BND.PORT and BND.ADDR fields
address and port number of the connecting host. contain the address and port number of the connecting
host.
UDP ASSOCIATE UDP ASSOCIATE
The UDP ASSOCIATE request is used to establish an association The UDP ASSOCIATE request is used to establish an asso-
within the UDP relay process to handle UDP datagrams. The DST.ADDR ciation within the UDP relay process to handle UDP
and DST.PORT fields contain the address and port that the client datagrams. The DST.ADDR and DST.PORT fields contain
expects to use to send UDP datagrams on for the association. The the address and port that the client expects to use to
server MAY use this information to limit access to the association. send UDP datagrams on for the association. The server
If the client is not in possesion of the information at the time of MAY use this information to limit access to the associ-
the UDP ASSOCIATE, the client MUST use a port number and address of ation. If the client is not in possesion of the infor-
all zeros. mation at the time of the UDP ASSOCIATE, the client
MUST use a port number and address of all zeros.
A UDP association terminates when the TCP connection that the UDP A UDP association terminates when the TCP connection
ASSOCIATE request arrived on terminates. that the UDP ASSOCIATE request arrived on terminates.
In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR In the reply to a UDP ASSOCIATE request, the BND.PORT
fields indicate the port number/address where the client MUST send and BND.ADDR fields indicate the port number/address
UDP request messages to be relayed. where the client MUST send UDP request messages to be
relayed.
Reply Processing Reply Processing
When a reply (REP value other than X'00') indicates a failure, the When a reply (REP value other than X'00') indicates a
SOCKS server MUST terminate the TCP connection shortly after failure, the SOCKS server MUST terminate the TCP con-
sending the reply. This must be no more than 10 seconds after nection shortly after sending the reply. This must be
detecting the condition that caused a failure. no more than 10 seconds after detecting the condition
that caused a failure.
If the reply code (REP value of X'00') indicates a success, and the If the reply code (REP value of X'00') indicates a suc-
request was either a BIND or a CONNECT, the client may now start cess, and the request was either a BIND or a CONNECT,
passing data. If the selected authentication method supports the client may now start passing data. If the selected
encapsulation for the purposes of integrity, authentication and/or authentication method supports encapsulation for the
confidentiality, the data are encapsulated using the method- purposes of integrity, authentication and/or confiden-
dependent encapsulation. Similarly, when data arrives at the SOCKS tiality, the data are encapsulated using the method-
server for the client, the server MUST encapsulate the data as dependent encapsulation. Similarly, when data arrives
appropriate for the authentication method in use. at the SOCKS server for the client, the server MUST
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 relay server A UDP-based client MUST send its datagrams to the UDP
at the UDP port indicated by BND.PORT in the reply to the UDP relay server at the UDP port indicated by BND.PORT in
ASSOCIATE request. If the selected authentication method provides the reply to the UDP ASSOCIATE request. If the
encapsulation for the purposes of authenticity, integrity, and/or selected authentication method provides encapsulation
confidentiality, the datagram MUST be encapsulated using the for the purposes of authenticity, integrity, and/or
appropriate encapsulation. Each UDP datagram carries a UDP request confidentiality, the datagram MUST be encapsulated
header with it: using the appropriate encapsulation. Each UDP datagram
carries a UDP request header with it:
center box tab(~); c|c|c|c|c|c. +----+------+------+----------+----------+----------+
RSV~FRAG~ATYP~DST.ADDR~DST.PORT~DATA = 2~1~1~Variable~2~Variable |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 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 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 DATA user data o DATA user data
When a UDP relay server decides to relay a UDP datagram, it does so When a UDP relay server decides to relay a UDP data-
silently, without any notification to the requesting client. gram, it does so silently, without any notification to
Similarly, it will drop datagrams it cannot or will not relay. the requesting client. Similarly, it will drop data-
When a UDP relay server receives a reply datagram from a remote grams it cannot or will not relay. When a UDP relay
host, it MUST encapsulate that datagram using the above UDP request server receives a reply datagram from a remote host, it
header, and any authentication-method-dependent encapsulation. MUST encapsulate that datagram using the above UDP
request header, and any authentication-method-dependent
encapsulation.
The UDP relay server MUST acquire from the SOCKS server the The UDP relay server MUST acquire from the SOCKS server
expected IP address of the client that will send datagrams to the the expected IP address of the client that will send
BND.PORT given in the reply to UDP ASSOCIATE. It MUST drop any datagrams to the BND.PORT given in the reply to UDP
datagrams arriving from any source IP address other than the one ASSOCIATE. It MUST drop any datagrams arriving from
recorded for the particular association. any source IP address other than the one recorded for
the particular association.
The FRAG field indicates whether or not this datagram is one of a The FRAG field indicates whether or not this datagram
number of fragments. If implemented, the high-order bit indicates is one of a number of fragments. If implemented, the
end-of-fragment sequence, while a value of X'00' indicates that high-order bit indicates end-of-fragment sequence,
this datagram is standalone. Values between 1 and 127 indicate the while a value of X'00' indicates that this datagram is
fragment position within a fragment sequence. Each receiver will standalone. Values between 1 and 127 indicate the
have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with fragment position within a fragment sequence. Each
these fragments. The reassembly queue must be reinitialized and receiver will have a REASSEMBLY QUEUE and a REASSEMBLY
the associated fragments abandoned whenever the REASSEMBLY TIMER TIMER associated with these fragments. The reassembly
expires, or a new datagram arrives carrying a FRAG field whose queue must be reinitialized and the associated frag-
value is less than the highest FRAG value processed for this ments abandoned whenever the REASSEMBLY TIMER expires,
fragment sequence. The reassembly timer MUST be no less than 5 or a new datagram arrives carrying a FRAG field whose
seconds. It is recommended that fragmentation be avoided by value is less than the highest FRAG value processed for
applications wherever possible. this fragment sequence. The reassembly timer MUST be
no less than 5 seconds. It is recommended that frag-
mentation be avoided by applications wherever possible.
Implementation of fragmentation is optional; an implementation that Implementation of fragmentation is optional; an imple-
does not support fragmentation MUST drop any datagram whose FRAG mentation that does not support fragmentation MUST drop
field is other than X'00'. any datagram whose FRAG field is other than X'00'.
The programming interface for a SOCKS-aware UDP MUST report an The programming interface for a SOCKS-aware UDP MUST
available buffer space for UDP datagrams that is smaller than the report an available buffer space for UDP datagrams that
actual space provided by the operating system: is smaller than the actual space provided by the oper-
ating system:
o if ATYP is X'01' - 10+method_dependent octets smaller o if ATYP is X'01' - 10+method_dependent octets smaller
o if ATYP is X'03' - 262+method_dependent octets smaller o if ATYP is X'03' - 262+method_dependent octets smaller
o if ATYP is X'04' - 20+method_dependent octets smaller o if ATYP is X'04' - 20+method_dependent octets smaller
8. Security Considerations 8. Security Considerations
This document describes a protocol for the application-layer This document describes a protocol for the application-
traversal of IP network firewalls. The security of such traversal layer traversal of IP network firewalls. The security
is highly dependent on the particular authentication and of such traversal is highly dependent on the particular
encapsulation methods provided in a particular implementation, and authentication and encapsulation methods provided in a
selected during negotiation between SOCKS client and SOCKS server. particular implementation, and selected during negotia-
tion between SOCKS client and SOCKS server.
Careful consideration should be given by the administrator to the Careful consideration should be given by the adminis-
selection of authentication methods. trator to the selection of authentication methods.
9. References 9. References
[1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security [1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Secu-
Symposium rity Symposium
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
 End of changes. 50 change blocks. 
165 lines changed or deleted 213 lines changed or added

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