RFC4552 日本語訳

Network Working Group                                           M. Gupta
Request for Comments: 4552                               Tropos Networks
Category: Standards Track                                       N. Melam
                                                        Juniper Networks
                                                               June 2006

コメントを求めるワーキンググループM.グプタ要求をネットワークでつないでください: 4552Troposはカテゴリをネットワークでつなぎます: 規格は2006年6月にN.Melam杜松ネットワークを追跡します。

               Authentication/Confidentiality for OSPFv3

OSPFv3のための認証/秘密性

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.

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   This document describes means and mechanisms to provide
   authentication/confidentiality to OSPFv3 using an IPv6 Authentication
   Header/Encapsulating Security Payload (AH/ESP) extension header.

このドキュメントは、IPv6 Authentication Header/要約Security有効搭載量(AH/超能力)拡張ヘッダーを使用することで認証/秘密性をOSPFv3に供給するために手段とメカニズムについて説明します。

Gupta & Melam               Standards Track                     [Page 1]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[1ページ]RFC4552認証/秘密性

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. Transport Mode vs. Tunnel Mode ..................................3
   3. Authentication ..................................................3
   4. Confidentiality .................................................3
   5. Distinguishing OSPFv3 from OSPFv2 ...............................4
   6. IPsec Requirements ..............................................4
   7. Key Management ..................................................5
   8. SA Granularity and Selectors ....................................7
   9. Virtual Links ...................................................8
   10. Rekeying .......................................................9
      10.1. Rekeying Procedure ........................................9
      10.2. KeyRolloverInterval .......................................9
      10.3. Rekeying Interval ........................................10
   11. IPsec Protection Barrier and SPD ..............................10
   12. Entropy of Manual Keys ........................................12
   13. Replay Protection .............................................12
   14. Security Considerations .......................................12
   15. References ....................................................13
      15.1. Normative References .....................................13
      15.2. Informative References ...................................13

1. 序論…2 1.1. このドキュメントで中古のコンベンション…2 2. トンネル・モードに対してモードを輸送してください…3 3. 認証…3 4. 秘密性…3 5. OSPFv2とOSPFv3を区別します…4 6. IPsec要件…4 7. 主要な管理…5 8. SA粒状とセレクタ…7 9. 仮想のリンク…8 10. Rekeyingします…9 10.1. 手順をRekeyingします…9 10.2. KeyRolloverInterval…9 10.3. 間隔をRekeyingします…10 11. IPsec保護のバリアとSPD…10 12. 手動のキーのエントロピー…12 13. 保護を再演してください…12 14. セキュリティ問題…12 15. 参照…13 15.1. 標準の参照…13 15.2. 有益な参照…13

1.  Introduction

1. 序論

   OSPF (Open Shortest Path First) Version 2 [N1] defines the fields
   AuType and Authentication in its protocol header to provide security.
   In OSPF for IPv6 (OSPFv3) [N2], both of the authentication fields
   were removed from OSPF headers.  OSPFv3 relies on the IPv6
   Authentication Header (AH) and IPv6 Encapsulating Security Payload
   (ESP) to provide integrity, authentication, and/or confidentiality.

OSPF(開いているShortest Path First)バージョン2[N1]は、セキュリティを提供するためにプロトコルヘッダーで分野のAuTypeとAuthenticationを定義します。 IPv6(OSPFv3)[N2]のためのOSPFでは、OSPFヘッダーから認証分野の両方を取り除きました。 OSPFv3は、保全、認証、そして/または、秘密性を提供するために、IPv6 Authentication Header(AH)とIPv6 Encapsulating Security有効搭載量(超能力)を当てにします。

   This document describes how IPv6 AH/ESP extension headers can be used
   to provide authentication/confidentiality to OSPFv3.

このドキュメントは認証/秘密性をOSPFv3に供給するのにどうIPv6 AH/超能力拡張ヘッダーを使用できるかを説明します。

   It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5],
   ESP [N4], the concept of security associations, tunnel and transport
   mode of IPsec, and the key management options available for AH and
   ESP (manual keying [N3] and Internet Key Exchange (IKE)[I1]).

読者がOSPFv3[N2]、AH[N5]、超能力[N4]、セキュリティ協会の概念、IPsecのトンネルと交通機関、およびAHと超能力に利用可能なかぎ管理オプション([N3]とインターネット・キー・エクスチェンジ(IKE)[I1]を合わせるマニュアル)に詳しいと思われます。

1.1.  Conventions Used in This Document

1.1. 本書では使用されるコンベンション

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

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[N7]で説明されるように本書では解釈されることであるべきですか?

Gupta & Melam               Standards Track                     [Page 2]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[2ページ]RFC4552認証/秘密性

2.  Transport Mode vs. Tunnel Mode

2. 交通機関対トンネル・モード

   The transport mode Security Association (SA) is generally used
   between two hosts or routers/gateways when they are acting as hosts.
   The SA must be a tunnel mode SA if either end of the security
   association is a router/gateway.  Two hosts MAY establish a tunnel
   mode SA between themselves.  OSPFv3 packets are exchanged between
   routers.  However, since the packets are locally delivered, the
   routers assume the role of hosts in the context of tunnel mode SA.
   All implementations conforming to this specification MUST support
   transport mode SA to provide required IPsec security to OSPFv3
   packets.  They MAY also support tunnel mode SA to provide required
   IPsec security to OSPFv3 packets.

司会しているとき、一般に、交通機関Security Association(SA)は2人のホストかルータ/ゲートウェイの間で使用されます。 セキュリティ協会のどちらかの終わりがルータ/ゲートウェイであるなら、SAはトンネルモードSAであるに違いありません。 2人のホストが自分たちの間にトンネルモードSAを設立するかもしれません。 ルータの間でOSPFv3パケットを交換します。 しかしながら、パケットが局所的に提供されるので、ルータはトンネルモードSAの文脈でホストの役割を引き受けます。 この仕様に従うすべての実装が、必要なIPsecセキュリティをOSPFv3パケットに提供するために交通機関SAをサポートしなければなりません。 また、彼らは、必要なIPsecセキュリティをOSPFv3パケットに提供するためにトンネルモードSAをサポートするかもしれません。

