throbber
RFC 1928 - SOCKS Protocol Version 5
`
`
`[Docs] [txt|pdf] [draft-ietf-aft-so...] [Diff1] [Diff2]
`
` PROPOSED STANDARD
`
`Network Working Group M. Leech
`Request for Comments: 1928 Bell-Northern Research Ltd
`Category: Standards Track M. Ganis
` International Business Machines
` Y. Lee
` NEC Systems Laboratory
` R. Kuris
` Unify Corporation
` D. Koblas
` Independent Consultant
` L. Jones
` Hewlett-Packard Company
` March 1996
`
` SOCKS Protocol Version 5
`Status of this Memo
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`Acknowledgments
` This memo describes a protocol that is an evolution of the previous
` version of the protocol, version 4 [1]. This new protocol stems from
` active discussions and prototype implementations. The key
` contributors are: Marcus Leech: Bell-Northern Research, David Koblas:
` Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont
` Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt
` Ganis: International Business Machines.
`1. Introduction
` The use of network firewalls, systems that effectively isolate an
` organizations internal network structure from an exterior network,
` such as the INTERNET is becoming increasingly popular. These
` firewall systems typically act as application-layer gateways between
` networks, usually offering controlled TELNET, FTP, and SMTP access.
` With the emergence of more sophisticated application layer protocols
` designed to facilitate global information discovery, there exists a
` need to provide a general framework for these protocols to
` transparently and securely traverse a firewall.
`
`Leech, et al Standards Track [Page 1]
`
`RFC 1928 SOCKS Protocol Version 5 March 1996
`
` There exists, also, a need for strong authentication of such
` traversal in as fine-grained a manner as is practical. This
` requirement stems from the realization that client-server
` relationships emerge between the networks of various organizations,
` and that such relationships need to be controlled and often strongly
` authenticated.
` The protocol described here is designed to provide a framework for
` client-server applications in both the TCP and UDP domains to
` 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
` There currently exists a protocol, SOCKS Version 4, that provides for
` unsecured firewall traversal for TCP-based client-server
`
`http://tools.ietf.org/html/rfc1928[7/8/2011 9:00:12 AM]
`
`Petitioner RPX Corporation - Ex. 1013, p. 1
`
`

