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

SCOKS協(xié)議5

備忘錄地位

本標(biāo)準(zhǔn)為Internet網(wǎng)詳細(xì)說(shuō)明了一份架構(gòu)委員會(huì)的標(biāo)準(zhǔn)軌跡協(xié)議，并且要求討論和建議以便進(jìn)一步的改進(jìn)。請(qǐng)關(guān)注最新的用于陳述標(biāo)準(zhǔn)化協(xié)議的的文件"IAB Official Protocol Standards"(STD1)。本備忘錄的發(fā)行無(wú)任何限制。

感謝

這份備忘錄詳細(xì)描述了一個(gè)由早先的版本(版本4[1])演化來(lái)的協(xié)議。新協(xié)議起源積極的討論和一些早先版本的實(shí)現(xiàn)。關(guān)鍵的投稿人有：Marcus Leech: 貝爾北方研究所, David Koblas:獨(dú)立研究者, Ying-Da Lee: NEC 系統(tǒng)實(shí)驗(yàn)室, LaMont Jones: Hewlett-Packard 公司, Ron Kuris: Unify 有限公司, Matt Ganis: IBM公司。

介紹

使用網(wǎng)絡(luò)防火墻將一個(gè)組織內(nèi)部的網(wǎng)絡(luò)結(jié)構(gòu)和外部網(wǎng)絡(luò)隔開(kāi)，這種方法在因特網(wǎng)上正變得日益流行。這些防火墻系統(tǒng)常常以應(yīng)用層網(wǎng)關(guān)的形式工作在網(wǎng)絡(luò)之間，一般提供對(duì)TELNET, FTP, 和 SMTP的訪問(wèn)控制。隨著越來(lái)越多促進(jìn)全球信息化的應(yīng)用協(xié)議的出現(xiàn)，有必要提供一個(gè)框架使得應(yīng)用協(xié)議可以透明并秘密的穿越防火墻。

而且在實(shí)際應(yīng)用中還需要一種安全的認(rèn)證方式用以穿越防火墻。這種要求起源于不同組織的網(wǎng)絡(luò)間客戶端/服務(wù)器關(guān)系的出現(xiàn)，這種關(guān)系常常需要得到控制并要求有安全的認(rèn)證。

在這兒所描述的協(xié)議框架是為了讓使用TCP和UDP的客戶/服務(wù)器應(yīng)用程序更方便安全地使用網(wǎng)絡(luò)防火墻提供的服務(wù)而設(shè)計(jì)的。這個(gè)協(xié)議從概念上來(lái)講是介于應(yīng)用層和傳輸層之間的“中介層(shim-layer)”，因而不提供如ICMP信息之類由網(wǎng)絡(luò)層網(wǎng)關(guān)的提供的服務(wù)。

現(xiàn)有的成果

當(dāng)前存在一個(gè)協(xié)議SOCKS 4，它為T(mén)ELNET、FTP、HTTP、WAIS和GOPHER等基于TCP協(xié)議的客戶/服務(wù)器程序提供不安全的防火墻穿越策略。

新協(xié)議擴(kuò)展了SCOKS4的模型使它可以用于UDP協(xié)議，擴(kuò)展了一個(gè)框架使它可以提供一般意義上的強(qiáng)認(rèn)證機(jī)制，擴(kuò)展了尋址機(jī)制使它支持域名和IPV6。為了實(shí)現(xiàn)這個(gè)SOCKS協(xié)議，通常需要重新編譯或者重新鏈接基于TCP的客戶端應(yīng)用程序以使用SOCKS庫(kù)中相應(yīng)的加密函數(shù)。

注意：

除非特別注明，所有出現(xiàn)在數(shù)據(jù)包格式圖中的十進(jìn)制數(shù)字均表示相應(yīng)域的字節(jié)長(zhǎng)度。如果一個(gè)給定的字節(jié)需要說(shuō)明其值，則用X'hh'來(lái)表示這個(gè)字節(jié)的值。如果某域中用到單詞'Variable'，這表示該域的長(zhǎng)度是可變的，且該域的長(zhǎng)度定義在一個(gè)和這個(gè)域相關(guān)聯(lián)(1–2個(gè)字節(jié))的域中，或一個(gè)數(shù)據(jù)類型域中。

