译者：Radeon（Radeon bise@cmmail.com）
译文公布时间：2001-6-18

文件夹

1.介绍
2．现有的协议
3．基于TCP协议的客户
4．请求
5．地址
6．应答
7．基于UDP协议的客户
8. 安全性考虑
9. 參考书目

1.介绍

利用网络防火墙能够将组织内部的网络结构从外部网络如INTERNET中有效地隔离，这样的方法在很多网络系统中正变得流行起来。这样的防火墙系统通常以应用层网关的形式工作在两个网络之间，提供TELNET、FTP、SMTP等的接入。随着越来越多的使全球信息查找更easy的复杂的应用层协议的出现，有必要提供一个通用框架来使这些协议安全透明地穿过防火墙。并且在实际应用中还须要一种安全的认证方式用以穿越防火墙。这个要求起源于两个组织的网络中客户/server关系的出现，这个关系须要得到控制并要求有安全的认证。
在这儿所描写叙述的协议框架是为了让使用TCP和UDP的客户/server应用程序更方便安全地使用网络防火墙所提供的服务所设计的。这个协议从概念上来讲是介于应用层和传输层之间的“中介层(shim-layer)”，因而不提供如传递ICMP信息之类由网络层网关的所提供的服务。

2．现有的协议
当前存在一个协议SOCKS 4，它为TELNET、FTP、HTTP、WAIS和GOPHER等基于TCP协议的客户/server程序提供了一个不安全的防火墙。而这个新的协议扩展了SOCKS V4，以使其支持UDP、框架规定的安全认证方案、地址解析方案(addressing scheme)中所规定的域名和IPV6。为了实现这个SOCKS协议，通常须要又一次编译或者又一次链接基于TCP的client应用程序以使用SOCKS库中对应的加密函数。
注意：
除非特别注明，全部出如今数据包格式图中的十进制数字均以字节表示对应域的长度。假设某域须要给定一个字节的值，用X’hh’来表示这个字节中的值。假设某域中用到单词’Variable’，这表示该域的长度是可变的，且该长度定义在一个和这个域相关联（1 – 2个字节）的域中，或一个数据类型域中。

3．基于TCP协议的客户
当一个基于TCP协议的client希望与一个仅仅能通过防火墙能够到达的目标(这是由实现所决定的)建立连接，它必须先建立一个与SOCKSserver上SOCKSport的TCP连接。通常这个TCPport是1080。当连接建立后，client进入协议的“握手(negotiation)”过程：认证方式的选择，依据选中的方式进行认证，然后发送转发的要求。SOCKSserver检查这个要求，依据结果，或建立合适的连接，或拒绝。
除非特别注明，全部出如今数据包格式图中的十进制数字均以字节表示对应域的长度。假设某域须要给定一个字节的值，用X’hh’来表示这个字节中的值。假设某域中用到单词’Variable’，这表示该域的长度是可变的，且该长度定义在一个和这个域相关联（1 – 2个字节）的域中，或一个数据类型域中。
client连到server后，然后就发送请求来协商版本号和认证方法：

这个版本号的SOCKS协议中，VER字段被设置成X‘05‘。NMETHODS字段包括了在METHODS字段中出现的方法标示的数目（以字节为单位）。
server从这些给定的方法中选择一个并发送一个方法选中的消息回client：

假设选中的消息是X’FF’，这表示client所列出的方法列表中没有一个方法被选中，client必须关闭连接。
当前定义的方法有：
· X’00’ 不须要认证
· X’01’ GSSAPI
· X’02’ username/password
· X’03’ -- X’7F’ 由IANA分配
· X’80’ -- X’FE’ 为私人方法所保留的
· X’FF’ 没有能够接受的方法
然后客户和server进入由选定认证方法所决定的子协商过程(sub-negotiation)。各种不同的方法的子协商过程的描写叙述请參考各自的备忘录。
开发人员假设要为自己的方法得到一个方法号，能够联系IANA。能够參考关于已经被分配号码的文档以得到当前全部方法的列表和对应的协议。
符合本文档的SOCKS V5实现必须支持GSSAPI，而且在将来支持username/password认证方式。

