Network Working Group S. Bellovin
Request for Comments: 3554 J. Ioannidis
Category: Standards Track AT&T Labs - Research
A. Keromytis
Columbia University
R. Stewart
Cisco
July 2003
On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
IPsecの持つストリーム制御伝送プロトコル（SCTP）の利用について
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic.
この文書では、SCTP（RFC 2960）のトラフィックを確保する上での使用を容易にするためにIPsec（RFC 2401）およびインターネット鍵交換（IKE）（RFC 2409）のための機能要件について説明します。
The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connection-less packet network such as IP. SCTP is designed to transport PSTN signaling messages over IP networks, but is capable of broader applications.
ストリーム制御伝送プロトコル（SCTP）がIPなどのコネクションレスのパケットネットワーク上で動作する信頼性の高いトランスポートプロトコルです。 SCTPは、IPネットワーク上でシグナリングメッセージをPSTNを輸送するために設計されていますが、より広範なアプリケーションすることが可能です。
When SCTP is used over IP networks, it may utilize the IP security protocol suite [RFC2402][RFC2406] for integrity and confidentiality. To dynamically establish IPsec Security Associations (SAs), a key negotiation protocol such as IKE [RFC2409] may be used.
SCTPは、IPネットワーク上で使用する場合は、完全性と機密性のためのIPセキュリティプロトコルスイート[RFC2402] [RFC2406]を利用することができます。動的にIPsecセキュリティアソシエーション（SA）を確立するために、IKEなどの鍵ネゴシエーションプロトコル[RFC2409]は使用されてもよいです。
This document describes functional requirements for IPsec and IKE to facilitate their use in securing SCTP traffic. In particular, we discuss additional support in the form of a new ID type in IKE [RFC2409] and implementation choices in the IPsec processing to accommodate for the multiplicity of source and destination addresses associated with a single SCTP association.
この文書では、SCTPトラフィックを確保する上での使用を容易にするために、IPsecとIKEのための機能要件について説明します。特に、我々は、単一のSCTPアソシエーションに関連付けられた送信元アドレスと宛先アドレスの多数に対処するためにIPsec処理における新しいIKEのIDタイプ[RFC2409]と実装選択肢の形で追加のサポートを議論します。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC-2119].
この文書では、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[RFC-2119]に記載されているように解釈されるべきです。
When utilizing the Authentication Header [RFC2402] or Encapsulating Security Payload [RFC2406] protocols to provide security services for SCTP frames, the SCTP frame is treated as just another transport layer protocol on top of IP (same as TCP, UDP, etc.)
認証ヘッダ[RFC2402]またはカプセル化セキュリティペイロード[RFC2406] SCTPフレームのセキュリティサービスを提供するためのプロトコルを利用する場合、SCTPフレームは（等TCP、UDP、同じ）IPの上にちょうど別のトランスポート層プロトコルとして扱われます
IPsec implementations should already be able to use the SCTP transport protocol number as assigned by IANA as a selector in their Security Policy Database (SPD). It should be straightforward to extend existing implementations to use the SCTP source and destination port numbers as selectors in the SPD. Since the concept of a port, and its location in the transport header is protocol-specific, the IPsec code responsible for identifying the transport protocol ports has to be suitably modified. This, however is not enough to fully support the use of SCTP in conjunction with IPsec.
IPsec実装は、すでにセキュリティポリシーデータベース（SPD）にセレクタとしてIANAによって割り当てられたSCTPトランスポートプロトコル番号を使用することができるはずです。 SPDのセレクタとしてSCTP送信元および宛先ポート番号を使用する既存の実装を拡張することは簡単であるべきです。トランスポートヘッダ内のポートの概念、およびその位置は、プロトコル固有であるため、トランスポート・プロトコル・ポートを識別するための責任のIPsecコードは、適切に修正しなければなりません。しかし、これは完全にIPsecと一緒にSCTPの使用をサポートするのに十分ではありません。
Since SCTP can negotiate sets of source and destination addresses (not necessarily in the same subnet or address range) that may be used in the context of a single association, the SPD should be able to accommodate this. The straightforward, and expensive, way is to create one SPD entry for each pair of source/destination addresses negotiated. A better approach is to associate sets of addresses with the source and destination selectors in each SPD entry (in the case of non-SCTP traffic, these sets would contain only one element). While this is an implementation decision, implementors are encouraged to follow this or a similar approach when designing or modifying the SPD to accommodate SCTP-specific selectors.
SCTPは、送信元アドレスと宛先アドレスの組を交渉することができるので（必ずしも同じサブネットまたはアドレス範囲）単一の関連の文脈で使用されてもよい、SPDは、これを収容することができなければなりません。 、率直、かつ安価な方法は、ネゴシエート元/宛先アドレスのペアごとに1つのSPDエントリを作成することです。より良いアプローチは、各SPDエントリの送信元と宛先セレクタとアドレスのセットを関連付けることである（非SCTPトラフィックの場合には、これらのセットは、一つの要素を含むであろう）。これは実装の決定であるが、実装は、SCTP固有セレクタを収容するSPDを設計または変更するときに、このまたは同様のアプローチに従うことが奨励されます。
Similarly, SAs may have multiple associated source and destination addresses. Thus an SA is identified by the extended triplet ({set of destination addresses}, SPI, Security Protocol). A lookup in the Security Association Database (SADB) using the triplet (Destination Address, SPI, Security Protocol), where Destination Address is any of the negotiated peer addresses, MUST return the same SA.
同様に、SAは、複数の関連する送信元アドレスと宛先アドレスを有していてもよいです。したがってSAは、拡張トリプレット（{宛先アドレスの集合}、SPI、セキュリティプロトコル）によって識別されます。宛先アドレスが交渉ピアアドレスのいずれかであるトリプレット（宛先アドレス、SPI、セキュリティプロトコル）を使用して、セキュリティアソシエーションデータベース（SADB）内のルックアップは、同じSAを返さなければなりません。
There are two issues relevant to the use of IKE when negotiating protection for SCTP traffic:
SCTPトラフィックの保護を交渉するIKEの使用に関連した2つの問題があります。
a) Since SCTP allows for multiple source and destination network addresses associated with an SCTP association, it MUST be possible for IKE to efficiently negotiate these in the Phase 2 (Quick Mode) exchange. The straightforward approach is to negotiate one pair of IPsec SAs for each combination of source and destination addresses. This can result in an unnecessarily large number of SAs, thus wasting time (in negotiating these) and memory. All current implementations of IKE support this functionality. However, a method for specifying multiple selectors in Phase 2 is desirable for efficiency purposes. Conformance with this document requires that implementations adhere to the guidelines in the rest of this section.
SCTPは、SCTPアソシエーションに関連付けられた複数のソースおよび宛先ネットワークアドレスを可能にするので、IKEを効率的フェーズ2（クイックモード）と引き換えに、これらを交渉するためのA）、それが可能でなければなりません。簡単なアプローチは、送信元アドレスと宛先アドレスの組み合わせ毎のIPsec SAの一組を交渉することです。これは、不必要に大きなSAの数、従って（これらの交渉に）時間を無駄にし、メモリをもたらすことができます。 IKEのすべての現在の実装では、この機能をサポートしています。しかしながら、フェーズ2で複数のセレクタを指定するための方法は、効率の目的のために望ましいです。この文書への適合は、実装は、このセクションの残りの部分にガイドラインを遵守する必要があります。
Define a new type of ID, ID_LIST, that allows for recursive inclusion of IDs. Thus, the IKE Phase 2 Initiator ID for an SCTP association MAY be of type ID_LIST, which would in turn contain as many ID_IPV4_ADDR IDs as necessary to describe Initiator addresses; likewise for Responder IDs. Note that other selector types MAY be used when establishing SAs for use with SCTP, if there is no need to use negotiate multiple addresses for each SCTP endpoint (i.e., if only one address is used by each peer of an SCTP flow). Implementations MUST support this new ID type.
IDの再帰的な包含を可能にID、ID_LISTの新しいタイプを定義します。したがって、IKEフェーズ2イニシエータID SCTPアソシエーションのために順番にイニシエータアドレスを記述するために必要な数ID_IPV4_ADDR IDを含むであろう、型ID_LISTのものであってもよいです。同様にレスポンダIDの。 SCTPで使用するためにSAを確立する際に（すなわち、1つのアドレスだけがSCTPフローの各ピアによって使用されている場合）、各SCTPエンドポイントに対して複数のアドレスを交渉使用する必要がない場合、他のセレクタタイプは、使用されてもよいことに留意されたいです。実装は、この新しいIDの種類をサポートしなければなりません。
ID_LIST IDs cannot appear inside ID_LIST ID payloads. Any of the ID types defined in [RFC2407] can be included inside an ID_LIST ID. Each of the IDs contained in the ID_LIST ID must include a complete Identification Payload header.
ID_LIST IDがID_LISTのIDペイロード内に表示することはできません。 [RFC2407]で定義されたIDタイプのいずれかがID_LIST ID内部に含めることができます。 ID_LIST IDに含まれているIDの各々は、完全な識別ペイロードヘッダを含まなければなりません。
The following diagram illustrates the content of an ID_LIST ID payload that contains two ID_FQDN payloads.
次の図は、2つのID_FQDNペイロードを含んID_LIST IDペイロードの内容を示しています。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol ID ! Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol ID ! Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FQDN 1 Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol ID ! Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FQDN 2 Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！次ペイロード！ RESERVED！ペイロード長！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！ IDタイプ！プロトコルID！港 ！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！次ペイロード！ RESERVED！ペイロード長！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！ IDタイプ！プロトコルID！港 ！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜FQDN 1識別データ〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！次ペイロード！ RESERVED！ペイロード長！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！ IDタイプ！プロトコルID！港 ！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜FQDN 2識別データ〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
The Next Payload field in any of the included IDs (for FQDN 1 and FQDN 2) MUST be ignored by the Responder. The Payload Length, ID Type, Protocol ID, and Port fields of the included Payloads should be set to the appropriate values. The Protocol ID and Port fields of the ID_LIST Payload should be set to zero by the Initiator and MUST be ignored by the Responder.
（FQDN 1及びFQDN 2）を含むIDのいずれかの次のペイロードフィールドは、レスポンダによって無視されなければなりません。ペイロード長、含まれるペイロードのIDタイプ、プロトコルID、およびポートフィールドが適切な値に設定する必要があります。 ID_LISTペイロードのプロトコルIDとポートのフィールドは、イニシエータによってゼロに設定されるべきであるとレスポンダで無視しなければなりません。
Different types of IDs (e.g., an ID_FQDN and an ID_IPV4_ADDR) can be included inside the same ID_LIST ID. If an ID type included in an ID_LIST ID payload is invalid in the context the ID_LIST ID is used, the whole ID_LIST should be considered to be at fault, e.g., if an ID_LIST ID payload that contains an ID_FQDN and an ID_IPV4_ADDR is received during an IKE Quick Mode exchange, the Responder should signal a fault to the Initiator and stop processing of the message (the same behavior it would exhibit if simply an ID_FQDN was received instead).
ID（例えば、ID_FQDN及びID_IPV4_ADDR）の異なるタイプが同じID_LISTのID内部に含めることができます。 ID_LIST IDペイロードに含まれるIDタイプがID_LISTのIDが使用されているコンテキストで無効である場合ID_FQDNとID_IPV4_ADDRが含まれているID_LISTのIDペイロードが中に受信した場合、全体ID_LISTは、例えば障害、であると考えるべきですIKEクイックモード交換、レスポンダは、イニシエータに障害を通知し、メッセージ（単にID_FQDN代わりに受信された場合、それが示すであろうと同じ動作）の処理を停止する必要があります。
The IANA-assigned number for the ID_LIST ID is 12.
ID_LIST IDのためのIANAによって割り当てられた数は12です。
b) For IKE to be able to validate the Phase 2 selectors, it must be possible to exchange sufficient information during Phase 1. Currently, IKE can directly accommodate the simple case of two peers talking to each other, by using Phase 1 IDs corresponding to their IP addresses, and encoding those same addresses in the SubjAltName of the certificates used to authenticate the Phase 1 exchange. For more complicated scenarios, external policy (or some other mechanism) needs to be consulted, to validate the Phase 2 selectors and SA parameters. All addresses presented in Phase 2 selectors MUST be validated. That is, enough evidence must be presented to the
B）IKEは、フェーズ2つのセレクタを検証できるようにするためには、現在フェーズ1の間に十分な情報を交換することが可能でなければならない、IKEは、直接1つのIDは、に対応する位相を使用することによって、お互いに話すつのピアの単純なケースを収容することができます自分のIPアドレス、およびフェーズ1交換を認証するために使用される証明書のSubjAltNameにそれらの同じアドレスをコードします。より複雑なシナリオでは、外部のポリシー（またはいくつかの他のメカニズムが）、フェーズ2つのセレクタとSAパラメータを検証するために、相談する必要があります。フェーズ2つのセレクタに提示されたすべてのアドレスを検証する必要があります。つまり、十分な証拠がに提示されなければなりません
Responder that the Initiator is authorized to receive traffic for all addresses that appear in the Phase 2 selectors. This evidence can be derived from the certificates exchanged during Phase 1 (if possible); otherwise it must be acquired through out-of-band means (e.g., policy mechanism, configured by the administrator, etc.).
イニシエータは、フェーズ2つのセレクタに表示されるすべてのアドレスのトラフィックを受信を許可されていることレスポンダ。この証拠は、フェーズ1（可能な場合）の間で交換証明書から誘導することができます。そうでない場合は、帯域外の手段を介して取得しなければならない（例えば、管理者によって設定されたポリシー機構、等）。
In order to accommodate the same simple scenario in the context of multiple source/destination addresses in an SCTP association, it MUST be possible to:
SCTPアソシエーションにおける複数のソース/宛先アドレスのコンテキストで同じ簡単なシナリオに対応するために、それが可能でなければなりません。
1) Specify multiple Phase 1 IDs, which are used to validate Phase 2 parameters (in particular, the Phase 2 selectors). Following the discussion on an ID_LIST ID type, it is possible to use the same method for specifying multiple Phase 1 IDs.
1）具体的にはフェーズ2つのパラメータ（フェーズ2のセレクタ）を検証するために使用される複数のフェーズ1つのIDを指定します。 ID_LIST IDタイプの議論に続いて、複数のフェーズ1つのIDを指定するための同じ方法を使用することが可能です。
2) Authenticate the various Phase 1 IDs. Using pre-shared key authentication, this is possible by associating the same shared key with all acceptable peer Phase 1 IDs. In the case of certificates, we have two alternatives:
2）様々なフェーズ1のIDを認証します。事前共有鍵認証を使用し、これは、すべての許容されるピア・フェーズ1つのIDと同一の共有キーを関連付けることによって可能です。証明書の場合は、我々は2つの方法があります。
a) The same certificate can contain multiple IDs encoded in
the SubjAltName field, as an ASN.1 sequence. Since this is
already possible, it is the preferred solution and any
conformant implementations MUST support this.
b) Multiple certificates MAY be passed during the Phase 1 exchange, in multiple CERT payloads. This feature is also supported by the current specification. Since only one signature may be issued per IKE Phase 1 exchange, it is necessary for all certificates to contain the same key as their Subject. However, this approach does not offer any significant advantage over (a), thus implementations MAY support it.
B）複数の証明書は、複数のCERTペイロードに、フェーズ1の交換時に渡すことができます。この機能は、現在の仕様でサポートされています。一つだけの署名がIKEフェーズ1つの交換毎に発行することができるので、すべての証明書が自分の件名と同じキーを格納するために、それが必要です。 （a）は、このように実装がそれをサポートするかもしれにわたりしかし、このアプローチは、任意の重要な利点を提供していません。
In either case, an IKE implementation needs to verify the validity of a peer's claimed Phase 1 ID, for all such IDs received over an exchange.
いずれの場合においても、IKE実装は、すべてのそのようなIDが交換を介して受信するために、ピアの記載フェーズ1 IDの正当性を検証する必要があります。
Although SCTP does not currently support modification of the addresses associated with an SCTP association (while the latter is in use), it is a feature that may be supported in the future. Unless the set of addresses changes extremely often, it is sufficient to do a full Phase 1 and Phase 2 exchange to establish the appropriate selectors and SAs.
SCTPは、現在（後者は使用中）SCTPアソシエーションに関連付けられているアドレスの変更をサポートしていないが、将来的にサポートすることができる機能です。アドレスのセットが非常に頻繁に変更がない限り、適切なセレクタとSAを確立するために、完全なフェーズ1とフェーズ2交換を行うのに十分です。
The last issue with respect to SCTP and IKE pertains to the initial offer of Phase 2 selectors (IDs) by the Initiator. Per the current IKE specification, the Responder must send in the second message of the Quick Mode the IDs received in the first message. Thus, it is assumed that the Initiator already knows all the Selectors relevant to this SCTP association. In most cases however, the Responder has more accurate knowledge of its various addresses. Thus, the IPsec Selectors established can be potentially insufficient or inaccurate.
SCTPとIKEに関して最後の問題は、イニシエータが、フェーズ2つのセレクタ（ID）をの最初のオファーに関係します。現在のIKE仕様に従って、レスポンダは、IDが最初のメッセージで受信したクイックモードの第2のメッセージで送信しなければなりません。したがって、イニシエータは、すでにこのSCTPアソシエーションに関連するすべてのセレクタを知っているものとします。ほとんどの場合、しかし、Responderはその様々なアドレスのより正確な知識を持っています。このように、設立されたIPsecセレクタは、潜在的に不十分または不正確になることができます。
If the proposed set of Selectors is not accurate from the Responder's point of view, the latter can start a new Quick Mode exchange. In this new Quick Mode exchange, the roles of Initiator and Responder have been reversed; the new Initiator MUST copy the SA and Selectors from the old Quick Mode message, and modify its set of Selectors to match reality. All SCTP-supporting IKE implementations MUST be able to do this.
セレクタの提案セットは、ビューのレスポンダの視点から正確でない場合、後者は、新しいクイックモード交換を開始することができます。この新しいクイックモード交換では、イニシエータとレスポンダの役割が逆転しています。新しいイニシエータは古いクイックモードメッセージからSAとセレクタをコピーして、現実に合わせて、セレクタのセットを変更する必要があります。すべてのSCTP支持IKEの実装は、これを行うことができなければなりません。
This documents discusses the use of a security protocol (IPsec) in the context of a new transport protocol (SCTP). SCTP, with its provision for mobility, opens up the possibility for traffic-redirection attacks whereby an attacker X claims that his address should be added to an SCTP session between peers A and B, and be used for further communications. In this manner, traffic between A and B can be seen by X. If X is not in the communication path between A and B, SCTP offers him new attack capabilities. Thus, all such address updates of SCTP sessions should be authenticated. Since IKE negotiates IPsec SAs for use by these sessions, IKE MUST validate all addresses attached to an SCTP endpoint either through validating the certificates presented to it during the Phase 1 exchange, or through some out-of-band method.
この文書は、新しいトランスポートプロトコル（SCTP）の文脈におけるセキュリティプロトコル（IPsec）の使用について説明します。攻撃者Xは、彼のアドレスは、ピアAとBとの間のSCTPセッションに追加されるべきであると主張し、さらに通信のために使用されるSCTPは、モビリティのために提供して、トラフィックリダイレクト攻撃の可能性を開きます。このように、AとBの間のトラフィックは、Xで見ることができ、XはAとBの間の通信経路にない場合は、SCTPは彼に新たな攻撃能力を提供しています。このように、SCTPセッションの全てのこのようなアドレスの更新は、認証されなければなりません。 IKEは、これらのセッションで使用するためのIPsec SAをネゴシエートするため、IKEは、フェーズ1の交換時に、それに提示された証明書の検証を経て、または何らかのアウトオブバンド方法を通してのいずれかSCTPエンドポイントに接続されているすべてのアドレスを検証する必要があります。
The Responder in a Phase 2 exchange MUST verify the Initiator's authority to receive traffic for all addresses that appear in the Initiator's Phase 2 selectors. Not doing so would allow for any valid peer of the Responder (i.e., anyone who can successfully establish a Phase 1 SA with the Responder) to see any other valid peer's traffic by claiming their address.
フェーズ2の交換でレスポンダはイニシエータのフェーズ2のセレクタに表示されるすべてのアドレスのトラフィックを受信するイニシエータの権限を確かめなければなりません。レスポンダの任意の有効なピアが可能になるそうではない（すなわち、成功したレスポンダでフェーズ1 SAを確立することができます誰もが）自分のアドレスを主張することにより、他の有効なピアのトラフィックを確認してください。
IANA has assigned number 12 for ID_LIST (defined in Section 3) in the "IPSEC Identification Type" registry from the Internet Security Association and Key Management Protocol (ISAKMP) Identifiers table.
IANAは、インターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）識別子テーブルから、「IPSEC識別タイプ」レジストリに（セクション3で定義された）ID_LISTの番号12を割り当てています。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Normative References
引用規格
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMPD", RFC 2407, November 1998.
"ISAKMPDための解釈のインターネットIPセキュリティー領域" [RFC2407]パイパー、D.、RFC 2407、1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998.
[RFC2408]モーガン、D.、Schertler、M.、シュナイダー、M.とJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル"、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.およびV.パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
Authors' Addresses
著者のアドレス
Steven M. Bellovin AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
スティーブン・M・ベロビンAT＆T研究所 - 研究180パークアベニューフローハムパーク、ニュージャージー州07932から0971
Phone: +1 973 360 8656 EMail: smb@research.att.com
電話：+1 973 360 8656 Eメール：smb@research.att.com
John Ioannidis AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
ジョン・P・A・ヨアニディスAT＆T研究所 - 研究180パークアベニューフローハムパーク、ニュージャージー州07932から0971
EMail: ji@research.att.com
メールアドレス：ji@research.att.com
Angelos D. Keromytis Columbia University, CS Department 515 CS Building 1214 Amsterdam Avenue, Mailstop 0401 New York, New York 10027-7003
アンゲロス・D. Keromytisコロンビア大学、CS部門515 CSビル1214年アムステルダムアベニュー、メールストップ0401ニューヨーク、ニューヨーク10027から7003
Phone: +1 212 939 7095 EMail: angelos@cs.columbia.edu
電話：+1 212 939 7095 Eメール：angelos@cs.columbia.edu
Randall R. Stewart 24 Burning Bush Trail. Crystal Lake, IL 60012
ランドールR.スチュワート24燃える柴トレイル。クリスタルレイク、IL 60012
Phone: +1-815-477-2127 EMail: rrs@cisco.com
電話：+ 1-815-477-2127 Eメール：rrs@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。