基于TCP連接的客戶端程序

當(dāng)一個(gè)基于TCP協(xié)議的客戶端希望與一個(gè)只能通過(guò)防火墻才可以到達(dá)的目標(biāo)(這是由實(shí)現(xiàn)所決定的)建立連接，它必須先建立一個(gè)與相應(yīng)SOCKS服務(wù)器的SOCKS端口的TCP連接。通常這個(gè)TCP端口是1080。當(dāng)連接建立后，客戶端進(jìn)入帶有認(rèn)證機(jī)制的“握手(negotiation)”過(guò)程，根據(jù)選中的認(rèn)證方式進(jìn)行認(rèn)證，然后發(fā)送需要轉(zhuǎn)發(fā)的請(qǐng)求。SOCKS服務(wù)器檢查這個(gè)請(qǐng)求，根據(jù)結(jié)果，或建立合適的連接，或拒絕。

除非特別注明，所有出現(xiàn)在數(shù)據(jù)包格式圖中的十進(jìn)制數(shù)字均以字節(jié)表示相應(yīng)域的長(zhǎng)度。如果某域需要給定一個(gè)字節(jié)的值，用X'hh'來(lái)表示這個(gè)字節(jié)中的值。如果某域中用到單詞'Variable'，這表示該域的長(zhǎng)度是可變的，且該長(zhǎng)度定義在一個(gè)和這個(gè)域相關(guān)聯(lián)(1–2個(gè)字節(jié))的域中，或一個(gè)數(shù)據(jù)類型域中。

客戶端連到服務(wù)器后，就發(fā)送一個(gè)版本標(biāo)識(shí)符/方法選擇消息：

+----+----------+----------+
|VER | NMETHODS | METHODS  |
+----+----------+----------+
| 1  |    1     | 1 to 255 |
+----+----------+----------+

這個(gè)版本的SOCKS協(xié)議中，VER字段被設(shè)置成X'05'。NMETHODS字段為METHODS字節(jié)字段的長(zhǎng)度。

服務(wù)器從這些給定的方法中選擇一個(gè)并發(fā)還給客戶端：

+----+--------+
|VER | METHOD |
+----+--------+
| 1  |   1    |
+----+--------+

如果選中的方法是X'FF'，這表示客戶端所列出的方法列表中沒(méi)有一個(gè)方法被選中，客戶端必須關(guān)閉連接。

當(dāng)前定義的方法有：

o  X'00' 不需要認(rèn)證
o  X'01' GSSAPI
o  X'02' 用戶名/密碼
o  X'03'-X'7F' IANA 分配
o  X'80'-X'FE' 保留用作私人方法
o  X'FF' 沒(méi)有可以接受的方法

然后客戶和服務(wù)器進(jìn)入由選定認(rèn)證方法所決定的子協(xié)商過(guò)程(sub-negotiation)。各種不同的方法的子協(xié)商過(guò)程的描述請(qǐng)參考各自的備忘錄。

開(kāi)發(fā)者如果要為自己的方法得到一個(gè)方法號(hào)，可以聯(lián)系IANA。可以參考關(guān)于已經(jīng)被分配號(hào)碼的文檔以得到當(dāng)前所有方法的列表和相應(yīng)的協(xié)議。

符合本文檔的SOCKS V5實(shí)現(xiàn)必須支持GSSAPI，并且在將來(lái)支持用戶名/密碼認(rèn)證方式。

請(qǐng)求

一旦子協(xié)商過(guò)程結(jié)束后，客戶端就發(fā)送詳細(xì)的請(qǐng)求信息。如果協(xié)商的方法中有以完整性檢查和/或安全性為目的的封裝，這些請(qǐng)求必須按照該方法所定義的方式進(jìn)行封裝。

SOCKS請(qǐng)求的格式如下：

+----+-----+-------+------+----------+----------+
|VER | CMD |  RSV  | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1  |  1  | X'00' |  1   | Variable |    2     |
+----+-----+-------+------+----------+----------+

其中：

