RFC3554 日本語訳

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

Bellovinがコメントのために要求するワーキンググループS.をネットワークでつないでください: 3554年のJ.Ioannidisカテゴリ: 標準化過程AT&T研究室--研究A.Keromytisコロンビア大学R.スチュワートコクチマス2003年7月

  On the Use of Stream Control Transmission Protocol (SCTP) with IPsec

IPsecとのストリーム制御伝動プロトコル(SCTP)の使用に関して

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

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.

このドキュメントはIPsec(RFC2401)とインターネット・キー・エクスチェンジ(IKE)(RFC2409)がSCTP(RFC2960)がトラフィックであると機密保護することにおける彼らの使用を容易にするという機能条件書について説明します。

1.  Introduction

1. 序論

   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プロトコル(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 Security Associations(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.

このドキュメントはIPsecとIKEがSCTPがトラフィックであると機密保護することにおける彼らの使用を容易にするという機能条件書について説明します。 特に、私たちはソースの多様性のために対応するIPsec処理と単一のSCTP関係に関連している送付先アドレスにおけるIKE[RFC2409]と実装選択における、新しいIDタイプの形で追加的支援について議論します。

Bellovin, et. al.           Standards Track                     [Page 1]

RFC 3554                    SCTP with IPsec                    July 2003

et Bellovin、アル。 規格は2003年7月にIPsecと共にRFC3554SCTPを追跡します[1ページ]。

1.1.  Terminology

1.1. 用語

   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].

そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[RFC-2119]で説明されるように解釈されることになっていてください、」であるべきです

2.  SCTP over IPsec

2. IPsecの上のSCTP

   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.)

SCTPフレームのためのセキュリティー・サービスを提供するのにAuthentication Header[RFC2402]かEncapsulating Security有効搭載量[RFC2406]プロトコルを利用するとき、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.

セレクタとしてそれらのSecurity Policy Database(SPD)でIANAによって割り当てられるようにIPsec実装は既に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はこれを収容するはずであることができます。 簡単で、高価な道は交渉されたソース/送付先アドレスの各組のために1SPDのエントリーを作成することです。 より良いアプローチはそれぞれの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、Securityプロトコル)によって特定されます。 三つ子(目的地Address、SPI、Securityプロトコル)を使用するSecurity Association Database(SADB)のルックアップはDestination Addressが交渉された同輩アドレスのいずれでもあるところに同じSAを返さなければなりません。

Bellovin, et. al.           Standards Track                     [Page 2]

RFC 3554                    SCTP with IPsec                    July 2003

et Bellovin、アル。 規格は2003年7月にIPsecと共にRFC3554SCTPを追跡します[2ページ]。

3.  SCTP and IKE