`

`RFC 1928 - SOCKS Protocol Version 5
`
` applications, including TELNET, FTP and the popular information-
` discovery protocols such as HTTP, WAIS and GOPHER.
` This new protocol extends the SOCKS Version 4 model to include UDP,
` and extends the framework to include provisions for generalized
` strong authentication schemes, and extends the addressing scheme to
` encompass domain-name and V6 IP addresses.
` The implementation of the SOCKS protocol typically involves the
` recompilation or relinking of TCP-based client applications to use
` 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
` When a TCP-based client wishes to establish a connection to an object
` that is reachable only via a firewall (such determination is left up
` to the implementation), it must open a TCP connection to the
` appropriate SOCKS port on the SOCKS server system. The SOCKS service
` is conventionally located on TCP port 1080. If the connection
` request succeeds, the client enters a negotiation for the
`
`Leech, et al Standards Track [Page 2]
`
`RFC 1928 SOCKS Protocol Version 5 March 1996
`
` authentication method to be used, authenticates with the chosen
` method, then sends a relay request. The SOCKS server evaluates the
` request, and either establishes the appropriate connection or denies
` it.
` 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.
` The client connects to the server, and sends a version
` identifier/method selection message:
` +----+----------+----------+
` |VER | NMETHODS | METHODS |
` +----+----------+----------+
` | 1 | 1 | 1 to 255 |
` +----+----------+----------+
` The VER field is set to X'05' for this version of the protocol. The
` NMETHODS field contains the number of method identifier octets that
` appear in the METHODS field.
` The server selects from one of the methods given in METHODS, and
` sends a METHOD selection message:
` +----+--------+
` |VER | METHOD |
` +----+--------+
` | 1 | 1 |
` +----+--------+
` If the selected METHOD is X'FF', none of the methods listed by the
` client are acceptable, and the client MUST close the connection.
` The values currently defined for METHOD are:
` o X'00' NO AUTHENTICATION REQUIRED
` o X'01' GSSAPI
` o X'02' USERNAME/PASSWORD
`
`http://tools.ietf.org/html/rfc1928[7/8/2011 9:00:12 AM]
`
`Petitioner RPX Corporation - Ex. 1013, p. 2
`
`

`

`RFC 1928 - SOCKS Protocol Version 5
` o X'03' to X'7F' IANA ASSIGNED
` o X'80' to X'FE' RESERVED FOR PRIVATE METHODS
` o X'FF' NO ACCEPTABLE METHODS
` The client and server then enter a method-specific sub-negotiation.
`
`Leech, et al Standards Track [Page 3]
`
`RFC 1928 SOCKS Protocol Version 5 March 1996
`
` Descriptions of the method-dependent sub-negotiations appear in
` separate memos.
` Developers of new METHOD support for this protocol should contact
` IANA for a METHOD number. The ASSIGNED NUMBERS document should be
` 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
` Once the method-dependent subnegotiation has completed, the client
` sends the request details. If the negotiated method includes
` encapsulation for purposes of integrity checking and/or
` confidentiality, these requests MUST be encapsulated in the method-
` dependent encapsulation.
` The SOCKS request is formed as follows:
` +----+-----+-------+------+----------+----------+
` |VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
` +----+-----+-------+------+----------+----------+
` | 1 | 1 | X'00' | 1 | Variable | 2 |
` +----+-----+-------+------+----------+----------+
` Where:
` o VER protocol version: X'05'
` o CMD
` o CONNECT X'01'
` o BIND X'02'
` o UDP ASSOCIATE X'03'
` o RSV RESERVED
` o ATYP address type of following address
` o IP V4 address: X'01'
` o DOMAINNAME: X'03'
` o IP V6 address: X'04'
` o DST.ADDR desired destination address
` o DST.PORT desired destination port in network octet
` order
` The SOCKS server will typically evaluate the request based on source
` and destination addresses, and return one or more reply messages, as
` appropriate for the request type.
`
`Leech, et al Standards Track [Page 4]
`
`RFC 1928 SOCKS Protocol Version 5 March 1996
`
`5. Addressing
` In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies
` the type of address contained within the field:
` o X'01'
` the address is a version-4 IP address, with a length of 4 octets
` o X'03'
` the address field contains a fully-qualified domain name. The first
`
`http://tools.ietf.org/html/rfc1928[7/8/2011 9:00:12 AM]
`
`Petitioner RPX Corporation - Ex. 1013, p. 3
`
`

`

`RFC 1928 - SOCKS Protocol Version 5
`
` octet of the address field contains the number of octets of name that
` follow, there is no terminating NUL octet.
` o X'04'
` the address is a version-6 IP address, with a length of 16 octets.
`6. Replies
` The SOCKS request information is sent by the client as soon as it has
` established a connection to the SOCKS server, and completed the
` authentication negotiations. The server evaluates the request, and
` returns a reply formed as follows:
` +----+-----+-------+------+----------+----------+
` |VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
` +----+-----+-------+------+----------+----------+
` | 1 | 1 | X'00' | 1 | Variable | 2 |
` +----+-----+-------+------+----------+----------+
` Where:
` o VER protocol version: X'05'
` o REP Reply field:
` o X'00' succeeded
` o X'01' general SOCKS server failure
` o X'02' connection not allowed by ruleset
` o X'03' Network unreachable
` o X'04' Host unreachable
` o X'05' Connection refused
` o X'06' TTL expired
` o X'07' Command not supported
` o X'08' Address type not supported
` o X'09' to X'FF' unassigned
` o RSV RESERVED
` o ATYP address type of following address
`
`Leech, et al Standards Track [Page 5]
`
`RFC 1928 SOCKS Protocol Version 5 March 1996
`
` o IP V4 address: X'01'
` o DOMAINNAME: X'03'
` o IP V6 address: X'04'
` o BND.ADDR server bound address
` o BND.PORT server bound port in network octet order
` Fields marked RESERVED (RSV) must be set to X'00'.
` If the chosen method includes encapsulation for purposes of
` authentication, integrity and/or confidentiality, the replies are
` encapsulated in the method-dependent encapsulation.
`CONNECT
` In the reply to a CONNECT, BND.PORT contains the port number that the
` server assigned to connect to the target 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 client to
` accept connections from the server. FTP is a well-known example,
` which uses the primary client-to-server connection for commands and
` status reports, but 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
` use the BIND request only to establish secondary connections after a
` primary connection is established using CONNECT. In is expected that
` a SOCKS server will use DST.ADDR and DST.PORT in evaluating the BIND
` request.
`
`http://tools.ietf.org/html/rfc1928[7/8/2011 9:00:12 AM]
`
`Petitioner RPX Corporation - Ex. 1013, p. 4
`
`

`

`RFC 1928 - SOCKS Protocol Version 5
` Two replies are sent from the SOCKS server to the client during a
` BIND operation. The first is sent after the server creates and binds
` a new socket. The BND.PORT field contains the port number that the
` SOCKS server assigned to listen for an incoming connection. The
` BND.ADDR field contains the associated IP address. The client will
` typically use these pieces of information to notify (via the primary
` or control connection) the application server of the rendezvous
` address. The second reply occurs only after the anticipated incoming
` connection succeeds or fails.
`
`Leech, et al Standards Track [Page 6]
`
`RFC 1928 SOCKS Protocol Version 5 March 1996
`
` In the second reply, the BND.PORT and BND.ADDR fields contain the
` address and port number of the connecting host.
`UDP ASSOCIATE
` The UDP ASSOCIATE request is used to establish an association within
` the UDP relay process to handle UDP datagrams. The DST.ADDR and
` DST.PORT fields contain the address and port that the client expects
` to use to send UDP datagrams on for the association. The server MAY
` use this information to limit access to the association. If the
` client is not in possesion of the information 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
` ASSOCIATE request arrived on terminates.
` In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR
` fields indicate the port number/address where the client MUST send
` UDP request messages to be relayed.
`Reply Processing
` When a reply (REP value other than X'00') indicates a failure, the
` SOCKS server MUST terminate the TCP connection shortly after sending
` the reply. This must be 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
` request was either a BIND or a CONNECT, the client may now start
` passing data. If the selected authentication method supports
` encapsulation for the purposes of integrity, authentication and/or
` confidentiality, the data are encapsulated using the method-dependent
` encapsulation. Similarly, when data arrives at the SOCKS server for
` the client, the server MUST encapsulate the data as appropriate for
` the authentication method in use.
`7. Procedure for UDP-based clients
` A UDP-based client MUST send its datagrams to the UDP relay server at
` the UDP port indicated by BND.PORT in 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:
`
`Leech, et al Standards Track [Page 7]
`
`RFC 1928 SOCKS Protocol Version 5 March 1996
`
` +----+------+------+----------+----------+----------+
` |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
` +----+------+------+----------+----------+----------+
` | 2 | 1 | 1 | Variable | 2 | Variable |
` +----+------+------+----------+----------+----------+
`
`http://tools.ietf.org/html/rfc1928[7/8/2011 9:00:12 AM]
`
`Petitioner RPX Corporation - Ex. 1013, p. 5
`
`

