RFC1928 日本語訳
1928 SOCKS Protocol Version 5. M. Leech, M. Ganis, Y. Lee, R. Kuris,D. Koblas, L. Jones. March 1996. (Format: TXT=19741 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループM.ヒルの要求をネットワークでつないでください: 1928年のベル-北研究Ltdカテゴリ: 標準化過程M.Ganisインターナショナル・ビジネス・マシーンズY.リーNECシステム研究所R.Kurisは1996年の会社行進のときに社のD.のKoblasの独立しているコンサルタントのL.ジョーンズのヒューレット・パッカードを統一します。
SOCKS Protocol Version 5
ソックスはバージョン5について議定書の中で述べます。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
このメモはプロトコル、バージョン4[1]の旧バージョンの発展であるプロトコルについて説明します。 この新しいプロトコルは活発な議論とプロトタイプ実装によります。 主要な貢献者は以下の通りです。 マーカスヒル: ベル-北研究、デヴィッドKoblas: 独立しているコンサルタント、Ying-Daリー: NECシステム研究所、ラモント・ジョーンズ: ヒューレット・パッカード会社、ロンKuris: マットGanis、社を統一してください: インターナショナル・ビジネス・マシーンズ。
1. Introduction
1. 序論
The use of network firewalls, systems that effectively isolate an organizations internal network structure from an exterior network, such as the INTERNET is becoming increasingly popular. These firewall systems typically act as application-layer gateways between networks, usually offering controlled TELNET, FTP, and SMTP access. With the emergence of more sophisticated application layer protocols designed to facilitate global information discovery, there exists a need to provide a general framework for these protocols to transparently and securely traverse a firewall.
ネットワークファイアウォール、事実上、インターネットなどの外のネットワークから組織インターナルネットワーク構造を隔離するシステムの使用はますますポピュラーになっています。 通常、制御TELNET、FTP、およびSMTPにアクセサリーを提供して、これらのファイアウォールシステムはネットワークの間の応用層ゲートウェイとして通常作動します。 より精巧な応用層プロトコルの出現がグローバルな情報発見を容易にするように設計されている状態で、これらのプロトコルが透過的に、しっかりとファイアウォールを横断するように一般的なフレームワークを提供する必要性は存在しています。
Leech, et al Standards Track [Page 1] RFC 1928 SOCKS Protocol Version 5 March 1996
ヒル、他のStandards Track[1ページ]RFC1928SOCKSプロトコルバージョン1996年3月5日
There exists, also, a need for strong authentication of such traversal in as fine-grained a manner as is practical. This requirement stems from the realization that client-server relationships emerge between the networks of various organizations, and that such relationships need to be controlled and often strongly authenticated.
また、実用的であるのときめ細かに同じくらい粒状の方法における、そのような縦断の強い認証の必要性は存在しています。 この要件はクライアント/サーバー関係が様々な組織のネットワークの間に現れて、そのような関係が制御されて、しばしば強く認証される必要があるという認識によります。
The protocol described here is designed to provide a framework for client-server applications in both the TCP and UDP domains to conveniently and securely use the services of a network firewall. The protocol is conceptually a "shim-layer" between the application layer and the transport layer, and as such does not provide network- layer gateway services, such as forwarding of ICMP messages.
ここで説明されたプロトコルは、TCPとUDPドメインの両方のクライアント/サーバアプリケーションが便利にしっかりとネットワークファイアウォールのサービスを利用するようにフレームワークを提供するように設計されています。 プロトコルは概念的に、「詰め物層」は応用層とトランスポート層の間、そして、そういうものとしてネットワーク層のゲートウェイサービスを提供しません、ICMPメッセージの推進などのようにことです。
2. Existing practice
2. 既存の習慣
There currently exists a protocol, SOCKS Version 4, that provides for unsecured firewall traversal for TCP-based client-server applications, including TELNET, FTP and the popular information- discovery protocols such as HTTP, WAIS and GOPHER.
プロトコル、SOCKSバージョン4は現在存在します、とそれがTCPベースのクライアント/サーバアプリケーションのための非機密保護しているファイアウォール縦断に前提とします、TELNET、FTP、およびHTTPや、WAISやゴーファーなどのポピュラーな情報発見プロトコルを含んでいて。
This new protocol extends the SOCKS Version 4 model to include UDP, and extends the framework to include provisions for generalized strong authentication schemes, and extends the addressing scheme to encompass domain-name and V6 IP addresses.
この新しいプロトコルは、UDPを含むようにSOCKSバージョン4モデルを広げていて、一般化された強い認証体系のための条項を含むようにフレームワークを広げていて、ドメイン名とV6 IPアドレスを包含するようにアドレシング体系を広げています。
The implementation of the SOCKS protocol typically involves the recompilation or relinking of TCP-based client applications to use the appropriate encapsulation routines in the SOCKS library.
SOCKSプロトコルの実装は、SOCKS図書館で適切なカプセル化ルーチンを使用するためにTCPベースのクライアントアプリケーションの「再-編集」か再リンクに通常かかわります。
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 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.
別の方法で注意されない場合、パケット形式ダイヤグラムで現れる10進数は八重奏における、対応する分野の長さを表します。 与えられた八重奏が特定の値を呈しなければならないところでは、構文X'hh'は、その分野のただ一つの八重奏の値を指示するのに使用されます。 '可変である'という単語が使用されているとき、それは、対応する分野には関連している(1か2八重奏)長さの分野、またはデータ型分野によって定義された可変長があるのを示します。
3. Procedure for TCP-based clients
3. TCPベースのクライアントのための手順
When a TCP-based client wishes to establish a connection to an object that is reachable only via a firewall (such determination is left up to the implementation), it must open a TCP connection to the appropriate SOCKS port on the SOCKS server system. The SOCKS service is conventionally located on TCP port 1080. If the connection request succeeds, the client enters a negotiation for the
TCPベースのクライアントが単にファイアウォールで届いているオブジェクトに取引関係を築きたがっているとき(そのような決断は実装に任せられます)、それはSOCKSサーバシステムの上の適切なSOCKSポートにTCP接続を開かなければなりません。 SOCKSサービスは慣習上TCPポート1080に見つけられています。 接続要求が成功するなら、クライアントは交渉に入ります。
Leech, et al Standards Track [Page 2] RFC 1928 SOCKS Protocol Version 5 March 1996
ヒル、他のStandards Track[2ページ]RFC1928SOCKSプロトコルバージョン1996年3月5日
authentication method to be used, authenticates with the chosen method, then sends a relay request. The SOCKS server evaluates the request, and either establishes the appropriate connection or denies it.
認証方法、使用されるために、選ぶことでメソッドを認証して、リレー要求はその時、発信します。 SOCKSサーバは、要求を評価して、適切な接続を確立するか、またはそれを否定します。
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 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.
別の方法で注意されない場合、パケット形式ダイヤグラムで現れる10進数は八重奏における、対応する分野の長さを表します。 与えられた八重奏が特定の値を呈しなければならないところでは、構文X'hh'は、その分野のただ一つの八重奏の値を指示するのに使用されます。 '可変である'という単語が使用されているとき、それは、対応する分野には関連している(1か2八重奏)長さの分野、またはデータ型分野によって定義された可変長があるのを示します。
The client connects to the server, and sends a version identifier/method selection message:
クライアントは、サーバに接続して、バージョン識別子/メソッド選択メッセージを送ります:
+----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 to 255 |
+----+----------+----------+
+----+----------+----------+ |VER| NMETHODS| メソッド| +----+----------+----------+ | 1 | 1 | 1〜255| +----+----------+----------+
The VER field is set to X'05' for this version of the protocol. The NMETHODS field contains the number of method identifier octets that appear in the METHODS field.
VER分野はプロトコルのこのバージョンのためのX'05'に設定されます。 NMETHODS分野はMETHODS分野に現れるメソッド識別子八重奏の数を含んでいます。
The server selects from one of the methods given in METHODS, and sends a METHOD selection message:
サーバは、METHODSで与えられたメソッドの1つから選び抜いて、METHOD選択メッセージを送ります:
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
+----+--------+ |VER| メソッド| +----+--------+ | 1 | 1 | +----+--------+
If the selected METHOD is X'FF', none of the methods listed by the client are acceptable, and the client MUST close the connection.
'選択されたMETHODはX'FFです'なら、クライアントによって記載されたメソッドのいずれも許容できません、そして、クライアントは接続を終えなければなりません。
The values currently defined for METHOD are:
現在METHODのために定義されている値は以下の通りです。
o X'00' NO AUTHENTICATION REQUIRED
o X'01' GSSAPI
o X'02' USERNAME/PASSWORD
o X'03' to X'7F' IANA ASSIGNED
o X'80' to X'FE' RESERVED FOR PRIVATE METHODS
o X'FF' NO ACCEPTABLE METHODS
o X'FE'RESERVED FOR PRIVATE METHODS o X'FF'NO ACCEPTABLE METHODSへの'X'00'NO AUTHENTICATION REQUIRED o X'01'GSSAPI o X'02'USERNAME/PASSWORD o X'03'X'7F'IANA ASSIGNED o X80年'
The client and server then enter a method-specific sub-negotiation.
そして、クライアントとサーバはメソッド特有のサブ交渉に入ります。
Leech, et al Standards Track [Page 3] RFC 1928 SOCKS Protocol Version 5 March 1996
ヒル、他のStandards Track[3ページ]RFC1928SOCKSプロトコルバージョン1996年3月5日
Descriptions of the method-dependent sub-negotiations appear in separate memos.
メソッド依存するサブ交渉の記述は別々のメモに現れます。
Developers of new METHOD support for this protocol should contact IANA for a METHOD number. The ASSIGNED NUMBERS document should be referred to for a current list of METHOD numbers and their corresponding protocols.
このプロトコルの新しいMETHODサポートの開発者はMETHOD番号のためにIANAに連絡するべきです。 ASSIGNED NUMBERSドキュメントはMETHOD番号の現在のリストとそれらの対応するプロトコルについて参照されるべきです。
Compliant implementations MUST support GSSAPI and SHOULD support USERNAME/PASSWORD authentication methods.
対応する実装は、GSSAPIとSHOULDがサポートUSERNAME/PASSWORD認証方法であるとサポートしなければなりません。
4. Requests
4. 要求
Once the method-dependent subnegotiation has completed, the client sends the request details. If the negotiated method includes encapsulation for purposes of integrity checking and/or confidentiality, these requests MUST be encapsulated in the method- dependent encapsulation.
かつての副交渉が完成したメソッド扶養家族であり、クライアントは要求の詳細を送ります。 交渉されたメソッドが保全の照合、そして/または、秘密性の目的のためのカプセル化を含んでいるなら、メソッドに依存するカプセル化でこれらの要求をカプセル化しなければなりません。
The SOCKS request is formed as follows:
SOCKS要求は以下の通り形成されます:
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
+----+-----+-------+------+----------+----------+ |VER| CMD| RSV| ATYP| DST.ADDR| DST.PORT| +----+-----+-------+------+----------+----------+ | 1 | 1 | X'00'| 1 | 変数| 2 | +----+-----+-------+------+----------+----------+
Where:
どこ:
o VER protocol version: X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV RESERVED
o ATYP address type of following address
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port in network octet
order
o VERはバージョンについて議定書の中で述べます: X'05'o CMD o CONNECT X'01'o BIND X'02'o UDP ASSOCIATE X'03'o RSV RESERVED o ATYPはアドレスo IP V4アドレスに従うタイプに演説します: X'01'o DOMAINNAME: X'03'o IP V6アドレス: X'04'o DST.ADDRの必要な送付先アドレスo DST.PORTはネットワーク八重奏命令で仕向港を望んでいました。
The SOCKS server will typically evaluate the request based on source and destination addresses, and return one or more reply messages, as appropriate for the request type.
SOCKSサーバはソースと送付先アドレスと、より多くのリターン1応答メッセージに基づく要求を通常評価するでしょう、要求タイプにおいて、適切です。
Leech, et al Standards Track [Page 4] RFC 1928 SOCKS Protocol Version 5 March 1996
ヒル、他のStandards Track[4ページ]RFC1928SOCKSプロトコルバージョン1996年3月5日
5. Addressing
5. アドレシング
In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies the type of address contained within the field:
アドレス・フィールド(DST.ADDR、BND.ADDR)では、ATYP分野が分野の中に保管されていたアドレスのタイプを指定します:
o X'01'
o X'01'
the address is a version-4 IP address, with a length of 4 octets
アドレスは4つの八重奏の長さがあるバージョン-4IPアドレスです。
o X'03'
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.
アドレス・フィールドは完全修飾ドメイン名を含んでいます。 アドレス・フィールドの最初の八重奏は続く名前の八重奏の数を含んでいて、NUL八重奏を終えてはいけません。
o X'04'
o X'04'
the address is a version-6 IP address, with a length of 16 octets.
アドレスは16の八重奏の長さがあるバージョン-6IPアドレスです。
6. Replies
6. 返信
The SOCKS request information is sent by the client as soon as it has established a connection to the SOCKS server, and completed the authentication negotiations. The server evaluates the request, and returns a reply formed as follows:
SOCKSは、SOCKSサーバに取引関係を築いて、認証交渉を終了するとすぐに、情報がクライアントによって送られるよう要求します。 サーバは、要求を評価して、以下の通り形成された回答を返します:
+----+-----+-------+------+----------+----------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
+----+-----+-------+------+----------+----------+ |VER| レップ| RSV| ATYP| BND.ADDR| BND.PORT| +----+-----+-------+------+----------+----------+ | 1 | 1 | X'00'| 1 | 変数| 2 | +----+-----+-------+------+----------+----------+
Where:
どこ:
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' to X'FF' unassigned
o RSV RESERVED
o ATYP address type of following address
o VERはバージョンについて議定書の中で述べます: X'05'o REP Reply分野: o X、'00が'rulesetの手の届かないo X'04'Host手の届かないo X'03'Network o Xによって許されなかったo X'01'一般的なSOCKSサーバの故障o X'02'接続の後任となった'、05'Connectionがo Xを拒否した、'TTLは○ X'07を吐き出した'Commandが○ X'08'Addressタイプをサポートしなかった'06が、oがX'09'であるとアドレスに従うo RSV RESERVED o ATYPアドレスタイプに割り当てられなかったX'FF'にサポートしませんでした。
Leech, et al Standards Track [Page 5] RFC 1928 SOCKS Protocol Version 5 March 1996
ヒル、他のStandards Track[5ページ]RFC1928SOCKSプロトコルバージョン1996年3月5日
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o BND.ADDR server bound address
o BND.PORT server bound port in network octet order
o IP V4アドレス: X'01'o DOMAINNAME: X'03'o IP V6アドレス: X'04'o BND.ADDRサーババウンドアドレスo BND.PORTサーバはネットワーク八重奏命令でポートを縛りました。
Fields marked RESERVED (RSV) must be set to X'00'.
RESERVED(RSV)であることが示される分野をX'00'に設定しなければなりません。
If the chosen method includes encapsulation for purposes of authentication, integrity and/or confidentiality, the replies are encapsulated in the method-dependent encapsulation.
選ばれたメソッドが認証、保全、そして/または、秘密性の目的のためのカプセル化を含んでいるなら、回答はメソッド依存するカプセル化でカプセル化されます。
CONNECT
接続してください。
In the reply to a CONNECT, BND.PORT contains the port number that the server assigned to connect to the target host, while BND.ADDR contains the associated IP address. The supplied BND.ADDR is often different from the IP address that the client uses to reach the SOCKS server, since such servers are often multi-homed. It is expected that the SOCKS server will use DST.ADDR and DST.PORT, and the client-side source address and port in evaluating the CONNECT request.
CONNECTへの回答では、BND.PORTはサーバが目標ホストに接するために割り当てたポートナンバーを含んでいます、BND.ADDRが関連IPアドレスを含んでいますが。 供給されたBND.ADDRはクライアントがSOCKSサーバに達するのに使用するIPアドレスとしばしば異なっています、しばしばそのようなサーバがそうのでマルチ、家へ帰り SOCKSサーバがCONNECT要求を評価する際にDST.ADDR、DST.PORT、クライアントサイドソースアドレス、およびポートを使用すると予想されます。
BIND
ひも
The BIND request is used in protocols which require the client to accept connections from the server. FTP is a well-known example, which uses the primary client-to-server connection for commands and status reports, but may use a server-to-client connection for transferring data on demand (e.g. LS, GET, PUT).
BIND要求はクライアントがサーバから接続を受け入れるのを必要とするプロトコルに使用されます。(それは、コマンドと現状報告にクライアントからサーバとのプライマリ接続を使用します)。FTPは、よく知られる例ですが、オンデマンドのデータ(例えば、LS、GET、PUT)を移すのにサーバからクライアントとの接続を使用するかもしれません。
It is expected that the client side of an application protocol will use the BIND request only to establish secondary connections after a primary connection is established using CONNECT. In is expected that a SOCKS server will use DST.ADDR and DST.PORT in evaluating the BIND request.
アプリケーション・プロトコルのクライアント側がプライマリ接続がCONNECTを使用することで確立された後に単にセカンダリ接続を確立するというBIND要求を使用すると予想されます。 SOCKSサーバがBIND要求を評価しながらDST.ADDRとDST.PORTを使用するコネは予想されます。
Two replies are sent from the SOCKS server to the client during a BIND operation. The first is sent after the server creates and binds a new socket. The BND.PORT field contains the port number that the SOCKS server assigned to listen for an incoming connection. The BND.ADDR field contains the associated IP address. The client will typically use these pieces of information to notify (via the primary or control connection) the application server of the rendezvous address. The second reply occurs only after the anticipated incoming connection succeeds or fails.
BIND操作の間、SOCKSサーバからクライアントに2つの回答を送ります。 サーバが新しいソケットを作成して、縛った後に1番目を送ります。 BND.PORT分野はSOCKSサーバが接続要求の聞こうとするために割り当てたポートナンバーを含んでいます。 BND.ADDR分野は関連IPアドレスを含んでいます。 クライアントは、ランデブーアドレスのアプリケーション・サーバーに通知すること(予備選挙かコントロール接続で)にこれらの情報を通常使用するでしょう。 予期された接続要求が成功するか、または失敗した後にだけ2番目の回答は起こります。
Leech, et al Standards Track [Page 6] RFC 1928 SOCKS Protocol Version 5 March 1996
ヒル、他のStandards Track[6ページ]RFC1928SOCKSプロトコルバージョン1996年3月5日
In the second reply, the BND.PORT and BND.ADDR fields contain the address and port number of the connecting host.
2番目の回答では、BND.PORTとBND.ADDR分野は接続ホストのアドレスとポートナンバーを含んでいます。
UDP ASSOCIATE
UDPは交際します。
The UDP ASSOCIATE request is used to establish an association within the UDP relay process to handle UDP datagrams. The DST.ADDR and DST.PORT fields contain the address and port that the client expects to use to send UDP datagrams on for the association. The server MAY use this information to limit access to the association. If the client is not in possesion of the information at the time of the UDP ASSOCIATE, the client MUST use a port number and address of all zeros.
UDP ASSOCIATE要求は、UDPデータグラムを扱うUDPリレープロセスの中の協会を証明するのに使用されます。DST.ADDRとDST.PORT分野はアドレスとクライアントが協会に、オンなデータグラムをUDPに送るのに使用すると予想するポートを含んでいます。 サーバは、アクセスを協会に制限するのにこの情報を使用するかもしれません。 クライアントがUDP ASSOCIATE時点で情報のpossesionにいないなら、クライアントはすべてのゼロのポートナンバーとアドレスを使用しなければなりません。
A UDP association terminates when the TCP connection that the UDP ASSOCIATE request arrived on terminates.
UDP ASSOCIATE要求が到着したTCP接続が終わると、UDP協会は終わります。
In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR fields indicate the port number/address where the client MUST send UDP request messages to be relayed.
UDP ASSOCIATE要求に関する回答では、BND.PORTとBND.ADDR分野はクライアントがリレーされるべき要求メッセージをUDPに送らなければならないポートナンバー/アドレスを示します。
Reply Processing
回答処理
When a reply (REP value other than X'00') indicates a failure, the SOCKS server MUST terminate the TCP connection shortly after sending the reply. This must be no more than 10 seconds after detecting the condition that caused a failure.
回答(X'00'を除いたREP値)が失敗を示すとき、回答を送ったすぐ後に、SOCKSサーバはTCP接続を終えなければなりません。 これは失敗を引き起こした状態を検出した10秒未満後でなければなりません。
If the reply code (REP value of X'00') indicates a success, and the request was either a BIND or a CONNECT, the client may now start passing data. If the selected authentication method supports encapsulation for the purposes of integrity, authentication and/or confidentiality, the data are encapsulated using the method-dependent encapsulation. Similarly, when data arrives at the SOCKS server for the client, the server MUST encapsulate the data as appropriate for the authentication method in use.
要求が回答コード(X'00'のREP値)が成功を示して、BINDかCONNECTのどちらかであったなら、クライアントは、今、データを通過し始めるかもしれません。 選択された認証方法が保全、認証、そして/または、秘密性の目的のためにカプセル化をサポートするなら、データは、メソッド依存するカプセル化を使用することでカプセル化されます。 同様に、データがクライアントのためにSOCKSサーバに到着すると、サーバは使用中の認証方法のために適宜データをカプセル化しなければなりません。
7. Procedure for UDP-based clients
7. UDPベースのクライアントのための手順
A UDP-based client MUST send its datagrams to the UDP relay server at the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE request. If the selected authentication method provides encapsulation for the purposes of authenticity, integrity, and/or confidentiality, the datagram MUST be encapsulated using the appropriate encapsulation. Each UDP datagram carries a UDP request header with it:
UDPベースのクライアントはUDP ASSOCIATE要求に関する回答でBND.PORTによって示されたUDPポートのUDPリレーサーバにデータグラムを送らなければなりません。 選択された認証方法が信憑性、保全、そして/または、秘密性の目的にカプセル化を提供するなら、適切なカプセル化を使用して、データグラムをカプセル化しなければなりません。 それぞれのUDPデータグラムはそれでUDP要求ヘッダーを運びます:
Leech, et al Standards Track [Page 7] RFC 1928 SOCKS Protocol Version 5 March 1996
ヒル、他のStandards Track[7ページ]RFC1928SOCKSプロトコルバージョン1996年3月5日
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+
+----+------+------+----------+----------+----------+ |RSV| 破片手榴弾で殺傷してください。| ATYP| DST.ADDR| DST.PORT| データ| +----+------+------+----------+----------+----------+ | 2 | 1 | 1 | 変数| 2 | 変数| +----+------+------+----------+----------+----------+
The fields in the UDP request header are:
UDP要求ヘッダーの分野は以下の通りです。
o RSV Reserved X'0000'
o FRAG Current fragment number
o ATYP address type of following addresses:
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port
o DATA user data
o RSV Reserved X'0000'o FRAG Current断片番号o ATYPはアドレスに従うタイプに演説します: o IP V4アドレス: X'01'o DOMAINNAME: X'03'o IP V6アドレス: X'04'o DST.ADDRの必要な送付先アドレスoのDST.PORTの必要な仕向港o DATA利用者データ
When a UDP relay server decides to relay a UDP datagram, it does so silently, without any notification to the requesting client. Similarly, it will drop datagrams it cannot or will not relay. When a UDP relay server receives a reply datagram from a remote host, it MUST encapsulate that datagram using the above UDP request header, and any authentication-method-dependent encapsulation.
UDPリレーサーバが、UDPデータグラムをリレーすると決めると、それほど静かにします、要求しているクライアントへの少しも通知なしで。 同様に、それはリレーしないか、またはリレーできないデータグラムを下げるでしょう。 UDPリレーサーバがリモートホストから応答データグラムを受けるとき、上のUDP要求ヘッダー、およびどんな認証メソッド扶養家族カプセル化も使用して、それはそのデータグラムをカプセル化しなければなりません。
The UDP relay server MUST acquire from the SOCKS server the expected IP address of the client that will send datagrams to the BND.PORT given in the reply to UDP ASSOCIATE. It MUST drop any datagrams arriving from any source IP address other than the one recorded for the particular association.
UDPリレーサーバはSOCKSサーバから回答でUDP ASSOCIATEに与えられたBND.PORTにデータグラムを送るクライアントの予想されたIPアドレスを習得しなければなりません。 それは特定の協会のために記録されたもの以外のどんなソースIPアドレスからも届くどんなデータグラムも下げなければなりません。
The FRAG field indicates whether or not this datagram is one of a number of fragments. If implemented, the high-order bit indicates end-of-fragment sequence, while a value of X'00' indicates that this datagram is standalone. Values between 1 and 127 indicate the fragment position within a fragment sequence. Each receiver will have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these fragments. The reassembly queue must be reinitialized and the associated fragments abandoned whenever the REASSEMBLY TIMER expires, or a new datagram arrives carrying a FRAG field whose value is less than the highest FRAG value processed for this fragment sequence. The reassembly timer MUST be no less than 5 seconds. It is recommended that fragmentation be avoided by applications wherever possible.
FRAG分野は、このデータグラムが多くの断片の1つであるかどうかを示します。 実装されるなら、高位のビットは断片の端の系列を示しますが、X'00'の値は、このデータグラムがスタンドアロンであることを示します。 1と127の間の値は断片系列の中に断片位置を示します。 各受信機には、これらの断片に関連しているREASSEMBLY QUEUEとREASSEMBLY TIMERがあるでしょう。 再アセンブリ待ち行列を再初期化しなければなりませんでした、そして、REASSEMBLY TIMERが期限が切れるか、または新しいデータグラムが値が最も高いFRAG値以下であるFRAG野原を運びながら届くときはいつも、捨てられた関連断片はこの断片系列のために処理されました。 再アセンブリタイマは5秒未満ノーであるに違いありません。 断片化がどこでも、可能であるところでアプリケーションで避けられるのは、お勧めです。
Implementation of fragmentation is optional; an implementation that does not support fragmentation MUST drop any datagram whose FRAG field is other than X'00'.
断片化の実装は任意です。 断片化をサポートしない実装はX'00'を除いて、FRAG分野があるどんなデータグラムも下げなければなりません。
Leech, et al Standards Track [Page 8] RFC 1928 SOCKS Protocol Version 5 March 1996
ヒル、他のStandards Track[8ページ]RFC1928SOCKSプロトコルバージョン1996年3月5日
The programming interface for a SOCKS-aware UDP MUST report an available buffer space for UDP datagrams that is smaller than the actual space provided by the operating system:
SOCKS意識しているUDP MUSTがUDPのために利用可能なバッファ領域を報告するのをデータグラムのためのオペレーティングシステムで提供された実際のスペースより小さいプログラミングインターフェース:
o if ATYP is X'01' - 10+method_dependent octets smaller
o if ATYP is X'03' - 262+method_dependent octets smaller
o if ATYP is X'04' - 20+method_dependent octets smaller
o ○ ○ ATYPが_依存する八重奏で、より小さくX'04'--20+メソッドであるならATYPが_依存する八重奏で、より小さくX'03'--262+メソッドであるならATYPが_依存する八重奏で、より小さくX'01'--10+メソッドであるなら
8. Security Considerations
8. セキュリティ問題
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.
このドキュメントはIPネットワークファイアウォールの応用層縦断のためにプロトコルについて説明します。 そのような縦断のセキュリティは特定の実装に提供されて、SOCKSクライアントとSOCKSサーバとの交渉の間に選択された特定の認証とカプセル化メソッドに非常に依存しています。
Careful consideration should be given by the administrator to the selection of authentication methods.
熟慮は管理者によって認証方法の品揃えに与えられるべきです。
9. References
9. 参照
[1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium.
[1]Koblas、D.、「ソックス」、議事: 1992年のUsenixセキュリティシンポジウム。
Author's Address
作者のアドレス
Marcus Leech
Bell-Northern Research Ltd
P.O. Box 3511, Stn. C,
Ottawa, ON
CANADA K1Y 4H7
マーカスヒルのベル-北研究Ltd私書箱3511、Stn。 C、カナダK1Y 4H7の上のオタワ
Phone: (613) 763-9145
EMail: mleech@bnr.ca
以下に電話をしてください。 (613) 763-9145 メールしてください: mleech@bnr.ca
Leech, et al Standards Track [Page 9]
ヒル、他のStandards Track[9ページ]
一覧
スポンサーリンク