3.  Authentication

3. 認証

   Implementations conforming to this specification MUST support
   authentication for OSPFv3.

この仕様に従う実装はOSPFv3のために認証をサポートしなければなりません。

   In order to provide authentication to OSPFv3, implementations MUST
   support ESP and MAY support AH.

認証をOSPFv3に供給するために、実装は、超能力をサポートしなければならなくて、AHをサポートするかもしれません。

   If ESP in transport mode is used, it will only provide authentication
   to OSPFv3 protocol packets excluding the IPv6 header, extension
   headers, and options.

交通機関における超能力が使用されていると、それはIPv6ヘッダー、拡張ヘッダー、およびオプションを除いたOSPFv3プロトコルパケットに認証を提供するだけでしょう。

   If AH in transport mode is used, it will provide authentication to
   OSPFv3 protocol packets, selected portions of IPv6 header, selected
   portions of extension headers, and selected options.

交通機関によるAHが使用されていると、それはOSPFv3プロトコルパケット、IPv6ヘッダーの選択された部分、拡張ヘッダーの選択された部分、および選択されたオプションに認証を提供するでしょう。

   When OSPFv3 authentication is enabled,

OSPFv3認証が可能にされるとき

      o  OSPFv3 packets that are not protected with AH or ESP MUST be
         silently discarded.

o 静かにAHか超能力で保護されないOSPFv3パケットを捨てなければなりません。

      o  OSPFv3 packets that fail the authentication checks MUST be
         silently discarded.

o 静かに認証チェックに失敗するOSPFv3パケットを捨てなければなりません。

4.  Confidentiality

4. 秘密性

   Implementations conforming to this specification SHOULD support
   confidentiality for OSPFv3.

この仕様SHOULDに従う実装はOSPFv3のために秘密性をサポートします。

   If confidentiality is provided, ESP MUST be used.

秘密性を提供するなら、超能力を使用しなければなりません。

Gupta & Melam               Standards Track                     [Page 3]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[3ページ]RFC4552認証/秘密性

   When OSPFv3 confidentiality is enabled,

OSPFv3秘密性が可能にされるとき

      o  OSPFv3 packets that are not protected with ESP MUST be silently
         discarded.

o 静かに超能力で保護されないOSPFv3パケットを捨てなければなりません。

      o  OSPFv3 packets that fail the confidentiality checks MUST be
         silently discarded.

o 静かに秘密性チェックに失敗するOSPFv3パケットを捨てなければなりません。

5.  Distinguishing OSPFv3 from OSPFv2

5. OSPFv2とOSPFv3を区別します。

   The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89), and
   OSPF distinguishes them based on the OSPF header version number.
   However, current IPsec standards do not allow using arbitrary
   protocol-specific header fields as the selectors.  Therefore, the
   OSPF version field in the OSPF header cannot be used to distinguish
   OSPFv3 packets from OSPFv2 packets.  As OSPFv2 is only for IPv4 and
   OSPFv3 is only for IPv6, the version field in the IP header can be
   used to distinguish OSPFv3 packets from OSPFv2 packets.

OSPFv2とOSPFv3のためのIP/IPv6プロトコルTypeは同じ(89)です、そして、OSPFはOSPFヘッダーバージョン番号に基づいてそれらを区別します。 しかしながら、現在のIPsec規格で、セレクタとして任意のプロトコル特有のヘッダーフィールドを使用しません。 したがって、OSPFv2パケットとOSPFv3パケットを区別するのにOSPFヘッダーのOSPFバージョン分野を使用できません。 OSPFv2がIPv4のためだけのものであり、OSPFv3がIPv6のためだけのものであって、OSPFv2パケットとOSPFv3パケットを区別するのにIPヘッダーのバージョン分野を使用できます。

6.  IPsec Requirements

6. IPsec要件

   In order to implement this specification, the following IPsec
   capabilities are required.

この仕様を履行するために、以下のIPsec能力が必要です。

   Transport mode
      IPsec in transport mode MUST be supported. [N3]

交通機関による交通機関IPsecをサポートしなければなりません。 [N3]

   Multiple Security Policy Databases (SPDs)
      The implementation MUST support multiple SPDs with an SPD
      selection function that provides an ability to choose a specific
      SPD based on interface. [N3]

実装が特定のSPDを選ぶ能力を提供するSPD選択機能がある複数のSPDsをサポートしなければならない複数のSecurity Policy Databases(SPDs)がインタフェースを基礎づけました。 [N3]

   Selectors
      The implementation MUST be able to use source address, destination
      address, protocol, and direction as selectors in the SPD.

実装ができるに違いないセレクタはセレクタとしてSPDでソースアドレス、送付先アドレス、プロトコル、および方向を使用します。

   Interface ID tagging
      The implementation MUST be able to tag the inbound packets with
      the ID of the interface (physical or virtual) via which it
      arrived. [N3]

実装にタグ付けをするインタフェースIDはを通したそれが到着したインタフェース(物理的であるか仮想の)のIDを本国行きのパケットにタグ付けできなければなりません。 [N3]

   Manual key support
      Manually configured keys MUST be able to secure the specified
      traffic. [N3]

手動の主要なサポートManuallyは、キーが指定されたトラフィックを保証できなければならないのを構成しました。 [N3]

Gupta & Melam               Standards Track                     [Page 4]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[4ページ]RFC4552認証/秘密性

   Encryption and authentication algorithms
      The implementation MUST NOT allow the user to choose stream
      ciphers as the encryption algorithm for securing OSPFv3 packets
      since the stream ciphers are not suitable for manual keys.

ユーザが実装で選ぶことができてはいけない暗号化と認証アルゴリズムはストリーム暗号が手動のキーに適当でないのでOSPFv3にパケットを機密保護するための暗号化アルゴリズムとして暗号を流します。

      Except when in conflict with the above statement, the key words
      "MUST", "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that
      appear in the [N6] document for algorithms to be supported are to
      be interpreted as described in [N7] for OSPFv3 support as well.

