draft-ietf-aft-socks-protocol-v5-03.txt   draft-ietf-aft-socks-protocol-v5-04.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-03.txt> M. Ganis <draft-ietf-aft-socks-protocol-v5-04.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 page 3, line 9 skipping to change at line 100
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 The VER field is set to X'05' for this version of the protocol.
protocol. The NMETHODS field contains the number of The NMETHODS field contains the number of method identifier octets
method identifier octets that appear in the METHODS that appear in the METHODS field.
field.
The server selects from one of the methods given in The server selects from one of the methods given in METHODS, and
METHODS, and sends a METHOD selection message: 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 If the selected METHOD is X'FF', none of the methods listed by the
listed by the client are acceptable, and the client client are acceptable, and the client MUST 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' 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 sub- The client and server then enter a method-specific subnegotiation.
negotiation. Descriptions of the method-dependent sub- Descriptions of the method-dependent subnegotiations appear in
negotiations appear in separate drafts. separate drafts.
Developers of new METHOD support for this protocol Developers of new METHOD support for this protocol should contact
should contact IANA for a METHOD number. The ASSIGNED IANA for a METHOD number. The ASSIGNED NUMBERS document should be
NUMBERS document should be referred to for a current referred to for a current list of METHOD numbers and their
list of METHOD numbers and their corresponding proto- corresponding protocols.
cols.
Compliant implementations MUST support GSSAPI and Compliant implementations MUST support GSSAPI and SHOULD support
SHOULD support USERNAME/PASSWORD authentication meth- USERNAME/PASSWORD authentication methods.
ods.
4. Requests 4. Requests
Once the method-dependent subnegotiation has completed, Once the method-dependent subnegotiation has completed, the client
the client sends the request details. If the negoti- sends the request details. If the negotiated method includes
ated method includes encapsulation for purposes of encapsulation for purposes of integrity checking and/or
integrity checking and/or confidentiality, these confidentiality, these requests MUST be encapsulated in the
requests MUST be encapsulated in the method-dependent method-dependent encapsulation.
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
|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 typically evaluate the request The SOCKS server will typically evaluate the request based on
based on source and destination addresses, and return source and destination addresses, and return one or more reply
one or more reply messages, as appropriate for the messages, as appropriate for the request type.
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 the address is a version-4 IP address, with a length of 4 octets
4 octets
o X'03' o X'03'
the address field contains a DNS-style domain name. the address field contains a DNS-style domain name. The first
The first octet of the address field contains the num- octet of the address field contains the number of octets that
ber of octets that follow. follow.
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
soon as it has established a connection to the SOCKS has established a connection to the SOCKS server, and completed the
server, and completed the authentication negotiations. authentication negotiations. The server evaluates the request, and
The server evaluates the request, and returns a reply returns a reply formed as follows:
formed as follows:
+----+-----+-------+------+----------+----------+ center tab(~) box; c|c|c|c|c|c. VER~REP~RSV~ATYP~BND.ADDR~BND.PORT
|VER | REP | RSV | ATYP | BND.ADDR | BND.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 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
skipping to change at page 6, line 18 skipping to change at line 223
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 pur- If the chosen method includes encapsulation for purposes of
poses of authentication, integrity and/or confidential- authentication, integrity and/or confidentiality, the replies are
ity, the replies are encapsulated in the method- encapsulated in the method-dependent encapsulation.
dependent encapsulation.
CONNECT CONNECT
In the reply to a CONNECT, BND.PORT contains the port In the reply to a CONNECT, BND.PORT contains the port number that
number that the server assigned to connect to the tar- the server assigned to connect to the target host, while BND.ADDR
get host, while BND.ADDR contains the associated IP contains the associated IP address. The supplied BND.ADDR is often
address. The supplied BND.ADDR is often different from different from the IP address that the client uses to reach the
the IP address that the client uses to reach the SOCKS SOCKS server, since such servers are often multi-homed. It is
server, since such servers are often multi-homed. It expected that the SOCKS server will use DST.ADDR and DST.PORT, and
is expected that the SOCKS server will use DST.ADDR and the client-side source address and port in evaluating the CONNECT
DST.PORT, and the client-side source address and port request.
in evaluating the CONNECT request.
BIND BIND
The BIND request is used in protocols which require the The BIND request is used in protocols which require the client to
client to accept connections from the server. FTP is a accept connections from the server. FTP is a well-known example,
well-known example, which uses the primary client-to- which uses the primary client-to-server connection for commands and
server connection for commands and status reports, but status reports, but may use a server-to-client connection for
may use a server-to-client connection for transferring 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
protocol will use the BIND request only to establish use the BIND request only to establish secondary connections after
secondary connections after a primary connection is a primary connection is established using CONNECT. In is expected
established using CONNECT. In is expected that a SOCKS that a SOCKS server will use DST.ADDR and DST.PORT in evaluating
server will use DST.ADDR and DST.PORT in evaluating the the BIND request.
BIND request.
Two replies are sent from the SOCKS server to the Two replies are sent from the SOCKS server to the client during a
client during a BIND operation. The first is sent BIND operation. The first is sent after the server creates and
after the server creates and binds a new socket. The binds a new socket. The BND.PORT field contains the port number
BND.PORT field contains the port number that the SOCKS that the SOCKS server assigned to listen for an incoming
server assigned to listen for an incoming connection. connection. The BND.ADDR field contains the associated IP address.
The BND.ADDR field contains the associated IP address. The client will typically use these pieces of information to notify
The client will typically use these pieces of informa- (via the primary or control connection) the application server of
tion to notify (via the primary or control connection) the rendezvous address. The second reply occurs only after the
the application server of the rendezvous address. The anticipated incoming connection succeeds or fails.
second reply occurs only after the anticipated incoming
connection succeeds or fails.
In the second reply, the BND.PORT and BND.ADDR fields In the second reply, the BND.PORT and BND.ADDR fields contain the
contain the address and port number of the connecting address and port number of the connecting host.
host.
UDP ASSOCIATE UDP ASSOCIATE
The UDP ASSOCIATE request is used to establish an asso- The UDP ASSOCIATE request is used to establish an association
ciation within the UDP relay process to handle UDP within the UDP relay process to handle UDP datagrams. The DST.ADDR
datagrams. The DST.ADDR field is ignored in a UDP and DST.PORT fields contain the address and port that the client
ASSOCIATE request, while the DST.PORT field contains expects to use to send UDP datagrams on for the association. The
the idle-timeout time, in minutes, that an association server MAY use this information to limit access to the association.
is allowed to exist without explicit client-side activ- If the client is not in possesion of the information at the time of
ity. If DST.PORT is zero, the SOCKS server SHOULD use the UDP ASSOCIATE, the client MUST use a port number and address of
an administrator-defined default. all zeros.
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 A UDP association terminates when the TCP connection that the UDP
ASSOCIATE request arrived on terminates.
The UDP DESTROY request is used to destroy an existing In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR
association within the UDP relay process. The DST.ADDR fields indicate the port number/address where the client MUST send
and DST.PORT fields contain the address and port number UDP request messages to be relayed.
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.
Reply Processing Reply Processing
When a reply (REP value other than X'00') indicates a When a reply (REP value other than X'00') indicates a failure, the
failure, the SOCKS server MUST terminate the TCP con- SOCKS server MUST terminate the TCP connection shortly after
nection shortly after sending the reply. This must be sending the reply. This must be no more than 10 seconds after
no more than 10 seconds after detecting the condition detecting the condition that 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 success, and the
cess, and the request was either a BIND or a CONNECT, request was either a BIND or a CONNECT, the client may now start
the client may now start passing data. If the selected passing data. If the selected authentication method supports
authentication method supports encapsulation for the encapsulation for the purposes of integrity, authentication and/or
purposes of integrity, authentication and/or confiden- confidentiality, the data are encapsulated using the method-
tiality, the data are encapsulated using the method- dependent encapsulation. Similarly, when data arrives at the SOCKS
dependent encapsulation. Similarly, when data arrives server for the client, the server MUST encapsulate the data as
at the SOCKS server for the client, the server MUST 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
relay server at the UDP port indicated by BND.PORT in at the UDP port indicated by BND.PORT in the reply to the UDP
the reply to the UDP ASSOCIATE request. If the ASSOCIATE request. If the selected authentication method provides
selected authentication method provides encapsulation encapsulation for the purposes of authenticity, integrity, and/or
for the purposes of authenticity, integrity, and/or confidentiality, the datagram MUST be encapsulated using the
confidentiality, the datagram MUST be encapsulated appropriate encapsulation. Each UDP datagram carries a UDP request
using the appropriate encapsulation. Each UDP datagram header with it:
carries a UDP request header with it:
+----+------+------+----------+----------+----------+ center box tab(~); c|c|c|c|c|c.
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | RSV~FRAG~ATYP~DST.ADDR~DST.PORT~DATA = 2~1~1~Variable~2~Variable
+----+------+------+----------+----------+----------+
| 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 data- When a UDP relay server decides to relay a UDP datagram, it does so
gram, it does so silently, without any notification to silently, without any notification to the requesting client.
the requesting client. Similarly, it will drop data- Similarly, it will drop datagrams it cannot or will not relay.
grams it cannot or will not relay. When a UDP relay When a UDP relay server receives a reply datagram from a remote
server receives a reply datagram from a remote host, it host, it MUST encapsulate that datagram using the above UDP request
MUST encapsulate that datagram using the above UDP header, and any authentication-method-dependent encapsulation.
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
the expected IP address of the client that will send expected IP address of the client that will send datagrams to the
datagrams to the BND.PORT given in the reply to UDP BND.PORT given in the reply to UDP ASSOCIATE. It MUST drop any
ASSOCIATE. It MUST drop any datagrams arriving from datagrams arriving from any source IP address other than the one
any source IP address other than the one recorded for recorded for the particular association.
the particular association.
The FRAG field indicates whether or not this datagram The FRAG field indicates whether or not this datagram is one of a
is one of a number of fragments. If implemented, the number of fragments. If implemented, the high-order bit indicates
high-order bit indicates end-of-fragment sequence, end-of-fragment sequence, while a value of X'00' indicates that
while a value of X'00' indicates that this datagram is this datagram is standalone. Values between 1 and 127 indicate the
standalone. Values between 1 and 127 indicate the fragment position within a fragment sequence. Each receiver will
fragment position within a fragment sequence. Each have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with
receiver will have a REASSEMBLY QUEUE and a REASSEMBLY these fragments. The reassembly queue must be reinitialized and
TIMER associated with these fragments. The reassembly the associated fragments abandoned whenever the REASSEMBLY TIMER
queue must be reinitialized and the associated frag- expires, or a new datagram arrives carrying a FRAG field whose
ments abandoned whenever the REASSEMBLY TIMER expires, value is less than the highest FRAG value processed for this
or a new datagram arrives carrying a FRAG field whose fragment sequence. The reassembly timer MUST be no less than 5
value is less than the highest FRAG value processed for seconds. It is recommended that fragmentation be avoided by
this fragment sequence. The reassembly timer MUST be applications wherever possible.
no less than 5 seconds. It is recommended that frag-
mentation be avoided by applications wherever possible.
Implementation of fragmentation is optional; an imple- Implementation of fragmentation is optional; an implementation that
mentation that does not support fragmentation MUST drop does not support fragmentation MUST drop any datagram whose FRAG
any datagram whose FRAG field is other than X'00'. field is other than X'00'.
The programming interface for a SOCKS-aware UDP MUST The programming interface for a SOCKS-aware UDP MUST report an
report an available buffer space for UDP datagrams that available buffer space for UDP datagrams that is smaller than the
is smaller than the actual space provided by the oper- actual space provided by the operating system:
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
The ASSOCIATION established with a UDP ASSOCIATE
request has a specific lifetime. The UDP server SHOULD
refresh the lifetime every time a valid datagram
arrives from the client at the UDP 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
layer traversal of IP network firewalls. The security traversal of IP network firewalls. The security of such traversal
of such traversal is highly dependent on the particular is highly dependent on the particular authentication and
authentication and encapsulation methods provided in a encapsulation methods provided in a particular implementation, and
particular implementation, and selected during negotia- selected during negotiation between SOCKS client and SOCKS server.
tion between SOCKS client and SOCKS server.
Careful consideration should be given by the adminis- Careful consideration should be given by the administrator to the
trator to the selection of authentication methods. selection of authentication methods.
9. References 9. References
[1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Secu- [1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security
rity Symposium 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. 42 change blocks. 
208 lines changed or deleted 147 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/