4．请求

一旦子协商过程结束后，client就发送具体的请求信息。假设协商的方法中有以完整性检查和/或安全性为目的的封装，这些请求必须依照该方法所定义的方式进行封装。
SOCKS请求的格式例如以下：

当中
· VER 协议版本号: X’05’
· CMD
· CONNECT：X’01’
· BIND：X’02’
· UDP ASSOCIATE：X’03’
· RSV 保留
· ATYP 后面的地址类型
· IPV4：X’01’
· 域名：X’03’
· IPV6：X’04’‘
· DST.ADDR 目的地址
· DST.PORT 以网络字节顺序出现的port号
SOCKSserver会依据源地址和目的地址来分析请求，然后依据请求类型返回一个或多个应答。

5．地址
ATYP字段中描写叙述了地址字段(DST.ADDR，BND.ADDR)所包括的地址类型：
· X‘01‘
基于IPV4的IP地址，4个字节长
· X‘03‘
基于域名的地址，地址字段中的第一字节是以字节为单位的该域名的长度，没有结尾的NUL字节。
· X‘04‘
基于IPV6的IP地址，16个字节长

6．应答
一旦建立了一个到SOCKSserver的连接，而且完毕了认证方式的协商过程，客户机将会发送一个SOCKS请求信息给server。server将会依据请求，以例如以下格式返回：

当中：
· VER 协议版本号: X’05’
· REP 应答字段:
· X’00’ 成功
· X’01’ 普通的SOCKSserver请求失败
· X’02’ 现有的规则不同意的连接
· X’03’ 网络不可达
· X’04’ 主机不可达
· X’05’ 连接被拒
· X’06’ TTL超时
· X’07’ 不支持的命令
· X’08’ 不支持的地址类型
· X’09’ – X’FF’ 没有定义
· RSV 保留
· ATYP 后面的地址类型
· IPV4：X’01’
· 域名：X’03’
· IPV6：X’04’
· BND.ADDR server绑定的地址
· BND.PORT 以网络字节顺序表示的server绑定的段口
标识为RSV的字段必须设为X’00’。
假设选中的方法中有以完整性检查和/或安全性为目的的封装，这些应答必须依照该方法所定义的方式进行封装。

CONNECT
在对一个CONNECT命令的应答中，BND.PORT包括了server分配的用来连到目标机的port号，BND.ADDR则是对应的IP地址。因为SOCKSserver通常有多个IP，应答中的BND.ADDR常和client连到SOCKSserver的那个IP不同。

SOCKSserver能够利用DST.ADDR和DST.PORT，以及client源地址和port来对一个CONNECT请求进行分析。

BIND
BIND请求通常被用在那些要求client接受来自server的连接的协议上。FTP是一个典型的样例。它建立一个从client到server端的连接来运行命令以及接收状态的报告，而使用还有一个从server到client的连接来接收数据传输的要求(如LS，GET，PUT)。
建议仅仅有在一个应用协议的client在使用CONNECT命令建立主连接后才干够使用BIND命令建立第二个连接。建议SOCKSserver使用DST.ADDR和DST.PORT来评价BIND请求。
在一个BIND请求的操作过程中，SOCKSserver要发送两个应答给client。当server建立并绑定一个新的套接口时发送第一个应答。BND.PORT字段包括SOCKSserver用来监听进入的连接的port号，BAND.ADDR字段包括了相应的IP地址。client通常使用这些信息来告诉（通过主连接或控制连接）应用server连接的汇接点。第二个应答仅发生在所期望到来的连接成功或失败之后。在第二个应答中，BND.PORT和BND.ADDR字段包括了连上来的主机的IP地址和port号。