o  VER  協(xié)議版本: X'05'
o  CMD
o  CONNECT  X'01'
o  BIND  X'02'
o  UDP  交互 X'03'
o  RSV  保留字段
o  ATYP  后面的地址類型
o  IP V4 地址: X'01'
o  域名: X'03'
o  IP V6 地址: X'04'
o  DST.ADDR  目的地址
o  DST.PORT  以網(wǎng)絡(luò)字節(jié)順序出現(xiàn)的端口號(hào)

SOCKS服務(wù)器會(huì)根據(jù)源地址和目的地址來(lái)分析請(qǐng)求，然后根據(jù)請(qǐng)求類型返回一個(gè)或多個(gè)應(yīng)答。

地址

ATYP字段中描述了地址字段(DST.ADDR，BND.ADDR)所包含的地址類型：

o  X'01'

這是IPV4的IP地址，4個(gè)字節(jié)長(zhǎng)。

o  X'03'

這是域名的地址，地址字段中的第一字節(jié)是該域名的字節(jié)長(zhǎng)度，沒(méi)有結(jié)尾的NUL字節(jié)。

o  X'04'

這是基于IPV6的IP地址，16個(gè)字節(jié)長(zhǎng)。

應(yīng)答

一旦建立了一個(gè)到SOCKS服務(wù)器的連接，并且完成了認(rèn)證協(xié)商，客戶機(jī)將會(huì)發(fā)送一個(gè)SOCKS請(qǐng)求信息給服務(wù)器。服務(wù)器將會(huì)根據(jù)請(qǐng)求，以如下格式返回：

+----+-----+-------+------+----------+----------+
|VER | REP |  RSV  | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 1  |  1  | X'00' |  1   | Variable |    2     |
+----+-----+-------+------+----------+----------+

其中：

o  VER    協(xié)議版本: X'05'
o  REP    應(yīng)答字段:
o  X'00' 成功
o  X'01' 普通的SCOKS服務(wù)器請(qǐng)求失敗
o  X'02' 現(xiàn)有的規(guī)則不允許連接
o  X'03' 網(wǎng)絡(luò)不可達(dá)
o  X'04' 主機(jī)不可達(dá)
o  X'05' 連接被拒絕
o  X'06' 連接超時(shí)
o  X'07' 命令不支持
o  X'08' 地址類型不支持
o  X'09' to X'FF' 未定義
o  RSV    保留
o  ATYP   后面的地址類型
o  IP V4 地址: X'01'
o  域名: X'03'
o  IP V6 地址: X'04'
o  BND.ADDR       服務(wù)器綁定的地址
o  BND.PORT       以網(wǎng)絡(luò)字節(jié)順序表示的服務(wù)器綁定的段口

標(biāo)識(shí)為RSV的字段必須設(shè)為X'00'。

如果選中的方法中有以完整性檢查和/或安全性為目的的封裝，這些應(yīng)答必須按照該方法所定義的方式進(jìn)行封裝。

CONNECT

在對(duì)一個(gè)CONNECT命令的應(yīng)答中，BND.PORT包含了服務(wù)器分配的用來(lái)連到目標(biāo)機(jī)的端口號(hào)，BND.ADDR則是相應(yīng)的IP地址。由于SOCKS服務(wù)器通常有多個(gè)IP，應(yīng)答中的BND.ADDR常和客戶端連到SOCKS服務(wù)器的那個(gè)IP不同。SOCKS服務(wù)器可以利用DST.ADDR和DST.PORT，以及客戶端源地址和端口來(lái)對(duì)一個(gè)CONNECT請(qǐng)求進(jìn)行分析。

BIND

BIND請(qǐng)求通常被用在那些要求客戶端接受來(lái)自服務(wù)器的連接的協(xié)議上。FTP是一個(gè)典型的例子。它建立一個(gè)從客戶端到服務(wù)器端的連接來(lái)執(zhí)行命令以及接收狀態(tài)的報(bào)告，而使用另一個(gè)從服務(wù)器到客戶端的連接來(lái)接收傳輸數(shù)據(jù)的要求(如LS，GET，PUT)。

建議只有在一個(gè)應(yīng)用協(xié)議的客戶端在使用CONNECT命令建立主連接后才可以使用BIND命令建立第二個(gè)連接。建議SOCKS服務(wù)器使用DST.ADDR和DST.PORT來(lái)評(píng)價(jià)BIND分析。

