INTERNET-DRAFT H. Kitamura <draft-kitamura-socks-ipv6-01.txt NEC Corporation Expires in six months 8 February 1999 SOCKSv5 Protocol Extensions for IPv6/IPv4 Communication Environment <draft-kitamura-socks-ipv6-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes three types of extensions of SOCKS Version 5 protocol [RFC1928]. A new address type and a new command for Requests and Replies are introduced. These extensions supplement the insufficient generic functions of the SOCKSv5 protocol. These extensions enable a SOCKS server to be used as a translator for IPv4 and IPv6 mixed heteregenous communications with ease. In addition, they make each homogeneous IPv4 and IPv6 communication efficient. H. Kitamura [Page 1]
INTERNET-DRAFT SOCKSv5 Extensions for IPv6 Support February 1999 Introduction The SOCKS Version 5 protocol [RFC1928] can deal with IPv6 address type. Only with this specification, however, it is insufficient to support IPv6 based efficient communication environment. Especially, it is difficult to support IPv4 and IPv6 mixed heterogeneous communication environment and to use a SOCKS server as a translator for mixed heterogeneous communication environment. In this document, three types of extensions of SOCKSv5 protocol are described. A new address type notion and a new command for Requests and Replies are introduced as the extensions. These extensions enable a SOCKS server to be used as a translator for IPv4 and IPv6 mixed heteregenous communications with ease. In addition, they make each homogeneous IPv4 and IPv6 communication efficient. Because they supplement the insufficient generic functions of the SOCKSv5 protocol. Extension * Extension 1 (New address type notion) As a new address type (ATYP) notion, "ADDRESS ID" is introduced. This extension is closely related with Extension 2 (New command), which is described below. An ADDRESS ID is an identifier that represents an entry of the address association mapping table between a SOCKS client and a SOCKS server. Typically, the ADDRESS ID represents the servers' internal address association table identifier. Internal ADDRESS ID Format +-----+-----------+ |CLASS|REALID(key)| +-----+-----------+ | 1 | 3 | +-----+-----------+ An ADDRESS ID occupies 4 octets. Internally, the first octet is used for a CLASS. The CLASS indicates categories and characteristics of the ADDRESS ID. For the time being, it is reserved and filled with zero. The rest octets are used for the real identifier (REALID) of the ADDRESS ID. Since the ADDRESS ID dose not include explicit address information, there are potential vulnerabilities. If some SOCKS clients use the same ADDRESS ID that is already used, the SOCKS server may cause H. Kitamura [Page 2]
INTERNET-DRAFT SOCKSv5 Extensions for IPv6 Support February 1999 confusion. (It depends on implementation methods of the SOCKS.) Most of the vulnerabilities can be avoided by the difference of the SOCKS clients' IP addresses, but they still exist for the processes at the same host. In order to avoid such potential problems and to enhance the security of the system, a simple key exchange mechanism is introduced. The SOCKS server provides a REALID as a key to the SOCKS client. It means that the REALID works as both a identifier and a key. A series of the provided REALIDs by the SOCKS server are not simple sequential numbers. The randomness of the REALIDs avoids the vulnerabilities. 3 octets are long enough to realize this mechanism, and long enough to support the number of the addresses to be dealt between the client and the server. The length of the ADDRESS ID is fixed and shorter than other address types that are specified in the current SOCKSv5 protocol, and the ADDRESS ID shows essential information between the client and the server. So, the introduction of the ADDRESS ID address type makes efficient communications via the SOCKS server. Especially, in case of UDP communications via the SOCKS server, the utilization of the ADDRESS ID address type contributes to shorten the length of the UDP Packet Structure header and to make the filtering procedure efficient. Since the introduction of the ADDRESS ID conceals the address family types, it becomes easy to enable to relay different address based connections (e.g., between IPv4 and IPv6) at the SOCKS server. * Extension 2 (New command for Requests and Replies) As a new command (CMD), "ADDRESS ASSOCIATE" is introduced. This extension is closely related with Extension 1 (New address type notion). This command is prepared for a SOCKS client to get a ADDRESS ID from a SOCKS server. Followings are the procedure to get the ADDRESS ID. 1. A SOCKS client sends a Request filled with the ADDRESS ASSOCIATE command to a SOCKS server. 2. The server sends a Reply filled with the ADDRESS ID information to the BND.ADDR field. After the procedure is finished successfully, the client can use the received ADDRESS ID to any ADDR fields instead of other address types (IP V4 address, DOMAINNAME, or IP V6 address) for the Requests and the UDP Packet Structure header. With this extension, the client's DNS query delegation to the server H. Kitamura [Page 3]
INTERNET-DRAFT SOCKSv5 Extensions for IPv6 Support February 1999 can be accomplished explicitly in the SOCKS protocol. An ADDRESS ASSOCIATE command has different characteristics from other commands. It can be executed as a dedicated command, but also, it is possible to execute the ADDRESS ASSOCIATE command with other commands (CONNECT, BIND, or UDP ASSOCIATE) simultaneously under the special conditions that the client does not require explicit BND.ADDR information from the Replies. With the simultaneous commands execution can reduce the handshake times between the SOCKS client and the server. In order to realize this function, the ADDRESS ASSOCIATE command needs to be assigned to an appropriate bit of the CMD field of the Requests. In case an ADDRESS ASSOCIATE command is executed with other command simultaneously, the meanings of the REP field of the Replies may become unclear, and the client can not get explicit BND.ADDR information from the Replies, because BND.ADDR field is filled with ADDRESS ID information. (BND.PORT field is filled with normal information.) In case confusion may happen, an orthodox method that the each command is executed as one dedicated function must be taken. Only when the client does not need BND.ADDR information and the meanings of the REP field is clear, this simultaneous commands execution can be taken. In case of the dedicated ADDRESS ASSOCIATE command Requests, DST.PORT field does not make sense. The meanings of this field is changed and reused. The name of it is changed to ADR.PREF. It shows the preference of the reply address type of the client. In the Extension 3 (Show the preference of the reply address type), the details of this specification are described. * Extension 3 (Show the preference of the reply address type) In case the SOCKS server relays different address based connections (e.g., between IPv4 and IPv6), the address type (ATYP) and the bound address (BND.ADDR) of the Replies are important. If the client can not deal with the replied address type, it causes confusion in the client. In order to avoid this confusion, the client needs to show the preference of the reply address type to the server. There are three methods to realize this feature. 1. Do nothing special The client shows nothing special to the server and expects a default reply address type that can be associated naturally. It means to expect the same address (family) type that is used for H. Kitamura [Page 4]
INTERNET-DRAFT SOCKSv5 Extensions for IPv6 Support February 1999 the connection between the client and the server. In this method, the client dose not care which address family type is used in the connection between the server and the desired destination. 2. Use FLAG field of the Requests The client shows the reply address type preference by setting the flag field FLAG of the Requests. An appropriate bit of the FLAG field shows off or on of the preference of the client. If the appropriate bit is off (0), it is the same case of the "Do nothing special." Default address type is replied. If the appropriate bit is on (1), the client asks the server to reply the address as the same address (family) type that is used in the connection between the server and the desired destination. In this case, the client must deal with all of the expected address family types. 3. Use DST.PORT field of the dedicated ADDRESS ASSOCIATE Requests In case of the dedicated ADDRESS ASSOCIATE Requests, the name of the DST.PORT field is changed to ADR.PREF, and it shows the preference of the reply address type. Since the ADR.PREF has 2 octets, it has a possibility to show complex preference. For the time being, the upper octet of the ADR.PREF is reserved. The lower octet is used to show the show the preference. The format is the same to the ATYP field. (As an additional function, this mechanism enables the client to realize the deligation of the reverse DNS query, also.) The appropriate bit of the FLAG has a high priority and can overwrite the preference that is shown by the ADR.PREF field. Formats In the following sections, the formats that include the described extensions are shown. Most parts are quoted from the [RFC1928] and the current SOCKS version 5 specification [SOCKSv5]. Since [RFC1928] and [SOCKSv5] explain the meanings of the fields except extensions that are described in this document, they are omitted here. x marks (instead of o marks) indicate extensions. 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 H. Kitamura [Page 5]
INTERNET-DRAFT SOCKSv5 Extensions for IPv6 Support February 1999 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. Requests Format +----+-----+------+------+----------+----------+ |VER | CMD | FLAG | ATYP | DST.ADDR | DST.PORT | +----+-----+------+------+----------+----------+ | 1 | 1 | 1 | 1 | Variable | 2 | +----+-----+------+------+----------+----------+ o VER protocol version: X'05' o CMD o CONNECT X'01' o BIND X'02' o UDP ASSOCIATE X'03' x ADDRESS ASSOCIATE X'08' (bit set) x CONNECT +ADDRESS ASSOCIATE X'09' x BIND +ADDRESS ASSOCIATE X'0A' x UDP ASSOCIATE +ADDRESS ASSOCIATE X'0B' o X'10' to X'7F' IANA ASSIGNED o X'80' to X'FF' RESERVED FOR PRIVATE METHODS o FLAG command dependent flag (defaults to X'00') x Prefer Default address family type X'00' (off) x Prefer address family type of the Destination X'10' (on) o ATYP address type of following address o IP V4 address: X'01' o DOMAINNAME: X'03' o IP V6 address: X'04' x ADDRESS ID: X'08' o DST.ADDR desired destination address o DST.PORT desired destination port in network octet order In case of the dedicated ADDRESS ASSOCIATE Requests: x DST.PORT = ADR.PREF show the preference of the reply address type. X'00'(reserved)+ ATYP x IP V4 address: X'01' x DOMAINNAME: X'03' x IP V6 address: X'04' H. Kitamura [Page 6]
INTERNET-DRAFT SOCKSv5 Extensions for IPv6 Support February 1999 Addressing Format 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 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. x X'08' the address is a identifier of the servers' internal address association table, with a length of 1 octet. Replies Format +----+-----+------+------+----------+----------+ |VER | REP | FLAG | ATYP | BND.ADDR | BND.PORT | +----+-----+------+------+----------+----------+ | 1 | 1 | 1 | 1 | Variable | 2 | +----+-----+------+------+----------+----------+ 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' Invalid address o X'0A' to X'FF' unassigned o FLAG command dependent flag o ATYP address type of following address o IP V4 address: X'01' H. Kitamura [Page 7]
INTERNET-DRAFT SOCKSv5 Extensions for IPv6 Support February 1999 o DOMAINNAME: X'03' o IP V6 address: X'04' x ADDRESS ID: X'08' o BND.ADDR server bound address o BND.PORT server bound port in network octet order UDP Control Channel Requests Format +----+-----+------+------+----------+------+ |RSV | SUB | FLAG | ATYP | ADDR | PORT | +----+-----+------+------+----------+------+ | 1 | 1 | 1 | 1 | Variable | 2 | +----+-----+------+------+----------+------+ o RSV Reserved X'00' o SUB Subcommand o INTERFACE DATA: X'01' o FLAG A subcommand dependent flag (normally X'00') o ATYP address type of following address o IP V4 address: X'01' o DOMAINNAME: X'03' o IP V6 address: X'04' x ADDRESS ID: X'08' o ADDR destination address information o PORT destination port information UDP Packet Structure Format +------+------+------+----------+----------+----------+ | FLAG | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | +------+------+------+----------+----------+----------+ | 2 | 1 | 1 | Variable | 2 | Variable | +------+------+------+----------+----------+----------+ The fields in the UDP request header are: o FLAG Reserved X'0000' o FRAG Current fragment number o ATYP address type of following address o IP V4 address: X'01' o DOMAINNAME: X'03' o IP V6 address: X'04' x ADDRESS ID: X'08' o DST.ADDR desired destination address o DST.PORT desired destination port o DATA user data H. Kitamura [Page 8]
INTERNET-DRAFT SOCKSv5 Extensions for IPv6 Support February 1999 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. References [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., & Jones, L., "SOCKS Protocol V5," RFC1928, April 1996. [SOCKSv5] VanHeyningen, M, "SOCKS Protocol Version 5," June 1998 currently draft-ietf-aft-socks-pro-v5-03.txt [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. Author's Address Hiroshi Kitamura NEC Corporation C&C Media Research Laboratories 1-1, Miyazaki, 4-Chome, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, JAPAN Phone: +81 (44) 856-2123 Fax: +81 (44) 856-2230 EMail: kitamura@ccm.cl.nec.co.jp H. Kitamura [Page 9]