`

`RFC 1928 - SOCKS Protocol Version 5
`
` The fields in the UDP request header are:
` o RSV Reserved X'0000'
` o FRAG Current fragment number
` o ATYP address type of following addresses:
` o IP V4 address: X'01'
` o DOMAINNAME: X'03'
` o IP V6 address: X'04'
` o DST.ADDR desired destination address
` o DST.PORT desired destination port
` o DATA user data
` When a UDP relay server decides to relay a UDP datagram, it does so
` silently, without any notification to the requesting client.
` Similarly, it will drop datagrams it cannot or will not relay. When
` a UDP relay server receives a reply datagram from a remote host, it
` MUST encapsulate that datagram using the above UDP request header,
` and any authentication-method-dependent encapsulation.
` The UDP relay server MUST acquire from the SOCKS server the expected
` IP address of the client that will send datagrams to the BND.PORT
` given in the reply to UDP ASSOCIATE. It MUST drop any datagrams
` arriving from 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
` number of fragments. If implemented, the high-order bit indicates
` 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. Each receiver will
` have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these
` fragments. The reassembly queue must be reinitialized and the
` associated fragments abandoned whenever 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.
` Implementation of fragmentation is optional; an implementation that
` does not support fragmentation MUST drop any datagram whose FRAG
` field is other than X'00'.
`
`Leech, et al Standards Track [Page 8]
`
`RFC 1928 SOCKS Protocol Version 5 March 1996
`
` The programming interface for a SOCKS-aware UDP MUST report an
` available buffer space for UDP datagrams that is smaller than the
` actual space provided by the operating system:
` 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'04' - 20+method_dependent octets smaller
`8. Security Considerations
` This document describes a protocol for the application-layer
` traversal of IP network firewalls. The security of such traversal is
` highly dependent on the particular authentication and encapsulation
` methods provided in a particular implementation, and selected during
` negotiation between SOCKS client and SOCKS server.
` Careful consideration should be given by the administrator to the
` selection of authentication methods.
`9. References
` [1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium.
`Author's Address
` Marcus Leech
` Bell-Northern Research Ltd
` P.O. Box 3511, Stn. C,
` Ottawa, ON
` CANADA K1Y 4H7
`
`http://tools.ietf.org/html/rfc1928[7/8/2011 9:00:12 AM]
`
`Petitioner RPX Corporation - Ex. 1013, p. 6
`
`

`

`RFC 1928 - SOCKS Protocol Version 5
` Phone: (613) 763-9145
` EMail: mleech@bnr.ca
`
`Leech, et al Standards Track [Page 9]
`
`Html markup produced by rfcmarkup 1.95, available from http://tools.ietf.org/tools/rfcmarkup/
`
`http://tools.ietf.org/html/rfc1928[7/8/2011 9:00:12 AM]
`
`Petitioner RPX Corporation - Ex. 1013, p. 7
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket