[要約] RFC 3620は、TUNNELプロファイルに関する仕様であり、IPトンネリングのためのセキュリティ要件を定義しています。その目的は、IPトンネリングのセキュリティを向上させ、ネットワーク上のデータの機密性と完全性を確保することです。
Network Working Group D. New
Request for Comments: 3620 October 2003
Category: Standards Track
The TUNNEL Profile
トンネルプロファイル
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.
このメモでは、ビープピアがアプリケーション層プロキシとして機能することを可能にするブロック拡張可能な交換プロトコル（BEEP）プロファイルについて説明しています。許可されたユーザーがファイアウォールを介してサービスにアクセスできるようになります。
Table of Contents
目次
1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 One-Hop Example. . . . . . . . . . . . . . . . . . . . . . 3
2.2 Two-Hop Example. . . . . . . . . . . . . . . . . . . . . . 4
2.3 Failed Set-Up Example. . . . . . . . . . . . . . . . . . . 5
2.4 Non-BEEP Example . . . . . . . . . . . . . . . . . . . . . 5
2.5 Profile Example. . . . . . . . . . . . . . . . . . . . . . 6
2.6 Endpoint Example . . . . . . . . . . . . . . . . . . . . . 8
3. Message Syntax. . . . . . . . . . . . . . . . . . . . . . . . 9
4. Message Semantics . . . . . . . . . . . . . . . . . . . . . . 10
5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Reply Codes. . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . . 15
A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
A.1 Registration: BEEP Profile . . . . . . . . . . . . . . . . 16
A.2 Registration: A System (Well-Known) TCP
port number for TUNNEL . . . . . . . . . . . . . . . . . . 16
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
The TUNNEL profile provides a mechanism for cooperating BEEP peers to form an application-layer tunnel. The peers exchange "tunnel" elements that specify a source route, with the outermost element being stripped off and used to decide the next hop. The innermost, empty "tunnel" element tells the final destination that it is, indeed, the final destination. The term "proxy" is used to refer any of the BEEP peers other than the initiator and the final destination.
トンネルプロファイルは、ビープ音のピアを協力してアプリケーション層トンネルを形成するメカニズムを提供します。ピアは、ソースルートを指定する「トンネル」要素を交換し、最も外側の要素を取り除き、次のホップを決定するために使用されます。最も内側の空の「トンネル」要素は、最終的な目的地に、実際には最終目的地であることを伝えます。「プロキシ」という用語は、イニシエーターと最終目的地以外のビープピアを参照するために使用されます。
In one use of this profile, a BEEP peer implementing the TUNNEL profile is co-resident with a firewall. An initiating machine inside the firewall makes a connection to the proxy, then ask that proxy to make a connection to an endpoint outside the firewall. Once this connection is established, the proxy tells the outside endpoint that it will be tunneling. If the outside machine agrees, the proxy "gets out of the way," simply passing octets transparently, and both the initiating and terminating machines perform a "tuning reset," not unlike the way starting a TLS negotiation discards cached session state and starts anew.
このプロファイルの1つの使用では、トンネルプロファイルを実装するビープピアがファイアウォールと共同住宅です。ファイアウォール内の開始マシンがプロキシに接続し、そのプロキシにファイアウォールの外側のエンドポイントに接続するように依頼します。この接続が確立されると、プロキシは外側のエンドポイントにトンネリングになることを伝えます。外部マシンが同意した場合、プロキシは「邪魔にならない」、単にオクテットを透過的に渡すだけで、開始マシンと終端マシンの両方が「チューニングリセット」を実行します。。
Another use for this profile is to limit connections to outside servers based on the user identity negotiated via SASL. For example, a manager may connect to a proxy, authenticate herself with SASL, then instruct the proxy to tunnel to an information service restricted to managers. Since each proxy knows the identity of the next proxy being requested, it can refuse to tunnel connections if inadequate levels of authorization have been established. It is also possible to use the TUNNEL profile to anonymize the true source of a BEEP connection, in much the way a NAT translates IP addresses. However, detailed discussion of such uses is beyond the scope of this document.
このプロファイルのもう1つの用途は、SASLを介してネゴシエートされたユーザーIDに基づいて、外部サーバーへの接続を制限することです。たとえば、マネージャーはプロキシに接続し、SASLで自分自身を認証し、プロキシにマネージャーに制限された情報サービスにトンネルを指示することができます。各プロキシは、要求される次のプロキシの身元を知っているため、不適切なレベルの承認が確立されている場合、接続のトンネルを拒否できます。また、トンネルプロファイルを使用して、NATがIPアドレスを翻訳する方法で、ビープ効果の真のソースを匿名化することも可能です。ただし、このような用途の詳細な議論は、このドキュメントの範囲を超えています。
Once both endpoint machines are connected, the tunneling proxy machine does no further interpretation of the data. In particular, it does not look for any BEEP framing. The two endpoint machines may therefore negotiate TLS between them, passing certificates appropriate to the endpoints rather than the proxy, with the assurance that even the proxy cannot access the information exchanged.
両方のエンドポイントマシンが接続されたら、トンネリングプロキシマシンはデータをこれ以上解釈しません。特に、ビープ音を探していません。したがって、2つのエンドポイントマシンは、それらの間でTLSを交渉し、プロキシではなくエンドポイントに適した証明書を渡すことができ、プロキシでさえ交換された情報にアクセスできないという保証があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。
While the semantics described in Section 4 may seem complex, the results are actually relatively simple. A few examples will show the operation and use of this profile. In these examples, the machine attempting to establish the connection is named "initial", while the intermediate proxies are "proxy1" or "proxy2", and the machine with the service that "initial" wishes to access is called "final". The examples also assume that the BEEP framework [2] is implemented on top of TCP [3], or some other mapping where one transport connection carries all channels.
セクション4で説明されているセマンティクスは複雑に思えるかもしれませんが、結果は実際には比較的単純です。いくつかの例では、このプロファイルの操作と使用を示します。これらの例では、接続を確立しようとするマシンは「初期」と呼ばれ、中間プロキシは「proxy1」または「proxy2」と呼ばれ、「初期」の希望を持つサービスを備えたマシンは「final」と呼ばれます。また、この例では、ビープフレームワーク[2]がTCP [3]の上に実装されていること、または1つの輸送接続がすべてのチャネルを運ぶ他のマッピングが実装されていることを想定しています。
A simple one-hop connection through a single proxy is illustrated first.
最初に単一のプロキシを介した単純なワンホップ接続が示されています。
initial proxy1 final
----- xport connect ----->
<------- greeting -------->
--- start TUNNEL [1] ---->
----- xport connect ------>
<-------- greeting -------->
---- start TUNNEL [2] ---->
<---------- ok ------------
<------- ok -------------- [3]
<------------- greeting [4]-------------------------->
Notes:
ノート：
[1] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' port='604'>
<tunnel/>
</tunnel>
[2] The TUNNEL element looks like this: <tunnel/>
[2] トンネル要素は次のようになります：<トンネル/>
[3] At this point, immediately after sending the <ok/> element, proxy1 starts passing octets transparently. It continues to do so until either transport connection is closed, after which it closes the other.
[3] この時点で、<ok/>要素を送信した直後に、proxy1はオクテットを透過的に通過し始めます。いずれかの輸送接続が閉じられるまで、それを続けます。その後、他方を閉じます。
[4] This greeting may include the TLS profile, allowing initial and final to communicate without proxy1 understanding or interfering without being caught.
[4] この挨拶には、TLSプロファイルが含まれる場合があり、初期および最終的にはproxy1の理解せずに通信できます。
The second example shows the initiator connecting to its proxy, that proxy connecting to another, and finally that second proxy finding a service outside.
2番目の例は、プロキシに接続するイニシエーター、他のプロキシに接続するプロキシ、そして最後に2番目のプロキシが外部にサービスを見つけたことを示しています。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
ノート：
[1] The TUNNEL element looks like this:
<tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' port='10290'>
<tunnel/>
</tunnel>
</tunnel>
[2] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' port='10290'>
<tunnel/>
</tunnel>
[3] The TUNNEL element looks like this: <tunnel/>
[3] トンネル要素は次のようになります：<トンネル/>
[4] Proxy2 starts passing octets transparently after sending the <ok/>.
[4] proxy2は、<ok/>を送信した後、オクテットを透過的に通過し始めます。
[5] Proxy1 starts passing octets transparently after sending the <ok/>.
[5] proxy1は、<ok/>を送信した後、オクテットを透過的に通過し始めます。
The third example shows the initiator connecting through two proxys, the second proxy attempting to connect to the specified service and finding the destination is not a BEEP server. (Of course, specifying the telnet service can be expected to lead to this error.) The same would result if the destination did not support the TUNNEL profile.
3番目の例は、2つのプロキシを介して接続するイニシエーターを示しています。指定されたサービスに接続して宛先を見つけることを試みる2番目のプロキシは、ビープサーバーではありません。（もちろん、Telnetサービスを指定すると、このエラーが発生すると予想されます。）目的地がトンネルプロファイルをサポートしなかった場合、同じことが生じます。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
--- xport connect -->
<----- greeting ----->
--start TUNNEL [2]-->
---- xport connect --->
<------- login: -------
----- xport close ---->
<---- <error> -------
--- xport close ---->
<---- <error> ------
--- xport close ---> [3]
Notes:
ノート：
[1] The TUNNEL element looks like this:
<tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
<tunnel/>
</tunnel>
</tunnel>
[2] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
<tunnel/>
</tunnel>
[3] This close is optional. "Initial" may also send another <tunnel> element, attempting to contact a different server, for example.
[3] このクローズはオプションです。「初期」は、別のサーバーに連絡しようとする別の<トンネル>要素を送信する場合もあります。
This example shows the initiator connecting through two proxys, the second proxy attempting to connect to the specified service and accepting that the destination is not a BEEP server. The difference at the protocol level is two-fold: The "initial" machine does not include the innermost "tunnel" element, and the final proxy ("proxy2") therefore does not expect a BEEP greeting.
この例は、2つのプロキシを介して接続するイニシエーターを示しています。これは、指定されたサービスに接続しようとする2番目のプロキシであり、目的地がビープサーバーではないことを受け入れます。プロトコルレベルでの違いは2つあります。「初期」マシンには、最も内側の」トンネル "要素は含まれません。したがって、最終プロキシ（" proxy2 "）はビープ音が挨拶することを期待していません。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
--- xport connect -->
<----- greeting ----->
--start TUNNEL [2]-->
---- xport connect --->
<------- login: -------
<------ <ok> ------- [3]
<----- login: ------ [4]
<------ <ok> --------- [3]
<----- login: -------- [4] [5]
Notes:
ノート：
[1] The TUNNEL element looks like this: <tunnel fqdn='proxy2.example.com' port='604'> <tunnel fqdn='final.example.com' svc='_telnet._tcp'> </tunnel> </tunnel> Note the lack of an innermost no-attribute <tunnel> element.
[1] トンネル要素は次のようになります。>最も内側の属性<tunnel>要素の欠如に注意してください。
[2] The TUNNEL element looks like this: <tunnel fqdn='final.example.com' srv='_telnet._tcp'> </tunnel> Note the lack of an innermost no-attribute <tunnel> element.
[2] トンネル要素は次のようになります。
[3] Each proxy starts transparently forwarding octets after this <ok>.
[3] 各プロキシは、この<OK>の後にオクテットを透過的に転送し始めます。
[4] Each proxy forwards any data it received from the final host, even if that data arrived before the <ok> was sent.
[4] 各プロキシは、<ok>が送信される前にそのデータが到着したとしても、最終ホストから受信したデータを転送します。
[5] After receiving the "ok" message, the "initial" peer can expect raw, non-BEEP data to be sent to and received from the "final" machine.
[5] 「OK」メッセージを受信した後、「最初の」ピアは、「最終」マシンに送信され、受信される生の非ビープデータを期待できます。
This example shows the initiator connecting through two proxys. The initial machine knows there is a server offering the SEP2 profile somewhere beyond proxy1, but it need not know where. Proxy1 has been locally configured to know that all SEP2 servers are beyond proxy2. Proxy2 has been locally configured to chose "final" as the server of choice for SEP2 services. Note that "final" does not necessarily need to offer the requested profile in its initial greeting.
この例は、2つのプロキシを介して接続するイニシエーターを示しています。最初のマシンは、proxy1を超えたどこかにSEP2プロファイルを提供するサーバーがあることを知っていますが、どこで知る必要はありません。proxy1は、すべてのSEP2サーバーがproxy2を超えていることを知るようにローカルに構成されています。Proxy2は、SEP2サービスに選択したサーバーとして「最終」を選択するようにローカルで構成されています。「最終」は、最初の挨拶で要求されたプロファイルを必ずしも提供する必要はないことに注意してください。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
ノート：
[1] The TUNNEL element looks like this: <tunnel profile="http://xml.resource/org/profiles/SEP2"/> Note the lack of an innermost no-attribute <tunnel> element.
[1] トンネル要素は次のようになります。
[2] Proxy1 maps this to <tunnel fqdn="proxy2.example.com" port="604"> <tunnel profile="http://xml.resource/org/profiles/SEP2"/> </tunnel> based on local configuration, then processes the new element, stripping off the outer element and routing <tunnel profile="http://xml.resource/org/profiles/SEP2"/> to proxy2.
[2] proxy1はこれを<トンネルfqdn = "proxy2.example.com" port = "604"> <トンネルプロファイル= "http：//xml.resource/org/profiles/sep2"/> </tunnel>、次に、新しい要素を処理し、外側の要素を取り除き、ルーティング<トンネルプロファイル= "http：//xml.resource/org/profiles/sep2"/>をproxy2にします。
[3] Proxy2 receives the TUNNEL element with simply the SEP2 URI specified. Local provisioning maps this to <tunnel fqdn='final.example.com' srv='_beep._tcp'> <tunnel/> </tunnel> Note the presence of an innermost no-attribute <tunnel> element. Proxy2 then strips the outermost element, looking up the appropriate address and port, and forwards the <tunnel/> element to the final machine.
[3] Proxy2は、単にSEP2 URIが指定された単純なトンネル要素を受信します。ローカルプロビジョニングは、これを<トンネルfqdn = 'final.example.com' srv = '_ beep._tcp'> <tunnel/> </tunnel>最も内側の属性<トンネル>要素の存在に注意してください。次に、Proxy2は最も外側の要素をストリップし、適切なアドレスとポートを検索し、<トンネル/>要素を最終マシンに転送します。
[4] Proxy2 starts transparently forwarding octets after this <ok>.
[4] proxy2は、この後にオクテットを透過的に転送し始めます<ok>。
[5] Proxy1 starts transparently forwarding octets after this <ok>.
[5] proxy1は、この後にオクテットを透過的に転送し始めます<ok>。
This example shows the initiator connecting through two proxys. The initial machine knows there is a server known as "operator console" somewhere beyond proxy1, but it needs not know where. Proxy1 has been locally configured to know that "operator console" is beyond proxy2. Proxy2 has been locally configured to use "final" as "operator console". This example is almost identical to the previous example, except that "endpoint" is intended to route to a particular server, while "profile" is intended to route to a particular service. Otherwise, these two attributes are very similar.
この例は、2つのプロキシを介して接続するイニシエーターを示しています。最初のマシンは、proxy1を超えた「オペレーターコンソール」と呼ばれるサーバーがあることを知っていますが、どこでわからない必要はありません。proxy1は、「オペレーターコンソール」がproxy2を超えていることを知るようにローカルに構成されています。proxy2は、「最終」として「オペレーターコンソール」として使用するようにローカルで構成されています。この例は、「エンドポイント」が特定のサーバーにルーティングすることを目的としているのに対し、「プロファイル」は特定のサービスにルーティングすることを目的としていることを除いて、この例とほぼ同じです。それ以外の場合、これらの2つの属性は非常に似ています。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
ノート：
[1] The TUNNEL element looks like this: <tunnel endpoint="operator console"> </tunnel> Note the lack of an innermost no-attribute <tunnel> element.
[1] トンネル要素は次のようになります。
[2] Proxy1 maps this to <tunnel fqdn="proxy2.example.com" port="604"> <tunnel endpoint="operator console"> </tunnel> </tunnel> based on local configuration, then processes the new element, stripping off the outer element and routing <tunnel endpoint="operator console"> </tunnel> to proxy2.
[2] proxy1はこれを<トンネルfqdn = "proxy2.example.com" port = "604"> <トンネルエンドポイント= "オペレーターコンソール"> </tunnel> </tunnel>ローカル構成に基づいて、新しい要素を処理します。外側の要素とルーティング<トンネルendpoint = "operator Console"> </tunnel> Proxy2へ。
[3] Proxy2 receives the TUNNEL element with simply the endpoint specified. Local provisioning maps this to <tunnel fqdn='final.example.com' srv='_beep._tcp'> <tunnel/> </tunnel> Note the presence of an innermost no-attribute <tunnel> element. Proxy2 then strips the outermost element, looking up the appropriate address and port, and forwards the <tunnel/> element to the final machine.
[3] proxy2は、単に指定されたエンドポイントを使用してトンネル要素を受信します。ローカルプロビジョニングは、これを<トンネルfqdn = 'final.example.com' srv = '_ beep._tcp'> <tunnel/> </tunnel>最も内側の属性<トンネル>要素の存在に注意してください。次に、Proxy2は最も外側の要素をストリップし、適切なアドレスとポートを検索し、<トンネル/>要素を最終マシンに転送します。
[4] Proxy2 starts transparently forwarding octets after this <ok>.
[4] proxy2は、この後にオクテットを透過的に転送し始めます<ok>。
[5] Proxy1 starts transparently forwarding octets after this <ok>.
[5] proxy1は、この後にオクテットを透過的に転送し始めます<ok>。
The only element defined in this profile is the "tunnel" element. It is described in the following DTD, with additional limitations as described afterwards.
このプロファイルで定義されている唯一の要素は、「トンネル」要素です。以下のDTDで説明されており、後で説明する追加の制限があります。
<!-- DTD for the TUNNEL Profile, as of 2001-02-03
<！-2001-02-03の時点で、トンネルプロファイル用のDTD
Refer to this DTD as:
このDTDを次のように参照してください。
<!ENTITY % TUNNEL PUBLIC "-//IETF//DTD TUNNEL//EN" "">
%TUNNEL;
-->
<!-- TUNNEL messages
<！ - トンネルメッセージ
role MSG RPY
====== === ===
I or L TUNNEL +: ok
-: error
-->
<!ELEMENT tunnel (tunnel?)>
<!ATTLIST tunnel
fqdn CDATA #IMPLIED
ip4 CDATA #IMPLIED
ip6 CDATA #IMPLIED
port CDATA #IMPLIED
srv CDATA #IMPLIED
profile CDATA #IMPLIED
endpoint CDATA #IMPLIED
>
The format of the "fqdn" attribute is a fully qualified domain name, such as "proxy.example.com". The format of the "ip4" attribute is four sets of decimal numbers separated by periods, such as "10.23.34.45". The format of the "ip6" attribute is as specified in RFC2373 [4]. The format of the "port" attribute is a decimal number between one and 65535, inclusive. The format of the "srv" attribute is a pair of identifiers each starting with an underline and separated by a period, such as "_sep._tcp". The format of the "profile" attribute is a URI [5]. The format of the "endpoint" attribute is any string that may appear as an attribute value.
「fqdn」属性の形式は、「proxy.example.com」などの完全に適格なドメイン名です。「IP4」属性の形式は、「10.23.34.45」などの期間で区切られた小数点以下の4セットです。「IP6」属性の形式は、RFC2373 [4]で指定されているとおりです。「ポート」属性の形式は、1〜65535の10進数です。「srv」属性の形式は、それぞれ下線から始まり、「_sep._tcp」などの期間で区切られた識別子のペアです。「プロファイル」属性の形式はURIです[5]。「エンドポイント」属性の形式は、属性値として表示される任意の文字列です。
The only allowable combinations of attributes are as follows:
属性の唯一の許容組み合わせは次のとおりです。
o fqdn + port;
o fqdnポート;
o fqdn + srv;
o fqdn srv;
o fqdn + srv + port;
o FQDN SRVポート。
o ip4 + port;
o IP4ポート;
o ip6 + port;
o IP6ポート;
o profile, but only on the innermost element;
o プロファイルですが、最も内側の要素のみ。
o endpoint, but only on the innermost element; or,
o エンドポイントですが、最も内側の要素のみ。または、
o no attributes, but only on the innermost element.
o 属性はありませんが、最も内側の要素のみです。
When a TUNNEL channel is started, the listener expects a "tunnel" element from the initiator, either in the "start" element on channel zero or on the new channel created. As usual, if it arrives on channel zero, it is processed before the reply is returned.
トンネルチャネルが開始されると、リスナーは、チャネルゼロの「開始」要素または作成された新しいチャネルの「開始」要素のいずれかで、イニシエーターから「トンネル」要素を期待します。いつものように、チャネルゼロに到着すると、返信が返される前に処理されます。
In either case, the outermost "tunnel" element is examined. If it has no attributes, then this peer is hosting the BEEP service that the initiator wishes to use. In this case, the listener performs a tuning reset:
どちらの場合でも、最も外側の「トンネル」要素が調べられます。属性がない場合、このピアはイニシエーターが使用したいビープサービスをホストしています。この場合、リスナーはチューニングリセットを実行します。
o All channels, including channel zero, are implicitly closed.
o チャネルゼロを含むすべてのチャネルは、暗黙的に閉じられています。
o Any previously cached information about the BEEP session is discarded.
o ビープ音セッションに関する以前にキャッシュされた情報は破棄されます。
o A new plaintext greeting is sent.
o 新しいプレーンテキストの挨拶が送信されます。
If the outermost element has a "port" attribute and an "fqdn" attribute but no "srv" attribute, then "fqdn" is looked up as an A record via DNS for translation to an IP number. An "ip4" attribute is interpreted as the dotted-quad representation of an IPv4 address. An "ip6" attribute is interpreted as a text representation of an IPv6 address. In each of these cases, a transport connection is established to the so-identified server. If the outermost element has a "srv" attribute, the concatenation of the "srv" attribute and the "fqdn" attribute (with a period between) is looked up in the DNS for a SRV record [6], and the appropriate server is contacted; if that lookup fails and a "port" attribute is present, the connection is attempted as if the "srv" attribute were not specified.
最も外側の要素に「ポート」属性と「FQDN」属性があるが、「SRV」属性がない場合、「FQDN」はIP番号への翻訳のためのDNSを介してAレコードとして検索されます。「IP4」属性は、IPv4アドレスの点線表現として解釈されます。「IP6」属性は、IPv6アドレスのテキスト表現として解釈されます。これらの各ケースでは、輸送接続がSO-INDEDIFIED SERVERに確立されます。最も外側の要素が「SRV」属性を持っている場合、「SRV」属性と「FQDN」属性の連結（間の期間）がSRVレコード[6]のDNSで検索され、適切なサーバーは連絡先;そのルックアップが失敗し、「ポート」属性が存在する場合、「SRV」属性が指定されていないかのように接続が試みられます。
Alternately, if the outermost element has a "profile" attribute, then it must have no nested elements. The proxy processing this element is responsible for determining the appropriate routing to reach a peer serving the BEEP profile indicated by the URI in the attribute's value. Rather than source routing, this provides a hop-by-hop routing mechanism to a desired service.
あるいは、最も外側の要素に「プロファイル」属性がある場合、ネストされた要素は必要ありません。プロキシ処理この要素は、属性の値でURIが示すビープ音プロファイルに到達するピアに到達するための適切なルーティングを決定する責任があります。ソースルーティングではなく、これは望ましいサービスにホップバイホップルーティングメカニズムを提供します。
Similarly, if the outermost element has an "endpoint" attribute, then it must have no nested elements. The proxy processing this element is responsible for determining the appropriate routing to reach a peer indicated by the value of the "endpoint" attribute. Rather than source routing, this provides a hop-by-hop routing mechanism to a desired machine. There are no restrictions on how machines are identified.
同様に、最も外側の要素に「エンドポイント」属性がある場合、ネストされた要素は必要ありません。プロキシ処理この要素は、「エンドポイント」属性の値によって示されるピアに到達するための適切なルーティングを決定する責任があります。ソースルーティングではなく、これにより、目的のマシンにホップバイホップルーティングメカニズムが提供されます。マシンの識別方法に関する制限はありません。
Then, if the outermost element has no nested elements, but it does have attributes other than "profile" or "endpoint", then this peer is the final BEEP hop. (This corresponds to "proxy2" in the "Non-BEEP" example above.) In this case, as soon as the final underlying transport connection is established, an "ok" element is returned over the listening session, and the tunneling of data starts. No BEEP greeting (or indeed any data) from the final hop is expected. Starting with the octet following the END(CR)(LF) trailer of the frame with the completion flag set (more=".") of the RPY carrying the "ok" element, the proxy begins copying octets directly and without any interpretation between the two underlying transport connections.
次に、最も外側の要素にネストされた要素がないが、「プロファイル」または「エンドポイント」以外の属性がある場合、このピアは最終的なビープホップです。（これは上記の「非ビープ」例の「proxy2」に対応します。）この場合、最終的な基礎となる輸送接続が確立されるとすぐに、リスニングセッションで「OK」要素が返され、データのトンネルが返されます。開始。最終ホップからのビープ音（または実際にはデータ）は予想されません。「OK」要素を運ぶRPYの完了フラグセット（more = "。"）を使用して、フレームの終了（cr）（lf）トレーラーに続くオクテットから始まり、プロキシはオクテットを直接コピーし始めます。2つの基礎となる輸送接続。
If the identified server cannot be contacted, an "error" element is returned over the listening channel and any connection established as an initiator is closed. If there is a nested "tunnel" element, and the server that has been contacted does not offer a BEEP greeting, or the BEEP greeting offered does not include the TUNNEL profile, then this too is treated as an error: the initiating transport connection is closed, and an error is returned.
識別されたサーバーに接触できない場合、「エラー」要素がリスニングチャネル上で返され、イニシエーターとして確立された接続が閉じられます。ネストされた「トンネル」要素があり、接触したサーバーがビープ音を提供しない場合、または提供されるビープ音にはトンネルプロファイルが含まれない場合、これもエラーとして扱われます。開始輸送接続は閉じて、エラーが返されます。
If there is a nested "tunnel" element, and the identified server is contacted and offers a BEEP greeting including the TUNNEL profile, then the outermost element from the "tunnel" element received is stripped off, a new TUNNEL channel is started on the initiating session, and the stripped (inner) element is sent to start the next hop. In this case, the peer is considered a "proxy" (meaning that the next paragraph is applicable).
ネストされた「トンネル」要素があり、識別されたサーバーが接触し、トンネルプロファイルを含むビープ音を提供する場合、受信した「トンネル」要素の最も外側の要素が剥がされ、開始時に新しいトンネルチャネルが開始されますセッション、および剥がれた（内側）要素が次のホップを開始するために送信されます。この場合、ピアは「プロキシ」と見なされます（次の段落が適用されることを意味します）。
Once the proxy has passed the "tunnel" element on the TUNNEL channel, it awaits an "error" or an "ok" element in response. If it receives an "error" element, it closes the initiated session and its underlying transport connection. It then passes the "error" element unchanged back on the listening session. If, on the other hand, it receives an "ok" element, it passes the "ok" element back on the listening session. Starting with the octet following the END(CR)(LF) trailer of the frame with the completion flag set (more=".") of the RPY carrying the "ok" element, the proxy begins copying octets directly and without any interpretation between the two underlying transport connections.
プロキシがトンネルチャネルの「トンネル」要素を通過すると、それに応じて「エラー」または「OK」要素が待っています。「エラー」要素を受信した場合、開始セッションとその基礎となる輸送接続を閉じます。次に、リスニングセッションで「エラー」要素を変更しない「エラー」要素を渡します。一方、「OK」要素を受信した場合、リスニングセッションで「OK」要素を渡します。「OK」要素を運ぶRPYの完了フラグセット（more = "。"）を使用して、フレームの終了（cr）（lf）トレーラーに続くオクテットから始まり、プロキシはオクテットを直接コピーし始めます。2つの基礎となる輸送接続。
While the BEEP Framework [2] is used, the attributes described are sufficient for the TCP mapping [3] of BEEP. The attributes on the "tunnel" element may need to be extended to handle other transport layers.
ビープフレームワーク[2]が使用されますが、説明されている属性は、ビープ音のTCPマッピング[3]に十分です。「トンネル」要素の属性は、他の輸送層を処理するために拡張する必要がある場合があります。
In a mapping where multiple underlying transport connections are used, once the "ok" element is passed, all channels are closed, including channel zero. Thus, only the underlying transport connection initially established remains, and all other underlying transport connections for the session should be closed as well.
複数の基礎となる輸送接続が使用されるマッピングでは、「OK」要素が渡されると、チャネルゼロを含むすべてのチャネルが閉じられます。したがって、最初に確立された基礎となる輸送接続のみが残り、セッションの他のすべての基礎となる輸送接続も閉鎖する必要があります。
If a transport security layer (such as TLS) has been negotiated over the session, the semantics for the TUNNEL profile are ill-defined. The TUNNEL profile MUST NOT be advertised in any greetings after transport security has been negotiated.
輸送セキュリティ層（TLSなど）がセッションで交渉されている場合、トンネルプロファイルのセマンティクスは不明確です。輸送のセキュリティが交渉された後、トンネルプロファイルを挨拶で宣伝してはなりません。
An SRV identifier of "_tunnel" is reserved by IANA for use with this profile. Hence, the "srv" attribute "_tunnel._tcp" MAY be used as a default for finding the appropriate address for tunneling into a particular domain.
「_tunnel」のSRV識別子は、このプロファイルで使用するためにIANAによって予約されています。したがって、「SRV」属性「_tunnel._tcp」は、特定のドメインにトンネリングするための適切なアドレスを見つけるためのデフォルトとして使用できます。
System port number 604 has been allocated by the IANA for TUNNEL.
システムポート番号604は、IANAによってトンネルに割り当てられています。
This section lists the three-digit error codes the TUNNEL profile may generate.
このセクションには、トンネルプロファイルが生成できる3桁のエラーコードをリストします。
code meaning
==== =======
421 Service not available
(E.g., the proxy does not have sufficient resources.)
450 Requested action not taken (E.g., DNS lookup failed or connection could not be established. See too 550.)
450の要求されたアクションが取られていない（例：DNSルックアップが失敗したか、接続が確立できなかった。550を参照）
500 General syntax error (E.g., poorly-formed XML)
500一般的な構文エラー（たとえば、形成されていないXML）
501 Syntax error in parameters (E.g., non-valid XML, letters in "ip4" attribute, etc.)
501パラメーターの構文エラー（例：非検証XML、「IP4」属性などの文字など）
504 Parameter not implemented
504パラメーターは実装されていません
530 Authentication required
530認証が必要です
534 Authentication mechanism insufficient (E.g., too weak, sequence exhausted, etc.)
534認証メカニズムが不十分です（たとえば、弱すぎる、シーケンスが使い果たされました。
537 Action not authorized for user
537アクションユーザーが許可されていません
538 Encryption already enabled (E.g., TLS already negotiated, or a SASL that provides encryption already negotiated.)
538暗号化は既に有効になっています（たとえば、既にネゴシエートされたTL、または既にネゴシエートされた暗号化を提供するSASL）。
550 Requested action not taken (E.g., next hop could be contacted, but malformed greeting or no TUNNEL profile advertised.)
550の要求されたアクションが取られていません（たとえば、次のホップに連絡することができますが、奇形の挨拶またはトンネルプロファイルが宣伝されていません。）
553 Parameter invalid
553パラメーター無効
554 Transaction failed (E.g., policy violation)
554トランザクションが失敗しました（例：ポリシー違反）
Note that the 450 error code is appropriate when the destination machine could not be contacted, while the 550 error code is appropriate when the destination machine could be contacted but the next phase of the protocol could not be negotiated. It is suggested that the beginning of any reply from the destination machine be included as part of the CDATA text of the error element, for debugging purposes.
宛先マシンに接触できなかった場合は450エラーコードが適切であり、550エラーコードは宛先マシンに連絡できるが、プロトコルの次のフェーズを交渉できなかった場合に適切です。デバッグ目的のために、宛先マシンからの返信の始まりを、エラー要素のCDATAテキストの一部として含めることをお勧めします。
The TUNNEL profile is a profile of BEEP. In BEEP, transport security, user authentication, and data exchange are orthogonal. Refer to Section 8 of [2] for a discussion of this.
トンネルプロファイルはビープ音のプロファイルです。ビープ音では、輸送セキュリティ、ユーザー認証、およびデータ交換は直交です。これについての議論については、[2]のセクション8を参照してください。
However, the intent of the TUNNEL profile is to allow bidirectional contact between two machines normally separated by a firewall. Since TUNNEL allows this connection between BEEP peers, and BEEP peers can offer a range of services with appropriate greetings, the TUNNEL profile should be configured with care. It is reasonable to strictly limit the hosts and services that a proxy is allowed to contact. It is also reasonable to limit the use of the TUNNEL profile to authorized users, as identified by a SASL profile.
ただし、トンネルプロファイルの意図は、通常、ファイアウォールで区切られる2つのマシン間の双方向接触を可能にすることです。トンネルはビープピア間のこの接続を可能にし、ビープピアは適切な挨拶を伴うさまざまなサービスを提供できるため、トンネルプロファイルは注意して構成する必要があります。プロキシが連絡できるようにするホストとサービスを厳密に制限することは合理的です。また、SASLプロファイルによって識別されるように、トンネルプロファイルの使用を認定ユーザーに制限することも合理的です。
Negotiation of a TLS profile in an end-to-end manner after a TUNNEL has been established will prevent intermediate proxies from observing or modifying the cleartext information exchanged, but only if TLS certificates are properly configured during the negotiation. The proxy could mount a "man in the middle" attack if public key infrastructure is not deployed.
トンネルが確立された後のエンドツーエンドの方法でのTLSプロファイルの交渉により、中間プロキシは交換されたクリアテキスト情報を観察または変更することができませんが、交渉中にTLS証明書が適切に構成されている場合のみです。公開キーインフラストラクチャが展開されていない場合、プロキシは「中央の男」攻撃を行う可能性があります。
In some environments, it is undesirable to expose the names of machines on one side of a firewall in unencrypted messages on the other side of that firewall. In this case, source routing (using the "fqdn", "ip4", "ip6", "port" and "srv" attributes) can route a connection to the firewall proxy, with an innermost "profile" or "endpoint" attribute which the firewall proxy understands. Local provisioning can allow a proxy to translate a particular "profile" or "endpoint" element into a new source route to reach the desired service. This can prevents two attacks:
一部の環境では、ファイアウォールの反対側にある暗号化されていないメッセージのファイアウォールの片側にあるマシンの名前を公開することは望ましくありません。この場合、ソースルーティング（「FQDN」、「IP4」、「IP6」、「ポート」、「SRV」属性を使用）は、最も内側の「プロファイル」または「エンドポイント」属性を持つファイアウォールプロキシへの接続をルーティングできます。ファイアウォールプロキシが理解しています。ローカルプロビジョニングにより、プロキシは特定の「プロファイル」または「エンドポイント」要素を新しいソースルートに変換して、目的のサービスに到達できます。これは、2つの攻撃を防ぐことができます。
o Attackers sniffing packets on one side of the firewall cannot see IP addresses or FQDNs of machines on the other side of the firewall; and,
o 攻撃者は、ファイアウォールの片側にあるパケットをスニッフィングしています。IPアドレスまたはファイアウォールの反対側にあるマシンのFQDNが表示されません。そして、
o Attackers cannot exhaustively attempt to connect to many FQDNs or IP addresses via source routing and use the error messages as an indication of whether the queried machine exists. For this attack to be prevented, the proxy must allow only "profile" or "endpoint" connections, always refusing to even attempt source-routed connections. This latter attack can also be thwarted by requiring a SASL identification before allowing a TUNNEL channel to be started, but this can have higher overhead.
o 攻撃者は、ソースルーティングを介して多くのFQDNSまたはIPアドレスに接続したり、クエリマシンが存在するかどうかを示すエラーメッセージを使用したりすることはできません。この攻撃が防止されるためには、プロキシは「プロファイル」または「エンドポイント」接続のみを許可する必要があり、常にソースにルートした接続を試みることを拒否します。この後者の攻撃は、トンネルチャネルの開始を許可する前にSASLの識別を要求することで妨害することもできますが、これはより高いオーバーヘッドを持つことができます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[2] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。
[3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[3] Rose、M。、「ビープコアをTCPにマッピング」、RFC 3081、2001年3月。
[4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[4] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[6] Gulbrandsen、A.、Vixie、P。and L. Esibov、「サービスの場所（DNS SRV）を指定するためのDNS RR」、RFC 2782、2000年2月。
The IANA has registered the profiles specified in this section and has selected an IANA-specific URI: "http://iana.org/beep/TUNNEL".
IANAは、このセクションで指定されたプロファイルを登録し、IANA固有のURIを選択しました：「http://iana.org/beep/tunnel」。
Profile identification: http://iana.org/beep/TUNNEL
プロフィール識別：http：//iana.org/beep/tunnel
Message exchanged during channel creation: "tunnel"
チャネル作成中に交換されるメッセージ：「トンネル」
Messages starting one-to-one exchanges: "tunnel"
1対1の交換を開始するメッセージ：「トンネル」
Messages in positive replies: "ok"
肯定的な返信のメッセージ：「OK」
Messages in negative replies: "error"
否定的な返信のメッセージ：「エラー」
Messages in one-to-many exchanges: None.
1対Many交換のメッセージ：なし。
Message syntax: See Section 3 of this document.
メッセージ構文：このドキュメントのセクション3を参照してください。
Message semantics: See Section 4 of this document.
メッセージセマンティクス：このドキュメントのセクション4を参照してください。
Contact information: See the Author's Address appendix of this document.
連絡先情報：このドキュメントの著者のアドレス付録を参照してください。
Any extensions to this protocol MUST be documented in a Standards track RFC.
このプロトコルの拡張機能は、標準トラックRFCに文書化する必要があります。
A single well-known port, 604, is allocated by the IANA to the TUNNEL profile.
1つの有名なポート、604は、IANAによってトンネルプロファイルに割り当てられます。
Protocol Number: TCP
プロトコル番号：TCP
Message Formats, Types, Opcodes, and Sequences: See Section 3.
メッセージ形式、タイプ、オペコード、およびシーケンス：セクション3を参照してください。
Functions: See Section 4.
関数：セクション4を参照してください。
Use of Broadcast/Multicast: none
ブロードキャスト/マルチキャストの使用：なし
Proposed Name: TUNNEL Profile
提案された名前：トンネルプロファイル
Short name: tunnel
短い名前：トンネル
Contact Information: See the "Authors' Addresses" section of this memo
連絡先情報：このメモの「著者のアドレス」セクションを参照してください
The author gratefully acknowledges the contributions of Marshall Rose, Greg Matthews, and Ben Feinstein.
著者は、マーシャル・ローズ、グレッグ・マシューズ、ベン・ファインスタインの貢献に感謝します。
Inspiration for this profile comes from the Intrusion Detection Working Group of the IETF.
このプロファイルのインスピレーションは、IETFの侵入検知ワーキンググループからのものです。
Author's Address
著者の連絡先
Darren New 5390 Caminito Exquisito San Diego, CA 92130 US
Darren New 5390 Caminito Exquisito San Diego、CA 92130 US
Phone: +1 858 350 9733
EMail: dnew@san.rr.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。