そして、上の声明との闘争では、キーワード“MUST"、「必須NOT」が「必要である」ときには除いてください、“SHOULD"、「」 それがアルゴリズムがサポートされる[N6]ドキュメントに現れるなら、また、OSPFv3サポートのために[N7]で説明されるように解釈されることになっていてください。

   Dynamic IPsec rule configuration
      The routing module SHOULD be able to configure, modify, and delete
      IPsec rules on the fly.  This is needed mainly for securing
      virtual links.

ダイナミックなIPsecはルーティングモジュールSHOULDがIPsec規則を構成できて、変更して、削除する構成を統治します。ハエ。 これが主に仮想のリンクを固定するのに必要です。

   Encapsulation of ESP packet
      IP encapsulation of ESP packets MUST be supported.  For
      simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.

超能力パケットの超能力パケットIPカプセル化のカプセル化をサポートしなければなりません。 簡単さ、超能力パケットSHOULD NOTのUDPカプセル化、使用されてください。

   Different SAs for different Differentiated Services Code Points
      (DSCPs)
      As per [N3], the IPsec implementation MUST support the
      establishment and maintenance of multiple SAs with the same
      selectors between a given sender and receiver.  This allows the
      implementation to associate different classes of traffic with the
      same selector values in support of Quality of Service (QoS).

[N3]に従って異なったDifferentiated Services Code Points(DSCPs)のための異なったSAs、IPsec実装は複数のSAsの設立と与えられた送付者と受信機の間には、同じセレクタはあるメインテナンスをサポートしなければなりません。これは、実装がService(QoS)のQualityを支持して異なったクラスのトラフィックを同じセレクタ値に関連づけるのを許容します。

7.  Key Management

7. Key Management

   OSPFv3 exchanges both multicast and unicast packets.  While running
   OSPFv3 over a broadcast interface, the authentication/confidentiality
   required is "one to many".  Since IKE is based on the Diffie-Hellman
   key agreement protocol and works only for two communicating parties,
   it is not possible to use IKE for providing the required "one to
   many" authentication/confidentiality.  This specification mandates
   the usage of Manual Keying with current IPsec implementations.
   Future specifications can explore the usage of protocols like
   Kerberized Internet Negotiation of Keys/Group Secure Association Key
   Management Protocol (KINK/GSAKMP) when they are widely available.  In
   manual keying, SAs are statically installed on the routers and these
   static SAs are used to authenticate/encrypt packets.

OSPFv3はマルチキャストとユニキャストパケットの両方を交換します。 放送インタフェースの上にOSPFv3を実行している間、必要である認証/秘密性は「多くへの1」です。 IKEが2のためだけのパーティーを伝えるディフィー-ヘルマンの主要な協定プロトコルと作品に基づいているので、「多くへの1」必要な認証/秘密性を提供するのにIKEを使用するのは可能ではありません。 この仕様は現在のIPsec実装があるManual Keyingの使用法を強制します。 それらが広く利用可能であるときに、将来の仕様はキーズ/グループSecure Association Key Managementプロトコル(KINK/GSAKMP)のKerberizedインターネットNegotiationのようなプロトコルの用法を探ることができます。 手動の合わせることでは、SAsは静的にルータにインストールされて、これらの静的なSAsは、パケットを認証するか、または暗号化するのに使用されます。

   The following discussion explains that it is not scalable and is
   practically infeasible to use different security associations for
   inbound and outbound traffic to provide the required "one to many"
   security.  Therefore, the implementations MUST use manually

以下の議論でそれがスケーラブルでなく、異なったセキュリティ協会を使用するのにおいて実際に実行不可能であることがわかる、本国行き、そして、「多くへの1」必要なセキュリティを提供するアウトバウンドトラフィック。 したがって、実装は手動で使用されなければなりません。

Gupta & Melam               Standards Track                     [Page 5]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[5ページ]RFC4552認証/秘密性

   configured keys with the same SA parameters (Security Parameter Index
   (SPI), keys, etc.) for both inbound and outbound SAs (as shown in
   Figure 3).

本国行きの、そして、外国行きの両方のSAs(図3に示されるように)のための同じSAパラメタ(セキュリティParameter Index(SPI)、キーなど)がある構成されたキー。

          A                  |
        SAa     ------------>|
        SAb     <------------|
                             |
          B                  |
        SAb     ------------>|
        SAa     <------------|                 Figure 1
                             |
          C                  |
        SAa/SAb ------------>|
        SAa/SAb <------------|
                             |
                         Broadcast
                          Network

A| SAa------------>| SAb<。------------| | B| SAb------------>| SAa<。------------| 図1| C| SAa/SAb------------>| SAa/SAb<。------------| | 放送網

   If we consider communication between A and B in Figure 1, everything
   seems to be fine.  A uses security association SAa for outbound
   packets and B uses the same for inbound packets and vice versa.  Now
   if we include C in the group and C sends a packet using SAa, then
   only A will be able to understand it.  Similarly, if C sends a packet
   using SAb, then only B will be able to understand it.  Since the
   packets are multicast and they are going to be processed by both A
   and B, there is no SA for C to use so that both A and B can
   understand them.

私たちがAとBとの間に図1のコミュニケーションを考えるなら、すべてがすばらしいように思えます。 外国行きのパケットのためのセキュリティ協会SAaとBが本国行きのパケットに同じように逆もまた同様に使用する用途。 現在、私たちがグループでCを入れて、CがSAaを使用することでパケットを送ると、Aだけがそれを理解できるでしょう。 同様に、CがSAbを使用することでパケットを送ると、Bだけがそれを理解できるでしょう。 パケットがマルチキャストであり、それらがAとBの両方によって処理されるので、使用へのC SAは全くAとBの両方がそれらを理解できるように、ありません。

          A                  |
        SAa     ------------>|
        SAb     <------------|
        SAc     <------------|
                             |
          B                  |
        SAb     ------------>|
        SAa     <------------|                 Figure 2
        SAc     <------------|
                             |
          C                  |
        SAc     ------------>|
        SAa     <------------|
        SAb     <------------|
                             |
                         Broadcast
                          Network