3. SCTPとIKE

   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がPhase2(迅速なMode)交換で効率的にこれらを交渉するのは、可能であるに違いありません。 簡単なアプローチはソースと送付先アドレスの各組み合わせのために1組のIPsec SAsを交渉することです。 これは多くのSAsをもたらして、その結果、時間(これらを交渉することにおける)とメモリを浪費できます。 IKEのすべての現在の実装がこの機能性をサポートします。 しかしながら、Phase2の複数のセレクタを指定するためのメソッドは効率目的のために望ましいです。 このドキュメントによる順応は、実装がこのセクションの残りにおけるガイドラインを固く守るのを必要とします。

   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の新しいタイプを定義してください。 したがって、タイプID_LISTにはSCTP協会のためのIKE Phase2Initiator IDがあるかもしれません。(順番にLISTはInitiatorアドレスについて説明する必要なだけのID_IPV4_ADDR IDを含むでしょう)。 同様にResponder IDのために。 SCTPとの使用のためにSAsを設立するとき、他のセレクタタイプが使用されるかもしれないことに注意してください、そして、使用する必要は全くなければ、それぞれのSCTP終点への複数のアドレスを交渉してください(すなわち、1つのアドレスだけが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ペイロードの中に現れることができません。 ID_LIST IDの中に[RFC2407]で定義されたIDタイプのいずれも含むことができます。 ID_LIST IDに含まれたそれぞれのIDは完全なIdentification有効搭載量ヘッダーを含まなければなりません。

   The following diagram illustrates the content of an ID_LIST ID
   payload that contains two ID_FQDN payloads.

以下のダイヤグラムは2個のID_FQDNペイロードを含むID_LIST IDペイロードの内容を例証します。

Bellovin, et. al.           Standards Track                     [Page 3]

RFC 3554                    SCTP with IPsec                    July 2003

et Bellovin、アル。 規格は2003年7月にIPsecと共にRFC3554SCTPを追跡します[3ページ]。

    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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 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.

Responderは含まれているID(FQDN1とFQDN2のための)のどれかにおけるNext有効搭載量分野を無視しなければなりません。 含まれている有効搭載量の有効搭載量Length、ID Type、Protocol ID、およびPort分野は適切な値に用意ができるべきです。 ID_LIST有効搭載量のProtocol IDとPort分野をInitiatorによってゼロに設定されるはずであり、Responderは無視しなければなりません。

   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_LIST IDの中に異なったタイプのID(例えば、ID_FQDNとID_IPV4_ADDR)を含むことができます。 ID_LIST IDペイロードに含まれていたIDタイプが文脈で無効であるならID_LIST IDが使用されている、全体のID_LISTが誤っていると考えられるべきです、例えば、IKEクィックMode交換の間、ID_FQDNとID_IPV4_ADDRを含むID_LIST IDペイロードを受け取ります、とResponderはメッセージ(代わりに単にID_FQDNを受け取るならそれが示す同じ振舞い)のInitiatorと停止処理に欠点に合図するはずです。

   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がPhase2セレクタを有効にすることができるように、Phase1の間、十分な情報を交換するのは可能でなければなりません。 現在、IKEは直接2人の同輩が互いに話す簡単なケースに対応できます、それらのIPアドレスに対応するPhase1IDを使用することによって、そして、同じであるそれらをコード化するのが認証するのにおいて中古の証明書のSubjAltNameでPhaseが1回の交換であると扱います。 より複雑なシナリオのために、対外政策(または、ある他のメカニズム)は、Phase2セレクタとSAパラメタを有効にするために相談される必要があります。 Phase2セレクタに提示されたすべてのアドレスを有効にしなければなりません。 すなわち、十分に証拠を提示しなければなりません。

Bellovin, et. al.           Standards Track                     [Page 4]

RFC 3554                    SCTP with IPsec                    July 2003

et Bellovin、アル。 規格は2003年7月にIPsecと共にRFC3554SCTPを追跡します[4ページ]。

   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.).

Initiatorが認可される応答者はPhase2セレクタに現れるすべてのアドレスのためにトラフィックを受けます。 Phase1(できれば)の間に交換された証明書からこの証拠を得ることができます。 さもなければ、それはバンドの外を通した後天的な手段であるに違いありません(例えば管理者によって構成された方針メカニズムなど)。

   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) 複数のPhase1IDを指定してください。(IDは、Phase2パラメタ(特にPhase2セレクタ)を有効にするのに使用されます)。 ID_LIST IDタイプについての議論に続いて、複数のPhase1IDを指定するのに同じメソッドを使用するのは可能です。

      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) 様々なPhase1IDを認証してください。 あらかじめ共有された主要な認証を使用して、これはすべての許容できる同輩Phase1IDに同じ共有されたキーを関連づけることによって、可能です。 証明書の場合では、私たちは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を含むことができます。 これが既に可能であるので、それは都合のよいソリューションです、そして、どんなconformant実装もこれをサポートしなければなりません。

            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ペイロードにおけるPhase1交換の間、渡されるかもしれません。 また、この特徴は現在の仕様でサポートされます。 IKE Phase1交換単位で1つの署名だけを発行してもよいので、すべての証明書がそれらのSubjectと同じキーを含むのが必要です。 しかしながら、このアプローチは(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実装が確かめる必要があるどちらかでは、同輩の正当性は、Phaseが1つのIDであると主張しました、交換の上に受け取られたそのようなすべての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関係に関連しているアドレスの変更をサポートしませんが(後者が使用中ですが)、それは将来サポートされるかもしれない特徴です。 アドレスのセットが非常にしばしば変化するというわけではないなら、適切なセレクタとSAsを証明できます完全なPhase1とPhase2交換をする。

Bellovin, et. al.           Standards Track                     [Page 5]

RFC 3554                    SCTP with IPsec                    July 2003

et Bellovin、アル。 規格は2003年7月にIPsecと共にRFC3554SCTPを追跡します[5ページ]。

   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に関する最後の問題はInitiatorによるPhase2セレクタ(ID)の初期の申し出に関係します。 現在のIKE仕様に従って、ResponderはIDが最初のメッセージで受けたクィックModeの2番目のメッセージを送らなければなりません。 したがって、Initiatorが既にこのSCTP協会に関連しているすべてのSelectorsを知ると思われます。 多くの場合しかしながら、Responderには、様々なアドレスに関する、より正確な知識があります。 したがって、設立されたIPsec Selectorsは潜在的に不十分であるか、または不正確である場合があります。

   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.

Selectorsの提案されたセットがResponderの観点から正確でないなら、後者は新しいクィックMode交換を始めることができます。 この新しいクィックMode交換では、InitiatorとResponderの役割は逆にされました。 新しいInitiatorは、古いクィックModeメッセージからSAとSelectorsをコピーして、現実を合わせるようにSelectorsのセットを変更しなければなりません。 すべてのSCTPをサポートしているIKE実装がこれができなければなりません。

4.  Security Considerations

4. セキュリティ問題

   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が、彼のアドレスが同輩AとBの間のSCTPセッションに加えられるべきであり、さらなるコミュニケーションに使用されると主張するトラフィックリダイレクション攻撃のために可能性を開けます。 この様に、X.はAとBとの間にトラフィックを見ることができます。If Xが通信路にAとBとの間になくて、SCTPは新しい攻撃能力を彼に提供します。 したがって、SCTPセッションのそのようなすべてのアドレス最新版が認証されるべきです。 IKEが使用のためにこれらのセッションでIPsec SAsを交渉するので、イケはPhase1交換の間にそれに提示された証明書を有効にすることを通して、または、何らかのバンドで出ているメソッドを通して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.

Phase2交換におけるResponderはInitiatorのPhase2セレクタに現れるすべてのアドレスのためにトラフィックを受けるInitiatorの権威について確かめなければなりません。 すなわち、首尾よくそうすることができるだれでもPhaseを設立します。そうしないのがResponderのどんな有効な同輩も考慮するだろう、(Responderと1SA) それらのアドレスを要求することによっていかなる他の有効な同輩のトラフィックも見るために。

5.  IANA Considerations

5. IANA問題

   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識別タイプ」登録にインターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)識別子テーブルからID_LIST(セクション3では、定義される)の規定番号12を持っています。

