RFC3620 日本語訳
3620 The TUNNEL Profile. D. New. October 2003. (Format: TXT=35365 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. New Request for Comments: 3620 October 2003 Category: Standards Track
コメントを求めるワーキンググループのD.の新しい要求をネットワークでつないでください: 3620 2003年10月のカテゴリ: 標準化過程
The TUNNEL Profile
トンネルプロフィール
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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同輩が応用層プロキシとして勤めることができるBlocks Extensible Exchangeプロトコル(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
1. 原理. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1のワンバウンドの例。 . . . . . . . . . . . . . . . . . . . . . 3 2.2の2ホップの例。 . . . . . . . . . . . . . . . . . . . . . 4 2.3の失敗したセットアップの例。 . . . . . . . . . . . . . . . . . . 5 2.4 非ビープ音の例. . . . . . . . . . . . . . . . . . . . . 5 2.5は例の輪郭を描きます。 . . . . . . . . . . . . . . . . . . . . . 6 2.6 終点の例. . . . . . . . . . . . . . . . . . . . . 8 3。 メッセージ構文。 . . . . . . . . . . . . . . . . . . . . . . . 9 4. メッセージ意味論. . . . . . . . . . . . . . . . . . . . . . 10 5。 .126に食糧を供給します。 回答コード。 . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 14 8. 引用規格. . . . . . . . . . . . . . . . . . . . . 15A.IANA問題. . . . . . . . . . . . . . . . . . . . . 16A.1登録: プロフィール. . . . . . . . . . . . . . . . 16A.2登録を鳴らしてください: TUNNEL. . . . . . . . . . . . . . . . . . 16B.Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 17AuthorのAddress. . . . . . . . . . . . . . . . . . . . . . . 17Full Copyright Statement. . . . . . . . . . . . . . . . . . . 18のためのSystem(よく知っている)TCPポートナンバー
New Standards Track [Page 1] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[1ページ]。
1. Rationale
1. 原理
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.
協力関係を持っているBEEP同輩が応用層トンネルを形成するように、TUNNELプロフィールはメカニズムを提供します。 同輩は送信元経路を指定する「トンネル」要素を交換します、一番はずれの要素が次のホップについて決めるのに全部はぎ取られて、使用されている状態で。 最も奥深くて、空の「トンネル」要素は、本当に、それが最終的な目的地であると最終的な目的地に言います。 「プロキシ」という用語は、創始者以外のBEEP同輩と最終的な目的地のどれかを参照するのに使用されます。
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つの使用で、TUNNELプロフィールを実装するBEEP同輩はファイアウォールをもっているコレジデントです。 ファイアウォールの中の開始マシンは接続をプロキシにして、次に、ファイアウォールの外で終点に接続を作るようにそのプロキシに頼んでください。 この接続がいったん確立されると、プロキシは、それがトンネルを堀ると外の終点に言います。 外のマシンが、単に八重奏を通過して、プロキシが「辺ぴになること」に透過的に同意して、両方の開始していて終わっているマシンが「チューニングリセット」を実行するなら、TLSを始動する道と似て、交渉破棄は新たにセッション状態と始めをキャッシュしました。
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.
このプロフィールの別の使用は接続をSASLを通して交渉されたユーザアイデンティティに基づく外のサーバに制限することです。 例えば、マネージャは、プロキシに接して、SASLと共に自分を認証して、次に、マネージャに制限された情報サービスにトンネルを堀るようプロキシに命令するかもしれません。 各プロキシが要求されている次期プロキシのアイデンティティを知っているので、承認の不十分なレベルが確立されたなら、それは、接続にトンネルを堀るのを拒否できます。 また、BEEP接続の正しい源をanonymizeするのにTUNNELプロフィールを使用するのも可能である、方法で、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.
両方の終点マシンがいったん接続されるようになると、トンネリングプロキシマシンはこれ以上データの解釈をしません。 特に、それはどんなBEEP縁どりも探しません。 したがって、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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
New Standards Track [Page 2] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[2ページ]。
2. Examples
2. 例
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"、および「最終的である」と呼ばれる「イニシャル」がアクセスに願っているサービスがあるマシン。」 また、例は、BEEPフレームワーク[2]がTCP[3]、または1つの輸送接続がオール・チャンネルを運ぶある他のマッピングの上で実装されると仮定します。
2.1 One-Hop Example
2.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]-------------------------->
初期のproxy1決勝----- xportは接続します。-----><。------- 挨拶-------->。--- TUNNEL[1]を始動してください。---->。----- xportは接続します。------><。-------- 挨拶-------->。---- TUNNEL[2]を始動してください。----><。---------- OK------------ <、-、-、-、-、-、-- OK-------------- [3] <。------------- 挨拶[4]-------------------------->。
Notes:
注意:
[1] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' port='604'>
<tunnel/>
</tunnel>
[1] TUNNEL要素はこれに似ています: <トンネルfqdnは'final.example.com'ポートは'604'><トンネル/></トンネル>と等しいこと'と等しいです。
[2] The TUNNEL element looks like this:
<tunnel/>
[2] TUNNEL要素はこれに似ています: <トンネル/>。
[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] この挨拶は、proxy1が捕らえられないで分かるか、または干渉しないで交信するためにTLSプロフィール、初期で許容して、および決勝を含むかもしれません。
New Standards Track [Page 3] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[3ページ]。
2.2 Two-Hop Example
2.2 2ホップの例
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 ---------------------------->
初期のproxy1 proxy2決勝--- xportに接続してください--、><。---- 挨拶------>--スタートTUNNEL[1]-->--xportは接続します。---><。----- 挨拶----->--スタートトンネル[2]-->。--- xportは接続します。---><。------- 挨拶----->。---TUNNEL[3]を始動してください。---><。-------- OK---------- <、-、-、-、-、-、-- OK--------- [4] <。------- OK--------- [5] <。-------------------------- 挨拶---------------------------->。
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>
[1] TUNNEL要素はこれに似ています: <トンネルfqdnは'proxy2.example.com'ポートは'604'><トンネルfqdn=と等しく'final.example.com'ポートは'10290'><トンネル/></トンネル></トンネル>と等しいこと'と等しいです。
[2] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' port='10290'>
<tunnel/>
</tunnel>
[2] TUNNEL要素はこれに似ています: <トンネルfqdnは'final.example.com'ポートは'10290'><トンネル/></トンネル>と等しいこと'と等しいです。
[3] The TUNNEL element looks like this:
<tunnel/>
[3] TUNNEL要素はこれに似ています: <トンネル/>。
[4] Proxy2 starts passing octets transparently after sending the
<ok/>.
[4] <OK/>を送った透過的に後に、Proxy2は八重奏を通過し始めます。
[5] Proxy1 starts passing octets transparently after sending the
<ok/>.
[5] <OK/>を送った透過的に後に、Proxy1は八重奏を通過し始めます。
New Standards Track [Page 4] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[4ページ]。
2.3 Failed Set-Up Example
2.3 失敗したセットアップの例
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番目の例は、創始者が2proxys(第2代指定されたサービスに接続するのを試みて、目的地がBEEPサーバでないことがわかっているプロキシ)を通して接続するのを示します(もちろん、telnetサービスを指定するのがこの誤りに通じると予想できます。)。 目的地がTUNNELプロフィールを支えないなら、同じくらいは結果として生じるでしょうに。
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]
初期のproxy1 proxy2決勝--- xportに接続してください--、><。---- 挨拶------>--スタートトンネル[1]-->。--- xportに接続してください--、><。----- 挨拶----->--スタートトンネル[2]-->。---- xportは接続します。---><。------- ログイン: ------- ----- xport閉鎖----><。---- <誤り>。------- --- xport閉鎖----><。---- <誤り>。------ --- xport閉鎖--->。[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>
[1] TUNNEL要素はこれに似ています: <トンネルfqdn='proxy2.example.com'ポートは'604'><トンネルfqdn=と等しく'final.example.com'srv='_telnet_tcp'><トンネル/></トンネル></トンネル>'
[2] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
<tunnel/>
</tunnel>
[2] TUNNEL要素はこれに似ています: '<トンネルfqdn='final.example.com'srv='_telnet_tcp'><トンネル/></トンネル>'
[3] This close is optional. "Initial" may also send another <tunnel>
element, attempting to contact a different server, for example.
[3] この閉鎖は任意です。 また、例えば異なったサーバに連絡するのを試みて、「初期」は別の<トンネル>要素を送るかもしれません。
2.4 Non-BEEP Example
2.4 非ビープ音の例
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.
この例は、プロトコルレベルの違いが二面であることを2proxys(第2代指定されたサービスに接続するのを試みて、目的地がBEEPサーバでないと受け入れるプロキシ)を通した創始者接続に示します: 「初期」のマシンが最も奥深い「トンネル」要素、および最終的なプロキシを含んでいない、(「proxy2")、したがって、BEEP挨拶を予想しない、」
New Standards Track [Page 5] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[5ページ]。
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]
初期のproxy1 proxy2決勝--- xportに接続してください--、><。---- 挨拶------>--スタートトンネル[1]-->。--- xportに接続してください--、><。----- 挨拶----->--スタートトンネル[2]-->。---- xportは接続します。---><。------- ログイン: ------- <、-、-、-、-、-- <の間違いない>。------- [3] <。----- ログイン: ------ [4] <。------ <の間違いない>。--------- [3] <。----- ログイン: -------- [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要素はこれに似ています: <トンネルfqdnは'proxy2.example.com'ポートは'604'><トンネルfqdn=と等しく'final.example.com'svc='_telnet_tcp'></トンネル></トンネル>Noteと等しいです。最も奥深い属性がない<トンネル>要素の不足、'
[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] TUNNEL要素はこれに似ています: '<トンネルfqdnが最も奥深い属性がない<の不足がトンネルを堀る'final.example.com'srv='_telnet_tcp'></トンネル>Noteと等しい、>要素、'
[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] 各プロキシはそれが終宿主から受け取ったどんなデータも転送します、<の間違いない>を送る前にそのデータが到着したとしても。
[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] 「間違いありません、な」メッセージを受け取った後に、「初期」の同輩は、「最終的な」マシンから生の、そして、非BEEPのデータが送られると予想して、受信できました。
2.5 Profile Example
2.5 プロフィールの例
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.
この例は、創始者が2proxysを通して接続するのを示します。 初期のマシンは、proxy1を超えたどこかにSEP2プロフィールを提供するサーバがあるのを知っていますが、それはどこかを知る必要はありません。 Proxy1は、すべてのSEP2サーバがproxy2を超えているのを知るために局所的に構成されました。 Proxy2が局所的に構成された、SEP2サービスのための選択のサーバとして「決勝」を選びました。 「決勝」が、必ず初期の挨拶で要求されたプロフィールを提供する必要であるというわけではないことに注意してください。
New Standards Track [Page 6] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[6ページ]。
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 ---------------------------->
初期のproxy1 proxy2決勝--- xportに接続してください--、><。---- 挨拶------>--スタートTUNNEL[1]-->--xportは接続します。---><。----- 挨拶----->--スタートトンネル[2]-->。--- xportは接続します。---><。------- 挨拶----->。---TUNNEL[3]を始動してください。---><。-------- OK---------- <、-、-、-、-、-、-- OK--------- [4] <。------- OK--------- [5] <。-------------------------- 挨拶---------------------------->。
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] TUNNEL要素はこれに似ています: <トンネルプロフィールは" http://xml.resource/org/profiles/SEP2 "/>Noteと等しいです。最も奥深い属性がない<トンネル>要素の不足。
[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が"proxy2.example.com"<トンネルfqdn=ポート=にこれを写像する、「604 「地方の構成に基づく><トンネルプロフィール=" http://xml.resource/org/profiles/SEP2 "/></トンネル>、新しい要素の当時のプロセス、外側の要素とルーティング<トンネルプロフィールを全部はぎ取るのはproxy2への" http://xml.resource/org/profiles/SEP2 "/>と等しいです」。
[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] 単にSEP2 URIが指定されている状態で、Proxy2はTUNNEL要素を受け取ります。 '地方の食糧を供給するのは最も奥深い属性がない<トンネル>要素の存在の'final.example.com'<トンネルfqdn=srv='_ビープ音_tcp'><トンネル/></トンネル>Noteにこれを写像します'。 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>の後に八重奏を送り始めます。
New Standards Track [Page 7] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[7ページ]。
2.6 Endpoint Example
2.6 終点の例
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.
この例は、創始者が2proxysを通して接続するのを示します。 初期のマシンは、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 ---------------------------->
初期のproxy1 proxy2決勝--- xportに接続してください--、><。---- 挨拶------>--スタートTUNNEL[1]-->--xportは接続します。---><。----- 挨拶----->--スタートトンネル[2]-->。--- xportは接続します。---><。------- 挨拶----->。---TUNNEL[3]を始動してください。---><。-------- OK---------- <、-、-、-、-、-、-- OK--------- [4] <。------- OK--------- [5] <。-------------------------- 挨拶---------------------------->。
Notes:
注意:
[1] The TUNNEL element looks like this:
<tunnel endpoint="operator console">
</tunnel>
Note the lack of an innermost no-attribute <tunnel> element.
[1] TUNNEL要素はこれに似ています: ></は>Noteにトンネルを堀ります。<トンネル終点=、「オペレータコンソール、「最も奥深い属性がない<トンネル>要素の不足、」
[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が"proxy2.example.com"<トンネルfqdn=ポート=にこれを写像する、「604「><トンネル終点=」オペレータコンソール「地方の構成、新しい要素の当時のプロセス、外側の要素を全部はぎ取って、およびルーティング<トンネル終点=に基づく></トンネル></トンネル>」オペレータコンソール「proxy2への></トンネル>。」
New Standards Track [Page 8] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[8ページ]。
[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はTUNNEL要素を受け取ります。 '地方の食糧を供給するのは最も奥深い属性がない<トンネル>要素の存在の'final.example.com'<トンネルfqdn=srv='_ビープ音_tcp'><トンネル/></トンネル>Noteにこれを写像します'。 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>の後に八重奏を送り始めます。
3. Message Syntax
3. メッセージ構文
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年2月3日現在トンネルプロフィールのためのDTD
Refer to this DTD as:
このDTDを以下を参照してください。
<!ENTITY % TUNNEL PUBLIC "-//IETF//DTD TUNNEL//EN" "">
%TUNNEL;
-->
<!実体%が公共の「-//IETF//DTDトンネル//アン」にトンネルを堀る、「「>%はトンネルを堀ります」。 -->。
<!--
TUNNEL messages
<!--TUNNELメッセージ
role MSG RPY
====== === ===
I or L TUNNEL +: ok
-: error
-->
役割のMSG RPY====== === === 私かLトンネル+: 間違いなさ、-、: 誤り-->。
<!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
>
<!ELEMENTトンネル(トンネル)?><!ATTLISTトンネルfqdn CDATA#IMPLIED ip4 CDATA#IMPLIED ip6 CDATA#IMPLIEDポートCDATA#IMPLIED srv CDATA#IMPLIEDプロフィールCDATA#IMPLIED終点CDATA#IMPLIED>。
New Standards Track [Page 9] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[9ページ]。
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"属性、4セットの10進数が周期的に切り離されて、そのようである、「10.23 .34 0.45インチ、」 「ip6"属性がRFC2373[4]で指定されるようにある」形式。 「ポート」属性の形式は、1〜65535の10進数的であって、包括的です。 「"srv"属性の形式は期間までにそれぞれアンダーラインから始まって、切り離された、1組の識別子です、」 _9月_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 しかし、いいえは最も奥深い要素だけの上で結果と考えます。
4. Message Semantics
4. メッセージ意味論
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.
TUNNELチャンネルが始動されるとき、リスナーはチャンネルゼロの「始め」要素、または、創始者か、新しいチャンネルの上に作成された「トンネル」要素を期待します。 いつものように、チャンネルゼロで到着するなら、回答を返す前にそれを処理します。
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:
どちらの場合ではも、一番はずれの「トンネル」要素は調べられます。 それに属性が全くないなら、この同輩は創始者が利用したがっているBEEPサービスを主催しています。 この場合、リスナーはチューニングリセットを実行します:
o All channels, including channel zero, are implicitly closed.
o チャンネルゼロを含むオール・チャンネルがそれとなく閉店します。
o Any previously cached information about the BEEP session is
discarded.
o BEEPおよそセッションどんな以前にキャッシュされた情報も捨てられます。
o A new plaintext greeting is sent.
o 新しい平文挨拶を送ります。
New Standards Track [Page 10] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[10ページ]。
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"はA記録として翻訳のためのDNSを通してIP番号まで見上げられます。 「ip4"属性はIPv4アドレスの点を打たされた回路表現として解釈されます。」 「ip6"属性はIPv6アドレスのテキスト表現として解釈されます。」 それぞれのこれらの場合では、輸送接続はしたがって、特定されたサーバに確立されます。一番はずれの要素に"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によって示されたBEEPプロフィールに勤めている同輩に届くことを決定するのにこの要素を処理するプロキシは責任があります。 ソースルーティングよりむしろ、これはホップごとのルーティングメカニズムを必要なサービスに提供します。
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.
そして、一番はずれの要素には入れ子にされた要素が全くありませんが、「プロフィール」か「終点」を除いた属性を持っているなら、この同輩は最終的なBEEPホップです。 (これが相当している、「上記の「非ビープ音」の例のproxy2")。」 この場合、最終的な基本的な輸送接続が確立されるとすぐに、聴取セッションの間、「間違いありません、な」要素を返します、そして、データのトンネリングは始まります。 最終的なホップからのいいえBEEP挨拶(または、本当にどんなデータも)は予想されます。 「完成旗でフレームのEND(CR)(LF)トレーラに続いて、八重奏から始まるのがセットした、(以上が等しい、」、」、)、「間違いありません、な」要素を運ぶRPYでは、プロキシは直接と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.
特定されたサーバに連絡できないなら、創始者が閉じられるので確立された聴取チャンネルとどんな接続の上にも「誤り」要素を返します。 入れ子にされた「トンネル」要素があって、連絡されたサーバがBEEP挨拶を提供しないか、または提供されたBEEP挨拶がTUNNELプロフィールを含んでいないなら、これも誤りとして扱われます: 開始している輸送接続は終えられます、そして、誤りは返されます。
New Standards Track [Page 11] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[11ページ]。
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).
入れ子にされた「トンネル」要素があって、特定されたサーバが連絡されて、TUNNELプロフィールを含むBEEP挨拶を提供するなら、受け取られた「トンネル」要素からの一番はずれの要素を全部はぎ取ります、そして、新しいTUNNELチャンネルは開始セッションを始動します、そして、次のホップを始めるために剥取られた(内側の)要素を送ります。 この場合、同輩は「プロキシ」であると考えられます(次のパラグラフが適切であることを意味して)。
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.
プロキシがTUNNELチャンネルでいったん「トンネル」要素を渡すと、それは応答で「誤り」か「間違いありません、な」要素を待ちます。 「誤り」要素を受け取るなら、それは開始しているセッションとその基本的な輸送接続を終えます。 そして、それは聴取セッションのときに変わりのない「誤り」要素を渡します。 他方では、「間違いありません、な」要素を受け取るなら、それは聴取セッションのときに「間違いありません、な」要素を戻します。 「完成旗でフレームのEND(CR)(LF)トレーラに続いて、八重奏から始まるのがセットした、(以上が等しい、」、」、)、「間違いありません、な」要素を運ぶRPYでは、プロキシは直接と2人の基本的な輸送の接続の間の少しも解釈なしで八重奏をコピーし始めます。
5. Provisioning
5. 食糧を供給すること
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.
BEEP Framework[2]が使用されている間、説明された属性はBEEPの[3]を写像するTCPに十分です。 「トンネル」要素の属性は、他のトランスポート層を扱うために広げられる必要があるかもしれません。
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.
「間違いありません、な」要素がいったん渡されると複数の基本的な輸送の接続が使用されているマッピングでは、オール・チャンネルは閉じられます、チャンネルゼロを含んでいて。 初めは確立された基本的な輸送接続だけが残っています、そして、また、セッションのための他のすべての基本的な輸送の接続が閉店するべきです。
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などの)がセッションの間、交渉されているなら、TUNNELプロフィールのための意味論はほとんど定義されていません。 輸送セキュリティを交渉した後に、どんな挨拶でもTUNNELプロフィールの広告を出してはいけません。
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.
「」 _トンネルに関するSRV識別子」はこのプロフィールによる使用のためにIANAによって予約されます。 「したがって、"srv"は」 _トンネル_tcpを結果と考えること」が、特定のドメインにトンネルを堀るための適切なアドレスを見つけるのにデフォルトとして使用されるかもしれません。
System port number 604 has been allocated by the IANA for TUNNEL.
システムポートNo.604はTUNNELのためにIANAによって割り当てられました。
New Standards Track [Page 12] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[12ページ]。
6. Reply Codes
6. 回答コード
This section lists the three-digit error codes the TUNNEL profile may generate.
このセクションはTUNNELプロフィールが生成するかもしれない3ケタのエラーコードを記載します。
code meaning
==== =======
421 Service not available
(E.g., the proxy does not have sufficient resources.)
コード意味==== ======= 利用可能でない421サービス(例えば、プロキシには、十分なリソースがありません。)
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暗号化(例えば、TLSが既に交渉したか、または暗号化を提供するSASLは既に交渉しました。)
550 Requested action not taken
(E.g., next hop could be contacted, but
malformed greeting or no TUNNEL profile advertised.)
550 取られなかった要求された行動(例えば次のホップに連絡できましたが、奇形の挨拶の広告を出しましたが、どんなTUNNELプロフィールも広告を出しませんでした。)
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テキストの一部として含まれていることが提案されます、デバッグ目的のために。
New Standards Track [Page 13] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[13ページ]。
7. Security Considerations
7. セキュリティ問題
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.
TUNNELプロフィールはBEEPのプロフィールです。 BEEPでは、輸送セキュリティ、ユーザー認証、およびデータ交換は直交しています。 この議論のための[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.
しかしながら、TUNNELプロフィールの意図は通常、ファイアウォールによって切り離された2台のマシンの間の双方向の接触を許すことです。 TUNNELがBEEP同輩の間のこの接続を許して、BEEP同輩が適切な挨拶と共に各種サービスを提供できるので、TUNNELプロフィールは慎重に構成されるべきです。 厳密に、プロキシが連絡できるホストとサービスを制限するのは妥当です。 また、TUNNELプロフィールの使用を認定ユーザに制限するのも妥当です、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.
TUNNELが設立された後に終わりから終わりへの方法における、TLSプロフィールの交渉は、中間的プロキシがTLS証明書が交渉の間、適切に構成される場合にだけ交換されたcleartext情報を観測するか、または変更するのを防ぐでしょう。 公開鍵認証基盤が配布されないなら、プロキシは「中央の男性」攻撃を仕掛けるかもしれません。
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"属性) ファイアウォールプロキシが理解している最も奥深い「プロフィール」か「終点」属性があるファイアウォールプロキシとの缶のルートa接続。」 地方の食糧を供給することで、プロキシは、必要なサービスに達するように特定の「プロフィール」か「終点」要素を新しい送信元経路に翻訳できます。 この缶は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アドレスかFQDNsを見ることができません。 そして
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アドレスに接続して、質問されたマシンが存在するかどうかしるしとしてエラーメッセージを使用するのを徹底的に試みることができません。 この攻撃が防がれるために、プロキシは「プロフィール」か「終点」接続だけを許さなければなりません、いつもソースによって発送された接続を試みるのさえ拒否して。 また、TUNNELチャンネルが始動されるのを許容する前にSASL識別を必要とすることによって、この後者の攻撃を阻まれることができますが、これは、より高いオーバーヘッドを持つことができます。
New Standards Track [Page 14] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[14ページ]。
8. Normative References
8. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[2] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
2001.
[3] M. ローズ、RFC3081、「TCPへのビープ音コアを写像すること」での3月2001日
[4] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[4]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、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.とL.Esibov、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2782、2000年2月。
New Standards Track [Page 15] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[15ページ]。
Appendix A. IANA Considerations
付録A.IANA問題
A.1 Registration: BEEP Profile
A.1登録: ビープ音プロフィール
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回の交換におけるメッセージ: なし。
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.
問い合わせ先: AuthorのこのドキュメントのAddress付録を見てください。
Any extensions to this protocol MUST be documented in a Standards track RFC.
このプロトコルへのどんな拡大もStandards道のRFCに記録しなければなりません。
A.2 Registration: The System (Well-Known) TCP port number for TUNNEL
A.2登録: TUNNELのためのSystem(よく知っている)TCPポートナンバー
A single well-known port, 604, is allocated by the IANA to the TUNNEL profile.
ただ一つのウェルノウンポート(604)はIANAによってTUNNELプロフィールに割り当てられます。
Protocol Number: TCP
数について議定書の中で述べてください: TCP
Message Formats, Types, Opcodes, and Sequences: See Section 3.
メッセージ・フォーマット、タイプ、Opcodes、および系列: セクション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
問い合わせ先: このメモの「作者のアドレス」セクションを見てください。
New Standards Track [Page 16] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[16ページ]。
Appendix B. Acknowledgements
付録B.承認
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のIntrusion Detection作業部会から来ます。
Author's Address
作者のアドレス
Darren New 5390 Caminito Exquisito San Diego, CA 92130 US
ダーレン・新しい5390Caminito Exquisitoカリフォルニア92130サンディエゴ(米国)
Phone: +1 858 350 9733 EMail: dnew@san.rr.com
以下に電話をしてください。 +1 9733年の858 350メール: dnew@san.rr.com
New Standards Track [Page 17] RFC 3620 The TUNNEL Profile October 2003
新しい規格はトンネルプロフィール2003年10月にRFC3620を追跡します[17ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
New Standards Track [Page 18]
新しい標準化過程[18ページ]
一覧
スポンサーリンク