A| SAa------------>| SAb<。------------| 嚢の<。------------| | B| SAb------------>| SAa<。------------| 図2 嚢の<。------------| | C| 嚢------------>| SAa<。------------| SAb<。------------| | 放送網

Gupta & Melam               Standards Track                     [Page 6]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[6ページ]RFC4552認証/秘密性

   The problem can be solved by configuring SAs for all the nodes on
   every other node as shown in Figure 2.  So A, B, and C will use SAa,
   SAb, and SAc, respectively, for outbound traffic.  Each node will
   lookup the SA to be used based on the source (A will use SAb and SAc
   for packets received from B and C, respectively).  This solution is
   not scalable and practically infeasible because a large number of SAs
   will need to be configured on each node.  Also, the addition of a
   node in the broadcast network will require the addition of another SA
   on every other node.

他のあらゆるノードの上のすべてのノードのために図2に示されるようにSAsを構成することによって、問題を解決できます。 そして、それで、A、B、およびCがSAa、SAbを使用する、それぞれSAc、アウトバウンドトラフィックのために。 各ノードは、ソース(それぞれパケットのためのSAbとSAcがBとCから受けた意志の使用)に基づいて使用されるためにルックアップにSAを望んでいます。 多くのSAsが、各ノードの上で構成される必要があるので、このソリューションは、スケーラブルでなくて、実際に実行不可能です。 また、放送網におけるノードの追加は他のあらゆるノードの上で別のSAの追加を必要とするでしょう。

         A                   |
        SAo     ------------>|
        SAi     <------------|
                             |
         B                   |
        SAo     ------------>|
        SAi     <------------|                 Figure 3
                             |
         C                   |
        SAo     ------------>|
        SAi     <------------|
                             |
                         Broadcast
                          Network

A| SAo------------>| サイ<。------------| | B| SAo------------>| サイ<。------------| 図3| C| SAo------------>| サイ<。------------| | 放送網

   The problem can be solved by using the same SA parameters (SPI, keys,
   etc.) for both inbound (SAi) and outbound (SAo) SAs as shown in
   Figure 3.

本国行きの(SAi)と外国行きの(SAo)SAsの両方に、図3に示されるように同じSAパラメタ(SPI、キーなど)を使用することによって、問題を解決できます。

8.  SA Granularity and Selectors

8. SA粒状とセレクタ

   The user SHOULD be given the choice of sharing the same SA among
   multiple interfaces or using a unique SA per interface.

複数のインタフェースの中で同じSAを共有することの選択を与えるか、または1インタフェースあたり1ユニークなSAを使用しているユーザSHOULD。

   OSPFv3 supports running multiple instances over one interface using
   the "Instance Id" field contained in the OSPFv3 header.  As IPsec
   does not support arbitrary fields in the protocol header to be used
   as the selectors, it is not possible to use different SAs for
   different OSPFv3 instances running over the same interface.
   Therefore, all OSPFv3 instances running over the same interface will
   have to use the same SA.  In OSPFv3 RFC terminology, SAs are per-link
   and not per-interface.

OSPFv3は、複数の実行しているインスタンスが1つ以上のインタフェースであるとOSPFv3ヘッダーに含まれた「インスタンスイド」分野を使用することでサポートします。 IPsecがセレクタとして使用されるためにプロトコルヘッダーの任意の分野をサポートしないとき、同じインタフェースをひく異なったOSPFv3インスタンスに異なったSAsを使用するのは可能ではありません。 したがって、同じインタフェースをひくすべてのOSPFv3インスタンスが同じSAを使用しなければならないでしょう。 OSPFv3 RFC用語では、SAsはインタフェースではなく、リンクです。

Gupta & Melam               Standards Track                     [Page 7]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[7ページ]RFC4552認証/秘密性

9.  Virtual Links

9. 仮想のリンク

   A different SA than the SA of the underlying interface MUST be
   provided for virtual links.  Packets sent on virtual links use
   unicast non-link local IPv6 addresses as the IPv6 source address,
   while packets sent on other interfaces use multicast and unicast link
   local addresses.  This difference in the IPv6 source address
   differentiates the packets sent on virtual links from other OSPFv3
   interface types.

基本的なインタフェースのSAを仮想のリンクに提供しなければならないのと異なったSA、。 パケットは、仮想のリンクがIPv6ソースアドレスとしてユニキャストの非リンクのローカルのIPv6アドレスを使用するのを転送しました、パケットが、他のインタフェースがマルチキャストとユニキャストリンクのローカルのアドレスを使用するのを転送しましたが。 IPv6ソースアドレスのこの違いは他のOSPFv3インターフェース型と仮想のリンクに送られたパケットを区別します。

   As the virtual link end point IPv6 addresses are not known, it is not
   possible to install SPD/Security Association Database (SAD) entries
   at the time of configuration.  The virtual link end point IPv6
   addresses are learned during the routing table computation process.
   The packet exchange over the virtual links starts only after the
   discovery of the end point IPv6 addresses.  In order to protect these
   exchanges, the routing module must install the corresponding SPD/SAD
   entries before starting these exchanges.  Note that manual SA
   parameters are preconfigured but not installed in the SAD until the
   end point addresses are learned.

仮想のリンクエンドポイントIPv6アドレスが知られていないように、構成時点でSPD/セキュリティAssociation Database(SAD)エントリーをインストールするのは可能ではありません。 仮想のリンクエンドポイントIPv6アドレスは経路指定テーブル計算プロセスの間、学習されます。 仮想のリンクの上のパケット交換はエンドポイントIPv6アドレスの発見の後にだけ始まります。 これらの交換を保護するために、これらの交換を始める前に、ルーティングモジュールは対応するSPD/SADエントリーをインストールしなければなりません。 エンドポイントアドレスが学習されるまで、手動のSAパラメタがあらかじめ設定されますが、SADにインストールされないことに注意してください。

   According to the OSPFv3 RFC [N2], the virtual neighbor's IP address
   is set to the first prefix with the "LA-bit" set from the list of
   prefixes in intra-area-prefix-Link State Advertisements (LSAs)
   originated by the virtual neighbor.  But when it comes to choosing
   the source address for the packets that are sent over the virtual
   link, the RFC [N2] simply suggests using one of the router's own
   global IPv6 addresses.  In order to install the required security
   rules for virtual links, the source address also needs to be
   predictable.  Hence, routers that implement this specification MUST
   change the way the source and destination addresses are chosen for
   packets exchanged over virtual links when IPsec is enabled.

