[要約] RFC 3104は、RSIP（Realm-Specific IP）がエンドツーエンドのIPsec（Internet Protocol Security）をサポートするための仕様です。その目的は、RSIPを使用してエンドツーエンドのIPsecトラフィックを効果的に管理することです。
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
エンドツーエンドIPSECのRSIPサポート
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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テクノロジーを説明するドキュメントのセットが、完全な実装のために重要なホストとゲートウェイの変更を暗示していることを指摘しています。さらに、ポート番号が浮かんでいると、一部のアプリケーションに問題が発生する可能性があり、RSIP対応のホストが既存のアプリケーションと透過的に相互運用することを防ぐことができます（例えば、IPSEC）。最後に、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).
このドキュメントでは、レルム固有のIP（RSIP）がエンドツーエンドのIPSEC（IPセキュリティ）を処理できるようにするメカニズムを提案しています。
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].
このドキュメントは、rsip拡張機能を指定して、エンドツーエンドのIPSECを有効にします。[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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119に記載されているとおりに解釈されます。
For clarity, the discussion below assumes this model:
明確にするために、以下の議論はこのモデルを想定しています。
RSIP client RSIP server Host
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サーバーです。nには2つのアドレスがあります。アドレススペースAのNAとアドレススペースBの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拡張とメカニズムを提案して、RSIPクライアントXがIKEとIPSECセッションをレガシーIKEおよびIPSECノードYに開始できるようにします。そのために、XはRSIPサーバーNとRSIPプロトコルメッセージを交換します。YからYからRSIPクライアントXへのIKE/IPSECセッションの開始に対応します。この問題に関するいくつかの考えについては、付録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がXに導かれるYによって送信されたパケットを調べていることを前提としています。これは、「ソース」がYを指し、「宛先」はYのピア、つまりNでの存在を指すことを意味します。
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フレーバーの使用を想定しています（ポート番号の割り当てがオプションであることを除く）。このため、複数の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は、アドレスベースのキーイングをサポートするように構成しないでください。アドレスベースのキーイングは、1人のRSIPクライアントのみが、YとYと交換するときにアドレスNBを使用することができることを意味します。代わりに、YのSPDをセッション指向キーイング、またはユーザー指向キーイング[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実装[GUPTA]によって満たされない追加の要件を課します。
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.
最小限のIKE実装（フェーズI認証用の事前共有キーを使用してメインモードのみを実装する）は、動的に割り当てられたアドレスを持つリモートホストでは使用できないことに注意してください。IKE Responder（Gateway）は、後者の3番目のメインモードメッセージ（フェーズ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]:
IKEパケットは通常、ソースと宛先の両方でUDPポート500で運ばれますが、短命ソースポートの使用は排除されていません[ISAKMP]。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をサポートする必要がありますが、他のポート番号も許可されています。実装でIKEの他のポート500を許可する場合、500ではなくIDペイロードで報告されているポート番号の値（「任意のポート」を意味する）の値を設定します。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の実装は、割り当てられたSPIおよびおそらくRSIPクライアントから他のパラメーターを受け取るために、少なくともある程度の周辺の意味で、RSIPに注意しなければならないことに注意することが重要です。したがって、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クライアントとサーバーは、イニシエーター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がイニシエーターCookieの相互に快適な値に到達すると、xはそれを使用してIKEパケットを作成し、RSIPサーバーNをトンネルします。
The minimum tuple negotiated via RSIP, and used for demultiplexing incoming IKE responses from Y at the RSIP server N, is:
RSIPを介して交渉され、RSIPサーバーnでのYからのIKE応答の再誘導に使用される最小タプルは次のとおりです。
- 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つの問題はまだ残っています。NBを介してパケットをXに送信することになっていることをどのように知っていますか？yはrsip-awareではありませんが、間違いなくike-awareです。yは、アドレスNBから来るikeパケットを見ます。yがパケットのソースアドレス（NB）に基づいてIKEピアの身元を誤って導き出すのを防ぐために、xはクライアント識別子をyと交換する必要があります。
- IDii, IDir if in Phase 1, and
- イディ、フェーズ1の場合はIDIR、および
- 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は、SPI値に到達してYからXへのIPSECセキュリティアソシエーションを示す必要があります。NとXがSPIが両方の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パケット（それぞれAHおよびESPのプロトコル51および50）[kent98a、kent98b]をxに送信します。
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に到着します。それらは、以下の非脱重フィールドの最小タプルに基づいて非gultiplexedされます。
- 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サポートを実装している場合、クライアントに送信されたREGISTE_RESPONSEメソッドのIPSECを使用したRSIPメソッドパラメーターを含めることができます。この方法には3の値が割り当てられます。
3 RSIP with IPsec (RSIPSEC)
3 rsip with ipsec（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が相互に一意のイニシエーター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を使用するリソースを最初に取得することで構成されています（assight_request_rsipsecを介して以下に定義します）。次に、イニシエーターCookieをランダムに選択し、最初のパケットをyに送信します。Xの割り当てられたアドレス（NB）ごとに一意性のクッキー。Cookieがユニークな場合、nはこのCookieを使用して、このRSIPバインディングでxとyの間のすべての後続のパケットを使用できます。Cookieが一意でない場合、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クライアントは、これらの再送信ごとに異なるイニシエーターCookieを使用する必要があります。
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:
NでのイニシエーターCookie衝突の確率とXによるその後の再送信の確率は、64ビットのCookieスペースを考えると無限です。誕生日のパラドックスによると、同じRSIPサーバーを通過する6億4,000万の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回の往復が必要になる可能性は非常に低いです。
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とESPをサポートするために必要なプロトコル拡張を定義します。必要なメッセージタイプは、assight_request_rsipsecとassight_response_rsipsecです。
ASSIGN_REQUEST_RSIPSEC
assight_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.
assight_request_rsipsecメッセージは、rsipクライアントがipsecパラメーターの割り当てを要求するために使用されます。RSIPクライアントは、1つのメッセージで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クライアントがIPSECを使用してTCPまたはUDPアプリケーションを保護したい場合は、ポート範囲パラメーターを使用する必要があります（付録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.
次のメッセージ固有のエラー条件が存在します。assile_request_rsip_ipsecのエラー動作は、すべての非IPSECエラーに対してassight_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パラメーターが「気にしない」値ではなく、RSIPサーバーが要求されたアドレスとSPIタプルが使用されているために割り当てられない場合、RSIPサーバーはIPSEC_SPI_INUSEエラーを含むERROR_RESPONSEで応答する必要があります。
ASSIGN_RESPONSE_RSIPSEC
assight_response_rsipsec
The ASSIGN_RESPONSE_RSIPSEC message is used by an RSIP server to assign parameters to an IPsec-enabled RSIP client.
assight_response_rsipsecメッセージは、RSIPサーバーによって使用され、IPSEC対応の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.
RSIPクライアントがAssign_request_rsipsecメッセージで送信して、特定の数のSPIを割り当てるように要求します。また、rsipサーバーからassight_response_rsipsecメッセージでクライアントに送信されます。
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」フィールドは、1つ以上のSPIをエンコードします。単一のSPIが指定されている場合、数字フィールドの値は1で、数字フィールドに続くSPIフィールドが1つあります。複数のSPIが指定されている場合、数字フィールドの値は含まれるSPIの総数を示し、パラメーターは2つのフォームのいずれかを取ることができます。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.
場合によっては、1つ以上のスピスに「気にしない」値を指定する必要があります。これは、長さフィールドを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.
- assight_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アドレスの1つの要素のみを持つタプルに基づいています。このドキュメントは、タプルにより多くの要素を追加するだけです。
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よりも安全でarbitrary意的ではありません。
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サーバーでも一意でなければなりません。RSIPクライアントが利用できるSPI値の範囲を制限すると、エントロピーはわずかに。
Many thanks to Bernard Aboba, Vipul Gupta, Jeffrey Lo, Dan Nessett, Gary Jaszewski and Prakash Iyer for helpful discussions.
Bernard Aboba、Vipul Gupta、Jeffrey Lo、Dan Nessett、Gary Jaszewski、Prakash Iyerに有益な議論に感謝します。
References
参考文献
[Gupta] Gupta, V., "Secure Remote Access over the Internet using IPSec", Work in Progress.
[Gupta] Gupta、V。、「IPSECを使用してインターネット上のリモートアクセスを保護する」、進行中の作業。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Ike] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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] Maughan、D.、Schertler、M.、Schneider、M.、J。Turner、「Internet Security Association and Key Management Protocol（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] ted 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] Kent、S。and R. Atkinson、「ip capsupsing payload」、RFC 2406、1998年11月。
[Kent98b] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[Kent98b] Kent、S。and R. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[Kent98c] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[Kent98c] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[Piper98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[Piper98] Piper、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] Borella、M.、Lo、J.、Grabelsky、D。、およびG. Montenegro、「レルム固有のIP：Aフレームワーク」、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] Borella、M.、Grabelsky、D.、Lo、J。およびK. Taniguchi、「Realm固有のIP：プロトコル仕様」、RFC 3103、2001年10月。
Authors' Addresses
著者のアドレス
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエルE.モンテネグロサンマイクロシステムズラボラトリーズ、ヨーロッパ29、ケミンデュヴィューチェーン38240メイランフランス
Phone: +33 476 18 80 45
EMail: gab@sun.com
Michael Borella CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
Michael Borella Commworks 3800 Golf Rd。ローリングメドウズIL 60008
Phone: (847) 262-3083 EMail: mike_borella@commworks.com
電話：（847）262-3083メール：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.
RSIPサーバーでのパケットの再退屈パケットにポートではなくSPISが使用されているという事実にもかかわらず、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を検討してください。どちらもパブリックアドレスNBを使用しており、どちらもポート80で外部サーバーYに連絡していると仮定します。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の使用に関して費用がかかります。したがって、RSIPクライアントの利便性として、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 assight_request_rsipsec
23 ASSIGN_RESPONSE_RSIPSEC
23 assile_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.
すべてのTCP/UDPポート番号が暗号化されるため、クライアントがエンドツーエンド暗号化にESPを使用する場合、RSIPサーバーはローカルまたはリモートマイクロフローポリシーを実施できない場合があります。ただし、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 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クライアントがIPSECセキュリティ協会（SA）を確立したリモートホストが再キー[Jenkins]になります。IKEポート500がクライアントが使用し、RekeyがISAKMPフェーズ1（ISAKMP SA）の場合、RSIPの問題は問題です。問題は、リモートホストが新しいイニシエーターCookieを使用してIKEパケットをポート500に送信することです。RSIPサーバーにはCookieのマッピングがなく、パケットをドロップする必要があります。これにより、RSIPクライアントとリモートホストの間のISAKMP 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クライアントはイニシエーター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.
- 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にはナプト、機能があります。現在、X1はピアYを使用してIPSEC SAを確立したいと考えています。これは、このドキュメントで定義されているIPSECサポートで拡張されたRSIPサーバーでもあるため、これは可能です。YはIPSEC対応ですが、RSIPが認識していません。これはおそらく最も典型的なアプリケーションシナリオです。
The above is equally applicable in the ROBO (remote office, branch office) scenario.
上記は、ロボ（リモートオフィス、ブランチオフィス）シナリオに等しく適用できます。
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セッションを確立するために使用されます。たとえば、オフィスにいるときのリモートユーザーの通常のデスクトップになる可能性があります。コーポレートファイアウォールコンプレックスは、RSIPを使用して、内部システムと外部システム間のIPSECトラフィックを選択的に有効にします。
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.
ピアYがIKE交換を500以外のポートに開始できる場合、IKE接続の着信ははるかに簡単にサポートできます。この場合、RSIPクライアントはAssight_Request_rsap-IPを介してRSIPサーバーにそのポートを割り当てます。あるいは、RSIPクライアントがagasion_request_rsa-ipを介してRSIPサーバーでIPアドレスを割り当てることができる場合、yはそのアドレスでIKE Exchangeをポート500に開始するだけです。
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サーバーとそのすべてのクライアントが共有する必要があるアドレスNBが1つしかなく、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 Responder（RSIPクライアント）のアイデンティティではなく、イニシエーター（Y）のアイデンティックではないことに注意してください。その理由は、IKEフェーズ1では、送信者が意図した受信者のアイデンティティではなく、独自のアイデンティティを含めることができるためです（両方とも、フェーズ2で許可されています）。さらに、RSIPサーバーがDemultiplexorとして使用できるようにするには、IDは最初の着信パケットで明確でなければなりません。これは、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イニシエーターのIDに基づいてRSIPサーバーの逆流が含まれるため、一度に1人のRSIPクライアントのみが特定のピアYからのフィールドリクエストに関心を登録できると考えられます。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サーバーが着信SPI値に同意し、クイックモードの一部としてピアYに通信します。
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セッションの開始に備えることさえ可能かもしれません。このようなメカニズムにより、いつでも複数のRSIPクライアントが利用可能になり、それぞれが不特定のピアからのIKE開始に応答できるようになります。ただし、このようなDNSクエリは発生することは保証されていません。たとえば、RSIPサーバーが特定のIke Peerの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イニシエーターの身元に頼らなければならないことで暗示される制限のため、着信接続をサポートする唯一の実用的な方法は、ピアYが500以外のポートでIKEセッションを開始することです。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。