在一個(gè)BIND請(qǐng)求的操作過(guò)程中，SOCKS服務(wù)器要發(fā)送兩個(gè)應(yīng)答給客戶端。當(dāng)服務(wù)器建立并綁定一個(gè)新的套接口時(shí)發(fā)送第一個(gè)應(yīng)答。BND.PORT字段包含SOCKS服務(wù)器用來(lái)監(jiān)聽(tīng)進(jìn)入的連接的端口號(hào)，BAND.ADDR字段包含了對(duì)應(yīng)的IP地址。客戶端通常使用這些信息來(lái)告訴(通過(guò)主連接或控制連接)應(yīng)用服務(wù)器連接的匯接點(diǎn)。第二個(gè)應(yīng)答僅發(fā)生在所期望到來(lái)的連接成功或失敗之后。

在第二個(gè)應(yīng)答中，BND.PORT和BND.ADDR字段包含了連上來(lái)的主機(jī)的IP地址和端口號(hào)。

UDP交換

請(qǐng)求通常是要求建立一個(gè)UDP轉(zhuǎn)發(fā)進(jìn)程來(lái)控制到來(lái)的UDP數(shù)據(jù)報(bào)。DST.ADDR和DST.PORT 字段包含客戶端所希望的用來(lái)發(fā)送UDP數(shù)據(jù)報(bào)的IP地址和端口號(hào)。服務(wù)器可以使用這個(gè)信息來(lái)限制進(jìn)入的連接。如果客戶端在發(fā)送這個(gè)請(qǐng)求時(shí)沒(méi)有地址和端口信息，客戶端必須用全0來(lái)填充。

當(dāng)與UDP相應(yīng)的TCP連接中斷時(shí)，該UDP連接也必須中斷。

應(yīng)答UDP 交互請(qǐng)求時(shí)，BND.PORT 和BND.ADDR字段指明了客戶發(fā)送UDP消息至服務(wù)器的端口和地址。

應(yīng)答處理

當(dāng)一個(gè)應(yīng)答(REP值不等于00)指明出錯(cuò)時(shí)，SOCKS服務(wù)器必須在發(fā)送完應(yīng)答消息后一小段時(shí)間內(nèi)終止TCP連接。這段時(shí)間應(yīng)該在發(fā)現(xiàn)錯(cuò)誤后10秒內(nèi)。

如果一個(gè)應(yīng)答(REP值等于00)指明成功，并且請(qǐng)求是一個(gè)BIND或CONNECT時(shí)，客戶端就可以開(kāi)始發(fā)送數(shù)據(jù)了。如果協(xié)商的認(rèn)證方法中有以完整性、認(rèn)證和/或安全性為目的的封裝，這些請(qǐng)求必須按照該方法所定義的方式進(jìn)行封裝。類似的，當(dāng)以客戶端主機(jī)為目的地的數(shù)據(jù)到達(dá)SOCKS服務(wù)器時(shí)，SOCKS服務(wù)器必須用正在使用的方法對(duì)這些數(shù)據(jù)進(jìn)行封裝。

基于UDP連接的客戶端程序

在UDP 交互應(yīng)答中由BND.PORT指明了服務(wù)器所使用的UDP端口，一個(gè)基于UDP協(xié)議的客戶端必須發(fā)送數(shù)據(jù)報(bào)至UDP轉(zhuǎn)發(fā)服務(wù)器的該端口上。如果協(xié)商的認(rèn)證方法中有以完整性、認(rèn)證和/或安全性為目的的封裝，這些數(shù)據(jù)報(bào)必須按照該方法所定義的方式進(jìn)行封裝。每個(gè)UDP數(shù)據(jù)報(bào)都有一個(gè)UDP請(qǐng)求頭部在其首部

+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
+----+------+------+----------+----------+----------+
| 2  |  1   |  1   | Variable |    2     | Variable |
+----+------+------+----------+----------+----------+

其中UDP頭部為：