OSPFv3 RFC[N2]によると、仮想の隣人のIPアドレスは接頭語のリストから設定された「LA-ビット」がある最初の接頭語への仮想の隣人によって溯源されたイントラ領域の接頭語リンク州Advertisements(LSAs)のセットです。 しかし、仮想のリンクの上に送られるパケットのためのソースアドレスを選ぶこととなると、RFC[N2]は、ルータの自己のグローバルなIPv6アドレスの1つを使用するのを単に示します。 また、必要なセキュリティ規則を仮想のリンクにインストールするために、ソースアドレスは、予測できる必要があります。 したがって、この仕様を履行するルータはソースと送付先アドレスがIPsecが有効にされるとき仮想のリンクの上と交換されたパケットに選ばれている方法を変えなければなりません。

   The first IPv6 address with the "LA-bit" set in the list of prefixes
   advertised in intra-area-prefix-LSAs in the transit area MUST be used
   as the source address for packets exchanged over the virtual link.
   When multiple intra-area-prefix-LSAs are originated, they are
   considered concatenated and are ordered by ascending Link State ID.

仮想のリンクの上と交換されたパケットにソースアドレスとしてイントラ領域がトランジット領域にLSAsを前に置いた状態で広告に掲載された接頭語のリストにおける「LA-ビット」セットとの最初のIPv6アドレスを使用しなければなりません。 複数のときに、イントラ領域はLSAsを前に置きます。溯源されていて、彼らが連結されていると考えられるということであり、Link州IDを昇ることによって、注文します。

   The first IPv6 address with the "LA-bit" set in the list of prefixes
   received in intra-area-prefix-LSAs from the virtual neighbor in the
   transit area MUST be used as the destination address for packets
   exchanged over the virtual link.  When multiple intra-area-prefix-
   LSAs are received, they are considered concatenated and are ordered
   by ascending Link State ID.

仮想のリンクの上と交換されたパケットに送付先アドレスとしてイントラ領域がトランジット領域の仮想の隣人からLSAsを前に置いた状態で受け取られた接頭語のリストにおける「LA-ビット」セットとの最初のIPv6アドレスを使用しなければなりません。 複数のイントラ領域接頭語-LSAsが受け取られているとき、彼らは、連結されていると考えられて、Link州IDを昇ることによって、命令されます。

   This makes both the source and destination addresses of packets
   exchanged over the virtual link predictable when IPsec is enabled.

IPsecが有効にされるとき、これで、仮想のリンクの上と交換されたソースとパケットの送付先アドレスの両方が予測できるようになります。

Gupta & Melam               Standards Track                     [Page 8]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[8ページ]RFC4552認証/秘密性

10.  Rekeying

10. Rekeyingします。

   To maintain the security of a link, the authentication and encryption
   key values SHOULD be changed periodically.

リンク、認証、および暗号化キーのセキュリティがSHOULDを評価すると主張するには、定期的に変えてください。

10.1.  Rekeying Procedure

10.1. 手順をRekeyingします。

   The following three-step procedure SHOULD be provided to rekey the
   routers on a link without dropping OSPFv3 protocol packets or
   disrupting the adjacency.

rekeyに、OSPFv3を下げることのないリンクの上のルータがパケットについて議定書の中で述べるか、そして、または隣接番組を混乱させることである以下の3ステップの手順SHOULD。

   (1) For every router on the link, create an additional inbound SA for
       the interface being rekeyed using a new SPI and the new key.

(1) リンクの上のあらゆるルータには、新しいSPIと新しいキーを使用することで「再-合わせ」られるインタフェースに追加本国行きのSAを作成してください。

   (2) For every router on the link, replace the original outbound SA
       with one using the new SPI and key values.  The SA replacement
       operation should be atomic with respect to sending OSPFv3 packets
       on the link so that no OSPFv3 packets are sent without
       authentication/encryption.

(2) リンクの上のあらゆるルータには、新しいSPIとキー値を使用することでオリジナルの外国行きのSAを1つに取り替えてください。 SA交換操作がリンクで送付OSPFv3パケットに関して原子であるべきであるので、認証/暗号化なしでOSPFv3パケットを全く送りません。

   (3) For every router on the link, remove the original inbound SA.

(3) リンクの上のあらゆるルータには、オリジナルの本国行きのSAを取り外してください。

   Note that all routers on the link must complete step 1 before any
   begin step 2.  Likewise, all the routers on the link must complete
   step 2 before any begin step 3.

いずれもステップ2を始める前にリンクの上のすべてのルータがステップ1を終了しなければならないことに注意してください。 同様に、いずれもステップ3を始める前にリンクの上のすべてのルータがステップ2を終了しなければなりません。

   One way to control the progression from one step to the next is for
   each router to have a configurable time constant KeyRolloverInterval.
   After the router begins step 1 on a given link, it waits for this
   interval and then moves to step 2.  Likewise, after moving to step 2,
   it waits for this interval and then moves to step 3.

ワンステップから次まで進行を制御する1つの方法は各ルータにはKeyRolloverIntervalが構成可能な時定数にあることです。 ルータが与えられたリンクにおけるステップ1を始めた後に、それは、この間隔の間、待っていて、次に、ステップ2に移行します。 同様に、それは、ステップ2に移行した後に、この間隔の間、待っていて、次に、ステップ3に移行します。

   In order to achieve smooth key transition, all routers on a link
   should use the same value for KeyRolloverInterval and should initiate
   the key rollover process within this time period.

