draft-ietf-aft-socks-protocol-v5-05.txt   rfc1928.txt 
Socks Protocol Version 5 Network Working Group M. Leech
INTERNET-DRAFT Request for Comments: 1928 Bell-Northern Research Ltd
Expires: In Six Months M. Leech Category: Standards Track M. Ganis
<draft-ietf-aft-socks-protocol-v5-05.txt> M. Ganis International Business Machines
Y. Lee Y. Lee
R. Kuris NEC Systems Laboratory
D. Koblas R. Kuris
L. Jones Unify Corporation
D. Koblas
Independent Consultant
L. Jones
Hewlett-Packard Company
March 1996
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 specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its areas, Internet community, and requests discussion and suggestions for
and its working groups. Note that other groups may also distribute improvements. Please refer to the current edition of the "Internet
working documents as Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft document 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 ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
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
from active discussions and prototype implementations. The key active discussions and prototype implementations. The key
contributors are: Marcus Leech: Bell-Northern Research, David contributors are: Marcus Leech: Bell-Northern Research, David Koblas:
Koblas: Independent Consultant, Ying-Da Lee: NEC Systems Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont
Laboratory, LaMont Jones: Hewlett-Packard Company, Ron Kuris: Unify Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt
Corporation, Matt Ganis: International Business Machines. 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
firewall systems typically act as application-layer gateways firewall systems typically act as application-layer gateways between
between networks, usually offering controlled TELNET, FTP, and SMTP networks, usually offering controlled TELNET, FTP, and SMTP access.
access. With the emergence of more sophisticated application layer With the emergence of more sophisticated application layer protocols
protocols designed to facilitate global information discovery, designed to facilitate global information discovery, there exists a
there exists a need to provide a general framework for these need to provide a general framework for these protocols to
protocols to transparently and securely traverse a firewall. 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 and that such relationships need to be controlled and often strongly
strongly authenticated. 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 The protocol is conceptually a "shim-layer" between the application
layer and the transport layer, and as such does not provide layer and the transport layer, and as such does not provide network-
network-layer gateway services, such as forwarding of ICMP layer gateway services, such as forwarding of ICMP messages.
messages.
2. Existing practice 2. Existing practice
There currently exists a protocol, SOCKS Version 4, that provides There currently exists a protocol, SOCKS Version 4, that provides for
for unsecured firewall traversal for TCP-based client-server 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 new protocol extends the SOCKS Version 4 model to include UDP, This new protocol extends the SOCKS Version 4 model to include UDP,
and extends the framework to include provisions for generalized and extends the framework to include provisions for generalized
strong authentication schemes, and extends the addressing scheme to strong authentication schemes, and extends the addressing scheme to
encompass domain-name and V6 IP addresses. encompass domain-name and V6 IP addresses.
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.
Note:
Unless otherwise noted, the decimal numbers appearing in packet-
format diagrams represent the length of the corresponding field, in
octets. Where a given octet must take on a specific value, the
syntax X'hh' is used to denote the value of the single octet in that
field. When the word 'Variable' is used, it indicates that the
corresponding field has a variable length defined either by an
associated (one or two octet) length field, or by a data type field.
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
object that is reachable only via a firewall (such determination is that is reachable only via a firewall (such determination is left up
left up to the implementation), it must open a TCP connection to to the implementation), it must open a TCP connection to the
the appropriate SOCKS port on the SOCKS server system. The SOCKS appropriate SOCKS port on the SOCKS server system. The SOCKS service
service is conventionally located on TCP port 1080. If the is conventionally located on TCP port 1080. If the connection
connection request succeeds, the client enters a negotiation for request succeeds, the client enters a negotiation for the
the authentication method to be used, authenticates with the chosen 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
denies it. it.
The client connects to the server, and sends a version Unless otherwise noted, the decimal numbers appearing in packet-
identifier/method selection message: format diagrams represent the length of the corresponding field, in
octets. Where a given octet must take on a specific value, the
syntax X'hh' is used to denote the value of the single octet in that
field. When the word 'Variable' is used, it indicates that the
corresponding field has a variable length defined either by an
associated (one or two octet) length field, or by a data type field.
The client connects to the server, and sends a version
identifier/method selection message:
+----+----------+----------+ +----+----------+----------+
|VER | NMETHODS | METHODS | |VER | NMETHODS | METHODS |
+----+----------+----------+ +----+----------+----------+
| 1 | 1 | 1 to 255 | | 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
protocol. The NMETHODS field contains the number of NMETHODS field contains the number of method identifier octets that
method identifier octets that appear in the METHODS 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:
+----+--------+ +----+--------+
|VER | METHOD | |VER | METHOD |
+----+--------+ +----+--------+
| 1 | 1 | | 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 sub-negotiation.
negotiation. Descriptions of the method-dependent sub-
negotiations appear in separate drafts.
Developers of new METHOD support for this protocol Descriptions of the method-dependent sub-negotiations appear in
should contact IANA for a METHOD number. The ASSIGNED separate memos.
NUMBERS document should be referred to for a current
list of METHOD numbers and their corresponding proto-
cols.
Compliant implementations MUST support GSSAPI and Developers of new METHOD support for this protocol should contact
SHOULD support USERNAME/PASSWORD authentication meth- IANA for a METHOD number. The ASSIGNED NUMBERS document should be
ods. referred to for a current list of METHOD numbers and their
corresponding protocols.
Compliant implementations MUST support GSSAPI and SHOULD support
USERNAME/PASSWORD authentication methods.
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 method-
requests MUST be encapsulated in the method-dependent dependent encapsulation.
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 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 source
based on source and destination addresses, and return and destination addresses, and return one or more reply messages, as
one or more reply messages, as appropriate for the appropriate for the request type.
request type.
5. Addressing 5. Addressing
In an address field (DST.ADDR, BND.ADDR), the ATYP
field specifies the type of address contained within In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies
the field: the type of address contained within 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 fully-qualified domain the address field contains a fully-qualified domain name. The first
name. The first octet of the address field contains octet of the address field contains the number of octets of name that
the number of octets of name that follow, there is no follow, there is no terminating NUL octet.
terminating NUL octet.
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
soon as it has established a connection to the SOCKS 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:
+----+-----+-------+------+----------+----------+ +----+-----+-------+------+----------+----------+
|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'
skipping to change at page 6, line 15 skipping to change at page 6, line 10
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 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 the
number that the server assigned to connect to the tar- 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 SOCKS
the IP address that the client uses to reach the SOCKS server, since such servers are often multi-homed. It is expected
server, since such servers are often multi-homed. It that the SOCKS server will use DST.ADDR and DST.PORT, and the
is expected that the SOCKS server will use DST.ADDR and 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 a
secondary connections after a primary connection is primary connection is established using CONNECT. In is expected that
established using CONNECT. In is expected that a SOCKS a SOCKS server 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 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 binds
after the server creates and binds a new socket. The a new socket. The BND.PORT field contains the port number that the
BND.PORT field contains the port number that the SOCKS SOCKS server assigned to listen for an incoming connection. The
server assigned to listen for an incoming connection. BND.ADDR field contains the associated IP address. The client will
The BND.ADDR field contains the associated IP address. typically use these pieces of information to notify (via the primary
The client will typically use these pieces of informa- or control connection) the application server of the rendezvous
tion to notify (via the primary or control connection) address. The second reply occurs only after the anticipated incoming
the application server of the rendezvous address. The 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 within
ciation within the UDP relay process to handle UDP the UDP relay process to handle UDP datagrams. The DST.ADDR and
datagrams. The DST.ADDR and DST.PORT fields contain DST.PORT fields contain the address and port that the client expects
the address and port that the client expects to use to to use to send UDP datagrams on for the association. The server MAY
send UDP datagrams on for the association. The server use this information to limit access to the association. If the
MAY use this information to limit access to the associ- client is not in possesion of the information at the time of the UDP
ation. If the client is not in possesion of the infor- ASSOCIATE, the client MUST use a port number and address of all
mation at the time of the UDP ASSOCIATE, the client zeros.
MUST use a port number and address of all zeros.
A UDP association terminates when the TCP connection A UDP association terminates when the TCP connection that the UDP
that the UDP ASSOCIATE request arrived on terminates. ASSOCIATE request arrived on terminates.
In the reply to a UDP ASSOCIATE request, the BND.PORT In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR
and BND.ADDR fields indicate the port number/address fields indicate the port number/address where the client MUST send
where the client MUST send UDP request messages to be UDP request messages to be relayed.
relayed.
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 sending
nection shortly after sending the reply. This must be the reply. This must be no more than 10 seconds after detecting the
no more than 10 seconds after detecting the condition 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-dependent
tiality, the data are encapsulated using the method- encapsulation. Similarly, when data arrives at the SOCKS server for
dependent encapsulation. Similarly, when data arrives the client, the server MUST encapsulate the data as appropriate for
at the SOCKS server for the client, the server MUST 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
relay server at the UDP port indicated by BND.PORT in the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE
the reply to the UDP ASSOCIATE request. If the 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:
+----+------+------+----------+----------+----------+ +----+------+------+----------+----------+----------+
|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. When
grams it cannot or will not relay. When a UDP relay a UDP relay server receives a reply datagram from a remote host, it
server receives a reply datagram from a remote host, it MUST encapsulate that datagram using the above UDP request header,
MUST encapsulate that datagram using the above UDP 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 expected
the expected IP address of the client that will send IP address of the client that will send datagrams to the BND.PORT
datagrams to the BND.PORT given in the reply to UDP given in the reply to UDP ASSOCIATE. It MUST drop any datagrams
ASSOCIATE. It MUST drop any datagrams arriving from arriving from any source IP address other than the one recorded for
any source IP address other than the one 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 this
while a value of X'00' indicates that this datagram is 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 these
receiver will have a REASSEMBLY QUEUE and a REASSEMBLY fragments. The reassembly queue must be reinitialized and the
TIMER associated with these fragments. The reassembly associated fragments abandoned whenever the REASSEMBLY TIMER expires,
queue must be reinitialized and the associated frag- or a new datagram arrives carrying a FRAG field whose value is less
ments abandoned whenever the REASSEMBLY TIMER expires, than the highest FRAG value processed for this fragment sequence.
or a new datagram arrives carrying a FRAG field whose The reassembly timer MUST be no less than 5 seconds. It is
value is less than the highest FRAG value processed for recommended that fragmentation be avoided by applications wherever
this fragment sequence. The reassembly timer MUST be 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
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 is
of such traversal is highly dependent on the particular highly dependent on the particular authentication and encapsulation
authentication and encapsulation methods provided in a methods provided in a particular implementation, and selected during
particular implementation, and selected during negotia- 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 Symposium.
rity Symposium
Authors Address Author's Address
Marcus Leech Marcus Leech
Bell-Northern Research Bell-Northern Research Ltd
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 Phone: (613) 763-9145
Phone: (613) 763-9145 EMail: mleech@bnr.ca
 End of changes. 58 change blocks. 
262 lines changed or deleted 241 lines changed or added

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