Bellovin, et. al.           Standards Track                     [Page 6]

RFC 3554                    SCTP with IPsec                    July 2003

et Bellovin、アル。 規格は2003年7月にIPsecと共にRFC3554SCTPを追跡します[6ページ]。

6.  Intellectual Property Rights Notice

6. 知的所有権通知

   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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC
              2402, November 1998.

[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。

   [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

[RFC2406]ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。

   [RFC2407]  Piper, D., "The Internet IP Security Domain of
              Interpretation for ISAKMPD", RFC 2407, November 1998.

[RFC2407]パイパー、D.、「ISAKMPDのための解釈のインターネットIPセキュリティー領域」、RFC2407、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.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは議定書を作ります」、RFC2408、1998年11月。

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 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.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年10月。

Bellovin, et. al.           Standards Track                     [Page 7]

RFC 3554                    SCTP with IPsec                    July 2003

et Bellovin、アル。 規格は2003年7月にIPsecと共にRFC3554SCTPを追跡します[7ページ]。

Authors' Addresses

作者のアドレス

   Steven M. Bellovin
   AT&T Labs - Research
   180 Park Avenue
   Florham Park, New Jersey 07932-0971

スティーブンM.Bellovin AT&T研究室--研究180パーク・アベニューFlorham公園、ニュージャージー07932-0971

   Phone: +1 973 360 8656
   EMail: smb@research.att.com

以下に電話をしてください。 +1 8656年の973 360メール: smb@research.att.com

   John Ioannidis
   AT&T Labs - Research
   180 Park Avenue
   Florham Park, New Jersey 07932-0971

ジョンIoannidis AT&T研究室--研究180パーク・アベニューFlorham公園、ニュージャージー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

Angelos D.Keromytisコロンビア大学、CS Department515Cs Building1214アムステルダムアベニュー、Mailstop0401ニューヨーク、ニューヨーク10027-7003

   Phone: +1 212 939 7095
   EMail: angelos@cs.columbia.edu

以下に電話をしてください。 +1 7095年の212 939メール: 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

以下に電話をしてください。 +1-815-477-2127 メールしてください: rrs@cisco.com

Bellovin, et. al.           Standards Track                     [Page 8]

RFC 3554                    SCTP with IPsec                    July 2003

et Bellovin、アル。 規格は2003年7月にIPsecと共にRFC3554SCTPを追跡します[8ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or 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機能のための基金は現在、インターネット協会によって提供されます。

Bellovin, et. al.           Standards Track                     [Page 9]

et Bellovin、アル。 標準化過程[9ページ]