滑らかな主要な変遷を達成するために、リンクの上のすべてのルータが、KeyRolloverIntervalに同じ値を使用するべきであり、この期間中に主要なロールオーバープロセスを開始するべきです。

   At the end of this procedure, all the routers on the link will have a
   single inbound and outbound SA for OSPFv3 with the new SPI and key
   values.

この手順の終わりでは、リンクの上のすべてのルータが新しいSPIとキー値と共にOSPFv3のための独身の本国行きの、そして、外国行きのSAを持つでしょう。

10.2.  KeyRolloverInterval

10.2. KeyRolloverInterval

   The configured value of KeyRolloverInterval should be long enough to
   allow the administrator to change keys on all the OSPFv3 routers.  As
   this value can vary significantly depending upon the implementation
   and the deployment, it is left to the administrator to choose an
   appropriate value.

KeyRolloverIntervalの構成された値は管理者がすべてのOSPFv3ルータで転調するのを許容できるくらい長いはずです。 この値が実装によって、展開をかなり変えることができるのに従って、それが適切な値を選ぶのが管理者に残されます。

Gupta & Melam               Standards Track                     [Page 9]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[9ページ]RFC4552認証/秘密性

10.3.  Rekeying Interval

10.3. 間隔をRekeyingします。

   This section analyzes the security provided by manual keying and
   recommends that the encryption and authentication keys SHOULD be
   changed at least every 90 days.

このセクションは、手動の合わせることで提供されたセキュリティを分析して、暗号化と認証キーSHOULDが少なくともあらゆる90日間単位で変えられることを勧めます。

   The weakest security provided by the security mechanisms discussed in
   this specification is when NULL encryption (for ESP) or no encryption
   (for AH) is used with the HMAC-MD5 authentication.  Any other
   algorithm combinations will at least be as hard to break as the ones
   mentioned above.  This is shown by the following reasonable
   assumptions:

この仕様で議論したセキュリティー対策によって提供される中で最も弱いセキュリティはNULL暗号化(超能力のための)を使用しますが、どんな暗号化(AHのための)もHMAC-MD5認証と共に使用されない時です。 いかなる他のアルゴリズム組み合わせも少なくとも壊しにくいように前記のようにものと同じくらいなるでしょう。 これは以下の妥当な想定で示されます:

      o  NULL Encryption and HMAC-SHA-1 Authentication will be more
         secure as HMAC-SHA-1 is considered to be more secure than
         HMAC-MD5.

o HMAC-SHA-1がHMAC-MD5より安全であると考えられるとき、NULL EncryptionとHMAC-SHA-1 Authenticationは、より安全になるでしょう。

      o  NON-NULL Encryption and NULL Authentication combination is not
         applicable as this specification mandates authentication when
         OSPFv3 security is enabled.

o OSPFv3セキュリティが可能にされるとき、この仕様が認証を強制するとき、NON-NULL EncryptionとNULL Authentication組み合わせは適切ではありません。

      o  Data Encryption Security (DES) Encryption and HMAC-MD5
         Authentication will be more secure because of the additional
         security provided by DES.

o データEncryption Security(DES)暗号化とHMAC-MD5 AuthenticationはDESによって提供された追加担保で、より安全になるでしょう。

      o  Other encryption algorithms like 3DES and the Advanced
         Encryption Standard (AES) will be more secure than DES.

o 3DESとエー・イー・エス(AES)のような他の暗号化アルゴリズムはDESよりさらに安全になるでしょう。

   RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5
   signature option.  The analysis provided in RFC 3562 is also
   applicable to this specification as the analysis is independent of
   data patterns.

RFC3562[I4]はTCP MD5署名オプションのための「再-合わせ」る要件を分析します。 また、分析がデータパターンから独立しているようにRFC3562に提供された分析もこの仕様に適切です。

11.  IPsec Protection Barrier and SPD

11. IPsec保護のバリアとSPD

   The IPsec protection barrier MUST be around the OSPF protocol.
   Therefore, all the inbound and outbound OSPF traffic goes through
   IPsec processing.

OSPFプロトコルの周りにIPsec保護バリアがあるに違いありません。 したがって、すべての本国行きの、そして、外国行きのOSPFトラフィックがIPsec処理に直面しています。

   The SPD selection function MUST return an SPD with the following rule
   for all the interfaces that have OSPFv3
   authentication/confidentiality disabled.

SPD選択機能は以下の規則でOSPFv3認証/秘密性を無効にするすべてのインタフェースにSPDを返さなければなりません。

      No.  source       destination       protocol        action
      1     any            any              OSPF          bypass

No.ソース目的地プロトコル動作1、どんなOSPFも迂回させるいずれも

Gupta & Melam               Standards Track                    [Page 10]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[10ページ]RFC4552認証/秘密性

   The SPD selection function MUST return an SPD with the following
   rules for all the interfaces that have OSPFv3
   authentication/confidentiality enabled.

SPD選択機能は以下の規則でOSPFv3認証/秘密性を可能にするすべてのインタフェースにSPDを返さなければなりません。

      No.  source       destination       protocol        action
      2   fe80::/10        any             OSPF           protect
      3   fe80::/10        any       ESP/OSPF or AH/OSPF  protect
      4   src/128        dst/128           OSPF           protect
      5   src/128        dst/128     ESP/OSPF or AH/OSPF  protect

No.ソース目的地プロトコル動作2fe80:、:/、10 どんなOSPFも3fe80を保護します:、:/、どんな超能力/OSPFやAH/OSPFも保護する10、4src/128dst/128OSPFが5src/128dst/128超能力/OSPFを保護するか、またはAH/OSPFは保護します。

   For rules 2 and 4, action "protect" means encrypting/calculating
   Integrity Check Value (ICV) and adding an ESP or AH header.  For
   rules 3 and 5, action "protect" means decrypting/authenticating the
   packets and stripping the ESP or AH header.

規則2と4、動作のために、「保護してください」は、Integrity Check Value(ICV)について暗号化するか、または計算して、超能力かAHヘッダーを加えることを意味します。 規則3と5、動作のために、「保護してください」は、パケットを解読するか、または認証して、超能力かAHヘッダーを裸にすることを意味します。

   Rule 1 will bypass the OSPFv3 packets without any IPsec processing on
   the interfaces that have OSPFv3 authentication/confidentiality
   disabled.

