RFC3104 日本語訳
3104 RSIP Support for End-to-end IPsec. G. Montenegro, M. Borella. October 2001. (Format: TXT=38719 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Montenegro
Request for Comments: 3104 Sun Microsystems, Inc.
Category: Experimental M. Borella
CommWorks
October 2001
コメントを求めるワーキンググループG.モンテネグロ要求をネットワークでつないでください: 3104年のサン・マイクロシステムズ・インクカテゴリ: 実験的なM.Borella CommWorks2001年10月
RSIP Support for End-to-end IPsec
終わりから終わりへのIPsecのRSIPサポート
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
IESG Note
IESG注意
The IESG notes that the set of documents describing the RSIP technology imply significant host and gateway changes for a complete implementation. In addition, the floating of port numbers can cause problems for some applications, preventing an RSIP-enabled host from interoperating transparently with existing applications in some cases (e.g., IPsec). Finally, there may be significant operational complexities associated with using RSIP. Some of these and other complications are outlined in section 6 of the RFC 3102, as well as in the Appendices of RFC 3104. Accordingly, the costs and benefits of using RSIP should be carefully weighed against other means of relieving address shortage.
IESGは、RSIP技術を説明するドキュメントのセットが完全な実装のために重要なホストとゲートウェイ変化を含意することに注意します。 さらに、ポートナンバーの浮動はいくつかのアプリケーションのために問題を起こすことができます、いくつかの場合(例えば、IPsec)、RSIPによって可能にされたホストが透過的に既存のアプリケーションで共同利用するのを防いで。 最終的に、RSIPを使用すると関連している重要な操作上の複雑さがあるかもしれません。 これらと他のいくつかの複雑さがRFC3102のセクション6、およびRFC3104のAppendicesに概説されています。 それに従って、RSIPを使用するコストと利益は慎重にアドレス不足を救う他の手段に比較考量されるべきです。
Abstract
要約
This document proposes mechanisms that enable Realm Specific IP (RSIP) to handle end-to-end IPsec (IP Security).
このドキュメントはRealm Specific IP(RSIP)が終わりから終わりへのIPsec(IP Security)を扱うのを可能にするメカニズムを提案します。
Montenegro & Borella Experimental [Page 1] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[1ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
Table of Contents
目次
1. Introduction .................................................. 2
2. Model ......................................................... 2
3. Implementation Notes .......................................... 3
4. IKE Handling and Demultiplexing ............................... 4
5. IPsec Handling and Demultiplexing ............................. 5
6. RSIP Protocol Extensions ...................................... 6
6.1 IKE Support in RSIP ....................................... 6
6.2 IPsec Support in RSIP ..................................... 7
7. IANA Considerations ........................................... 10
8. Security Considerations ....................................... 10
9. Acknowledgements .............................................. 10
References ....................................................... 11
Authors' Addresses ............................................... 12
Appendix A: On Optional Port Allocation to RSIP Clients .......... 13
Appendix B: RSIP Error Numbers for IKE and IPsec Support ......... 14
Appendix C: Message Type Values for IPsec Support ................ 14
Appendix D: A Note on Flow Policy Enforcement .................... 14
Appendix E: Remote Host Rekeying ................................. 14
Appendix F: Example Application Scenarios ........................ 15
Appendix G: Thoughts on Supporting Incoming Connections .......... 17
Full Copyright Statement ......................................... 19
1. 序論… 2 2. モデル化してください… 2 3. 実装注意… 3 4. IKE取り扱いと逆多重化… 4 5. IPsec取り扱いと逆多重化… 5 6. RSIPは拡大について議定書の中で述べます… 6 6.1 RSIPでのIKEサポート… 6 6.2 RSIPでのIPsecサポート… 7 7. IANA問題… 10 8. セキュリティ問題… 10 9. 承認… 10の参照箇所… 11人の作者のアドレス… 12 付録A: RSIPクライアントへの任意のポート配分に関して… 13 付録B: IKEのためのRSIPエラー番号とIPsecサポート… 14 付録C: メッセージタイプはIPsecのためにサポートを評価します… 14 付録D: 流れ方針実施に関する注… 14 付録E: リモートホストRekeying… 14 付録F: 例のアプリケーションシナリオ… 15 付録G: 接続要求をサポートすることに関する考え… 17 完全な著作権宣言文… 19
1. Introduction
1. 序論
This document specifies RSIP extensions to enable end-to-end IPsec. It assumes the RSIP framework as presented in [RSIP-FW], and specifies extensions to the RSIP protocol defined in [RSIP-P]. Other terminology follows [NAT-TERMS].
このドキュメントは、終わりから終わりへのIPsecを有効にするためにRSIP拡張子を指定します。 それは、[RSIP-FW]に提示されるようにRSIPフレームワークを仮定して、[RSIP-P]で定義されたRSIPプロトコルに拡大を指定します。 他の用語は[NAT-TERMS]に続きます。
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 RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
2. Model
2. モデル
For clarity, the discussion below assumes this model:
明快ために、以下での議論はこのモデルに就きます:
RSIP client RSIP server Host
RSIPクライアントRSIPサーバHost
Xa Na Nb Yb
+------------+ Nb1 +------------+
[X]------| Addr space |----[N]-----| Addr space |-------[Y]
| A | Nb2 | B |
+------------+ ... +------------+
Xa Na Nb Yb+------------+ Nb1+------------+ [X]------| Addrスペース|----[N]-----| Addrスペース|-------[Y]| A| Nb2| B| +------------+ ... +------------+
Montenegro & Borella Experimental [Page 2] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[2ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
Hosts X and Y belong to different address spaces A and B, respectively, and N is an RSIP server. N has two addresses: Na on address space A, and Nb on address space B. For example, A could be a private address space, and B the public address space of the general Internet. Additionally, N may have a pool of addresses in address space B which it can assign to or lend to X.
ホストXとYはそれぞれ異なったアドレス空間AとBに属します、そして、NはRSIPサーバです。Nには、2つのアドレスがあります: アドレス空間Aに関するNa、およびアドレス空間B.Forの例のNb、Aはプライベート・アドレススペースであるかもしれなく、Bは一般的なインターネットの場内放送スペースです。 さらに、Nは、Xにそれが割り当てることができるアドレス空間Bにおけるアドレスのプールを持っているか、または貸すかもしれません。
This document proposes RSIP extensions and mechanisms to enable an RSIP client X to initiate IKE and IPsec sessions to a legacy IKE and IPsec node Y. In order to do so, X exchanges RSIP protocol messages with the RSIP server N. This document does not yet address IKE/IPsec session initiation from Y to an RSIP client X. For some thoughts on this matter see Appendix G.
このドキュメントはRSIPクライアントXがIKEとIPsecノードY.Inがそうするよう命令するレガシーにIKEとIPsecセッションを開始するのを可能にするためにRSIP拡張子とメカニズムを提案して、N.ThisがまだYからRSIPクライアントX.ForまでのIKE/IPsecセッション開始にこの件に関するいくつかの考えを扱っていないと記録するRSIPサーバがあるX交換RSIPプロトコルメッセージはAppendix Gを見ます。
The discussion below assumes that the RSIP server N is examining a packet sent by Y, destined for X. This implies that "source" refers to Y and "destination" refers to Y's peer, namely, X's presence at N.
以下での議論は、RSIPサーバNがパケットがその「ソース」が示すThisが、含意するX.のために運命づけられたYでYを送った審査であると仮定します、そして、「目的地」はNにYの同輩、すなわち、Xの存在を呼びます。
This document assumes the use of the RSAP-IP flavor of RSIP (except that port number assignments are optional), on top of which SPI values are used for demultiplexing. Because of this, more than one RSIP client may share the same global IP address.
このドキュメントはRSIPのRSAP-IP風味の使用を仮定します(ポートナンバー課題が任意であるのを除いて)、どのSPI値が逆多重化に使用されるかの上で。 これのために、1人以上のRSIPクライアントが同じグローバルIPアドレスを共有するかもしれません。
3. Implementation Notes
3. 実装注意
The RSIP server N is not required to have more than one address on address space B. RSIP allows X (and any other hosts on address space A) to reuse Nb. Because of this, Y's SPD SHOULD NOT be configured to support address-based keying. Address-based keying implies that only one RSIP client may, at any given point in time, use address Nb when exchanging IPsec packets with Y. Instead, Y's SPD SHOULD be configured to support session-oriented keying, or user-oriented keying [Kent98c]. In addition to user-oriented keying, other types of identifications within the IKE Identification Payload are equally effective at disambiguating who is the real client behind the single address Nb [Piper98].
RSIPサーバNは、B. RSIPがX(そして、アドレス空間Aのいかなる他のホストも)をNbを再利用させるアドレス空間に関する1つ以上のアドレスを持つのに必要ではありません。 これ、YのSPD SHOULD NOT、構成されて、アドレスベースの合わせることをサポートしてください。 アドレスベースの合わせるのは、セッション指向の合わせているか、または利用者志向の合わせるのが[Kent98c]であるとサポートするために構成されていて、Y.Instead、YのSPD SHOULDとIPsecパケットを交換するとき、1人のRSIPクライアントだけが時間内にの任意な与えられた点でアドレスNbを使用するかもしれないのを含意します。 利用者志向合わせることに加えて、IKE Identification有効搭載量の中の他のタイプの識別はだれのあいまいさを除くかで等しく有効であるのが、独身のアドレスNb[Piper98]の後ろの本当のクライアントであるということです。
Because it cannot rely on address-based keying, RSIP support for IPsec is similar to the application of IPsec for remote access using dynamically assigned addresses. Both cases impose additional requirements which are not met by minimally compliant IPsec implementations [Gupta]:
アドレスベースの合わせることを当てにすることができないので、遠隔アクセスに、IPsecのRSIPサポートはIPsecのアプリケーションとダイナミックに割り当てられたアドレスを使用することで同様です。 両方のケースは最少量で対応することのIPsec実装[グプタ]によって満たされない追加必要条件を課します:
Note that a minimally-compliant IKE implementation (which only
implements Main mode with Pre-shared keys for Phase I
authentication) cannot be used on a remote host with a dynamically
assigned address. The IKE responder (gateway) needs to look up
the initiator's (mobile node's) pre-shared key before it can
リモートホストの上でダイナミックに割り当てられたアドレスで最少量で対応することのIKE実装(Phase I認証のためのPreによって共有されたキーでMainがモードであると実装するだけである)を使用できないことに注意してください。 必要があることができる前にIKE応答者(ゲートウェイ)は、創始者(モバイルノードのもの)のあらかじめ共有されたキーを見上げる必要があります。
Montenegro & Borella Experimental [Page 3] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[3ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
decrypt the latter's third main mode message (fifth overall in
Phase I). Since the initiator's identity is contained in the
encrypted message, only its IP address is available for lookup and
must be predictable. Other options, such as Main mode with
digital signatures/RSA encryption and Aggressive mode, can
accommodate IKE peers with dynamically assigned addresses.
後者の3番目の主なモードメッセージが(全体的に見てPhase Iの5番目)であると解読してください。 創始者のアイデンティティが暗号化メッセージに含まれているので、IPアドレスだけが、ルックアップに利用可能であり、予測できるに違いありません。 デジタル署名/RSA暗号化によるMainモードなどの別の選択肢とAggressiveモードはダイナミックに割り当てられたアドレスと共にIKE同輩を収容できます。
IKE packets are typically carried on UDP port 500 for both source and destination, although the use of ephemeral source ports is not precluded [ISAKMP]. IKE implementations for use with RSIP SHOULD employ ephemeral ports, and should handle them as follows [IPSEC- MSG]:
IKEパケットはソースと目的地の両方のためにUDPポート500の上で通常運ばれます、はかないソースポートの使用は排除されませんが[ISAKMP]。 RSIP SHOULDとの使用のためのIKE実装は、エフェメラルポートを使って、以下の通りそれらを扱うべきです[IPSEC- MSG]:
IKE implementations MUST support UDP port 500 for both source and
destination, but other port numbers are also allowed. If an
implementation allows other-than-port-500 for IKE, it sets the
value of the port numbers as reported in the ID payload to 0
(meaning "any port"), instead of 500. UDP port numbers (500 or
not) are handled by the common "swap src/dst port and reply"
method.
IKE実装は、ソースと目的地の両方のためにUDPがポート500であるとサポートしなければなりませんが、また、他のポートナンバーは許容されています。 実装がポート以外のIKEのための500を許容するなら、IDペイロードで0に報告されるように(「どんなポートも」を意味して)ポートナンバーの値を設定します、500の代わりに。 UDPポートナンバー(500であるか否かに関係なく)は一般的な「スワッピングsrc/dstポートと回答」メソッドで扱われます。
It is important to note that IPsec implementations MUST be aware of RSIP, at least in some peripheral sense, in order to receive assigned SPIs and perhaps other parameters from an RSIP client. Therefore, bump-in-the-stack (BITS) implementations of IPsec are not expected to work "out of the box" with RSIP.
IPsec実装がRSIPを意識しているに違いないことに注意するのは重要です、少なくとも何らかの周囲の意味で、RSIPクライアントから割り当てられたSPIsと恐らく他のパラメタを受け取るために。 したがって、IPsecのスタックでの隆起(BITS)実装が「創造的に」RSIPと共に働かないと予想されます。
4. IKE Handling and Demultiplexing
4. IKE取り扱いと逆多重化
If an RSIP client requires the use of port 500 as its IKE source, this prevents that field being used for demultiplexing. Instead, the "Initiator Cookie" field in the IKE header fields must be used for this purpose. This field is appropriate as it is guaranteed to be present in every IKE exchange (Phase 1 and Phase 2), and is guaranteed to be in the clear (even if subsequent IKE payloads are encrypted). However, it is protected by the Hash payload in IKE [IKE]. Because of this, an RSIP client and server must agree upon a valid value for the Initiator Cookie.
RSIPクライアントがIKEソースとしてポート500の使用を必要とするなら、これは、逆多重化において、その分野が使用されているのを防ぎます。 代わりに、このためにIKEヘッダーフィールドにおける「創始者クッキー」分野を使用しなければなりません。 この分野は、あらゆるIKE交換(フェーズ1とPhase2)で存在しているのが保証されているとき適切であり、明確にあるように保証されます(その後のIKEペイロードが暗号化されていても)。 しかしながら、それはIKE[IKE]にHashペイロードによって保護されます。 これのために、RSIPクライアントとサーバはInitiator Cookieのために有効値に同意しなければなりません。
Once X and N arrive at a mutually agreeable value for the Initiator Cookie, X uses it to create an IKE packet and tunnels it the RSIP server N. N decapsulates the IKE packet and sends it on address space B.
XとNがInitiator Cookieのためにいったん互いに快い値に到着すると、Xは、IKEパケットを作成するのにそれを使用して、それにトンネルを堀ります。RSIPサーバN.Nは、IKEパケットをdecapsulatesして、アドレス空間Bにそれを送ります。
The minimum tuple negotiated via RSIP, and used for demultiplexing incoming IKE responses from Y at the RSIP server N, is:
RSIPを通して交渉されて、逆多重化の入って来るIKE応答にYからRSIPサーバNに使用される最小のtupleは以下の通りです。
Montenegro & Borella Experimental [Page 4] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[4ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
- IKE destination port number
- IKE目的地ポートナンバー
- Initiator Cookie
- 創始者クッキー
- Destination IP address
- 送付先IPアドレス
One problem still remains: how does Y know that it is supposed to send packets to X via Nb? Y is not RSIP-aware, but it is definitely IKE-aware. Y sees IKE packets coming from address Nb. To prevent Y from mistakenly deriving the identity of its IKE peer based on the source address of the packets (Nb), X MUST exchange client identifiers with Y:
1つの問題がまだ残っています: Yは、Nbを通してパケットをXに送るべきであるのをどのように知っていますか? YはRSIP意識していませんが、それは確実にIKE意識しています。 Yは、IKEパケットがアドレスNbから来るのを見ます。 Yがパケット(Nb)のソースアドレスに基づくIKE同輩のアイデンティティを誤って引き出すのを防ぐために、Xはクライアント識別子をYと交換しなければなりません:
- IDii, IDir if in Phase 1, and
- そしてIDii、中ならIDirが1をフェーズである。
- IDci, IDcr if in Phase 2.
- IDci、中なら、IDcrは2の位相を合わせます。
The proper use of identifiers allows the clear separation between those identities and the source IP address of the packets.
識別子の適切な使用はそれらのアイデンティティとソースIPの間の明確な分離にパケットのアドレスを許容します。
5. IPsec Handling and Demultiplexing
5. IPsec取り扱いと逆多重化
The RSIP client X and server N must arrive at an SPI value to denote the incoming IPsec security association from Y to X. Once N and X make sure that the SPI is unique within both of their SPI spaces, X communicates its value to Y as part of the IPsec security association establishment process, namely, Quick Mode in IKE [IKE] or manual assignment.
RSIPクライアントXとサーバNはYからOnce NとXがSPIがそれらのSPI空間の両方の中でユニークであることを確信するようにするX.まで入って来るIPsecセキュリティ協会を指示するためにSPI値に到着しなければならなくて、Xはすなわち、IPsecセキュリティ協会設立プロセス、IKE[IKE]か手動の課題におけるクィックModeの一部として値をYに伝えます。
This ensures that Y sends IPsec packets (protocols 51 and 50 for AH and ESP, respectively) [Kent98a,Kent98b] to X via address Nb using the negotiated SPI.
これは、YがアドレスNbを通して交渉されたSPIを使用することでXへのパケット(AHと超能力のためのそれぞれプロトコル51と50)[Kent98a、Kent98b]をIPsecに送るのを確実にします。
IPsec packets from Y destined for X arrive at RSIP server N. They are demultiplexed based on the following minimum tuple of demultiplexing fields:
Xのために運命づけられたYからのIPsecパケットはRSIPサーバN.に到着します。Theyは逆多重化分野の以下の最小のtupleに基づいて反多重送信されます:
- protocol (50 or 51)
- プロトコル(50か51)
- SPI
- SPI
- destination IP address
- 送付先IPアドレス
If N is able to find a matching mapping, it tunnels the packet to X according to the tunneling mode in effect. If N cannot find an appropriate mapping, it MUST discard the packet.
Nが合っているマッピングを見つけることができるなら、トンネリングモードによると、事実上、それはXにパケットにトンネルを堀ります。 Nが適切なマッピングを見つけることができないなら、それはパケットを捨てなければなりません。
Montenegro & Borella Experimental [Page 5] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[5ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
6. RSIP Protocol Extensions
6. RSIPプロトコル拡張子
The next two sections specify how the RSIP protocol [RSIP-P] is extended to support both IKE (a UDP application) and the IPsec- defined AH and ESP headers (layered directly over IP with their own protocol numbers).
次の2つのセクションがRSIPプロトコル[RSIP-P]が両方がIKE(UDPアプリケーション)と、IPsecの定義されたAHと超能力ヘッダー(IPの直接上でそれら自身のプロトコル番号で層にされる)であるとサポートするためにどう広げられるかを指定します。
If a server implements RSIP support for IKE and IPsec as defined in this document, it MAY include the RSIP Method parameter for RSIP with IPsec in the REGISTER_RESPONSE method sent to the client. This method is assigned a value of 3:
サーバが、本書では定義されるようにRSIPがIKEとIPsecのサポートであると実装するなら、それはIPsecと共にクライアントに送られたREGISTER_RESPONSEメソッドにRSIPのためのRSIP Methodパラメタを含むかもしれません。 3の値はこのメソッドに割り当てられます:
3 RSIP with IPsec (RSIPSEC)
3 IPsecとRSIP(RSIPSEC)
Unless otherwise specified, requirements of micro and macro flow- based policy are handled according to [RSIP-P].
別の方法で指定されない場合、[RSIP-P]に従って、マイクロの、そして、マクロ流れに基づいている方針の要件は扱われます。
6.1 IKE Support in RSIP
6.1 RSIPでのIKEサポート
As discussed above, if X's IPsec implementation allows use of an ephemeral source port for IKE, then incoming IKE traffic can be demultiplexed by N based on the destination address and port tuple. This is the simplest and most desirable way of supporting IKE, and IPsec implementations that interact with RSIP SHOULD allow it.
上で議論するように、XのIPsec実装がはかないソースポートのIKEの使用を許すなら、送付先アドレスとポートtupleに基づくNは入って来るIKEトラフィックを反多重送信できます。 これはIKEをサポートする最も簡単で最も望ましい方法です、そして、RSIP SHOULDと対話するIPsec実装がそれを許容します。
However, if X must use source port 500 for IKE, there are two techniques with which X and N can arrive at a mutually unique Initiator Cookie.
しかしながら、XがIKEにソースポート500を使用しなければならないなら、XとNが互いにユニークなInitiator Cookieに到着できる2つのテクニックがあります。
- Trial and error.
- 試行錯誤。
- Negotiation via an extension of the RSIP protocol.
- RSIPプロトコルの拡大を通した交渉。
The trial and error technique consists of X first obtaining resources with which to use IPsec (via ASSIGN_REQUEST_RSIPSEC, defined below), and then randomly choosing an Initiator Cookie and transmitting the first packet to Y. Upon arrival at N, the RSIP server examines the Initiator Cookie for uniqueness per X's assigned address (Nb). If the cookie is unique, N allows the use of this cookie for this an all subsequent packets between X and Y on this RSIP binding. If the cookie is not unique, N drops the packet.
試行錯誤のテクニックは最初にIPsecを使用するリソースを得るXから成ります、そして、(以下で定義された_ASSIGN_REQUEST RSIPSECを通して)次に、手当たりしだいにInitiator Cookieを選んで、NへのY.Upon到着に最初のパケットを伝えて、RSIPサーバはXの割り当てられたアドレス(Nb)あたりのユニークさがないかどうかInitiator Cookieを調べます。 クッキーがユニークであるなら、NはこのRSIP結合のときにXとYの間のすべてのその後のパケットをこのクッキーのこの使用に許容します。 クッキーがユニークでないなら、Nはパケットを下げます。
When an IKE packet is determined to be lost, the IKE client will attempt to retransmit at least three times [IKE]. An RSIP-aware IKE client SHOULD use different Initiator Cookies for each of these retransmissions.
IKEパケットが失われると決心しているとき、IKEクライアントは、少なくとも3回[IKE]再送するのを試みるでしょう。 RSIP意識しているIKEクライアントSHOULDがそれぞれのこれらに異なったInitiator Cookiesを使用するのを「再-トランスミッション」。
Montenegro & Borella Experimental [Page 6] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[6ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
The probability of an Initiator Cookie collision at N and subsequent retransmissions by X, is infinitesimal given the 64-bit cookie space. According to the birthday paradox, in a population of 640 million RSIP clients going through the same RSIP server, the chances of a first collision is just 1%. Thus, it is desirable to use the trial and error method over negotiation, for these reasons:
64ビットのクッキースペースを考えて、NでのInitiator Cookie衝突とXによるその後の「再-トランスミッション」の確率は微小です。 誕生日のパラドックスによると、同じRSIPサーバに直面している6億4000万人のRSIPクライアントの人口において、最初の衝突の機会はちょうど1%です。 したがって、これらの理由に交渉の上で試行錯誤法を使用するのは望ましいです:
- Simpler implementation requirements
- より簡単な実装要件
- It is highly unlikely that more than one round trip between X
and N will be necessary.
- XとNの間の1つ以上の周遊旅行が必要になるのは、非常にありそうもないです。
6.2 IPsec Support in RSIP
6.2 RSIPでのIPsecサポート
This section defines the protocol extensions required for RSIP to support AH and ESP. The required message types are ASSIGN_REQUEST_RSIPSEC and ASSIGN_RESPONSE_RSIPSEC:
このセクションは拡張子が、RSIPがAHと超能力をサポートするのを必要としたプロトコルを定義します。 必要なメッセージタイプは、ASSIGN_REQUEST_RSIPSECとASSIGN_RESPONSE_RSIPSECです:
ASSIGN_REQUEST_RSIPSEC
_要求_RSIPSECを割り当ててください。
The ASSIGN_REQUEST_RSIPSEC message is used by an RSIP client to
request IPsec parameter assignments. An RSIP client MUST request
an IP address and SPIs in one message.
ASSIGN_REQUEST_RSIPSECメッセージは、IPsecパラメタ課題を要求するのにRSIPクライアントによって使用されます。 RSIPクライアントは1つのメッセージでIPアドレスとSPIsを要求しなければなりません。
If the RSIP client wishes to use IPsec to protect a TCP or UDP
application, it MUST use the port range parameter (see Appendix
A). Otherwise, it MUST set the port parameters to the "don't
need" value. This is accomplished by setting the length field to
0, and by omitting both the number field and the port field. This
informs the server that the client does not actually need any port
assignments.
RSIPクライアントがTCPかUDPアプリケーションを保護するのにIPsecを使用したいと思うなら、それはポート範囲パラメタを使用しなければなりません(Appendix Aを見てください)。 さもなければ、ポートパラメタを設定しなければならない、「」 値を必要としません。 これは、長さの分野を0に設定して、ナンバーフィールドとポート分野の両方を省略することによって、達成されます。 これは、クライアントが実際にどんなポート課題も必要としないことをサーバに知らせます。
The client may initialize the SPI parameter to the "don't care"
value (see below). In this case, it is requesting the server to
assign it a valid SPI value to use.
クライアントは「気にかけないでください」という値にSPIパラメタを初期化するかもしれません(以下を見てください)。 この場合、それは、使用する有効なSPI値をそれに割り当てるようサーバに要求しています。
Alternatively, the client may initialize the SPI parameter to a
value it considers valid. In this case, it is suggesting that
value to the server. Of course, the server may choose to reject
that suggestion and return an appropriate error message.
あるいはまた、クライアントはそれが有効であると考える値にSPIパラメタを初期化するかもしれません。 この場合、それはその値をサーバに示しています。もちろん、サーバはその提案を拒絶して、適切なエラーメッセージを返すのを選ぶかもしれません。
Montenegro & Borella Experimental [Page 7] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[7ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
The format of this message is:
このメッセージの形式は以下の通りです。
<ASSIGN_REQUEST_RSIPSEC> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<SPI>
[Message Counter]
[Lease Time]
[Tunnel Type]
<案配_は_RSIPSEC>を要求します:、:= タイプ><全長><クライアントID><が、(地方)の><ポートが(地方)の><アドレス(リモート)><であると扱うという<バージョン><メッセージは(リモート)の><SPI>[メッセージカウンタ][リース時間]を移植します。[トンネルタイプ]
The following message-specific error conditions exist. The error
behavior of ASSIGN_REQUEST_RSIP_IPSEC follows that of
ASSIGN_REQUEST_RSAP-IP for all non-IPsec errors.
以下のメッセージ特有のエラー条件は存在しています。 ASSIGN_REQUEST_RSIP_IPSECの誤り動きはすべての非IPsec誤りによってASSIGN_REQUEST_RSAP-IPのものに続きます。
- If the client is not allowed to use IPsec through the server,
the server MUST respond with an ERROR_RESPONSE containing the
IPSEC_UNALLOWED parameter.
- クライアントがサーバを通してIPsecを使用できないなら、ERROR_RESPONSEがIPSEC_UNALLOWEDパラメタを含んでいて、サーバは反応しなければなりません。
- If the SPI parameter is a "don't care" value and the RSIP
server cannot allocate ANY SPIs, the RSIP server MUST respond
with an ERROR_RESPONSE containing the IPSEC_SPI_UNAVAILABLE
error.
- SPIパラメタが「気にかけないでください」という値であり、RSIPサーバがどんなSPIsも割り当てることができないなら、ERROR_RESPONSEがIPSEC_SPI_UNAVAILABLE誤りを含んでいて、RSIPサーバは反応しなければなりません。
- If an SPI parameter is not a "don't care" value and the RSIP
server cannot allocate it because the requested address and SPI
tuple is in use, the RSIP server MUST respond with an
ERROR_RESPONSE containing the IPSEC_SPI_INUSE error.
- SPIパラメタが「気にかけないでください」という値でなく、要求されたアドレスとSPI tupleが使用中であるのでRSIPサーバがそれを割り当てることができないなら、ERROR_RESPONSEがIPSEC_SPI_椚瀬誤りを含んでいて、RSIPサーバは反応しなければなりません。
ASSIGN_RESPONSE_RSIPSEC
_応答_RSIPSECを割り当ててください。
The ASSIGN_RESPONSE_RSIPSEC message is used by an RSIP server to
assign parameters to an IPsec-enabled RSIP client.
ASSIGN_RESPONSE_RSIPSECメッセージはRSIPサーバによって使用されて、IPsecによって可能にされたRSIPクライアントにパラメタを割り当てます。
Montenegro & Borella Experimental [Page 8] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[8ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
The format of this message is:
このメッセージの形式は以下の通りです。
<ASSIGN_RESPONSE_RSIPSEC> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<SPI>
<Lease Time>
<Tunnel Type>
[Address (tunnel endpoint)]
[Message Counter]
_<案配_応答RSIPSEC>:、:= (地方)の(リモート)の(リモート)の<バージョン><Message Type><Overall Length><Client ID><Bind ID><Address(地方の)の<Lease Time><Tunnel Type><Ports><Address><Ports><SPI>>[アドレス(トンネル終点)][メッセージカウンタ]
If the port parameters were set to the "don't need" value in the
request (see above), the RSIP server must do the same in the
response.
ポートパラメタが設定される、「応答で同じように」 要求(上を見る)、必須がそうするRSIPサーバの値を必要としません。
Additionally, RSIP support for IPsec requires the following new parameter:
さらに、IPsecのRSIPサポートは以下の新しいパラメタを必要とします:
SPI
Code Length Number SPI SPI
+------+--------+---------+---------+ +---------+
| 22 | 2 | 2 bytes | 4 bytes | ... | 4 bytes |
+------+--------+---------+---------+ +---------+
SPIコード長さの数のSPI SPI+------+--------+---------+---------+ +---------+ | 22 | 2 | 2バイト| 4バイト| ... | 4バイト| +------+--------+---------+---------+ +---------+
Sent by the RSIP client in ASSIGN_REQUEST_RSIPSEC messages to ask for a particular number of SPIs to be assigned. Also sent by the RSIP server to the client in ASSIGN_RESPONSE_RSIPSEC messages.
RSIPクライアントで、SPIsの特定の数が割り当てられるように頼むASSIGN_REQUEST_RSIPSECメッセージで発信しました。 また、ASSIGN_RESPONSE_RSIPSECメッセージのクライアントへのRSIPサーバで、送ります。
The "SPI" fields encode one or more SPIs. When a single SPI is specified, the value of the number field is 1 and there is one SPI field following the number field. When more than one SPI is specified, the value of the number field will indicate the total number of SPIs contained, and the parameter may take one of two forms. If there is one SPI field, the SPIs specified are considered to be contiguous starting at the SPI number specified in the SPI field. Alternatively, there may be a number of SPI fields equal to the value of the number field. The number of SPI fields can be extrapolated from the value of the length field.
"SPI"分野は1SPIsをコード化します。 独身のSPIが指定されるとき、ナンバーフィールドの値は1です、そして、ナンバーフィールドに続く1つのSPI分野があります。 1SPIが指定されるとき、ナンバーフィールドの値は、SPIsの総数が含んだのを示すでしょう、そして、パラメタは2つのフォームの1つを取るかもしれません。1つのSPI分野があれば、SPI分野で指定されたSPI番号で始まって、指定されたSPIsが隣接であると考えられます。 あるいはまた、ナンバーフィールドの値と等しい多くのSPI分野があるかもしれません。 長さの分野の値からSPI分野の数を推定できます。
Montenegro & Borella Experimental [Page 9] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[9ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
In some cases, it is necessary to specify a "don't care" value for one or more SPIs. This is accomplished by setting the length field to 2 (to account for the 2 bytes in the Number field), setting the number field to the number of SPIs necessary, and omitting all SPI fields. The value of the number field MUST be greater than or equal to one.
いくつかの場合、「気にかけないでください」という値を1SPIsに指定するのが必要です。 これは2(Number分野で2バイトを説明する)に長さの分野を設定することによって、達成されます、SPIs必要の数にナンバーフィールドを設定して、すべてのSPI分野を省略して。 ナンバーフィールドの値は1以上でなければなりません。
7. IANA Considerations
7. IANA問題
All of the designations below are tentative.
以下の名称のすべてが一時的です。
- RSIP IPsec error codes (see below).
- RSIP IPsecエラーコード(以下を見ます)。
- ASSIGN_REQUEST_RSIP_IPSEC message type code.
- ASSIGN_REQUEST_RSIP_IPSECメッセージタイプコード。
- SPI parameter code.
- SPIパラメタコード。
8. Security Considerations
8. セキュリティ問題
This document does not add any security issues to those already posed by NAT, or normal routing operations. Current routing decisions typically are based on a tuple with only one element: destination IP address. This document just adds more elements to the tuple.
このドキュメントはNAT、または通常のルーティング操作で既にポーズをとられたものに少しの安全保障問題も加えません。 現在のルーティング決定は1つの要素だけがあるtupleに通常基づいています: 送付先IPアドレス。 このドキュメントはただより多くの要素をtupleに加えます。
Furthermore, by allowing an end-to-end mode of operation and by introducing a negotiation phase to address reuse, the mechanisms described here are more secure and less arbitrary than NAT.
その上、終わりから終わりへの運転モードを許容して、アドレス再利用に交渉フェーズを紹介することによって、ここで説明されたメカニズムは、NATより安全であって、より任意ではありません。
A word of caution is in order: SPI values are meant to be semi- random, and, thus serve also as anti-clogging tokens to reduce off- the-path denial-of-service attacks. However, RSIP support for IPsec, renders SPI's a negotiated item: in addition to being unique values at the receiver X, they must also be unique at the RSIP server, N. Limiting the range of the SPI values available to the RSIP clients reduces their entropy slightly.
警告の単語は整然としています: SPI値が準無作為であることが意味されて、その結果、また、減少するために反目詰まりトークンとして機能してください、オフである、経路サービス不能攻撃。 しかしながら、RSIPがIPsecのためにサポートする、交渉された項目をSPIのaに表します: 受信機Xのユニークな値、また、彼らもRSIPサーバでユニークであるに違いありません、N.Limitingということであることに加えたRSIPクライアントにとって、利用可能なSPI値の範囲は彼らのエントロピーをわずかに減少させます。
9. Acknowledgements
9. 承認
Many thanks to Bernard Aboba, Vipul Gupta, Jeffrey Lo, Dan Nessett, Gary Jaszewski and Prakash Iyer for helpful discussions.
役立つ議論のためにバーナードAboba、Vipulグプタ、ジェフリーLo、ダンNessett、ゲーリーJaszewski、およびプラカシュ・アイヤルをありがとうございます。
Montenegro & Borella Experimental [Page 10] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[10ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
References
参照
[Gupta] Gupta, V., "Secure Remote Access over the Internet using
IPSec", Work in Progress.
[グプタ]グプタ、V.、「IPSecを使用するインターネットの上の安全な遠隔アクセス」が進行中で働いています。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[ISAKMP] Maughan, D., Schertler, M., Schneider, M. and J. Turner,
"Internet Security Association and Key Management
Protocol (ISAKMP)", RFC 2408, November 1998.
[ISAKMP] Maughan、D.、Schertler、M.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。
[IPSEC-MSG] Ted Ts'o, message to the IETF's IPsec mailing list,
Message-Id:<199911232216.RAA01932@trampoline.thunk.org>,
November 23, 1999.
[IPSEC-MSG]テッドTs'o、IETFのIPsecメーリングリスト、 Message-Id:<199911232216.RAA01932@trampoline.thunk.org へのメッセージ、gt;、1999年11月23日。
[Jenkins] Jenkins, T., "IPsec Rekeying Issues", Work in Progress.
[ジェンキンス]ジェンキンス、T.が進行中で働くのを「IPsec Rekeyingは発行します」。
[Kent98a] Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC
2406, November 1998.
[Kent98a]ケントとS.とR.アトキンソン、「有効搭載量をカプセル化するIP」、RFC2406、1998年11月。
[Kent98b] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[Kent98b] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[Kent98c] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[Kent98c] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[Piper98] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[Piper98]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[NAPT] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[NAPT] SrisureshとP.とK.Egevang、「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」、RFC3022、2001年1月。
[NAT-TERMS] Srisuresh, P. and M. Holdredge, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[ナット-用語]Srisuresh、P.、M.Holdredge、および「IPネットワークアドレス変換機構(NAT)用語と問題」、RFC2663、1999年8月。
[RSIP-FW] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
"Realm Specific IP: A Framework", RFC 3102, October 2001.
[RSIP-FW] Borella、M.、最低気温、J.、Grabelsky、D.、およびG.モンテネグロ、「分野の特定のIP:」 「フレームワーク」、RFC3102、2001年10月。
[RSIP-P] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi,
"Realm Specific IP: Protocol Specification", RFC 3103,
October 2001.
[RSIP-P] Borella、M.、Grabelsky、D.、最低気温、J.、およびK.谷口、「分野の特定のIP:」 「プロトコル仕様」、RFC3103、2001年10月。
Montenegro & Borella Experimental [Page 11] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[11ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
Authors' Addresses
作者のアドレス
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエルE.モンテネグロサン・マイクロシステムズ研究所、ヨーロッパ29、chemin du Vieux Chene38240メラン・フランス
Phone: +33 476 18 80 45 EMail: gab@sun.com
以下に電話をしてください。 +33 476 18 80 45はメールされます: gab@sun.com
Michael Borella CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
マイケルBorella CommWorks3800Golf通り Meadowsイリノイ 60008を回転させます。
Phone: (847) 262-3083 EMail: mike_borella@commworks.com
以下に電話をしてください。 (847) 262-3083 メールしてください: mike_borella@commworks.com
Montenegro & Borella Experimental [Page 12] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[12ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
Appendix A: On Optional Port Allocation to RSIP Clients
付録A: RSIPクライアントへの任意のポート配分に関して
Despite the fact that SPIs rather than ports are used to demultiplex packets at the RSIP server, the RSIP server may still allocate mutually exclusive port numbers to the RSIP clients. If this does not happen, there is the possibility that two RSIP clients using the same IP address attempt an IPsec session with the same server using the same source port numbers.
ポートよりむしろSPIsがRSIPサーバに「反-マルチプレックス」パケットに使用されるという事実にもかかわらず、RSIPサーバはまだ互いに唯一のポートナンバーをRSIPクライアントに割り当てているかもしれません。 これが起こらないなら、同じIPアドレスを使用している2人のRSIPクライアントが同じソースポート番号を使用する同じサーバとのIPsecセッションを試みる可能性があります。
+-------------+
| RSIP client |
| X1 +--+
| | | +-------------+
+-------------+ | | |Nb
+---------+ RSIP server +----------------
+-------------+ | | N |
| RSIP client | | +-------------+
| X2 +--+ private public
| | | network network
+-------------+ |
|
|
+-------------+ | RSIPクライアント| | X1+--+| | | +-------------+ +-------------+ | | |Nb+---------+ RSIPサーバ+---------------- +-------------+ | | N| | RSIPクライアント| | +-------------+ | X2+--+ 個人的な公衆| | | ネットワークネットワーク+-------------+ | | |
For example, consider hosts X1 and X2 depicted above. Assume that they both are using public address Nb, and both are contacting an external server Y at port 80. If they are using IPsec but are not allocated mutually exclusive port numbers, they may both choose the same ephemeral port number to use when contacting Y at port 80. Assume client X1 does so first, and after engaging in an IKE negotiation begins communicating with the public server using IPsec.
例えば、ホストが上に表現されたX1とX2であると考えてください。 それらの両方が場内放送Nbを使用していると仮定してください。そうすれば、両方が外部のサーバYにポート80へ連絡しています。 IPsecを使用していますが、互いに唯一のポートナンバーが割り当てられないなら、彼らはともにポート80へYに連絡するとき使用する同じエフェメラルポート番号を選ぶかもしれません。 クライアントX1が最初にそうして、IKE交渉に従事した後にIPsecを使用することで公共のサーバとコミュニケートし始めると仮定してください。
When Client X2 starts its IKE session, it sends its identification to the public server. The latter's SPD requires that different identities use different flows (port numbers). Because of this, the IKE negotiation will fail. Client X2 will be forced to try another ephemeral port until it succeeds in obtaining one which is currently not in use by any other security association between the public server and any of the RSIP clients in the private network.
Client X2がIKEセッションを始めるとき、それは識別を公開サーバに送ります。後者のSPDは、異なったアイデンティティが異なった流れ(ポートナンバー)を使用するのを必要とします。 これのために、IKE交渉は失敗するでしょう。 私設のネットワークで現在公開サーバとRSIPクライアントのどれかとのいかなる他のセキュリティ仲間でも使用中でないものを得るのに成功するまで、クライアントX2はやむを得ず別のエフェメラルポートを試みるでしょう。
Each such iteration is costly in terms of round-trip times and CPU usage. Hence --and as a convenience to its RSIP clients--, an RSIP server may also assign mutually exclusive port numbers to its IPsec RSIP clients.
そのようなそれぞれの繰り返しは往復の回とCPU用法で高価です。 したがってRSIPクライアントへの便利として--、また、RSIPサーバは互いに唯一のポートナンバーをIPsec RSIPクライアントに割り当てるかもしれません。
Montenegro & Borella Experimental [Page 13] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[13ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
Despite proper allocation of port numbers, an RSIP server cannot prevent their misuse because it cannot examine the port fields in packets that have been encrypted by the RSIP clients. Presumably, if the RSIP clients have gone through the trouble of negotiating ports numbers, it is in their best interest to adhere to these assignments.
ポートナンバーの適切な配分にもかかわらず、それがRSIPクライアントによって暗号化されたパケットのポート分野を調べることができないので、RSIPサーバは彼らの誤用を防ぐことができません。 おそらく、RSIPクライアントが通ったなら、交渉するという問題は数を移植して、これらの課題を固く守るのは、晴れ着を着て関心です。
Appendix B: RSIP Error Numbers for IKE and IPsec Support
付録B: IKEとIPsecサポートのためのRSIPエラー番号
This section provides descriptions for the error values in the RSIP error parameter beyond those defined in [RSIP-P].
このセクションは[RSIP-P]で定義されたものを超えたRSIPエラー・パラメータの誤り値のための記述を提供します。
401: IPSEC_UNALLOWED. The server will not allow the client
to use end-to-end IPsec.
401: IPSEC_UNALLOWED。 サーバで、クライアントは終わりから終わりへのIPsecを使用できないでしょう。
402: IPSEC_SPI_UNAVAILABLE. The server does not have an SPI
available for client use.
402: 入手できないIPSEC_SPI_。 サーバには、クライアント使用に利用可能なSPIがありません。
403: IPSEC_SPI_INUSE. The client has requested an SPI that
another client is currently using.
403: IPSEC_SPI_椚瀬。 クライアントは別のクライアントが現在使用しているSPIを要求しました。
Appendix C: Message Type Values for IPsec Support
付録C: IPsecサポートのためのメッセージタイプ値
This section defines the values assigned to RSIP message types beyond those defined in [RSIP-P].
このセクションは[RSIP-P]で定義されたものを超えたRSIPメッセージタイプに割り当てられた値を定義します。
22 ASSIGN_REQUEST_RSIPSEC
22は_要求_RSIPSECを割り当てます。
23 ASSIGN_RESPONSE_RSIPSEC
23は_応答_RSIPSECを割り当てます。
Appendix D: A Note on Flow Policy Enforcement
付録D: 流れ方針実施に関する注
An RSIP server may not be able to enforce local or remote micro-flow policy when a client uses ESP for end-to-end encryption, since all TCP/UDP port numbers will be encrypted. However, if AH without ESP is used, micro-flow policy is enforceable. Macro-flow policy will always be enforceable.
クライアントが終端間暗号化に超能力を使用するとき、RSIPサーバは地方の、または、リモートなマイクロ流れ方針を実施できないかもしれません、すべてのTCP/UDPポートナンバーが暗号化されるので。 しかしながら、超能力のないAHが使用されているなら、マイクロ流れ方針は実施できます。 マクロ流動方針はいつも実施できるでしょう。
Appendix E: Remote Host Rekeying
付録E: リモートホストRekeying
Occasionally, a remote host with which an RSIP client has established an IPsec security association (SA) will rekey [Jenkins]. SA rekeying is only an issue for RSIP when IKE port 500 is used by the client and the rekey is of ISAKMP phase 1 (the ISAKMP SA). The problem is that the remote host will transmit IKE packets to port 500 with a new initiator cookie. The RSIP server will not have a mapping for the cookie, and SHOULD drop the the packets. This will cause the ISAKMP
時折、RSIPクライアントとIPsecセキュリティ協会(SA)を設立したリモートホストはrekey[ジェンキンス]がそうするでしょう。 IKEポート500がクライアントによって使用されて、rekeyがISAKMPフェーズ1(ISAKMP SA)のものであるときにだけ、SA rekeyingはRSIPのための問題です。 問題はリモートホストが新しい創始者クッキーで500を移植するためにIKEパケットを伝えるということです。 RSIPサーバには、クッキーのためのマッピングがないでしょう、そして、SHOULDはパケットを下げます。 これはISAKMPを引き起こすでしょう。
Montenegro & Borella Experimental [Page 14] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[14ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
SA between the RSIP client and remote host to be deleted, and may lead to undefined behavior given that current implementations handle rekeying in a number of different ways.
削除されて、与えられた未定義の動作に通じるかもしれないということである多くの異なった方法で「再-合わせ」る現在の実装が扱うRSIPクライアントとリモートホストの間のSA。
If the RSIP client uses an ephemeral source port, rekeying will not be an issue for RSIP. If this cannot be done, there are a number of RSIP client behaviors that may reduce the number of occurrences of this problem, but are not guaranteed to eliminate it.
RSIPクライアントがはかないソースポートを使用すると、「再-合わせ」ることはRSIPのために問題にならないでしょう。 これができないなら、この問題の反復回数を減少させるかもしれませんが、それを排除するために保証されない多くのRSIPクライアントの振舞いがあります。
- The RSIP client's IKE implementation is given a smaller ISAKMP
SA lifetime than is typically implemented. This would likely
cause the RSIP client to rekey the ISAKMP SA before the remote
host. Since the RSIP client chooses the Initiator Cookie,
there will be no problem routing incoming traffic at the RSIP
server.
- 通常実装されるよりわずかなISAKMP SA生涯をRSIPクライアントのIKE実装に与えます。 これはリモートホストの前でおそらくRSIPクライアントにrekeyへのISAKMP SAを引き起こすでしょう。 RSIPクライアントがInitiator Cookieを選ぶので、RSIPサーバで入って来るトラフィックを発送することにおける問題が全くないでしょう。
- The RSIP client terminates the ISAKMP SA as soon as the first
IPsec SA is established. This may alleviate the situation to
some degree if the SA is coarse-grained. On the other hand,
this exacerbates the problem if the SA is fine-grained (such
that it cannot be reused by other application-level
connections), and the remote host needs to initialize sockets
back to the RSIP client.
- 最初のIPsec SAが設立されるとすぐに、RSIPクライアントはISAKMP SAを終えます。 SAが下品であるなら、これは状況をある程度軽減するかもしれません。 他方では、SAがきめ細かに粒状であるなら(他のアプリケーションレベル接続がそれを再利用できないように)、これは問題を悪化させます、そして、リモートホストはRSIPクライアントにソケットを初期化して戻す必要があります。
Note that the unreliability of UDP essentially makes the ephemeral source approach the only robust solution.
はかないソースがUDPの非信頼性で本質的には唯一のロバスト解にアプローチすることに注意してください。
Appendix F: Example Application Scenarios
付録F: 例のアプリケーションシナリオ
This section briefly describes some examples of how RSIP may be used to enable applications of IPsec that are otherwise not possible.
このセクションは簡潔にRSIPがそうでなければ可能でないIPsecのアプリケーションを可能にするのにどう使用されるかもしれないかに関するいくつかの例について説明します。
The SOHO (small office, home office) scenario ---------------------------------------------
ソーホー(小さいオフィス、ホームオフィス)シナリオ---------------------------------------------
+----------+
|RSIP |
|client X1 +--+
| | | +-------------+ +-------+
+----------+ | |NAPT gateway | |public |
+--+ and +--.......---+IPsec |
+----------+ | |RSIP server | |peer Y |
|RSIP | | +-------------+ +-------+
|client X2 +--+ private public
| | | "home" Internet
+----------+ | network
|
|
+----------+ |RSIP| |クライアントX1+--+| | | +-------------+ +-------+ +----------+ | |NAPTゲートウェイ| |公衆| +(+と+)…---+ IPsec| +----------+ | |RSIPサーバ| |同輩Y| |RSIP| | +-------------+ +-------+ |クライアントX2+--+ 個人的な公衆| | | 「ホーム」インターネット+----------+ | ネットワーク| |
Montenegro & Borella Experimental [Page 15] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[15ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
Suppose the private "home" network is a small installation in somebody's home, and that the RSIP clients X1 and X2 must use the RSIP server N as a gateway to the outside world. N is connected via an ISP and obtains a single address which must be shared by its clients. Because of this, N has NAPT, functionality. Now, X1 wishes to establish an IPsec SA with peer Y. This is possible because N is also an RSIP server augmented with the IPsec support defined in this document. Y is IPsec-capable, but is not RSIP aware. This is perhaps the most typical application scenario.
私設の「ホーム」ネットワークがだれかのホームでの小さい取り付けであり、RSIPクライアントのX1とX2が外の世界へのゲートウェイとしてRSIPサーバNを使用しなければならないと仮定してください。 Nは、ISPで接続されて、クライアントが共有しなければならないただ一つのアドレスを得ます。 これのために、Nには、NAPT、機能性があります。 今、X1は同輩Y.と共にIPsec SAを設立したがっています。Nがまた、IPsecサポートが本書では定義されている状態で増大するRSIPサーバであるので、Thisは可能です。 Yは、IPsecできますが、RSIP意識していません。 これは恐らく最も典型的なアプリケーションシナリオです。
The above is equally applicable in the ROBO (remote office, branch office) scenario.
上記はROBO(遠く離れたオフィス、支店)シナリオで等しく適切です。
The Roadwarrior scenario ------------------------
Roadwarriorシナリオ------------------------
+---------+ +------------+ +----------+
|RSIP | |Corporate | | IPsec |
|client X +--..........--+Firewall +---+ peer Y |
| | public | and | | (user's |
+---------+ Internet |RSIP server | | desktop) |
| N | | |
+------------+ +----------+
private corporate
network
+---------+ +------------+ +----------+ |RSIP| |法人| | IPsec| |クライアントX+--…… …--+ ファイアウォール+---+ 同輩Y| | | 公衆| そして| | (ユーザ| +、-、-、-、-、-、-、-、--、+ インターネット| RSIPサーバ| | デスクトップ、) | | N| | | +------------+ +----------+ 私設の企業ネットワーク
In this example, a remote user with a laptop gains access to the Internet, perhaps by using PPP or DHCP. The user wants to access its corporation private network. Using mechanisms not specified in this document, the RSIP client in the laptop engages in an RSIP authentication and authorization phase with the RSIP server at the firewall. After that phase is completed, the IPsec extensions to RSIP defined here are used to establish an IPsec session with a peer, Y, that resides within the corporation's network. Y could be, for example, the remote user's usual desktop when at the office. The corporate firewall complex would use RSIP to selectively enable IPsec traffic between internal and external systems.
この例では、ラップトップをもっているリモート・ユーザーは、インターネットと、恐らくPPPかDHCPを使用することによって、アクセスを得ます。 ユーザは会社の私設のネットワークにアクセスしたがっています。 本書では指定されなかったメカニズムを使用して、ラップトップのRSIPクライアントはファイアウォールのRSIPサーバとのRSIP認証と承認フェーズに従事しています。 そのフェーズが完成した後に、ここで定義されたRSIPへのIPsec拡張子は、同輩、会社のネットワークの中に住んでいるYとのIPsecセッションを証明するのに使用されます。 オフィスで例えば、Yはリモート・ユーザーの普通のデスクトップであるかもしれません。 法人のファイアウォール複合体は、選択的に内部の、そして、外部のシステムの間のIPsecトラフィックを可能にするのにRSIPを使用するでしょう。
Note that this scenario could also be reversed in order to allow an internal system (Y) to initiate and establish an IPsec session with an external IPsec peer (X).
また、内部のシステム(Y)が外部のIPsec同輩(X)とのIPsecセッションを開始して、確立するのを許容するためにこのシナリオを逆にすることができたことに注意してください。
Montenegro & Borella Experimental [Page 16] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[16ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
Appendix G: Thoughts on Supporting Incoming Connections
付録G: 接続要求をサポートすることに関する考え
Incoming IKE connections are much easier to support if the peer Y can initiate IKE exchanges to a port other than 500. In this case, the RSIP client would allocate that port at the RSIP server via ASSIGN_REQUEST_RSAP-IP. Alternatively, if the RSIP client is able to allocate an IP address at the RSIP server via ASSIGN_REQUEST_RSA-IP, Y could simply initiate the IKE exchange to port 500 at that address.
同輩Yが500以外のポートへのIKE交換を起こすことができるなら、入って来るIKE接続ははるかにサポートしやすいです。 この場合、RSIPクライアントは_REQUEST_RSAP-IPをASSIGNを通したRSIPサーバにおけるそのポートに割り当てるでしょう。 あるいはまた、RSIPクライアントが_REQUEST_RSA-IPをASSIGNを通したRSIPサーバにおけるIPアドレスに割り当てることができるなら、Yは、そのアドレスで500を移植するために単にIKE交換を起こすかもしれません。
If there is only one address Nb that must be shared by the RSIP server and all its clients, and if Y can only send to port 500, the problem is much more difficult. At any given time, the combination of address Nb and UDP port 500 may be registered and used by only one RSIP system (including clients and server).
RSIPサーバとそのすべてのクライアントが共有しなければならない1アドレスNbしかなくて、Yが500を移植するために発信できるだけであるなら、問題ははるかに難しいです。 その時々で、アドレスNbとUDPポート500の組み合わせは、1台のRSIPシステムだけによって登録されて、使用されるかもしれません(クライアントとサーバを含んでいて)。
Solving this issue would require demultiplexing the incoming IKE connection request based on something other than the port and address combination. It may be possible to do so by first registering an identity with a new RSIP command of LISTEN_RSIP_IKE. Note that the identity could not be that of the IKE responder (the RSIP client), but that of the initiator (Y). The reason is that IKE Phase 1 only allows the sender to include its own identity, not that of the intended recipient (both, by the way, are allowed in Phase 2). Furthermore, the identity must be in the clear in the first incoming packet for the RSIP server to be able to use it as a demultiplexor. This rules out all variants of Main Mode and Aggressive Mode with Public Key Encryption (and Revised Mode of Public Key Encryption), since these encrypt the ID payload.
この問題を解決するのは入って来るIKE接続要求がポートとアドレス組み合わせ以外の何かに基礎づけた逆多重化を必要とするでしょう。 最初にLISTEN_RSIP_IKEの新しいRSIPコマンドにアイデンティティを示すことによってそうするのは可能であるかもしれません。 アイデンティティがIKE応答者(RSIPクライアント)のものではなく、創始者(Y)のものであるかもしれないことに注意してください。 理由はIKE Phase1が送付者に意図している受取人のものではなく、それ自身のアイデンティティを入れさせるだけであるという(両方がPhase2にところで、許容されています)ことです。 その上、アイデンティティがRSIPサーバが「反-マルチプレクサー」としてそれを使用できる最初の入って来るパケットの明確にあるに違いありません。 これはPublic Key Encryption(そして、Public Key EncryptionのRevised Mode)とMain ModeとAggressive Modeのすべての異形を除外します、これらがIDペイロードを暗号化するので。
The only Phase 1 variants which enable incoming IKE sessions are Aggressive Mode with signatures or with pre-shared keys. Because this scheme involves the RSIP server demultiplexing based on the identity of the IKE initiator, it is conceivable that only one RSIP client at a time may register interest in fielding requests from any given peer Y. Furthermore, this precludes more than one RSIP client' s being available to any unspecified peer Y.
入って来るIKEセッションを可能にする唯一のPhase1異形が署名かあらかじめ共有されたキーがあるAggressive Modeです。 'この体系がIKE創始者のアイデンティティに基づくRSIPサーバ逆多重化にかかわるので一度に1人のRSIPクライアントだけが同輩Y.Furthermoreを考えて、いずれからの要求をさばくことへの関心を示すのが想像できる、これは1人以上のRSIPクライアントを排除する'というどんな不特定の同輩Yにとっても、利用可能なs。
Once the IKE session is in place, IPsec is set up as discussed in this document, namely, by the RSIP client and the RSIP server agreeing on an incoming SPI value, which is then communicated to the peer Y as part of Quick Mode.
IKEセッションが適所にいったんあると、IPsecはすなわち、このドキュメントで次にクィックModeの一部として同輩Yに伝えられる入って来るSPI値に同意するRSIPクライアントとRSIPサーバによって議論されていた状態で開業されます。
The alternate address and port combination must be discovered by the remote peer using methods such as manual configuration, or the use of KX (RFC2230) or SRV (RFC2052) records. It may even be possible for the DNS query to trigger the above mechanisms to prepare for the incoming and impending IKE session initiation. Such a mechanism would allow more than one RSIP client to be available at any given
リモート同輩は、手動の構成、またはKX(RFC2230)かSRV(RFC2052)記録の使用などのメソッドを使用することで代替アドレスとポート組み合わせを発見しなければなりません。 DNS質問が入って来て差し迫っているIKEセッション開始のために準備する上のメカニズムの引き金となるのは、可能でさえあるかもしれません。 そのようなメカニズムは、1人以上のRSIPクライアントがいずれにも手があいているのを与えた状態で許容するでしょう。
Montenegro & Borella Experimental [Page 17] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[17ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
time, and would also enable each of them to respond to IKE initiations from unspecified peers. Such a DNS query, however, is not guaranteed to occur. For example, the result of the query could be cached and reused after the RSIP server is no longer listening for a given IKE peer's identity.
調節してください、そして、また、それぞれの彼らが不特定の同輩からIKE開始に応じるのを可能にするでしょう。 しかしながら、そのようなDNS質問は、起こるように保証されません。 例えば、RSIPサーバがもう与えられたIKE同輩のアイデンティティの聞こうとしなかった後に、質問の結果は、キャッシュされて、再利用されるかもしれません。
Because of the limitations implied by having to rely on the identity of the IKE initiator, the only practical way of supporting incoming connections is for the peer Y to initiate the IKE session at a port other than 500.
接続要求をサポートする唯一の実用的な方法はIKE創始者のアイデンティティを当てにしなければならないことによって含意された制限のために、同輩Yが500以外のポートでIKEセッションを開始することです。
Montenegro & Borella Experimental [Page 18] RFC 3104 RSIP Support for End-to-end IPsec October 2001
モンテネグロとBorellaの実験的な[18ページ]RFC3104RSIPは、終わりから終わりへのIPsecのために10月が2001であるとサポートします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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機能のための基金は現在、インターネット協会によって提供されます。
Montenegro & Borella Experimental [Page 19]
モンテネグロとBorella実験的です。[19ページ]
一覧
スポンサーリンク