o  RSV  保留字段 X'0000'
o  FRAG   當(dāng)前的分段號(hào)
o  ATYP    后面的地址類型:
o  IP V4 地址: X'01'
o  域名: X'03'
o  IP V6 地址: X'04'
o  DST.ADDR       目的地址
o  DST.PORT       目的端口
o  DATA     用戶數(shù)據(jù)

當(dāng)一個(gè)UDP轉(zhuǎn)發(fā)服務(wù)器轉(zhuǎn)發(fā)一個(gè)UDP數(shù)據(jù)報(bào)時(shí)，不會(huì)發(fā)送任何通知給客戶端；同樣，它也將丟棄任何它不能發(fā)至遠(yuǎn)端主機(jī)的數(shù)據(jù)報(bào)。當(dāng)UDP轉(zhuǎn)發(fā)服務(wù)器從遠(yuǎn)端服務(wù)器收到一個(gè)應(yīng)答的數(shù)據(jù)報(bào)時(shí)，必須加上上述UDP請(qǐng)求頭，并對(duì)數(shù)據(jù)報(bào)進(jìn)行封裝。

UDP轉(zhuǎn)發(fā)服務(wù)器必須從SOCKS服務(wù)器得到期望的客戶端IP地址，并將數(shù)據(jù)報(bào)發(fā)送到UDP ASSOCIATE應(yīng)答中給定的端口號(hào)。如果數(shù)據(jù)報(bào)從任何IP地址到來(lái)，而該IP地址與該特定連接中指定的IP地址不同，那么該數(shù)據(jù)報(bào)會(huì)被丟棄。

FRAG字段指明數(shù)據(jù)報(bào)是否是一些分片中的一片。如果SOCKS服務(wù)器要實(shí)現(xiàn)這個(gè)功能，X'00'指明數(shù)據(jù)報(bào)是獨(dú)立的；否則其越大越是接近數(shù)據(jù)報(bào)的尾端。介于1到127之間的值說(shuō)明了該分片在分片序列里的位置。每個(gè)接收者都為這些分片提供一個(gè)重組隊(duì)列和一個(gè)重組的計(jì)時(shí)器。這個(gè)重組隊(duì)列必須在重組計(jì)時(shí)器超時(shí)后重新初始化，并丟棄相應(yīng)的數(shù)據(jù)報(bào)。或者當(dāng)一個(gè)新到達(dá)的數(shù)據(jù)報(bào)有一個(gè)比當(dāng)前在處理的數(shù)據(jù)報(bào)序列中最大的FRAG值要小時(shí)，也必須重新初始化重組隊(duì)列。重組計(jì)時(shí)器必須不小于5秒。只要有可能，應(yīng)用程序最好不要使用分片。

分片的實(shí)現(xiàn)是可選的；如果某實(shí)現(xiàn)不支持分片，所有FRAG字段不為0的數(shù)據(jù)報(bào)都必須被丟棄。

一個(gè)SOCKS的UDP界面(The programming interface for a SOCKS-aware UDP)必須報(bào)告當(dāng)前可用UDP數(shù)據(jù)報(bào)緩存空間小于操作系統(tǒng)提供的實(shí)際空間的情況。

o  如果 ATYP 是 X'01' - 10+method_dependent octets smaller
o  如果 ATYP 是X'03' - 262+method_dependent octets smaller
o  如果 ATYP 是X'04' - 20+method_dependent octets smaller
(譯者注：這里可能會(huì)有問(wèn)題)
安全性考慮

這篇文檔描述了一個(gè)用來(lái)透過(guò)IP網(wǎng)絡(luò)防火墻的應(yīng)用層協(xié)議。這種傳輸?shù)陌踩栽诤艽蟪潭壬弦蕾囉谔囟ǖ膶?shí)現(xiàn)以及在SOCKS客戶與SOCKS服務(wù)器之間經(jīng)協(xié)商所選定的特殊的認(rèn)證和封裝方式。

系統(tǒng)管理員需要對(duì)用戶認(rèn)證方式的選擇進(jìn)行仔細(xì)考慮。

參考文獻(xiàn)

[1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium.

作者地址：

Marcus Leech
Bell-Northern Research Ltd
P.O. Box 3511, Stn. C,
Ottawa, ON
CANADA K1Y 4H7

Phone: (613) 763-9145
EMail: mleech@bnr.ca