規則1はOSPFv3認証/秘密性を無効にするインタフェースにおける少しもIPsec処理なしでOSPFv3パケットを迂回させるでしょう。

   Rules 2 and 4 will drop the inbound OSPFv3 packets that have not been
   secured with ESP/AH headers.

規則2と4は超能力/AHヘッダーと共に機密保護されていない本国行きのOSPFv3パケットを下げるでしょう。

   ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet
   secured with ESP or AH.

規則3と5による超能力/OSPFかAH/OSPFが、それが超能力かAHと共に機密保護されたOSPFパケットであることを意味します。

   Rules 2 and 3 are meant to secure the unicast and multicast OSPF
   packets that are not being exchanged over the virtual links.

規則2と3は、ユニキャストとマルチキャストが仮想のリンクの上と交換されていないOSPFパケットであると、機密保護することになっています。

   Rules 4 and 5 are meant to secure the packets being exchanged over
   virtual links.  These rules are installed after learning the virtual
   link end point IPv6 addresses.  These rules MUST be installed in the
   SPD for the interfaces that are connected to the transit area for the
   virtual link.  These rules MAY alternatively be installed on all the
   interfaces.  If these rules are not installed on all the interfaces,
   clear text or malicious OSPFv3 packets with the same source and
   destination addresses as the virtual link end point IPv6 addresses
   will be delivered to OSPFv3.  Though OSPFv3 drops these packets as
   they were not received on the right interface, OSPFv3 receives some
   clear text or malicious packets even when the security is enabled.
   Installing these rules on all the interfaces ensures that OSPFv3 does
   not receive these clear text or malicious packets when security is
   enabled.  On the other hand, installing these rules on all the
   interfaces increases the processing overhead on the interfaces where
   there is no other IPsec processing.  The decision of whether to
   install these rules on all the interfaces or on just the interfaces
   that are connected to the transit area is a private decision and
   doesn't affect the interoperability in any way.  Hence it is an
   implementation choice.

規則4と5は仮想のリンクの上と交換されるパケットを機密保護することになっています。 仮想のリンクエンドポイントIPv6アドレスを学んだ後に、これらの規則はインストールされます。 仮想のリンクのためにトランジット領域に関連づけられるインタフェースのためにこれらの規則をSPDにインストールしなければなりません。 あるいはまた、これらの規則はすべてのインタフェースにインストールされるかもしれません。 これらの規則がすべてのインタフェースにインストールされないなら、仮想のリンクエンドポイントIPv6アドレスがOSPFv3に提供されるとき、同じソースと送付先アドレスでテキストか悪意があるOSPFv3パケットをきれいにしてください。 それらが正しいインタフェースに受け取られなかったようにOSPFv3はこれらのパケットを下げますが、セキュリティが可能にされるときさえ、OSPFv3はいくつかのクリアテキストか悪意があるパケットを受け取ります。 すべてのインタフェースにこれらの規則をインストールするのは、セキュリティが可能にされるとき、OSPFv3がこれらのクリアテキストか悪意があるパケットを受け取らないのを確実にします。 他方では、すべてのインタフェースにこれらの規則をインストールすると、処理オーバヘッドは処理するいいえ他のIPsecがあるインタフェースで増強されます。 すべてのインタフェース、または、まさしくトランジット領域に関連づけられるインタフェースにこれらの規則をインストールするかどうかに関する決定は、個人的な決定であり、何らかの方法で相互運用性に影響しません。 したがって、それは実装選択です。

Gupta & Melam               Standards Track                    [Page 11]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[11ページ]RFC4552認証/秘密性

12.  Entropy of Manual Keys

12. 手動のキーのエントロピー

   The implementations MUST allow the administrator to configure the
   cryptographic and authentication keys in hexadecimal format rather
   than restricting it to a subset of ASCII characters (letters,
   numbers, etc.).  A restricted character set will reduce key entropy
   significantly as discussed in [I2].

実装で、管理者はそれをASCII文字(手紙、数など)の部分集合に制限するより16進形式で暗号と認証キーをむしろ構成できなければなりません。 制限された文字集合は[I2]で議論するように主要なエントロピーをかなり減少させるでしょう。

13.  Replay Protection

13. 反復操作による保護

   Since it is not possible using the current standards to provide
   complete replay protection while using manual keying, the proposed
   solution will not provide protection against replay attacks.

手動の合わせることを使用している間、完全な反復操作による保護を提供するのに現在の規格を使用するのが可能でないので、提案されたソリューションは反射攻撃に対する保護を提供しないでしょう。

   Detailed analysis of various vulnerabilities of the routing protocols
   and OSPF in particular is discussed in [I3] and [I2].  The conclusion
   is that replay of OSPF packets can cause adjacencies to be disrupted,
   which can lead to a DoS attack on the network.  It can also cause
   database exchange process to occur continuously thus causing CPU
   overload as well as micro loops in the network.

[I3]と[I2]でルーティング・プロトコルと特にOSPFの様々な脆弱性の詳細に渡る分析について議論します。 結論はパケットで隣接番組を混乱させることができるOSPFのその再生です。(その再生はネットワークに対するDoS攻撃につながることができます)。 また、それで、データベース交換プロセスは、その結果、絶え間なくネットワークにおけるマイクロ輪と同様にCPUオーバーロードを引き起こしながら、起こることができます。

14.  Security Considerations

14. セキュリティ問題

   This memo discusses the use of IPsec AH and ESP headers to provide
   security to OSPFv3 for IPv6.  Hence, security permeates throughout
   this document.

このメモは、IPv6のためにセキュリティをOSPFv3に供給するためにIPsec AHと超能力ヘッダーの使用について議論します。 したがって、セキュリティはこのドキュメント中で染みます。

   OSPF Security Vulnerabilities Analysis [I2] identifies OSPF
   vulnerabilities in two scenarios -- one with no authentication or
   simple password authentication and the other with cryptographic
   authentication.  The solution described in this specification
   provides protection against all the vulnerabilities identified for
   scenarios with cryptographic authentication with the following
   exceptions:

