RFC文檔中文翻譯計劃（http://www.china/-
pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：Radeon（Radeon bise@cmmail.com）
譯文發布時間：2001-6-18
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用於非商業用途自由轉載，
但必須保留本文檔的翻譯及版權信息。
Network Working Group M. Leech
Request for Comments:1929 Bell-Northern Research Ltd
Category: Standard 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 V5
本備忘錄狀態：
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建議以
得到改進。請參考最新版的「Internet正式協議標準」 (STD1)來獲得本協議的標準化程度和狀
態。本備忘錄的發布不受任何限制。
知識背景
這個備忘錄描述了從同一協議的前一版本(版本4[1])發展而來的一個協議。這個新的協議起
源於當前的一些討論和原型的實現(active discussions and prototype implementations)。關鍵的貢
獻人有：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.介紹 2
2．現有的協議 2
3．基於TCP協議的客戶 3
4．請求 3
5．地址 4
6．應答 4
7．基於UDP協議的客戶 6
8. 安全性考慮 7
9. 參考書目 7
1.介紹
利 用網絡防火牆可以將組織內部的網絡結構從外部網絡如INTERNET中有效地隔離，這種方法在許多網絡系統中正變得流行起來。這種防火牆系統通常以應用層 網關的形式工作在兩個網絡之間，提供TELNET、FTP、SMTP等的接入。隨著越來越多的使全球信息查找更容易的複雜的應用層協議的出現，有必要提供 一個通用框架來使這些協議安全透明地穿過防火牆。而且在實際應用中還需要一種安全的認證方式用以穿越防火牆。這個要求起源於兩個組織的網絡中客戶/服務器 關係的出現，這個關係需要得到控制並要求有安全的認證。
在這兒所描述的協議框架是為了讓使用TCP和UDP的客戶/服務器應用程序更方便安全地使 用網絡防火牆所提供的服務所設計的。這個協議從概念上來講是介於應用層和傳輸層之間的「中介層(shim-layer)」，因而不提供如傳遞ICMP信息 之類由網絡層網關的所提供的服務。
2．現有的協議
當前存在一個協議SOCKS 4，它為TELNET、FTP、HTTP、WAIS和GOPHER等基於TCP協議的客戶/服務器程序提供了一個不安全的防火牆。而這個新的協議擴展了 SOCKS V4，以使其支持UDP、框架規定的安全認證方案、地址解析方案(addressing scheme)中所規定的域名和IPV6。為了實現這個SOCKS協議，通常需要重新編譯或者重新鏈接基於TCP的客戶端應用程序以使用SOCKS庫中相 應的加密函數。
注意：
除非特別註明，所有出現在數據包格式圖中的十進制數字均以字節表示相應域的長度。如果某域需要給定一個字節的值，用 X'hh'來表示這個字節中的值。如果某域中用到單詞'Variable'，這表示該域的長度是可變的，且該長度定義在一個和這個域相關聯（1 – 2個字節）的域中，或一個數據類型域中。
3．基於TCP協議的客戶
當一個基於TCP協議的客戶端希望與一個只能通過防火牆可以到達的目標(這是由實現所決定的)建立連接，它必須先建立一個與SOCKS服務器上SOCKS端口的TCP連接。通常這個TCP端口是
1080。當連接建立後，客戶端進入協議的「握手(negotiation)」過程：認證方式的選擇，根據選中的方式進行認證，然後發送轉發的要求。SOCKS服務器檢查這個要求，根據結果，或建立合適的連接，或拒絕。
除 非特別註明，所有出現在數據包格式圖中的十進制數字均以字節表示相應域的長度。如果某域需要給定一個字節的值，用X'hh'來表示這個字節中的值。如果某 域中用到單詞'Variable'，這表示該域的長度是可變的，且該長度定義在一個和這個域相關聯（1 – 2個字節）的域中，或一個數據類型域中。
客戶端連到服務器後，然後就發送請求來協商版本和認證方法：
VER
NMETHODS
METHODS
1
1
1 to 255
這個版本的SOCKS協議中，VER字段被設置成X'05'。NMETHODS字段包含了在METHODS字段中
出現的方法標示的數目（以字節為單位）。
服務器從這些給定的方法中選擇一個併發送一個方法選中的消息回客戶端：
VER
METHOD
1
1
如果選中的消息是X'FF'，這表示客戶端所列出的方法列表中沒有一個方法被選中，客戶端必須關閉連接。
當前定義的方法有：
? X'00' 不需要認證
? X'01' GSSAPI
? X'02' 用戶名/密碼
? X'03' -- X'7F' 由IANA分配
? X'80' -- X'FE' 為私人方法所保留的
? X'FF' 沒有可以接受的方法
然後客戶和服務器進入由選定認證方法所決定的子協商過程(sub-negotiation)。各種不同的方法的子協商過程的描述請參考各自的備忘錄。
開發者如果要為自己的方法得到一個方法號，可以聯繫IANA。可以參考關於已經被分配號碼的文檔以得到當前所有方法的列表和相應的協議。
符合本文檔的SOCKS V5實現必須支持GSSAPI，並且在將來支持用戶名/密碼認證方式。
4．請求
一旦子協商過程結束後，客戶端就發送詳細的請求信息。如果協商的方法中有以完整性檢查和/或安全性為目的的封裝，這些請求必須按照該方法所定義的方式進行封裝。
SOCKS請求的格式如下：
VER
CMD
RSV
ATYP
DST.ADDR
DST.PORT
1
1
X'00'
1
Variable
2
其中
? 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 以網絡字節順序出現的端口號
SOCKS服務器會根據源地址和目的地址來分析請求，然後根據請求類型返回一個或多個應答。
5．地址
ATYP字段中描述了地址字段(DST.ADDR，BND.ADDR)所包含的地址類型：
? X'01'
基於IPV4的IP地址，4個字節長
? X'03'
基於域名的地址，地址字段中的第一字節是以字節為單位的該域名的長度，沒有結尾的NUL字節。
? X'04'
基於IPV6的IP地址，16個字節長
6．應答
一旦建立了一個到SOCKS服務器的連接，並且完成了認證方式的協商過程，客戶機將會發送一個SOCKS請求信息給服務器。服務器將會根據請求，以如下格式返回：
VER
REP
RSV
ATYP
BND.ADDR
BND.PORT
1
1
X'00'
1
Variable
2
其中：
? VER 協議版本: X'05'
? REP 應答字段:
? X'00' 成功
? X'01' 普通的SOCKS服務器請求失敗
? 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 服務器綁定的地址
? BND.PORT 以網絡字節順序表示的服務器綁定的段口
標識為RSV的字段必須設為X'00'。
如果選中的方法中有以完整性檢查和/或安全性為目的的封裝，這些應答必須按照該方法所定義的方式進行封裝。
CONNECT
在對一個CONNECT命令的應答中，BND.PORT包含了服務器分配的用來連到目標機的端口號，
BND.ADDR則是相應的IP地址。由於SOCKS服務器通常有多個IP，應答中的BND.ADDR常和客戶端
連到SOCKS服務器的那個IP不同。
SOCKS服務器可以利用DST.ADDR和DST.PORT，以及客戶端源地址和端口來對一個CONNECT請
求進行分析。
BIND
BIND請求通常被用在那些要求客戶端接受來自服務器的連接的協議上。FTP是一個典型的例子。它建立一個從客戶端到服務器端的連接來執行命令以及接收狀態的報告，而使用另一個從服務
器到客戶端的連接來接收傳輸數據的要求(如LS，GET，PUT)。
建議只有在一個應用協議的客戶端在使用CONNECT命令建立主連接後才可以使用BIND命令建立第二個連接。建議SOCKS服務器使用DST.ADDR和DST.PORT來評價BIND請求。
在 一個BIND請求的操作過程中，SOCKS服務器要發送兩個應答給客戶端。當服務器建立並綁定一個新的套接口時發送第一個應答。BND.PORT字段包含 SOCKS服務器用來監聽進入的連接的端口號，BAND.ADDR字段包含了對應的IP地址。客戶端通常使用這些信息來告訴（通過主連接或控制連接）應用 服務器連接的匯接點。第二個應答僅發生在所期望到來的連接成功或失敗之後。在第二個應答中，BND.PORT和BND.ADDR字段包含了連上來的主機的 IP地址和端口號。
UDP ASSOCIATE
UDP ASSOCIATE請求通常是要求建立一個UDP轉發進程來控制到來的UDP數據報。DST.ADDR和DST.PORT 字段包含客戶端所希望的用來發送UDP數據報的IP地址和端口號。服務器可以使用這個信息來限制進入的連接。如果客戶端在發送這個請求時沒有地址和端口信 息，客戶端必須用全0來填充。
當與UDP相應的TCP連接中斷時，該UDP連接也必須中斷。
應答UDP ASSOCIATE請求時，BND.PORT 和BND.ADDR字段指明了客戶發送UDP消息至服務器的端口和地址。
應答處理
當 一個應答(REP值不等於00)指明出錯時，SOCKS服務器必須在發送完應答消息後一小段時間內終止TCP連接。這段時間應該在發現錯誤後少於10秒。 如果一個應答(REP值等於00)指明成功，並且請求是一個BIND或CONNECT時，客戶端就可以開始發送數據了。如果協商的認證方法中有以完整性、 認證和/或安全性為目的的封裝，這些請求必須按照該方法所定義的方式進行封裝。類似的，當以客戶機為目的地的數據到達SOCKS服務器
時，SOCKS服務器必須用正在使用的方法對這些數據進行封裝。
7．基於UDP協議的客戶
在UDP ASSOCIATE應答中由BND.PORT指明了服務器所使用的UDP端口，一個基於UDP協議的客戶必須發送數據報至UDP轉發服務器的該端口上。如 果協商的認證方法中有以完整性、認證和/或安全性為目的的封裝，這些數據報必須按照該方法所定義的方式進行封裝。每個UDP數據報都有一個UDP請求頭在 其首部：
RSV
FRAG
ATYP
DST.ADDR
DST.PORT
DATA
2
1
1
Variable
2
Variable
在UDP請求頭中的字段是：
? RSV 保留 X'0000'
? FRAG 當前的分段號
? ATYP 後面的地址類型
? IPV4：X'01'
? 域名：X'03'
? IPV6：X'04'
? DST.ADDR 目的地址
? DST.PORT 以網絡字節順序出現的端口號
? DATA 用戶數據
當一個UDP轉發服務器轉發一個UDP數據報時，不會發送任何通知給客戶端；同樣，它也將丟棄任何它不能發至遠端主機的數據報。當UDP轉發服務器從遠端服務器收到一個應答的數據報時，
必 須加上上述UDP請求頭，並對數據報進行封裝。UDP轉發服務器必須從SOCKS服務器得到期望的客戶端IP地址，並將數據報發送到 UDPASSOCIATE應答中給定的端口號。如果數據報從任何IP地址到來，而該IP地址與該特定連接中指定的IP地址不同，那麼該數據報會被丟棄。
FRAG字段指明數據報是否是一些分片中的一片。如果SOCKS服務器要實現這個功能，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客戶與SOCKS服務器之間經協商所選定的特殊的認證和封裝方
式。
系統管理員需要對用戶認證方式的選擇進行仔細考慮。
9. 參考書目
[1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium.
作者地址
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
RFC1929——SOCKETS V5 SOCKETS V5
RFC文檔中文翻譯計劃
沒有留言:
張貼留言