[要約] RFC 3554は、SCTPとIPsecの組み合わせの使用に関するガイドラインを提供します。その目的は、セキュリティを強化し、SCTPを使用する際のベストプラクティスを示すことです。
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.
Copyright（c）The Internet Society（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.
Stream Control Transmission Protocol（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セキュリティ協会（SAS）を動的に確立するには、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の機能要件について説明しています。特に、IKE [RFC2409]の新しいIDタイプの形で追加のサポートと、単一のSCTP協会に関連するソースおよび宛先アドレスの多様性に対応するために、IPSEC処理の実装選択について説明します。
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].
このドキュメントでは、キーワードは「可能性があります」、「必要はありません」、「オプション」、「推奨」、「必要」、「必要はありません」は、[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フレームはIP上の別のトランスポートレイヤープロトコルとして扱われます（TCP、UDPなどと同じ）
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の実装は、IANAによってセキュリティポリシーデータベース（SPD）のセレクターとして割り当てられたSCTPトランスポートプロトコル番号を既に使用できる必要があります。SCTPソースと宛先ポート番号をSPDのセレクターとして使用するために、既存の実装を拡張することは簡単です。ポートの概念とトランスポートヘッダーの位置はプロトコル固有であるため、トランスポートプロトコルポートの識別を担当する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トラフィックの場合、これらのセットには1つの要素のみが含まれます）。これは実装決定ですが、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.
同様に、SASには複数の関連ソースおよび宛先アドレスがある場合があります。したがって、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.
a) SCTPはSCTP関連に関連付けられた複数のソースおよび宛先ネットワークアドレスを許可するため、IKEはフェーズ2（クイックモード）交換でこれらを効率的にネゴシエートすることが可能である必要があります。簡単なアプローチは、ソースアドレスと宛先アドレスの組み合わせごとに1組のIPSEC SASを交渉することです。これにより、不必要に多数のSASが生じる可能性があり、時間を無駄にします（これらを交渉します）と記憶があります。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を定義します。したがって、SCTPアソシエーションのIKEフェーズ2イニシエーターIDは、ID_LISTタイプである場合があります。これには、イニシエーターアドレスを説明するために必要な数のID_IPV4_ADDR IDが含まれます。同様に、レスポンダーIDの場合。各SCTPエンドポイントの複数のアドレスをネゴシエートする必要がない場合（つまり、SCTPフローの各ピアで1つのアドレスのみが使用されている場合）、SCTPで使用するSASを確立するときに他のセレクタータイプを使用できることに注意してください。実装は、この新しい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 IDSは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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
含まれているIDのいずれかの次のペイロードフィールド（FQDN 1およびFQDN 2の場合）は、レスポンダーによって無視する必要があります。含まれるペイロードのペイロード長、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_LIST IDペイロードとID_IPV4_ADDRが含まれている場合、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 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.).
b) IKEがフェーズ2セレクターを検証できるようにするには、フェーズ1の間に十分な情報を交換できる必要があります。現在、IKEはIPに対応するフェーズ1 IDを使用して、2人のピアが互いに話し合っているという単純なケースに直接対応できます。アドレス、およびフェーズ1エクスチェンジの認証に使用される証明書のサブジャルトネームの同じアドレスをエンコードします。より複雑なシナリオのために、フェーズ2セレクターとSAパラメーターを検証するには、外部ポリシー（またはその他のメカニズム）を参照する必要があります。フェーズ2セレクターで提示されたすべてのアドレスを検証する必要があります。つまり、イニシエーターがフェーズ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.
a) 同じ証明書には、asn.1シーケンスとして、subjaltnameフィールドにエンコードされた複数のIDを含めることができます。これはすでに可能であるため、優先ソリューションであり、適合の実装はこれをサポートする必要があります。
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) 複数の証明書は、フェーズ1の交換中に、複数の証明書のペイロードで渡される場合があります。この機能は、現在の仕様でもサポートされています。IKEフェーズ1エクスチェンジごとに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仕様に従って、Responderは、IDが最初のメッセージで受信したクイックモードの2番目のメッセージを送信する必要があります。したがって、イニシエーターは、このSCTP協会に関連するすべてのセレクターをすでに知っていると想定されています。ただし、ほとんどの場合、レスポンダーはさまざまなアドレスについてより正確な知識を持っています。したがって、確立された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）の使用について説明します。SCTPは、モビリティの規定により、攻撃者XがPeers AとBの間のSCTPセッションにアドレスを追加し、さらなる通信に使用する必要があると主張するトラフィックリダイレクト攻撃の可能性を開きます。この方法で、aとbの間のトラフィックはxによって見ることができます。xがAとBの間の通信パスにない場合、SCTPは彼に新しい攻撃機能を提供します。したがって、SCTPセッションのそのようなアドレス更新はすべて認証されるべきです。IKEはこれらのセッションで使用するためにIPSEC SASを交渉しているため、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は、インターネットセキュリティ協会の「IPSEC識別タイプ」レジストリおよびキーマネジメントプロトコル（ISAKMP）識別子テーブルの「IPSEC識別タイプ」レジストリにID_LIST（セクション3で定義）の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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMPD", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPDの解釈のインターネットIPセキュリティドメイン」、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] Maughan、D.、Schertler、M.、Schneider、M.およびJ. Turner、「インターネットセキュリティ協会および主要管理プロトコル」、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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] 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、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
John Ioannidis AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
John Ioannidis AT＆T Labs -Research180 Park Avenue Florham Park、ニュージャージー07932-0971
EMail: 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.ケロミティコロンビア大学、CS部門515 CSビル1214アムステルダムアベニュー、メールストップ0401ニューヨーク、ニューヨーク10027-7003
Phone: +1 212 939 7095
EMail: angelos@cs.columbia.edu
Randall R. Stewart 24 Burning Bush Trail. Crystal Lake, IL 60012
ランドールR.スチュワート24バーニングブッシュトレイル。クリスタルレイク、イリノイ州60012
Phone: +1-815-477-2127
EMail: rrs@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。