OSPF Security Vulnerabilities Analysis[I2]は2つのシナリオのOSPF脆弱性を特定します--暗号の認証がある認証も簡単なパスワード認証ともう片方のない1。 この仕様で説明されたソリューションはシナリオのために暗号の認証で特定されたすべての脆弱性に対する保護を以下の例外に提供します:

   Limitations of manual key:

手動のキーの限界:

   This specification mandates the usage of manual keys.  The following
   are the known limitations of the usage of manual keys.

この仕様は手動のキーの使用法を強制します。 ↓これは手動のキーの使用法の知られている制限です。

      o  As the sequence numbers cannot be negotiated, replay protection
         cannot be provided.  This leaves OSPF insecure against all the
         attacks that can be performed by replaying OSPF packets.

o 一連番号を交渉できないので、反復操作による保護を提供できません。 これはOSPFをOSPFパケットを再演することによって実行できるすべての攻撃に対して不安定な状態でおきます。

      o  Manual keys are usually long lived (changing them often is a
         tedious task).  This gives an attacker enough time to discover
         the keys.

o 通常、手動のキーは長い間、送られます(しばしばそれらを変えるのは、うんざりする仕事です)。 これはキーを発見できるくらいの時間を攻撃者に与えます。

Gupta & Melam               Standards Track                    [Page 12]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[12ページ]RFC4552認証/秘密性

      o  As the administrator is manually configuring the keys, there is
         a chance that the configured keys are weak (there are known
         weak keys for DES/3DES at least).

o 管理者が手動でキーを構成しているとき、構成されたキーが弱いという(少なくともDES/3DESに、弱いキーは知られています)見込みがあります。

   Impersonating attacks:

まねは攻撃されます:

   The usage of the same key on all the OSPF routers connected to a link
   leaves them all insecure against impersonating attacks if any one of
   the OSPF routers is compromised, malfunctioning, or misconfigured.

リンクに接続されたすべてのOSPFルータの同じキーの使用法は、OSPFルータのどれかが感染されるか、誤動作するか、またはmisconfiguredされるなら攻撃をまねないようにそれらを皆、不安定な状態でおきます。

   Detailed analysis of various vulnerabilities of routing protocols is
   discussed in [I3].

[I3]でルーティング・プロトコルの様々な脆弱性の詳細に渡る分析について議論します。

15.  References

15. 参照

15.1.  Normative References

15.1. 引用規格

   [N1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[N1]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。

   [N2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740,
        December 1999.

[N2] ColtunとR.とファーガソン、D.とJ.Moy、「IPv6"、RFC2740、1999年12月のためのOSPF。」

   [N3] Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", RFC 4301, December 2005.

[N3] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。

   [N4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
        December 2005.

[N4]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。

   [N5] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[N5] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。

   [N6] Eastlake 3rd, D., "Cryptographic Algorithm Implementation
        Requirements for Encapsulating Security Payload (ESP) and
        Authentication Header (AH)", RFC 4305, December 2005.

[N6] イーストレーク3番目、D.、「セキュリティが有効搭載量(超能力)と認証ヘッダー(ああ)であるとカプセル化するための暗号アルゴリズム実装要件」、RFC4305(2005年12月)。

   [N7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[N7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

15.2.  Informative References

15.2. 有益な参照

   [I1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
        December 2005.

[I1] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。

   [I2] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities
        Analysis", Work in Progress.

[I2] 「OSPFセキュリティの脆弱性分析」というジョーンズ、E.、およびO.Moigneは進行中で働いています。

   [I3] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing
        Protocols", Work in Progress.

[I3] Barbir、A.、マーフィー、S.、およびY.陽、「ルーティング・プロトコルへのジェネリックの脅威」は進行中で働いています。

Gupta & Melam               Standards Track                    [Page 13]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[13ページ]RFC4552認証/秘密性

   [I4] Leech, M., "Key Management Considerations for the TCP MD5
        Signature Option", RFC 3562, July 2003.

[I4] ヒル、M.、「TCP MD5署名オプションのためのKey Management問題」、RFC3562、2003年7月。

Acknowledgements

承認

   The authors would like to extend sincere thanks to Marc Solsona,
   Janne Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells,
   Vishwas Manral, and Sam Hartman for providing useful information and
   critiques on this memo.  The authors would like to extend special
   thanks to Acee Lindem for many editorial changes.

作者は、このメモで役に立つ情報と批評を提供するためにマークソルソナ、ヤンネPeltonen、ジョン・クルス、Dhavalシャー、Abhayロイ、ポール・ウェルズ、Vishwas Manral、およびサム・ハートマンに心からの感謝を表したがっています。 作者は多くの編集の変化のために特別な感謝をAcee Lindemに表したがっています。

   We would also like to thank members of the IPsec and OSPF WG for
   providing valuable review comments.

また、貴重なレビューコメントを提供して頂いて、IPsecとOSPF WGのメンバーに感謝申し上げます。

Authors' Addresses

作者のアドレス

   Mukesh Gupta
   Tropos Networks
   555 Del Rey Ave
   Sunnyvale, CA 94085

MukeshグプタTroposネットワーク555デル・レイAveサニーベル、カリフォルニア 94085

   Phone: 408-331-6889
   EMail: mukesh.gupta@tropos.com

以下に電話をしてください。 408-331-6889 メールしてください: mukesh.gupta@tropos.com

   Nagavenkata Suresh Melam
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089

Nagavenkata Suresh Melam杜松は1194N.マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。

   Phone: 408-505-4392
   EMail: nmelam@juniper.net

以下に電話をしてください。 408-505-4392 メールしてください: nmelam@juniper.net

Gupta & Melam               Standards Track                    [Page 14]

RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006

OSPFv3 June 2006のためのグプタとMelam標準化過程[14ページ]RFC4552認証/秘密性

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Gupta & Melam               Standards Track                    [Page 15]

グプタとMelam標準化過程[15ページ]