SOCKS Protocol Version 5

前面部分备忘

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.

Introduction

防火墙的使用，有效的隔离了机构的内部网络和外部网络，这种类型的Internet架构变得越来越流行了。这种防火墙系统大都充当着网络之间的应用层网关的角色，通常提供经过控制的Telnet、FTP和SMTP访问。为了推动全球信息的交流，更多的新的应用层协议的推出，这就有必要提供一个总的架构使这些协议能够更明显和更安全的穿过防火墙，也有必要在实际上为它们穿过防火墙时提供一个更强的认证机制。这需要基于客户机-服务器机制在不同组织网络之间实现，而这种联系必须得到控制并且有安全认证。

在此所描述的协议框架是为了让使用TCP和UDP的客户/服务器应用程序更方便地使用网络防火墙所提供的服务所设计的。这个协议从概念上来讲是介于应用层和传输层之间的“中介层”，因而不提供如发ICMP信息之类的网络层网关服务。

Existing practice

-略

Procedure for TCP-based clients

当一个基于TCP的客户端想要去建立一个只有通过防火墙才能到达的目标的连接时（例如从开始准备到完成），必须打开一个TCP连接到对方的SOCKS服务器的SOCKS端口上。这个SOCKS服务默认在1080端口上，如果这个连接请求成功，客户端就需要协商用哪个加密方法、哪些可用，然后发送转发请求。SOCKS服务器检查这个请求根据结果建立连接或拒绝。

除非特别注明，在数据包图标里的长度都是十进制的。如果需要给定一个字节值，用X’hh’表示该字节的值。如果用到单词’Variable’,表示长度可变。

客户端连到服务器后，然后就发送请求来协商版本和认证方法：

VAR	NMETHODS	METHODS
1	1	1 to 255

VAR 字段在这个协议版本中写 X’05’，NMETHODS 中选择一个METHODS中的方法（填写序号）

服务器从METHODS给出的方法中选出一个，发送选择报文

VAR	METHOD
1	1

如果选择的METHOD的值是X’FF’ ，则表示客户端列出的方法是没有可以背接受的，客户端就必须关闭连接。

现在定义的METHOD的值有：

X’00’ 无验证
X’01’ 通用安全服务应用程序接口（GSSAPI）
X’02’ 用户名密码
X’03’ to X’7F’ IANA分配
X’80’ to X’FE’ 私人保留
X’FF’ 无可接受方法

之后客户端和服务端对于进入方法细节进行二次协商（sub-negotiation）。二次协商的描述在独立的文档中。开发者希望得到新的METHOD支持需要和IANA联系。当前已分配的METHOD号参考文档。如果想顺利的执行则必须支持GSSAPI和支持用户名/密码（USERAE/PASSWORD）认证方法。

需求

一旦方法选择子商议结束，客户机就发送请求细节。如果商议方法包括了完整性检查的目的或机密性封装，则请求必然被封在方法选择的封装中。

SOCKS请求如下表所示：

VER	CMD	RSV	ATYP	DST.ADDR	DST.PORT
1	1	X’00’	1	Variable	2

VER protocol version: X’05’
CMD
- CONNECT X’01’
- BIND X’02’
- UDP ASSOCIATE X’03’
RSV RESERVED
ATYP address type of following address
- IP V4 address: X’01’
- DOMAINNAME: X’03’
- IP V6 address: X’04’
DST.ADDR desired destination address
DST.PORT desired destination port in network octet order

SOCKS服务器会评估基于源和目标地址的请求，然后返回一条或几条消息作为合适的请求类型。

地址

在地址域(DST.ADDR，BND.ADDR)中，ATYP域详细说明了包含在该域内部的地址类型：

X’01’ 该地址是IPv4地址，长4个八位组。
X’03’ 该地址包含一个完全的域名。第一个八位组包含了后面名称的八位组的数目，没有中止的空八位组。
X’04’ 该地址是IPv6地址，长16个八位组。

回应

到SOCKS服务器的连接一经建立，客户机即发送SOCKS请求信息，并且完成认证商议。服务器评估请求，返回一个回应如下表所示：

VER	REP	RSV	ATYP	BND.ADDR	BND.PORT
1	1	X’00’	1	Variable	2

VER protocol version: X’05’
REP Reply field:
- X’00’ succeeded - X’01’ general SOCKS server failure - X’02’ connection not allowed by ruleset - X’03’ Network unreachable - X’04’ Host unreachable
- X’05’ Connection refused
- X’06’ TTL expired
- X’07’ Command not supported
- X’08’ Address type not supported
- X’09’ to X’FF’ unassigned
RSV RESERVED
ATYP address type of following address
- IP V4 address: X’01’
- DOMAINNAME: X’03’
- IP V6 address: X’04’
BND.ADDR server bound address
BND.PORT server bound port in network octet order

标志RESERVED(RSV)的地方必须设置为X’00’。

如果被选中的方法包括有认证目的封装，完整性和/或机密性的检查，则回应就被封装在方法选择的封装套中。

连接

在CONNECT的回应中，BND.PORT包括了服务器分配的连接到目标主机的端口号，同时BND.ADDR包含了关联的IP地址。此处所提供的BND.ADDR通常情况不同于客户机连接到SOCKS服务器所用的IP地址，因为这些服务器提供的经常都是多址的(muti-homed)。都期望SOCKS主机能使用DST.ADDR和DST.PORT，连接请求评估中的客户端源地址和端口。

绑定

BIND请求被用在那些需要客户机接受到服务器连接的协议中。FTP就是一个众所周知的例子，它通过使用命令和状态报告建立最基本的客户机-服务器连接，按照需要使用服务器-客户端连接来传输数据。(例如：ls,get,put)都期望在使用应用协议的客户端在使用CONNECT建立首次连接之后仅仅使用BIND请求建立第二次连接。都期望SOCKS主机在评估BIND请求时能够使用ST.ADDR和DST.PORT。

有两次应答都是在BIND操作期间从SOCKS服务器发送到客户端的。第一次是发送在服务器创建和绑定一个新的socket之后。BIND.PORT域包含了SOCKS主机分配和侦听一个接入连接的端口号。BND.ADDR域包含了关联的IP地址。

客户端具有代表性的是使用这些信息来通报应用程序连接到指定地址的服务器。第二次应答只是发生在预期的接入连接成功或者失败之后。在第二次应答中，BND.PORT和BND.ADDR域包含了欲连接主机的地址和端口号。

UDP ASSOCIATE

-略

Procedure for UDP-based clients

-略

References:

https://www.ietf.org/rfc/rfc1928.txt

SOCKS5 RFC1928