Network Working Group G. Montenegro
Request for Comments: 3104 Sun Microsystems, Inc.
Category: Experimental M. Borella
CommWorks
October 2001
RSIP Support for End-to-end IPsec
Status of this 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.
著作権（C）インターネット協会（2001）。全著作権所有。
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を使用することに伴う大幅な運用の複雑さがあるかもしれません。これらおよび他の合併症のいくつかは、したがってRFC 3102のセクション6で、だけでなく、RFC 3104の付録に概説されている、RSIPを使用してのコストとベネフィットを慎重アドレス不足を緩和する他の手段と比較して検討する必要があります。
Abstract
抽象
This document proposes mechanisms that enable Realm Specific IP (RSIP) to handle end-to-end IPsec (IP Security).
この文書では、エンドツーエンドのIPsec（IPセキュリティ）を処理するレルム特定IP（RSIP）を有効にメカニズムを提案しています。
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
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
For clarity, the discussion below assumes this model:
明確にするために、以下の議論は、このモデルを前提としています。
RSIP client RSIP server Host
RSIPクライアントRSIPサーバホスト
Xa Na Nb Yb
+------------+ Nb1 +------------+
[X]------| Addr space |----[N]-----| Addr space |-------[Y]
| A | Nb2 | B |
+------------+ ... +------------+
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サーバです。例えば、アドレス空間B上のNaアドレス空間Aに、およびNb、Aは、プライベートアドレス空間とすることができる、とB一般的なインターネットのパブリックアドレス空間：Nは2つのアドレスを有しています。また、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拡張機能やメカニズムがそうするためには、従来のIKEおよびIPsecノードYにIKEおよびIPsecセッションを開始するためにRSIPクライアントXを有効にすることを提案し、RSIPサーバNを持つX交換RSIPプロトコルメッセージは、この文書はまだありませんこの問題に関するいくつかの考え付録G.を参照してくださいRSIPクライアントXにYからのIKE / IPsecのセッション開始に対処
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.
以下の議論は、これは、「ソース」は、Yを指すことを意味し、「宛先」がYのピア、N.ですなわち、Xの存在を指すX.宛、RSIPサーバNは、Yによって送信されたパケットを検査していることを前提としてい
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.
この文書では、SPI値を分離するために使用されているの上に、（そのポート番号の割り当ては任意である除く）RSIPのRSAP-IP風味の使用を想定しています。このため、複数のRSIPクライアントが同じグローバルIPアドレスを共有する場合があります。
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を再利用することを可能にします。このため、YのSPDは、アドレスベースのキーイングをサポートするように設定されるべきではありません。アドレスベースキーが代わりY.とのIPsecパケットを交換する、YのSPDは、セッション指向のキーをサポートするように構成する必要があるときのみRSIPクライアントは、時間内の任意の所与の時点でアドレスのNbを用いることができることを意味し、またはユーザ指向キーイング[Kent98c ]。ユーザ指向のキーに加えて、IKE識別ペイロード内の識別の他のタイプは、単一のアドレスの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 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.
（唯一のフェーズI認証のための事前共有キーとメインモードを実装する）最小限準拠IKE実装は、動的に割り当てられたアドレスを使用して、リモートホスト上で使用することができないことに留意されたいです。 IKE応答者（ゲートウェイ）は、（フェーズIで総合5）後者の第三のメインモードメッセージを復号化する前に、開始剤の（モバイルノードの）事前共有キーを検索する必要があります。イニシエータの身元が暗号化されたメッセージに含まれているので、唯一のIPアドレスは、ルックアップのために利用可能であり、予測可能でなければなりません。このようなデジタル署名/ RSAの暗号化とアグレッシブモード、メインモードのような他のオプションは、動的に割り当てられたアドレスと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]:
エフェメラルソースポートの使用は[ISAKMP]除外されないものの、IKEパケットは、典型的には、送信元と宛先の両方のためのUDPポート500に担持されています。 RSIPと共に使用するための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をサポートしなければならないが、他のポート番号も許されます。実装が他方より-ポート500 IKEを可能にする場合（「任意のポート」を意味する）を0にIDペイロードに報告されているように、それは（500ではない）の代わりに500 UDPポート番号、ポート番号の値を設定します一般的な「スワップの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クライアントから割り当てられたのSPIおよびおそらく他のパラメータを受信するためには、少なくとも一部の周辺意味では、RSIPを知っていなければならないことに注意することが重要です。したがって、バンプ・イン・スタック（BITS）のIPsecの実装は、RSIPで「箱の外」に動作することが期待されていません。
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とフェーズ2）に存在することが保証されるよう適切である、クリア（後続のIKEペイロードが暗号化されていても）であることが保証されます。しかし、IKE [IKE]でハッシュペイロードによって保護されています。このため、RSIPクライアントとサーバは、イニシエータクッキーの有効な値に同意しなければなりません。
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は、IKEパケットとトンネルを作成するためにそれを使用するイニシエータCookieの相互に合意値に到達するX一度、NはRSIPサーバN. Nは、IKEパケットをデカプセル化し、アドレス空間Bに送信します
The minimum tuple negotiated via RSIP, and used for demultiplexing incoming IKE responses from Y at the RSIP server N, is:
RSIPサーバNでYからの着信IKE応答を逆多重化するためのRSIPを介して交渉され、使用される最小の組は、次のとおりです。
- 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:
一つの問題はまだ残っている：どのようにYは、Nbを経由してXにパケットを送信することになっていることを知っていますか？ YはRSIP-認識していないが、それは間違いなくIKE-認識しています。 Yは、アドレスのNbから来るIKEパケットを見ています。誤ったパケット（NB）の送信元アドレスに基づいて、IKEピアのアイデンティティを導出からYを防止するために、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アドレスとの間に明確に分離することができます。
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は、NおよびXは、SPIがそのSPI空間の両方内で一意であることを確認してくださいたらXにYからの着信のIPsecセキュリティアソシエーションを示すためにSPI値に到達しなければならない、XはYにその値としての通信しますIPSecセキュリティアソシエーションの確立プロセスの一部、すなわち、IKE [IKE]または手動割り当てにクイックモード。
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がネゴシエートSPIを使用してアドレスのNbを介してXにIPsecパケット（それぞれ、プロトコル51とAHとESP 50）[Kent98a、Kent98b]を送信することを保証します。
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.到着します：
- 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は、適切なマッピングが見つからない場合は、パケットを捨てなければなりません。
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およびESPヘッダ（独自のプロトコル番号と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:
サーバは、この文書で定義されたIKEおよびIPsecのRSIPサポートを実装している場合、それはクライアントに送信されたREGISTER_RESPONSE方式のIPsecとのRSIPのためのRSIPメソッドのパラメータを含むかもしれません。この方法は、3の値を割り当てられます。
3 RSIP with IPsec (RSIPSEC)
IPsecで3 RSIP（RSIPSEC）
Unless otherwise specified, requirements of micro and macro flow-based policy are handled according to [RSIP-P].
特に断りのない限り、ミクロ及びマクロフローベースのポリシーの必要条件は、[RSIP-P]に従って処理されます。
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用のエフェメラルソースポートの使用を許可する場合、上述したように、着信IKEトラフィックが宛先アドレス及びポートのタプルに基づいてNで分離することができます。これは、IKEをサポートする最も単純で最も望ましい方法であり、RSIPと対話する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は、互いにユニークイニシエータクッキーに到達することができる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.
試行錯誤手法は、Xが最初の（以下に定義ASSIGN_REQUEST_RSIPSEC、経由）IPsecを使用するとリソースを取得し、次にランダムに開始クッキーを選択し、Nに到着するとYに最初のパケットを送信することから成る、RSIPサーバはイニシエータを調べXの割り当てられたアドレス（NB）あたりの一意性のためのクッキー。クッキーが一意である場合、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クライアントは、これらの再送信ごとに異なるイニシエータクッキーを使用すべきです。
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:
XによってN及びその後の再送信で開始クッキー衝突の確率は、64ビット・クッキー空間所与微小です。誕生日のパラドックスによると、同じRSIPサーバを経由6.4億RSIPクライアントの集団では、最初の衝突の可能性はわずか1％です。したがって、これらの理由のために、交渉の上に試行錯誤メソッドを使用することが望ましいです。
- Simpler implementation requirements
- シンプルな実装要件
- It is highly unlikely that more than one round trip between X and N will be necessary.
- XとNの間に複数のラウンドトリップが必要になる可能性はほとんどありません。
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:
このセクションでは、AHとESPをサポートするためにRSIPのために必要なプロトコル拡張を定義します。必要なメッセージタイプがASSIGN_REQUEST_RSIPSECとASSIGN_RESPONSE_RSIPSEC、次のとおりです。
ASSIGN_REQUEST_RSIPSEC
ASSIGN_REQUEST_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クライアントは一つのメッセージにIPアドレスとSPIを要求しなければなりません。
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を使用したい場合は、ポートの範囲パラメータを（付録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パラメータを初期化することができます。この場合、サーバにその値を示唆しています。もちろん、サーバーはその提案を拒否し、適切なエラーメッセージを返すように選択することができます。
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]
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を使用することを許可されていない場合、サーバーはIPSEC_UNALLOWEDパラメータを含むERROR_RESPONSEで応じなければなりません。
- 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サーバはどのSPIを割り当てることができない「気にしない」であれば、RSIPサーバはIPSEC_SPI_UNAVAILABLEエラーを含むERROR_RESPONSEで応じなければなりません。
- 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のタプルが使用されているため、値とRSIPサーバがそれを割り当てることができない「気にしない」でない場合は、RSIPサーバはIPSEC_SPI_INUSEエラーを含むERROR_RESPONSEで応じなければなりません。
ASSIGN_RESPONSE_RSIPSEC
ASSIGN_RESPONSE_RSIPSEC
The ASSIGN_RESPONSE_RSIPSEC message is used by an RSIP server to assign parameters to an IPsec-enabled RSIP client.
ASSIGN_RESPONSE_RSIPSECメッセージは、IPSec対応のRSIPクライアントにパラメータを割り当てるためにRSIPサーバによって使用されています。
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]
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 |
+------+--------+---------+---------+ +---------+
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.
割り当てられるのSPIの特定の数を求めるためにASSIGN_REQUEST_RSIPSECメッセージにRSIPクライアントによって送信されます。また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」のフィールドは、一個の以上のSPIを符号化します。単一SPIが指定されている場合、番号フィールドの値が1であり、1つのSPIフィールドが数値フィールド以下があります。複数のSPIが指定されている場合、番号フィールドの値は、のSPIの総数が含まれる表示されます、そして、パラメータは、二つのいずれかの形式をとることができます。 1 SPIフィールドがある場合は、指定のSPIは、SPIフィールドで指定したSPI番号での連続起動であると考えられています。あるいは、番号フィールドの値に等しいSPIフィールドの数が存在してもよいです。 SPIフィールドの数は、長さフィールドの値から推定することができます。
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.
いくつかのケースでは、一個の以上のSPIのために、「気にしない」の値を指定する必要があります。これは、（Numberフィールドに2バイトのアカウントに）長さフィールドに2を設定する必要のSPIの数に番号フィールドを設定し、全てのSPIフィールドを省略することによって達成されます。番号フィールドの値が1以上でなければなりません。
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パラメータコード。
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、または通常のルーティング操作によってもたらされるものに任意のセキュリティ上の問題を追加しません。送信先IPアドレス：現在のルーティング決定は、一般的に一つだけの要素を持つタプルに基づいています。この文書では、単にタプルに要素を追加します。
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値は、セミランダムで、及び、従ってオフパスサービス拒否攻撃を軽減するための抗詰まりトークンを兼ねることを意味します。しかし、IPsecのRSIPサポートは、SPIの交渉された項目をレンダリングします：受信機Xに固有の値であることに加えて、彼らはまた、RSIPサーバで一意である必要があり、N.はRSIPクライアントが利用可能なSPI値の範囲を制限することは、彼らのを低減しますエントロピーわずか。
Many thanks to Bernard Aboba, Vipul Gupta, Jeffrey Lo, Dan Nessett, Gary Jaszewski and Prakash Iyer for helpful discussions.
有益な議論のためのバーナードAboba、ビパル・グプタ、ジェフリー・ロー、ダンNessett、ゲイリーJaszewskiとプラカシュアイヤルに感謝します。
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）"、RFC 2409、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]モーガン、D.、Schertler、M.、シュナイダー、M.とJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル（ISAKMP）"、RFC 2408、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のメーリングリストへのメッセージ、メッセージ-ID：<199911232216.RAA01932@trampoline.thunk.org>、1999年11月23日。
[Jenkins] Jenkins, T., "IPsec Rekeying Issues", Work in Progress.
[ジェンキンス]ジェンキンス、T.、 "IPsecの鍵の再生成の問題" が進行中で働いています。
[Kent98a] Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC 2406, November 1998.
[Kent98a]ケント、S.とR.アトキンソン、 "IPカプセル化ペイロード"、RFC 2406、1998年11月。
[Kent98b] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[Kent98b]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[Kent98c] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[Kent98c]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[Piper98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[Piper98]パイパー、D.、 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、RFC 2407、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繁体字）"、RFC 3022、2001年1月。
[NAT-TERMS] Srisuresh, P. and M. Holdredge, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERMS] Srisuresh、P.とM. Holdredge、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RSIP-FW] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: A Framework", RFC 3102, October 2001.
[RSIP-FW]ボレッラ、M.、ロー、J.、Grabelsky、D.およびG.モンテネグロ、 "レルム特定IP：フレームワーク"、RFC 3102、2001年10月。
[RSIP-P] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[RSIP-P]ボレッラ、M.、Grabelsky、D.、ロー、J.及びK.谷口、 "レルム特定IP：プロトコル仕様"、RFC 3103、2001年10月。
Authors' Addresses
著者のアドレス
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエル・E.モンテネグロSun Microsystemsの研究所、欧州29、CHEMINドゥヴューシュヌ38240メランFRANCE
Phone: +33 476 18 80 45 EMail: gab@sun.com
電話：+33 476 18 80 45 Eメール：gab@sun.com
Michael Borella CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
マイケルボレッラCommWorks 3800ゴルフRdを。ローリングメドウズIL 60008
Phone: (847) 262-3083 EMail: mike_borella@commworks.com
電話：（847）262-3083 Eメール：mike_borella@commworks.com
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.
SPIのではなく、ポートがRSIPサーバ側でパケットを分離するために使用されているという事実にもかかわらず、RSIPサーバはまだRSIPクライアントへの相互排他的なポート番号を割り当てることができます。これが起こらない場合は、同じIPアドレスを使用して、2つのRSIPクライアントが同じ送信元ポート番号を使用して、同じサーバーとのIPsecセッションを試みる可能性があります。
+-------------+
| RSIP client |
| X1 +--+
| | | +-------------+
+-------------+ | | |Nb
+---------+ RSIP server +----------------
+-------------+ | | N |
| RSIP client | | +-------------+
| X2 +--+ private public
| | | network network
+-------------+ |
|
|
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を考えます。彼らは、両方のYと接触する際に使用する同じエフェメラルポート番号を選択することができ、それらの両方がパブリックアドレスのNbを使用しており、両方がポート80彼らはIPsecを使用している場合に、外部サーバYに接触しているが、相互に排他的なポート番号が割り当てられていないことを前提としていポート80でクライアント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.
クライアントX2は、そのIKEセッションを開始すると、それは公開サーバにその識別情報を送信します。後者のSPDは異なるアイデンティティが異なるフロー（ポート番号）を使用する必要があります。このため、IKEネゴシエーションは失敗します。クライアントX2は、公開サーバとプライベートネットワークにおけるRSIPクライアントのいずれかの間のいずれかの他のセキュリティ・アソシエーションによって現在使用されていないものを得ることに成功するまで、別の一時的なポートを試みることを余儀なくされます。
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使用率の面でコストがかかります。したがって--andそのRSIPのclients--の便宜のために、RSIPサーバは、そのIPsecのRSIPクライアントに相互に排他的なポート番号を割り当てることができます。
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_UNAVAILABLE。サーバーは、クライアントの使用可能なSPIを持っていません。
403: IPSEC_SPI_INUSE. The client has requested an SPI that another client is currently using.
403：IPSEC_SPI_INUSE。クライアントは、別のクライアントが現在使用している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 ASSIGN_REQUEST_RSIPSEC
23 ASSIGN_RESPONSE_RSIPSEC
23 ASSIGN_RESPONSE_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ポート番号は暗号化されますので、クライアントは、エンドツーエンドの暗号化のためにESPを使用する場合、ローカルまたはリモートのマイクロフローポリシーを強制することはできないかもしれません。 ESPのないAHが使用されている場合には、マイクロフローポリシーは強制力です。マクロフローポリシーは、常に強制力になります。
Appendix E: Remote Host Rekeying
付録E：リモートホスト鍵の再生成
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）を確立したリモートホストが[ジェンキンス]をリキーます。 SAの再キーイングは、IKEポート500は、クライアントによって使用され、再入力がISAKMPフェーズ1（ISAKMP SA）であるRSIPのための唯一の問題です。問題は、リモートホストが新しいイニシエータクッキーとポート500にIKEパケットを送信することです。 RSIPサーバは、クッキーのマッピングを持っていないだろう、とパケットを廃棄すべきです。これは、ISAKMPの原因となります
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.
- RSIPクライアントのIKEの実装は、一般的に実装されているよりも小さいISAKMP SAの寿命を与えています。これはおそらくRSIPクライアントがリモートホストの前にISAKMP SAキーを再生成する原因となります。 RSIPクライアントはイニシエータクッキーを選択しているので、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.
- RSIPクライアントはすぐに最初のIPsec SAが確立されると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
|
|
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はNも、この文書で定義されたIPsecサポートで拡張RSIPサーバであるので、これは可能であるピアY.とのIPsec SAを確立することを希望します。 Yは、IPsec対応ですが、意識しRSIPされていません。これは、おそらく最も一般的なアプリケーションのシナリオです。
The above is equally applicable in the ROBO (remote office, branch office) scenario.
上記ROBO（リモートオフィス、ブランチオフィス）シナリオにも等しく適用可能です。
The Roadwarrior scenario
------------------------
+---------+ +------------+ +----------+
|RSIP | |Corporate | | IPsec |
|client X +--..........--+Firewall +---+ peer Y |
| | public | and | | (user's |
+---------+ Internet |RSIP server | | desktop) |
| N | | |
+------------+ +----------+
private corporate
network
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セッションを確立することを可能にするために逆にすることができることに留意されたいです。
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.
着信IKE接続は、ピアY、この場合に500以外のポートにIKE交換を開始することができるかどうサポートする方がはるかに簡単であり、RSIPクライアントはASSIGN_REQUEST_RSAP-IP経由RSIPサーバでそのポートを割り当てることになります。 RSIPクライアントがASSIGN_REQUEST_RSA-IP経由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サーバとそのすべてのクライアントが共有しなければならない、とYだけポート500に送ることができる場合のみ、一つのアドレスNbが存在する場合、問題ははるかに困難です。任意の時点で、アドレスNbおよびUDPポート500の組み合わせは、（クライアントおよびサーバーを含む）のみ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フェーズ1のみ送信者は、自身のアイデンティティを含むことができることではなく、その意図された受信者の（両方によって、フェーズ2で許可されます）。さらに、アイデンティティはRSIPサーバは、デマルチプレクサとして使用することができるようにするための最初の着信パケットに明確でなければなりません。これらは、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セッションを有効にのみ、フェーズ1変異体は、署名付き、または事前共有キーを使用してアグレッシブモードです。この方式は、IKEイニシエータのアイデンティティに基づいてRSIPサーバの分離を含むので、それは一度に一つだけRSIPクライアントは、さらに任意のピア・Y.から守備要求への関心を登録することも考えられる、これは、複数のRSIPクライアント」を排除しますSは、任意の不特定のピアYに利用可能です
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がRSIPクライアントとRSIPサーバは次いで、クイックモードの一部として、ピアYに伝達される着信SPI値に同意することによって、即ち、設定されています。
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 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.
代替アドレスとポートの組み合わせは、手動設定、またはKX（RFC2230）またはSRV（RFC2052）レコードの使用などの方法を使用してリモートピアによって発見されなければなりません。 DNSクエリが到来すると、差し迫ったIKEセッション開始の準備をするために、上記のメカニズムをトリガすることも可能です。このようなメカニズムは、任意の時点で利用可能にし、また、不特定ピアからIKEのイニシエーションに対応するために、それらのそれぞれを可能にする複数のRSIPクライアントを可能にします。このようなDNSクエリが、しかし、発生することが保証されていません。たとえば、クエリの結果をキャッシュすることができ、RSIPサーバはもはや特定のIKEピアのIDを待機した後に再利用します。
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イニシエータの識別に依拠することによって暗示制限により、着信接続をサポートする唯一の実用的な方法は、500以外のポートでIKEセッションを開始するピアYのためのものです。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。