UDP ASSOCIATE
UDP ASSOCIATE请求一般是要求建立一个UDP转发进程来控制到来的UDP数据报。DST.ADDR和DST.PORT 字段包括client所希望的用来发送UDP数据报的IP地址和port号。server能够使用这个信息来限制进入的连接。假设client在发送这个请求时没有地址和port信息，client必须用全0来填充。
当与UDP对应的TCP连接中断时，该UDP连接也必须中断。
应答UDP ASSOCIATE请求时，BND.PORT 和BND.ADDR字段指明了客户发送UDP消息至server的port和地址。

应答处理
当一个应答(REP值不等于00)指明出错时，SOCKSserver必须在发送完应答消息后一小段时间内终止TCP连接。这段时间应该在发现错误后少于10秒。
假设一个应答(REP值等于00)指明成功，而且请求是一个BIND或CONNECT时，client就能够開始发送数据了。假设协商的认证方法中有以完整性、认证和/或安全性为目的的封装，这些请求必须依照该方法所定义的方式进行封装。类似的，当以客户机为目的地的数据到达SOCKSserver时，SOCKSserver必须用正在使用的方法对这些数据进行封装。

7．基于UDP协议的客户
在UDP ASSOCIATE应答中由BND.PORT指明了server所使用的UDPport，一个基于UDP协议的客户必须发送数据报至UDP转发server的该port上。假设协商的认证方法中有以完整性、认证和/或安全性为目的的封装，这些数据报必须依照该方法所定义的方式进行封装。每一个UDP数据报都有一个UDP请求头在其首部：

在UDP请求头中的字段是：

· RSV 保留 X’0000’
· FRAG 当前的分段号
· ATYP 后面的地址类型
· IPV4：X’01’
· 域名：X’03’
· IPV6：X’04’
· DST.ADDR 目的地址
· DST.PORT 以网络字节顺序出现的port号
· DATA 用户数据
当一个UDP转发server转发一个UDP数据报时，不会发送不论什么通知给client；相同，它也将丢弃不论什么它不能发至远端主机的数据报。当UDP转发server从远端server收到一个应答的数据报时，必须加上上述UDP请求头，并对数据报进行封装。
UDP转发server必须从SOCKSserver得到期望的clientIP地址，并将数据报发送到UDP ASSOCIATE应答中给定的port号。假设数据报从不论什么IP地址到来，而该IP地址与该特定连接中指定的IP地址不同，那么该数据报会被丢弃。
FRAG字段指明数据报是否是一些分片中的一片。假设SOCKSserver要实现这个功能，X’00’指明数据报是独立的；其它则越大越是数据报的尾端。介于1到127之间的值说明了该分片在分片序列里的位置。每一个接收者都为这些分片提供一个重组队列和一个重组的计时器。这个重组队列必须在重组计时器超时后又一次初始化，并丢弃对应的数据报。或者当一个新到达的数据报有一个比当前在处理的数据报序列中最大的FRAG值要小时，也必须又一次初始化从组队列。重组计时器必须小于5秒。仅仅要有可能，应用程序最好不要使用分片。
分片的实现是可选的；假设某实现不支持分片，全部FRAG字段不为0的数据报都必须被丢弃。
一个SOCKS的UDP编程界面(The programming interface for a SOCKS-aware UDP)必须报告当前可用UDP数据报缓存空间小于操作系统提供的实际空间。
· 假设 ATYP是 X’01’ - 10+method_dependent octets smaller
· 假设 ATYP是X’03’ - 262+method_dependent octets smaller
· 假设 ATYP是X’04’ - 20+method_dependent octets smaller

8. 安全性考虑
这篇文档描写叙述了一个用来透过IP网络防火墙的应用层协议。这样的传输的安全性在非常大程度上依赖于特定实现所拥有以及在SOCKS客户与SOCKSserver之间经协商所选定的特殊的认证和封装方式。
系统管理员须要对用户认证方式的选择进行细致考虑。

作者地址
Marcus Leech
Bell-Northern Research Ltd
P.O. Box 3511, Station C
Ottawa, ON
CANADA K1Y 4H7
Phone: (613) 763 - 9145
EMail: mleech@bnr.ca