RFC5269 日本語訳
5269 Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover KeyUsing SEcure Neighbor Discovery (SEND). J. Kempf, R. Koodli. June 2008. (Format: TXT=32742 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Kempf
Request for Comments: 5269 DoCoMo Labs USA
Category: Standards Track R. Koodli
Starent Networks
June 2008
コメントを求めるワーキンググループJ.ケンフの要求をネットワークでつないでください: 5269年のDoCoMo研究室米国カテゴリ: 規格は2008年6月にR.Koodli Starentネットワークを追跡します。
Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using
SEcure Neighbor Discovery (SEND)
安全な隣人発見を使用することで左右対称の速いモバイルIPv6(FMIPv6)引き渡しキーを分配します。(発信します)
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a Mobile Node in order to avoid certain attacks. In this document, a method for provisioning a shared key from the Access Router to the Mobile Node is defined to protect this signaling. The Mobile Node generates a public/private key pair using the same public key algorithm as for SEND (RFC 3971). The Mobile Node sends the public key to the Access Router. The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node. The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update. The Mobile Node and Access Router use the Router Solicitation for Proxy Advertisement and Proxy Router Advertisement from Fast Mobile IPv6 for the key exchange. The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node. This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key.
速く、モバイルIPv6は、Fast Binding Updateが、ある攻撃を避けるためにAccess RouterとモバイルNodeの間で共有されたセキュリティ協会を使用することで固定されているのを必要とします。 本書では、共有されたAccess RouterからモバイルNodeまでのキーに食糧を供給するためのメソッドは、このシグナリングを保護するために定義されます。 モバイルNodeは、SEND(RFC3971)のように同じ公開鍵アルゴリズムを使用することで公衆/秘密鍵組を生成します。 モバイルNodeは公開鍵をAccess Routerに送ります。 Access Routerは公開鍵を使用することで共有された引き渡しキーを暗号化して、モバイルNodeにそれを送り返します。 モバイルNodeは合っている秘密鍵を使用することで共有された引き渡しキーを解読します、そして、次に、Fast Binding Updateの固有識別文字を生成するのについて、引き渡しキーがあります。 モバイルNodeとAccess RouterはProxy AdvertisementとProxy Router Advertisementに主要な交換のためのFastのモバイルIPv6からRouter Solicitationを使用します。 主要な交換メッセージがSENDセキュリティを持つのに必要です。 すなわち、ソースアドレスはCryptographically Generated Address(CGA)です、そして、送付ノードのCGA秘密鍵を使用することでメッセージは署名されます。 これはAccess Routerを許容します、したがって、アドレスを要求するためにモバイルNodeの承認について確かめるために分配している引き渡しキーを提供する前にそれ、前である、注意、-、Fast Binding UpdateのCGAがキーの名前として機能できます。
Kempf & Koodli Standards Track [Page 1] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Overview of the Protocol ........................................3
2.1. Brief Review of SEND .......................................3
2.2. Protocol Overview ..........................................4
3. Handover Key Provisioning and Use ...............................4
3.1. Sending Router Solicitations for Proxy Advertisement .......4
3.2. Receiving Router Solicitations for Proxy
Advertisement and Sending Proxy Router Advertisements ......5
3.3. Receiving Proxy Router Advertisements ......................6
3.4. Sending FBUs ...............................................7
3.5. Receiving FBUs .............................................7
3.6. Key Generation and Lifetime ................................7
3.7. Protocol Constants .........................................8
4. Message Formats .................................................8
4.1. Handover Key Request Option ................................8
4.2. Handover Key Reply Option .................................10
5. Security Considerations ........................................11
6. IANA Considerations ............................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................12
1. 序論…2 1.1. 用語…3 2. プロトコルの概要…3 2.1. レビューに事情を知らせる、発信してください…3 2.2. 概要について議定書の中で述べてください…4 3. 引き渡しの主要な食糧を供給するのと使用…4 3.1. プロキシ広告のためのルータ懇願を送ります…4 3.2. プロキシ広告のためのルータ懇願を受けて、ルータ通知をプロキシに送ります…5 3.3. プロキシルータ通知を受け取ります…6 3.4. FBUsを送ります…7 3.5. FBUsを受けます…7 3.6. キー生成と生涯…7 3.7. 定数について議定書の中で述べてください…8 4. メッセージ形式…8 4.1. 引き渡しの主要な要求オプション…8 4.2. 引き渡しの主要な回答オプション…10 5. セキュリティ問題…11 6. IANA問題…11 7. 参照…12 7.1. 標準の参照…12 7.2. 有益な参照…12
1. Introduction
1. 序論
In Fast Mobile IPv6 (FMIPv6) [FMIP], a Fast Binding Update (FBU) is sent from a Mobile Node (MN), undergoing IP handover, to the previous Access Router (AR). The FBU causes a routing change so traffic sent to the MN's previous Care-of Address on the previous AR's link is tunneled to the new Care-of Address on the new AR's link. Only an MN authorized to claim the address should be able to change the routing for the previous Care-of Address. If such authorization is not established, an attacker can redirect a victim MN's traffic at will.
FastのモバイルIPv6(FMIPv6)[FMIP]では、モバイルNode(ミネソタ)からFast Binding Update(FBU)を送ります、IP引き渡しを受けて、前のAccess Router(AR)に。 したがって、FBUがミネソタのものに前であることの状態で送られたトラフィックをルーティング変化に引き起こす、Care、-、前のARのリンクの上のAddressが新しさにトンネルを堀られる、Care、-、Addressは新しいARのものにリンクします。 アドレスを要求するのが認可されたミネソタだけが前のためにルーティングを変えることができるべきである、Care、-、Address。 そのような承認が確立されないなら、攻撃者は犠牲者ミネソタのトラフィックを自由自在に向け直すことができます。
In this document, a lightweight mechanism is defined by which a shared handover key for securing FMIP can be provisioned on the MN by the AR. The mechanism utilizes SEND [SEND] and an additional public/private key pair, generated on the MN using the same public key algorithm as SEND, to encrypt/decrypt a shared handover key sent from the AR to the MN. The key provisioning occurs at some arbitrary time prior to handover, thereby relieving any performance overhead on the handover process. The message exchange between the MN and AR to provision the handover key is required to be protected by SEND; that is, the source address for the key provisioning messages must be a CGA and the messages must be signed with the CGA private key. This allows the AR to establish the MN's authorization to operate on the
本書では、ARがミネソタでFMIPを固定するのに、主要な共有された引き渡しに食糧を供給することができる軽量のメカニズムは定義されます。 メカニズムは、ARからミネソタに送られた共有された引き渡しキーを暗号化するか、または解読するのにミネソタでSENDと同じ公開鍵アルゴリズムを使用することで生成されたSEND[SEND]と追加公衆/秘密鍵組を利用します。 主要な食糧を供給することは引き渡しの前にいつかの任意の時に起こって、その結果、業務引き継ぎ作業のどんな性能オーバーヘッドも救います。 SENDによって保護されるのに引き渡しキーに食糧を供給するミネソタとARの間の交換処理が必要です。 すなわち、メッセージに食糧を供給するキーのためのソースアドレスはCGAであるに違いありません、そして、CGA秘密鍵をメッセージと契約しなければなりません。 これで、ARは作動するミネソタの承認を確立できます。
Kempf & Koodli Standards Track [Page 2] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[2ページ]。
CGA. The AR uses the CGA to name the handover key. The SEND key pair is, however, independent from the handover encryption/decryption key pair and from the actual handover key. Once the shared handover key has been established, when the MN undergoes IP handover, the MN generates an authorization Message Authentication Code (MAC) on the FBU. The previous care-of CGA included in the FBU is used by the AR to find the right handover key for checking the authorization.
CGA。 ARは、引き渡しキーを命名するのにCGAを使用します。 しかしながら、SEND主要な組は引き渡し暗号化/復号化主要な組と、そして、実際の引き渡しキーから独立しています。 ミネソタがIP引き渡しを受けるとき、共有された引き渡しキーがいったん設立されると、ミネソタは、承認がFBUに関するメッセージ立証コード(MAC)であると生成します。 前である、注意、-、FBUにCGAを含んでいるのは、承認をチェックするのに、正しい引き渡しが主要であることがわかるのにARによって使用されます。
Handover keys are an instantiation of the purpose built key architectural principle [PBK].
引き渡しキーは主要な建築原則[PBK]が築き上げられた目的の具体化です。
1.1. Terminology
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
In addition, the following terminology is used:
さらに、以下の用語は使用されています:
CGA public key
CGA公開鍵
Public key used to generate the CGA according to RFC 3972
[CGA].
RFC3972[CGA]によると、公開鍵は以前はよくCGAを生成していました。
CGA private key
CGA秘密鍵
Private key corresponding to the CGA public key.
CGA公開鍵に対応する秘密鍵。
Handover key encryption public key
引き渡しの主要な暗号化公開鍵
Public key generated by the MN and sent to the current AR to
encrypt the shared handover key.
共有された引き渡しキーを暗号化するためにミネソタによって生成されて、現在のARに送られた公開鍵。
Handover key encryption private key
引き渡しの主要な暗号化秘密鍵
Private key corresponding to handover key encryption public
key, held by the MN.
引き渡しの主要な暗号化公開鍵に対応する、ミネソタによって保たれた秘密鍵。
2. Overview of the Protocol
2. プロトコルの概要
2.1. Brief Review of SEND
2.1. レビューに事情を知らせる、発信
SEND protects against a variety of threats to local link address resolution (also known as Neighbor Discovery) and last hop router (AR) discovery in IPv6 [RFC3756]. These threats are not exclusive to wireless networks, but they generally are easier to mount on certain wireless networks because the link between the access point and MN can't be physically secured.
SENDはIPv6[RFC3756]での地方のリンクアドレス解決(また、Neighborディスカバリーとして、知られている)と最後のホップルータ(AR)発見へのさまざまな脅威から守ります。 これらの脅威はワイヤレス・ネットワークに限っていませんが、あるワイヤレス・ネットワークでは、一般に、それらは、物理的にアクセスポイントとミネソタとのリンクを固定できないので、より上がりやすいです。
Kempf & Koodli Standards Track [Page 3] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[3ページ]。
SEND utilizes CGAs in order to secure Neighbor Discovery signaling [CGA]. Briefly, a CGA is formed by hashing together the IPv6 subnet prefix for a node's subnet, a random nonce, and an RSA public key, called the CGA public key. The CGA private key is used to sign a Neighbor Advertisement (NA) message sent to resolve the link-layer address to the IPv6 address. The combination of the CGA and the signature on the NA proves to a receiving node the sender's authorization to claim the address. The node may opportunistically generate one or several keys specifically for SEND, or it may use a certified key that it distributes more widely.
SENDは、Neighborディスカバリーがシグナリング[CGA]であると機密保護するのにCGAsを利用します。 無作為の一回だけ、およびRSA公開鍵は、CGA公開鍵を簡潔に、CGAがノードのサブネットのためにIPv6サブネット接頭語を一緒に論じ尽くすことによって形成されると呼びました。 CGA秘密鍵は、IPv6アドレスにリンクレイヤアドレスを決議するために送られたNeighbor Advertisement(NA)メッセージに署名するのに使用されます。 NAにおけるCGAと署名の組み合わせは、送付者の承認がアドレスを要求すると受信ノードに立証します。 ノードが特にSENDのために便宜主義的に1か数個のキーを生成するかもしれませんか、またはそれは、より広く、分配する公認されたキーを使用するかもしれません。
2.2. Protocol Overview
2.2. プロトコル概要
The protocol utilizes the SEND secured Router Solicitation for Proxy Advertisement (RtSolPr)/Proxy Router Advertisement (PrRtAdv) [FMIP] exchange between the MN and the AR to transport an encrypted, shared handover key from the AR to the MN. First, the MN generates the necessary key pair and associated CGA addresses so that the MN can employ SEND. Then, the MN generates a public/private key pair for encrypting/decrypting the shared handover key, using the same public key algorithm as was used for SEND. The MN then sends an RtSolPr message with a Handover Key Request Option containing the handover key encryption public key. The source address of the RtSolPr message is the MN's care-of CGA on the AR's link, the RtSolPr message is signed with the MN's CGA key, and contains the CGA Parameters option, in accordance with RFC 3971 [SEND]. The AR verifies the message using SEND, then utilizes the handover key encryption public key to encrypt a shared handover key, which is included with the PrRtAdv in the Handover Key Reply Option. The MN decrypts the shared handover key and uses it to establish an authorization MAC when it sends an FBU to the previous AR.
プロトコルはミネソタとARの間のProxy Advertisement(RtSolPr)/プロキシRouter Advertisement(PrRtAdv)[FMIP]交換がARからミネソタまで主要な暗号化されて、共有された引き渡しを輸送するようにRouter Solicitationであることが固定されたSENDを利用します。 まず最初に、ミネソタは、ミネソタがSENDを使うことができるように、必要な主要な組と関連CGAがアドレスであると生成します。 そして、ミネソタは、SENDに使用されたのと同じ公開鍵アルゴリズムを共有された引き渡しキー、使用に暗号化するか、または解読するために公衆/秘密鍵組を生成します。 そして、ミネソタはHandover Key Request Optionが引き渡しの主要な暗号化公開鍵を含んでいるRtSolPrメッセージを送ります。 RtSolPrメッセージのソースアドレスがミネソタのものである、注意、-、ARのリンクの上のCGA、RtSolPrメッセージは、ミネソタのCGAキーで署名されて、CGA Parametersオプションを含んでいます、RFC3971[SEND]によると。 ARは、SENDを使用することでメッセージについて確かめて、次に、共有された引き渡しキーを暗号化するのに引き渡しの主要な暗号化公開鍵を利用します。(キーはHandover Key Reply OptionのPrRtAdvと共に含まれています)。 前のARにFBUを送るとき、ミネソタは、共有された引き渡しキーを解読して、承認MACを証明するのにそれを使用します。
3. Handover Key Provisioning and Use
3. 引き渡しの主要な食糧を供給するのと使用
3.1. Sending Router Solicitations for Proxy Advertisement
3.1. プロキシ広告のための送付ルータ懇願
At some time prior to handover, the MN MUST generate a handover key encryption public/private key pair, using exactly the same public key algorithm with exactly the same parameters (key size, etc.) as for SEND [SEND]. The MN can reuse the key pair on different access routers but MUST NOT use the key pair for any other encryption or for signature operation. In order to prevent cryptanalysis, the key pair SHOULD be discarded after either a duration of HKEPK-LIFETIME or HKEPK-HANDOVERS number of handovers, whichever occurs first. See Section 3.7 for definitions of protocol constants.
引き渡しの前のいつかの時に、ミネソタは引き渡しの主要な暗号化公衆/秘密鍵組を生成しなければなりません、SEND[SEND]のようにまさに同じパラメタ(主要なサイズなど)があるまさに同じ公開鍵アルゴリズムを使用して。 ミネソタは、異なったアクセスルータで主要な組を再利用できますが、いかなる他の暗号化か署名操作にも主要な組を使用してはいけません。 暗号文解読術を防ぐために、捨てられて、キーはHKEPK-LIFETIMEの持続時間か身柄の引き渡しのHKEPK-HANDOVERS番号のどちらかの後にSHOULDを対にします、どれが最初に起こっても。 プロトコル定数の定義に関してセクション3.7を見てください。
Kempf & Koodli Standards Track [Page 4] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[4ページ]。
The MN MUST send a Router Solicitation for Proxy Advertisement (RtSolPr) containing a Handover Key Request Option with the handover encryption public key. A CGA for the MN MUST be the source address on the packet, and the MN MUST include the SEND CGA Option and SEND Signature Option with the packet, as specified in [SEND]. The SEND signature covers all fields in the RtSolPr, including the 128-bit source and destination addresses and ICMP checksum as described in RFC 3971, except for the Signature Option itself. The MN also sets the handover authentication Algorithm Type (AT) extension field in the Handover Key Request Option to the MN's preferred FBU authentication algorithm. The SEND Nonce MUST also be included for anti-replay protection.
ミネソタは引き渡し暗号化公開鍵があるHandover Key Request Optionを含むProxy Advertisement(RtSolPr)のためにRouter Solicitationを送らなければなりません。 ミネソタへのCGAはパケットに関するソースアドレスであるに違いありません、そして、ミネソタはパケットがあるSEND CGA OptionとSEND Signature Optionを含めなければなりません、[SEND]で指定されるように。 SEND署名はRtSolPrのすべての分野をカバーしています、RFC3971で説明される128ビットのソース、送付先アドレス、およびICMPチェックサムを含んでいて、Signature Option自身を除いて。 また、ミネソタはHandover Key Request Optionの引き渡し認証Algorithm Type(AT)拡大分野をミネソタの都合のよいFBU認証アルゴリズムに設定します。 また、反反復操作による保護のためにSEND Nonceを含まなければなりません。
3.2. Receiving Router Solicitations for Proxy Advertisement and Sending
Proxy Router Advertisements
3.2. プロキシ広告のためのルータ懇願を受けて、ルータ通知をプロキシに送ります。
When an FMIPv6 capable AR with SEND receives an RtSolPr from an MN protected with SEND and including a Handover Key Request Option, the AR MUST first validate the RtSolPr using SEND as described in RFC 3971. If the RtSolPr can not be validated, the AR MUST NOT include a Handover Key Reply Option in the reply. The AR also MUST NOT change any existing key record for the address, since the message may be an attempt by an attacker to disrupt communications for a legitimate MN. The AR SHOULD respond to the RtSolPr but MUST NOT perform handover key provisioning.
SENDとFMIPv6のできるARがSENDと共に保護されて、Handover Key Request Optionを含むミネソタからRtSolPrを受けるとき、RFC3971で説明されるようにSENDを使用して、アルゴンは最初に、RtSolPrを有効にしなければなりません。 RtSolPrを有効にすることができないなら、アルゴンは回答にHandover Key Reply Optionを含んではいけません。 ARもアドレスのためのどんな既存の主要な記録も変えてはいけません、メッセージが正統のミネソタのための通信システムを遮断する攻撃者による試みであるかもしれないので。 AR SHOULDはRtSolPrに応じますが、引き渡しの主要な食糧を供給することを実行してはいけません。
If the RtSolPr can be validated, the AR MUST then determine whether the CGA is already associated with a shared handover key. If the CGA is associated with an existing handover key, the AR MUST return the existing handover key to the MN. If the CGA does not have a shared handover key, the AR MUST construct a shared handover key as described in Section 3.6. The AR MUST encrypt the handover key with the handover key encryption public key included in the Handover Key Request Option. The AR MUST insert the encrypted handover key into a Handover Key Reply Option and MUST attach the Handover Key Reply Option to the PrRtAdv. The lifetime of the key, HK-LIFETIME, MUST also be included in the Handover Key Reply Option. The AR SHOULD set the AT field of the Handover Key Option to the MN's preferred algorithm type indicated in the AT field of the Handover Key Request Option, if it is supported; otherwise, the AR MUST select an authentication algorithm that is of equivalent strength or stronger, and set the field to that. The AR MUST also include the SEND nonce from the RtSolPr for anti-replay protection. The AR MUST have a certificate suitable for a SEND-capable router, support SEND certificate discovery, and include a SEND CGA Option and a SEND Signature Option in the PrRtAdv messages it sends. Similarly, the mobile nodes MUST be configured with one or more SEND trust anchors so that they can verify these messages. The SEND signature covers
RtSolPrを有効にすることができるなら、アルゴンは、CGAが既に共有された引き渡しキーに関連しているかどうか決定しなければなりません。 CGAが既存の引き渡しキーに関連しているなら、アルゴンはミネソタに主要な既存の引き渡しを返さなければなりません。 CGAに共有された引き渡しキーがないなら、アルゴンはセクション3.6で説明されるように共有された引き渡しキーを組み立てなければなりません。 アルゴンは主要なHandover Key Request Optionに含まれている引き渡しの主要な暗号化公開鍵で引き渡しを暗号化しなければなりません。 アルゴンは、Handover Key Reply Optionに主要な暗号化された引き渡しを挿入しなければならなくて、Handover Key Reply OptionをPrRtAdvに取り付けなければなりません。 また、Handover Key Reply Optionにキーの生涯(HK-LIFETIME)を含まなければなりません。 AR SHOULDはHandover Key Request OptionのAT分野で示されたミネソタの都合のよいアルゴリズムタイプにHandover Key OptionのAT分野を設定します、それがサポートされるなら。 さもなければ、アルゴンは、強さか、より強い状態で同等物のものである認証アルゴリズムを選択して、それに分野を設定しなければなりません。 また、アルゴンは反反復操作による保護のためのRtSolPrからのSEND一回だけを含まなければなりません。 アルゴンは、それが送るPrRtAdvメッセージで証明書をSENDできるルータに適するようにして、SENDが証明書発見であるとサポートして、SEND CGA OptionとSEND Signature Optionを含めなければなりません。 同様に、彼らがこれらのメッセージについて確かめることができるように、1人以上のSEND信頼アンカーでモバイルノードを構成しなければなりません。 SEND署名カバー
Kempf & Koodli Standards Track [Page 5] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[5ページ]。
all fields in the PrRtAdv, including the 128-bit source and destination addresses and ICMP checksum as described in RFC 3971, except for the Signature Option itself. The PrRtAdv is then unicast back to the MN at the MN's care-of CGA that was the source address on the RtSolPr. The handover key MUST be stored by the AR for future use, indexed by the CGA, and the authentication algorithm type (i.e., the resolution of the AT field processing) and HK-LIFETIME MUST be recorded with the key.
128ビットのソース、送付先アドレス、およびRFC3971で説明されるSignature Option自身以外のICMPチェックサムを含むPrRtAdvのすべての分野。 次に、PrRtAdvがミネソタのところのミネソタへのユニキャスト後部である、注意、-、RtSolPrに関するソースアドレスであったCGA。 記録されていて、認証アルゴリズムのCGAによって索引をつけられた今後の使用のためのAR、タイプ(すなわち、ATフィールド処理の解決)、およびHK-LIFETIME MUSTはキーで引き渡しキーを保存しなければなりません。
3.3. Receiving Proxy Router Advertisements
3.3. プロキシルータ通知を受け取ります。
Upon receipt of one or more PrRtAdvs secured with SEND and having the Handover Key Reply Option, the MN MUST first validate the PrRtAdvs as described in RFC 3971. Normally, the MN will have obtained the router's certification path to validate an RA prior to sending the PrRtSol and the MN MUST check to ensure that the key used to sign the PrRtAdv is the router's certified public key. If the MN does not have the router's certification path cached, it MUST use the SEND CPS/CPA messages to obtain the certification path to validate the key. If a certified key from the router was not used to sign the message, the message MUST be dropped.
SENDと共に固定されていて、Handover Key Reply Optionを持っている1PrRtAdvsを受け取り次第、ミネソタは最初に、RFC3971で説明されるようにPrRtAdvsを有効にしなければなりません。 通常、ミネソタはPrRtSolを送る前にRAを有効にするためにルータの証明経路を得てしまうでしょう、そして、ミネソタは、PrRtAdvに署名するのに使用されるキーがルータの公認された公開鍵であることを保証するためにチェックしなければなりません。 ミネソタがルータの証明経路をキャッシュさせないなら、それはキーを有効にするために証明経路を得るSEND CPS/CPAメッセージを使用しなければなりません。 ルータからの公認されたキーがメッセージに署名するのに使用されなかったなら、メッセージを下げなければなりません。
From the messages that validate, the MN SHOULD choose one with an AT flag in the Handover Key Reply Option indicating an authentication algorithm that the MN supports. From that message, the MN MUST determine which handover key encryption public key to use in the event the MN has more than one. The MN finds the right public key to use by matching the SEND nonce from the RtSolPr. If no such match occurs, the MN MUST drop the PrRtAdv. The MN MUST use the matching private key to decrypt the handover key using its handover key encryption private key, and store the handover key for later use, named with the AR's CGA, along with the algorithm type and HK-LIFETIME. The MN MUST use the returned algorithm type indicated in the PrRtAdv. The MN MUST index the handover keys with the AR's IPv6 address, to which the MN later sends the FBU, and the MN's CGA to which the handover key applies. This allows the MN to select the proper key when communicating with a previous AR. Prior to HK-LIFETIME expiring, the MN MUST request a new key from the AR if FMIPv6 service is still required from the router.
それが有効にするメッセージから、Handover Key Reply OptionのAT旗がミネソタがサポートする認証アルゴリズムを示していて、MN SHOULDは1つを選びます。 そのメッセージから、ミネソタは、イベントにミネソタを使用するどの引き渡しの主要な暗号化公開鍵に1つ以上があるかを決定しなければなりません。 ミネソタはRtSolPrからSEND一回だけを合わせることによって使用する正しい公開鍵を見つけます。 どれかそのようなマッチが現れないなら、ミネソタはPrRtAdvを下げなければなりません。 ミネソタは、引き渡しの主要な暗号化秘密鍵を使用することで引き渡しキーを解読するのに合っている秘密鍵を使用して、ARのCGAと共に指定された後の使用に、アルゴリズムのタイプとHK-LIFETIMEと共に主要な引き渡しを保存しなければなりません。 ミネソタはPrRtAdvで示された返されたアルゴリズムタイプを使用しなければなりません。 ミネソタはARのIPv6アドレスで引き渡しキーに索引をつけなければなりません。(ミネソタは後で引き渡しキーが適用されるFBU、およびミネソタのCGAをそれに送ります)。 前のARとコミュニケートするとき、これで、ミネソタは適切なキーを選択できます。 HK-LIFETIMEの期限が切れる前に、FMIPv6サービスがルータからまだ必要であるなら、ミネソタはARから新しいキーを要求しなければなりません。
If more than one router responds to the RtSolPr, the MN MAY keep track of all such keys. If none of the PrRtAdvs contains an algorithm type indicator corresponding to an algorithm the MN supports, the MN MAY re-send the RtSolPr requesting a different algorithm, but to prevent bidding down attacks from compromised routers, the MN SHOULD NOT request an algorithm that is weaker than its original request.
1つ以上のルータがRtSolPrに応じるなら、ミネソタはそのようなすべてのキーの動向をおさえるかもしれません。 PrRtAdvsのいずれもミネソタがサポートするアルゴリズムに対応するアルゴリズムタイプインディケータを含んでいないなら、ミネソタは、RtSolPrが異なったアルゴリズムを要求するのを再送するかもしれませんが、感染しているルータから攻撃の下側に入札するのを防ぐために、MN SHOULD NOTはオリジナルの要求より弱いアルゴリズムを要求します。
Kempf & Koodli Standards Track [Page 6] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[6ページ]。
3.4. Sending FBUs
3.4. 送付FBUs
When the MN needs to signal the Previous AR (PAR) using an FMIPv6 FBU, the MN MUST utilize the handover key and the corresponding authentication algorithm to generate an authenticator for the message. The MN MUST select the appropriate key for the PAR using the PAR's CGA and the MN's previous care-of CGA on the PAR's link. As defined by the FMIPv6 [FMIP], the MN MUST generate the authentication MAC using the handover key and the appropriate algorithm and MUST include the MAC in the FBU message. As specified by FMIPv6, the MN MUST include the old care-of CGA in a Home Address Option. The FMIPv6 document provides more detail about the construction of the authenticator on the FBU.
ミネソタが、FMIPv6 FBUを使用することでPrevious AR(PAR)に合図する必要があると、ミネソタは、メッセージのために固有識別文字を生成するのに引き渡しキーと対応する認証アルゴリズムを利用しなければなりません。 ミネソタがPARのために前であることの状態でPARのCGAとミネソタのものを使用することで適切なキーを選択しなければならない、注意、-、PARのリンクの上のCGA。 FMIPv6[FMIP]によって定義されるように、ミネソタは、引き渡しキーと適切なアルゴリズムを使用して、認証がMACであると生成しなければならなくて、FBUメッセージでMACを含めなければなりません。 FMIPv6によって指定されるようにミネソタが老人を含めなければならない、注意、-、ホームAddress OptionのCGA。 FMIPv6ドキュメントはFBUにおける固有識別文字の工事に関するその他の詳細を提供します。
3.5. Receiving FBUs
3.5. FBUsを受けます。
When the PAR receives an FBU message containing an authenticator, the PAR MUST find the corresponding handover key using the MN's care-of CGA in the Home Address Option as the index. If a handover key is found, the PAR MUST utilize the handover key and the appropriate algorithm to verify the authenticator. If the handover key is not found, the PAR MUST NOT change forwarding for the care-of CGA. The FMIPv6 document [FMIP] provides more detail on how the AR processes an FBU containing an authenticator.
PARが固有識別文字を含むFBUメッセージを受け取るとき、PAR MUSTが、対応する引き渡しが主要であることがミネソタのものを使用することでわかる、注意、-、インデックスとしてのホームAddress OptionのCGA。 引き渡しキーが見つけられるなら、PAR MUSTは、固有識別文字について確かめるのに引き渡しキーと適切なアルゴリズムを利用します。 引き渡しキーが見つけられないなら、PAR MUST NOTが推進を変える、注意、-、CGA。 FMIPv6ドキュメント[FMIP]はARがどう固有識別文字を含むFBUを処理するかに関するその他の詳細を提供します。
3.6. Key Generation and Lifetime
3.6. キー生成と生涯
The AR MUST randomly generate a key having sufficient strength to match the authentication algorithm. Some authentication algorithms specify a required key size. The AR MUST generate a unique key for each CGA public key, and SHOULD take care that the key generation is uncorrelated between handover keys, and between handover keys and CGA keys. The actual algorithm used to generate the key is not important for interoperability since only the AR generates the key; the MN simply uses it.
アルゴンは、認証アルゴリズムを合わせるために手当たりしだいに十分な力を持っているキーを生成しなければなりません。 いくつかの認証アルゴリズムが必要な主要なサイズを指定します。 アルゴンはそれぞれのCGA公開鍵のためにユニークキーを生成しなければなりません、そして、SHOULDはキー生成が引き渡しキーと、引き渡しキーとCGAキーの間の非相関であることに注意します。 ARだけがキーを生成するので、相互運用性には、キーを生成するのに使用される実際のアルゴリズムは重要ではありません。 ミネソタは単にそれを使用します。
A PAR SHOULD NOT discard the handover key immediately after use if it is still valid. It is possible that the MN may undergo rapid movement to another AR prior to the completion of Mobile IPv6 binding update on the PAR, and the MN MAY as a consequence initialize another, subsequent handover optimization to move traffic from the PAR to another new AR. The default time for keeping the key valid corresponds to the default time during which forwarding from the PAR to the new AR is performed for FMIP. The FMIPv6 document [FMIP] provides more detail about the FMIP forwarding time default.
それがまだ有効であるなら、PAR SHOULD NOTは使用直後主要な引き渡しを捨てます。 結果が別のものを初期化するとき、ミネソタがPAR、およびミネソタ5月のモバイルIPv6拘束力があるアップデートの完成の前に別のARへの急速な運動を受けるのは、可能です、PARから新しい別のARまでトラフィックを動かすその後の引き渡し最適化。 キーを有効に保つためのデフォルト時間はPARから新しいARまでの推進がFMIPのために実行されるデフォルト時間に対応しています。 FMIPv6ドキュメント[FMIP]はFMIP推進およそ時間のその他の詳細にデフォルトを提供します。
If the MN returns to a PAR prior to the expiration of the handover key, the PAR MAY send and the MN MAY receive the same handover key as
ミネソタが引き渡しキーの満了の前にPARに戻るのをPAR MAYが送って、ミネソタが、同じ引き渡しキーを受けるかもしれないなら
Kempf & Koodli Standards Track [Page 7] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[7ページ]。
was previously returned, if the MN generates the same CGA for its Care-of Address. However, the MN MUST NOT assume that it can continue to use the old key without actually receiving the handover key again from the PAR. The MN SHOULD discard the handover key after MIPv6 binding update is complete on the new AR. The PAR MUST discard the key after FMIPv6 forwarding for the previous Care-of Address times out or when HK-LIFETIME expires.
ミネソタが同じCGAを生成するなら以前に返した、それ、Care、-、Address。 しかしながら、ミネソタは、実際に再びPARから主要な引き渡しを受けないで古いキーを使用し続けることができると仮定してはいけません。 MIPv6の拘束力があるアップデートが新しいARで完全になった後にMN SHOULDは引き渡しキーを捨てます。 PAR MUSTが前のためのFMIPv6推進の後にキーを捨てる、Care、-、Address回のアウトかいつHK-LIFETIMEが期限が切れるか。
3.7. Protocol Constants
3.7. プロトコル定数
The following are protocol constants with suggested defaults:
↓これは提案されたデフォルトがあるプロトコル定数です:
HKEPK-LIFETIME: The maximum lifetime for the handover key
encryption public key. Default is 12 hours.
HKEPK-生涯: 引き渡しの主要な暗号化公開鍵のための最大の生涯。 デフォルトは12時間です。
HKEPK-HANDOVERS: The maximum number of handovers for which the
handover key encryption public key should be
reused. Default is 10.
HKEPK-身柄の引き渡し: 引き渡しの主要な暗号化公開鍵が再利用されるべきである身柄の引き渡しの最大数。 デフォルトは10です。
HK-LIFETIME: The maximum lifetime for the handover key. Default
is 12 hours (43200 seconds).
HK-生涯: 引き渡しキーのための最大の生涯。 デフォルトは12時間(43200秒)です。
4. Message Formats
4. メッセージ・フォーマット
4.1. Handover Key Request Option
4.1. 引き渡しの主要な要求オプション
The Handover Key Request Option is a standard IPv6 Neighbor Discovery [RFC4861] option in TLV format. The Handover Key Request Option is included in the RtSolPr message along with the SEND CGA Option, RSA Signature Option, and Nonce Option.
Handover Key Request OptionはTLV形式において標準のIPv6 Neighborディスカバリー[RFC4861]オプションです。 Handover Key Request OptionはSEND CGA Option、RSA Signature Option、およびNonce Optionに伴うRtSolPrメッセージに含まれています。
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | AT |Resrvd.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Handover Key Encryption Public Key .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| パッドの長さ| at|Resrvd| +++++++++++++++++++++++++++++++++| | . . . 引き渡しの主要な暗号化公開鍵…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . そっと歩きます…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kempf & Koodli Standards Track [Page 8] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[8ページ]。
Fields:
分野:
Type: 27
以下をタイプしてください。 27
Length: The length of the option in units of 8 octets,
including the Type and Length fields. The value 0
is invalid. The receiver MUST discard a message
that contains this value.
長さ: TypeとLength分野を含む8つの八重奏のユニットのオプションの長さ。 値0は無効です。 受信機はこの値を含むメッセージを捨てなければなりません。
Pad Length: The number of padding octets beyond the end of the
Handover Key Encryption Public Key field but within
the length specified by the Length field. Padding
octets MUST be set to zero by senders and ignored
by receivers.
長さを水増ししてください: しかしHandover Key Encryption Public Keyの端の八重奏が長さの中でさばく詰め物の数はLength分野のそばで指定しました。 八重奏を水増しするのを送付者によってゼロに設定されて、受信機で無視しなければなりません。
AT: A 4-bit algorithm type field describing the
algorithm used by FMIPv6 to calculate the
authenticator. See [FMIP] for details.
: 4ビットのアルゴリズムタイプはアルゴリズムが固有識別文字について計算するのにFMIPv6で使用した説明をさばきます。 詳細に関して[FMIP]を見てください。
Resrvd.: A 4-bit field reserved for future use. The value
MUST be initialized to zero by the sender and MUST
be ignored by the receiver.
Resrvd、: 今後の使用のために予約された4ビットの分野。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Handover Key Encryption Public Key:
The handover key encryption public key. The key
MUST be formatted according to the same
specification as the CGA key in the CGA Parameters
Option [CGA] of the message, and MUST have the same
parameters as the CGA key.
引き渡しの主要な暗号化公開鍵: 引き渡しの主要な暗号化公開鍵。 キーは、メッセージのCGA Parameters Option[CGA]で主要なCGAと同じ仕様通りにフォーマットしなければならなくて、CGAキーと同じパラメタを持たなければなりません。
Padding: A variable-length field making the option length a
multiple of 8, containing as many octets as
specified in the Pad Length field.
詰め物: Pad Length分野で指定されるのと同じくらい多くの八重奏を含んでいて、オプションの長さを8の倍数にする可変長の分野。
Kempf & Koodli Standards Track [Page 9] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[9ページ]。
4.2. Handover Key Reply Option
4.2. 引き渡しの主要な回答オプション
The Handover Key Reply Option is a standard IPv6 Neighbor Discovery [RFC4861] option in TLV format. The Handover Key Reply Option is included in the PrRtAdv message along with the SEND CGA Option, RSA Signature Option, and Nonce Option.
Handover Key Reply OptionはTLV形式において標準のIPv6 Neighborディスカバリー[RFC4861]オプションです。 Handover Key Reply OptionはSEND CGA Option、RSA Signature Option、およびNonce Optionに伴うPrRtAdvメッセージに含まれています。
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | AT |Resrvd.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
. .
. Encrypted Handover Key .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| パッドの長さ| at|Resrvd| +++++++++++++++++++++++++++++++++| 主要な生涯| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | . . . 引き渡しキーを暗号化します…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . そっと歩きます…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
分野:
Type: 28
以下をタイプしてください。 28
Length: The length of the option in units of 8 octets,
including the Type and Length fields. The value 0
is invalid. The receiver MUST discard a message
that contains this value.
長さ: TypeとLength分野を含む8つの八重奏のユニットのオプションの長さ。 値0は無効です。 受信機はこの値を含むメッセージを捨てなければなりません。
Pad Length: The number of padding octets beyond the end of the
Encrypted Handover Key field but within the length
specified by the Length field. Padding octets MUST
be set to zero by senders and ignored by receivers.
長さを水増ししてください: しかしEncrypted Handover Keyの端の八重奏が長さの中でさばく詰め物の数はLength分野のそばで指定しました。 八重奏を水増しするのを送付者によってゼロに設定されて、受信機で無視しなければなりません。
AT: A 4-bit algorithm type field describing the
algorithm used by FMIPv6 to calculate the
authenticator. See [FMIP] for details.
: 4ビットのアルゴリズムタイプはアルゴリズムが固有識別文字について計算するのにFMIPv6で使用した説明をさばきます。 詳細に関して[FMIP]を見てください。
Kempf & Koodli Standards Track [Page 10] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[10ページ]。
Resrvd.: A 4-bit field reserved for future use. The value
MUST be initialized to zero by the sender and MUST
be ignored by the receiver.
Resrvd、: 今後の使用のために予約された4ビットの分野。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Key Lifetime: Lifetime of the handover key, HK-LIFETIME, in
seconds.
キー生涯: 引き渡しキー、秒のHK-LIFETIMEの生涯。
Encrypted Handover Key:
The shared handover key, encrypted with the MN's
handover key encryption public key, using the
RSAES-PKCS1-v1_5 format [RFC3447].
暗号化された引き渡しキー: RSAES-PKCS1-v1_5形式[RFC3447]を使用するミネソタの引き渡しの主要な暗号化公開鍵で暗号化された共有された引き渡しキー。
Padding: A variable-length field making the option length a
multiple of 8, containing as many octets as
specified in the Pad Length field.
詰め物: Pad Length分野で指定されるのと同じくらい多くの八重奏を含んでいて、オプションの長さを8の倍数にする可変長の分野。
5. Security Considerations
5. セキュリティ問題
This document describes a shared key provisioning protocol for the FMIPv6 handover optimization protocol. The key provisioning protocol utilizes a public key generated with the same public key algorithm as SEND to bootstrap a shared key for authorizing changes due to handover associated with the MN's former address on the PAR. General security considerations involving CGAs apply to the protocol described in this document, see [CGA] for a discussion of security considerations around CGAs. This protocol is subject to the same risks from replay attacks and denial-of-service (DoS) attacks using the RtSolPr as the SEND protocol [SEND] for RS. The measures recommended in RFC 3971 for mitigating replay attacks and DoS attacks apply here as well. An additional consideration involves when to generate the handover key on the AR. To avoid state depletion attacks, the handover key SHOULD NOT be generated prior to SEND processing that verifies the originator of RtSolPr. State depletion attacks can be addressed by techniques, such as rate limiting RtSolPr, restricting the amount of state reserved for unresolved solicitations, and clever cache management. These techniques are the same as used in implementing Neighbor Discovery.
このドキュメントはFMIPv6引き渡し最適化プロトコルのためにプロトコルに食糧を供給する共有されたキーについて説明します。 プロトコルに食糧を供給するキーはPARに関するミネソタの前のアドレスに関連している引き渡しによる変化を認可するための共有されたキーを独力で進むためにSENDと同じ公開鍵アルゴリズムで生成された公開鍵を利用します。 CGAsにかかわる総合証券問題が本書では説明されたプロトコルに適用されます、と[CGA]はCGAsの周りのセキュリティ問題の議論に関して見ます。 このプロトコルは、SENDがRSのために[SEND]について議定書の中で述べるのでRtSolPrを使用することで反射攻撃からの同じリスクとサービスの否定(DoS)攻撃を受けることがあります。 また、反射攻撃とDoS攻撃を緩和するためのRFC3971のお勧めの測定はここに適用されます。 追加的約因は、ARで主要な引き渡しを生成するためにいつにかかわるか。 州の減少攻撃、引き渡しの主要なSHOULD NOTを避けるには、RtSolPrの創始者について確かめるSEND処理の前に生成されてください。 テクニックで州の減少攻撃を扱うことができます、RtSolPrを制限するレートなどのように、未定の懇願、および賢明なキャッシュ管理のために予約された状態の量を制限して。 これらのテクニックはNeighborがディスカバリーであると実装する際に使用されるのと同じです。
For other FMIPv6 security considerations, please see the FMIPv6 document [FMIP].
他のFMIPv6セキュリティ問題に関しては、FMIPv6ドキュメント[FMIP]を見てください。
6. IANA Considerations
6. IANA問題
IANA has assigned IPv6 Neighbor Discovery option type codes for the two new IPv6 Neighbor Discovery options, the Handover Key Request Option (27) and Handover Key Reply Option (28), defined in this document.
IANAはディスカバリーオプション、Handover Key Request Option(27)、およびHandover Key Reply Option(28)が本書では定義した2の新しいIPv6 NeighborのためにオプションタイプコードをIPv6 Neighborディスカバリーに割り当てました。
Kempf & Koodli Standards Track [Page 11] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[11ページ]。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[FMIP] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268,
June 2008.
[FMIP] Koodli、R.、エド、「モバイルIPv6速い身柄の引き渡し」、RFC5268、6月2008日
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[発信します] Arkko、J.、エド、ケンフ、J.、Zill、B.、およびP.Nikander、「安全な隣人発見(発信する)」、RFC3971、3月2005日
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[CGA] 香気、T.、「アドレス(CGA)であると暗号で生成された」RFC3972、2005年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4861] Narten、T.、Nordmark、E.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3447] イェンソン、J.、およびB.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日
7.2. Informative References
7.2. 有益な参照
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats", RFC
3756, May 2004.
[RFC3756]Nikander、P.(エド)、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信頼モデルと脅威」(RFC3756)は2004がそうするかもしれません。
[PBK] Bradner, S., Mankin, A., and Schiller, J., "A Framework for
Purpose-Built Keys (PBK)", Work in Progress, June 2003.
Progress.
2003年6月の[PBK]ブラドナーとS.とマンキン、A.とシラー、J.、「特注のキー(PBK)のためのフレームワーク」処理中の作業。 進歩をしてください。
Kempf & Koodli Standards Track [Page 12] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[12ページ]。
Authors' Addresses
作者のアドレス
James Kempf DoCoMo Labs USA 3240 Hillview Avenue Palo Alto, CA 94303 USA
ジェームスケンフDoCoMo研究室米国3240Hillview Avenueカリフォルニア94303パロアルト(米国)
Phone: +1 650 496 4711 EMail: kempf@docomolabs-usa.com
以下に電話をしてください。 +1 4711年の650 496メール: kempf@docomolabs-usa.com
Rajeev Koodli Starent Networks 30 International Place Tewksbury, MA 01876 USA
Rajeev Koodli Starentネットワーク30の国際Place MA01876テュークスベリー(米国)
Phone: +1 408 735 7679 EMail: rkoodli@starentnetworks.com
以下に電話をしてください。 +1 7679年の408 735メール: rkoodli@starentnetworks.com
Kempf & Koodli Standards Track [Page 13] RFC 5269 FMIP Security June 2008
ケンフとKoodli規格はFMIPセキュリティ2008年6月にRFC5269を追跡します[13ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を扱ってください。
Kempf & Koodli Standards Track [Page 14]
ケンフとKoodli標準化過程[14ページ]
一覧
スポンサーリンク
