RFC4718 日本語訳
4718 IKEv2 Clarifications and Implementation Guidelines. P. Eronen, P.Hoffman. October 2006. (Format: TXT=129982 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Eronen
Request for Comments: 4718 Nokia
Category: Informational P. Hoffman
VPN Consortium
October 2006
Eronenがコメントのために要求するワーキンググループP.をネットワークでつないでください: 4718年のノキアカテゴリ: 情報のP.ホフマンVPN共同体2006年10月
IKEv2 Clarifications and Implementation Guidelines
IKEv2明確化と実施要綱
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations.
このドキュメントはIKEv2仕様の多くの領域をはっきりさせます。 それは、少しの変化もプロトコルに紹介しないようにしますが、むしろそれほどあいまいな解釈に傾向がない記述を提供します。 このドキュメントの目的は共同利用できる実現の開発を奨励することです。
Eronen & Hoffman Informational [Page 1] RFC 4718 IKEv2 Clarifications October 2006
[1ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
Table of Contents
目次
1. Introduction ....................................................4
2. Creating the IKE_SA .............................................4
2.1. SPI Values in IKE_SA_INIT Exchange .........................4
2.2. Message IDs for IKE_SA_INIT Messages .......................5
2.3. Retransmissions of IKE_SA_INIT Requests ....................5
2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD ...............6
2.5. Invalid Cookies ............................................8
3. Authentication ..................................................9
3.1. Data Included in AUTH Payload Calculation ..................9
3.2. Hash Function for RSA Signatures ...........................9
3.3. Encoding Method for RSA Signatures ........................10
3.4. Identification Type for EAP ...............................11
3.5. Identity for Policy Lookups When Using EAP ................11
3.6. Certificate Encoding Types ................................12
3.7. Shared Key Authentication and Fixed PRF Key Size ..........12
3.8. EAP Authentication and Fixed PRF Key Size .................13
3.9. Matching ID Payloads to Certificate Contents ..............13
3.10. Message IDs for IKE_AUTH Messages ........................14
4. Creating CHILD_SAs .............................................14
4.1. Creating SAs with the CREATE_CHILD_SA Exchange ............14
4.2. Creating an IKE_SA without a CHILD_SA .....................16
4.3. Diffie-Hellman for First CHILD_SA .........................16
4.4. Extended Sequence Numbers (ESN) Transform .................17
4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED ..............17
4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO ...................18
4.7. Semantics of Complex Traffic Selector Payloads ............18
4.8. ICMP Type/Code in Traffic Selector Payloads ...............19
4.9. Mobility Header in Traffic Selector Payloads ..............20
4.10. Narrowing the Traffic Selectors ..........................20
4.11. SINGLE_PAIR_REQUIRED .....................................21
4.12. Traffic Selectors Violating Own Policy ...................21
4.13. Traffic Selector Authorization ...........................22
5. Rekeying and Deleting SAs ......................................23
5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange ............23
5.2. Rekeying the IKE_SA vs. Reauthentication ..................24
5.3. SPIs When Rekeying the IKE_SA .............................25
5.4. SPI When Rekeying a CHILD_SA ..............................25
5.5. Changing PRFs When Rekeying the IKE_SA ....................26
5.6. Deleting vs. Closing SAs ..................................26
5.7. Deleting a CHILD_SA Pair ..................................26
5.8. Deleting an IKE_SA ........................................27
5.9. Who is the original initiator of IKE_SA ...................27
5.10. Comparing Nonces .........................................27
5.11. Exchange Collisions ......................................28
5.12. Diffie-Hellman and Rekeying the IKE_SA ...................36
1. 序論…4 2. IKE_SAを作成します…4 2.1. SPIはイケ_SAで_イニット交換を評価します…4 2.2. イケ_SA_イニットメッセージのためのメッセージID…5 2.3. イケ_SA_イニット要求のRetransmissions…5 2.4. クッキーと無効の_KE_ペイロードの相互作用…6 2.5. 無効のクッキー…8 3. 認証…9 3.1. データはAUTHに有効搭載量計算を含んでいました…9 3.2. RSA署名のための機能を論じ尽くしてください…9 3.3. RSA署名のための方法をコード化します…10 3.4. EAPのための識別タイプ…11 3.5. アイデンティティ、方針ルックアップいつ使用EAP…11 3.6. タイプをコード化する証明書…12 3.7. 主要な認証を共有して、主要なサイズをPRFに固定します…12 3.8. EAP認証と固定PRF主要なサイズ…13 3.9. コンテンツを証明するためにID有効搭載量を合わせます…13 3.10. イケ_AUTHメッセージのためのメッセージID…14 4. 子供_SAsを作成します…14 4.1. SAsを作成する、_子供_SA交換を引き起こしてください…14 4.2. 子供_SAなしでIKE_SAを作成します…16 4.3. 最初に、子供_SAのためのディフィー-ヘルマン…16 4.4. 拡張配列番号(ESN)は変形します…17 4.5. どんな_も支持しなかった_を水増しする超能力_TFC_の交渉…17 4.6. _また、非_の最初の_の交渉は断片化します…18 4.7. 複雑な交通セレクタ有効搭載量の意味論…18 4.8. ICMPは交通セレクタで有効搭載量をタイプするか、またはコード化します…19 4.9. 交通セレクタ有効搭載量における移動性ヘッダー…20 4.10. 交通セレクタを狭くします…20 4.11. シングル_組_が必要です…21 4.12. 自己の方針に違反する交通セレクタ…21 4.13. 交通セレクタ認可…22 5. SAsをRekeyingして、削除します…23 5.1. Rekeying SAs、_子供_SA交換を引き起こしてください…23 5.2. IKE_SA対ReauthenticationをRekeyingします…24 5.3. SPIsいつRekeying IKE_SA…25 5.4. SPI、Rekeying a子供_SAであるときに…25 5.5. Rekeying IKE_SAであるときに、PRFsを変えます…26 5.6. SAsを閉じることに対して削除します。26 5.7. _子供を削除して、SAは対にします…26 5.8. IKE_SAを削除します…27 5.9. IKE_SAのオリジナルの創始者はだれです…27 5.10. 一回だけを比較します…27 5.11. 衝突を交換してください…28 5.12. ディフィー-ヘルマンとRekeying IKE_SA…36
Eronen & Hoffman Informational [Page 2] RFC 4718 IKEv2 Clarifications October 2006
[2ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
6. Configuration Payloads .........................................37
6.1. Assigning IP Addresses ....................................37
6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS ...................38
6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ...................38
6.4. INTERNAL_IP4_NETMASK ......................................41
6.5. Configuration Payloads for IPv6 ...........................42
6.6. INTERNAL_IP6_NBNS .........................................43
6.7. INTERNAL_ADDRESS_EXPIRY ...................................43
6.8. Address Assignment Failures ...............................44
7. Miscellaneous Issues ...........................................45
7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR ....................45
7.2. Relationship of IKEv2 to RFC 4301 .........................45
7.3. Reducing the Window Size ..................................46
7.4. Minimum Size of Nonces ....................................46
7.5. Initial Zero Octets on Port 4500 ..........................46
7.6. Destination Port for NAT Traversal ........................47
7.7. SPI Values for Messages outside an IKE_SA .................47
7.8. Protocol ID/SPI Fields in Notify Payloads .................48
7.9. Which message should contain INITIAL_CONTACT ..............48
7.10. Alignment of Payloads ....................................48
7.11. Key Length Transform Attribute ...........................48
7.12. IPsec IANA Considerations ................................49
7.13. Combining ESP and AH .....................................50
8. Implementation Mistakes ........................................50
9. Security Considerations ........................................51
10. Acknowledgments ...............................................51
11. References ....................................................51
11.1. Normative References .....................................51
11.2. Informative References ...................................52
Appendix A. Exchanges and Payloads ................................54
A.1. IKE_SA_INIT Exchange ......................................54
A.2. IKE_AUTH Exchange without EAP .............................54
A.3. IKE_AUTH Exchange with EAP ................................55
A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying
CHILD_SAs .................................................56
A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA ..........56
A.6. INFORMATIONAL Exchange ....................................56
6. 構成有効搭載量…37 6.1. IPアドレスを割り当てます…37 6.2. どんなINTERNAL_IP4/IP6_ADDRESSも要求します…38 6.3. 内部の_IP4_サブネット/内部の_IP6_サブネット…38 6.4. 内部の_IP4_ネットマスク…41 6.5. IPv6のための構成有効搭載量…42 6.6. 内部の_IP6_NBNS…43 6.7. 内部の_アドレス_満期…43 6.8. 課題失敗を記述してください…44 7. 種々雑多な問題…45 7.1. _合っているID IPV4_ADDRと_ID IPV6_ADDR…45 7.2. RFC4301へのIKEv2の関係…45 7.3. ウィンドウサイズを減少させます…46 7.4. 一回だけの最小規模…46 7.5. ポート4500の上で八重奏に全く頭文字をつけないでください…46 7.6. NAT縦断のための目的地港…47 7.7. IKE_SAの外のMessagesのためのSPI Values…47 7.8. プロトコルID/SPI分野は中で有効搭載量に通知します…48 7.9. どのメッセージがINITIAL_CONTACTを含むべきであるか…48 7.10. 有効搭載量の整列…48 7.11. キー長変換属性…48 7.12. IPsec IANA問題…49 7.13. そして、超能力を結合する、ああ…50 8. 実現誤り…50 9. セキュリティ問題…51 10. 承認…51 11. 参照…51 11.1. 標準の参照…51 11.2. 有益な参照…52回の付録A.交換と有効搭載量…54 A.1。 イケ_SA_イニット交換…54 A.2。 EAPのないイケ_AUTH交換…54 A.3。 EAPとのイケ_AUTH交換…55 A.4。 _作成/Rekeying子供_SAsへの子供_SA交換を引き起こしてください…56 A.5。 _Rekeying IKE_SAへの子供_SA交換を引き起こしてください…56 A.6。 情報の交換…56
Eronen & Hoffman Informational [Page 3] RFC 4718 IKEv2 Clarifications October 2006
[3ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
1. Introduction
1. 序論
This document clarifies many areas of the IKEv2 specification that may be difficult to understand to developers not intimately familiar with the specification and its history. The clarifications in this document come from the discussion on the IPsec WG mailing list, from experience in interoperability testing, and from implementation issues that have been brought to the editors' attention.
このドキュメントは親密に仕様とその歴史に詳しくない開発者に理解しているのが難しいかもしれないIKEv2仕様の多くの領域をはっきりさせます。 明確化はIPsec WGメーリングリストについての議論から本書では来ます、相互運用性テストであることと、そして、エディタに注目していただかれた導入問題からの経験から。
IKEv2/IPsec can be used for several different purposes, including IPsec-based remote access (sometimes called the "road warrior" case), site-to-site virtual private networks (VPNs), and host-to-host protection of application traffic. While this document attempts to consider all of these uses, the remote access scenario has perhaps received more attention here than the other uses.
いくつかの異なる役割にIKEv2/IPsecを使用できます、IPsecベースの遠隔アクセス(時々「道行く戦士」ケースと呼ばれる)、サイトからサイトへの仮想私設網(VPNs)、およびホストからホストへのアプリケーション交通の保護を含んでいて。 このドキュメントは、これらの用途のすべてを考えるのを試みますが、遠隔アクセスのシナリオは恐らくここでのもう片方が使用するより多くの配慮を受けました。
This document does not place any requirements on anyone and does not use [RFC2119] keywords such as "MUST" and "SHOULD", except in quotations from the original IKEv2 documents. The requirements are given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic algorithms document [IKEv2ALG].
このドキュメントは、どんな要件もだれにも置かないで、また“MUST"や“SHOULD"などの[RFC2119]キーワードを使用しません、オリジナルのIKEv2ドキュメントからの引用を除いて。 IKEv2仕様[IKEv2]とIKEv2暗号アルゴリズムドキュメント[IKEv2ALG]で要件を与えます。
In this document, references to a numbered section (such as "Section 2.15") mean that section in [IKEv2]. References to mailing list messages or threads refer to the IPsec WG mailing list at ipsec@ietf.org. Archives of the mailing list can be found at <http://www.ietf.org/mail-archive/web/ipsec/index.html>.
本書では、aの参照はセクションに付番しました。(「セクション2.15インチ) 中で[IKEv2]を区分する平均」などのように。 メーリングリストメッセージか糸の参照は ipsec@ietf.org のIPsec WGメーリングリストを示します。 <メールhttp://www.ietf.org/アーカイブ/ウェブ/ipsec/index.html>でメーリングリストのアーカイブを見つけることができます。
2. Creating the IKE_SA
2. IKE_SAを作成します。
2.1. SPI Values in IKE_SA_INIT Exchange
2.1. イケ_SA_イニット交換におけるSPI値
Normal IKE messages include the initiator's and responder's Security Parameter Indexes (SPIs), both of which are non-zero, in the IKE header. However, there are some corner cases where the IKEv2 specification is not fully consistent about what values should be used.
正常なIKEメッセージは創始者と応答者のSecurity Parameter Indexes(SPIs)を含んでいます、IKEヘッダーで。その両方が非ゼロです。 しかしながら、いくつかの角のケースがどんな値が使用されるべきであるかに関してIKEv2仕様が完全に一貫しているというわけではないところにあります。
First, Section 3.1 says that the Responder's SPI "...MUST NOT be zero in any other message" (than the first message of the IKE_SA_INIT exchange). However, the figure in Section 2.6 shows the second IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text in 3.1.
「まず最初にセクション3.1がそれを言う、ResponderのSPI、」 …「いかなる他のゼロもメッセージであったに違いないなら」(イケ_SA_INIT交換の最初のメッセージより)。 しかしながら、3.1におけるテキストに矛盾して、セクション2.6の図は「HDR(A、0)、N(クッキー)」として2番目のイケ_SA_INITメッセージを示しています。
Since the responder's SPI identifies security-related state held by the responder, and in this case no state is created, sending a zero value seems reasonable.
応答者のSPIが応答者によって保持されたセキュリティ関連の状態を特定して、この場合状態が全く創設されないので、ゼロが評価する発信は妥当に思えます。
Eronen & Hoffman Informational [Page 4] RFC 4718 IKEv2 Clarifications October 2006
[4ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
Second, in addition to cookies, there are several other cases when the IKE_SA_INIT exchange does not result in the creation of an IKE_SA (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). What responder SPI value should be used in the IKE_SA_INIT response in this case?
イケ_SA_INIT交換がIKE_SA(例えば、INVALID_KE_有効搭載量にもかかわらず、_PROPOSAL_CHOSENがない)の創造をもたらさないとき、2番目に、クッキーに加えて、他の数個のケースがいます。 どんな応答者SPI価値がこの場合イケ_SA_INIT応答に使用されるべきですか?
Since the IKE_SA_INIT request always has a zero responder SPI, the value will not be actually used by the initiator. Thus, we think sending a zero value is correct also in this case.
応答者SPI、INITが要求するイケ_SA_がいつもゼロを持っているので、値は実際に創始者によって使用されないでしょう。 したがって、私たちは、ゼロが評価する発信がこの場合も正しいと思います。
If the responder sends a non-zero responder SPI, the initiator should not reject the response only for that reason. However, when retrying the IKE_SA_INIT request, the initiator will use a zero responder SPI, as described in Section 3.1: "Responder's SPI [...] This value MUST be zero in the first message of an IKE Initial Exchange (including repeats of that message including a cookie) [...]". We believe the intent was to cover repeats of that message due to other reasons, such as INVALID_KE_PAYLOAD, as well.
SPI、応答者が非ゼロ応答者を送るなら、創始者は単にその理由で応答を拒絶するべきではありません。 しかしながら、INITが要求するイケ_SA_を再試行するとき、創始者はセクション3.1で説明されるように応答者SPIを全く使用しないでしょう: 「応答者のSPI[…]」 「この値はIKE Initial Exchange(クッキーを含むそのメッセージの反復を含んでいる)[…]の最初のメッセージのゼロでなければなりません。」 私たちは、意図がまた、INVALID_KE_有効搭載量などの他の理由のためそのメッセージの反復をカバーすることであったと信じています。
(References: "INVALID_KE_PAYLOAD and clarifications document" thread, Sep-Oct 2005.)
(参照: 「INVALID_KE_有効搭載量と明確化ドキュメント」は2005年9月-10月に縫うように通ります。)
2.2. Message IDs for IKE_SA_INIT Messages
2.2. イケ_SA_イニットメッセージのためのメッセージID
The Message ID for IKE_SA_INIT messages is always zero. This includes retries of the message due to responses such as COOKIE and INVALID_KE_PAYLOAD.
いつもイケ_SA_INITメッセージのためのMessage IDはゼロです。 これはCOOKIEやINVALID_KE_有効搭載量などの応答のためメッセージの再試行を含んでいます。
This is because Message IDs are part of the IKE_SA state, and when the responder replies to IKE_SA_INIT request with N(COOKIE) or N(INVALID_KE_PAYLOAD), the responder does not allocate any state.
これがMessage IDがIKE_SA状態の一部であるからである応答者がINITがN(COOKIE)かN(INVALID_KE_有効搭載量)と共に要求するイケ_SA_に答える場合、応答者は少しの状態も割り当てません。
(References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD) combination" thread, Oct 2004. Tero Kivinen's mail "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
(参照: 「質問およそN(COOKIE)とN(INVALID_KE_有効搭載量)組み合わせ」糸、「草稿eronen-ipsec-ikev2明確化02.txtのコメント」という10月2004日のTero Kivinenのメール、2005年4月5日)。
2.3. Retransmissions of IKE_SA_INIT Requests
2.3. イケ_SA_イニット要求のRetransmissions
When a responder receives an IKE_SA_INIT request, it has to determine whether the packet is a retransmission belonging to an existing "half-open" IKE_SA (in which case the responder retransmits the same response), or a new request (in which case the responder creates a new IKE_SA and sends a fresh response).
応答者がINITが要求するイケ_SA_を受け取るとき、それは、パケットが既存の「半開きな」IKE_SA(その場合、応答者は同じ応答を再送する)、または新しい要求に属す「再-トランスミッション」(その場合、新しいIKE_SAを作成して、応答者は、新鮮な応答を送る)であるかどうか決定しなければなりません。
The specification does not describe in detail how this determination is done. In particular, it is not sufficient to use the initiator's SPI and/or IP address for this purpose: two different peers behind a single NAT could choose the same initiator SPI (and the probability
仕様は詳細でありこの決断がどのように完了していたかを記述しません。 このために創始者のSPI、そして/または、IPアドレスを使用するのは特に、十分ではありません: ただ一つのNATの後ろの2人の異なった同輩が同じ創始者SPIを選ぶことができた、(確率
Eronen & Hoffman Informational [Page 5] RFC 4718 IKEv2 Clarifications October 2006
[5ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
of this happening is not necessarily small, since IKEv2 does not require SPIs to be chosen randomly). Instead, the responder should do the IKE_SA lookup using the whole packet or its hash (or at the minimum, the Ni payload which is always chosen randomly).
IKEv2が、SPIsが手当たりしだいに選ばれるのを必要としないのでこれでは、出来事が必ず小さいというわけではない、) 代わりに、応答者は、全体のパケットかその細切れ肉料理(または最小限、いつも手当たりしだいに選ばれているNiペイロードで)を使用することでIKE_SAルックアップをするべきです。
For all other packets than IKE_SA_INIT requests, looking up right IKE_SA is of course done based on the recipient's SPI (either the initiator or responder SPI depending on the value of the Initiator bit in the IKE header).
イケ_SA_INIT要求以外のパケットに関しては、右のIKE_SAは受取人のSPI(IKEヘッダーのInitiatorビットの価値に依存する創始者か応答者SPIのどちらか)に基づいてもちろん見上げられます。
2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD
2.4. クッキーと無効の_KE_ペイロードの相互作用
There are two common reasons why the initiator may have to retry the IKE_SA_INIT exchange: the responder requests a cookie or wants a different Diffie-Hellman group than was included in the KEi payload. Both of these cases are quite simple alone, but it is not totally obvious what happens when they occur at the same time, that is, the IKE_SA_INIT exchange is retried several times.
創始者がイケ_SA_INIT交換を再試行しなければならないかもしれない2つの一般的な理由があります: 応答者は、クッキーを要求するか、またはKEiペイロードに含まれていたのと異なったディフィー-ヘルマングループが欲しいです。 これらのケースの両方が単独でかなり簡単ですが、同時に起こると起こること、すなわち、イケ_SA_INIT交換が何度か再試行されるのは、完全に明白であるというわけではありません。
The main question seems to be the following: if the initiator receives a cookie from the responder, should it include the cookie in only the next retry of the IKE_SA_INIT request, or in all subsequent retries as well? Section 3.10.1 says that:
主な質問は以下であるように思えます: 創始者が応答者からクッキーを受け取るなら、それはINITが要求するイケ_SA_の次の再試行だけ、またはまた、すべてのその後の再試行にクッキーを含むべきですか? セクション3.10 .1 それを言います:
"This notification MUST be included in an IKE_SA_INIT request
retry if a COOKIE notification was included in the initial
response."
「COOKIE通知が初期の応答に含まれていたなら、イケ_SA_INIT要求再試行にこの通知を含まなければなりません。」
This could be interpreted as saying that when a cookie is received in the initial response, it is included in all retries. On the other hand, Section 2.6 says that:
初期の応答でクッキーを受け取るとき、すべての再試行にそれを含んでいると言いながら、これを解釈できました。 他方では、セクション2.6は、以下のことと言います。
"Initiators who receive such responses MUST retry the
IKE_SA_INIT with a Notify payload of type COOKIE containing
the responder supplied cookie data as the first payload and
all other payloads unchanged."
「そのような応答を受ける創始者は変わりがない状態でタイプCOOKIEのNotifyペイロードが応答者を含んでいるINITが最初のペイロードと他のすべてのペイロードとしてクッキーデータを提供したイケ_SA_を再試行しなければなりません。」
Including the same cookie in later retries makes sense only if the "all other payloads unchanged" restriction applies only to the first retry, but not to subsequent retries.
後の再試行に同じクッキーを含んでいると意味だけがなられる、「他のすべてのペイロード、変わりのなさ、」 制限は、最初の再試行だけに適用しますが、その後の再試行に適用されるというわけではありません。
It seems that both interpretations can peacefully coexist. If the initiator includes the cookie only in the next retry, one additional roundtrip may be needed in some cases:
両方の解釈が平和に共存できるように思えます。 創始者が次の再試行だけでクッキーを入れるなら、いくつかの場合、1つの追加往復旅行が必要であるかもしれません:
Eronen & Hoffman Informational [Page 6] RFC 4718 IKEv2 Clarifications October 2006
[6ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), SAi1, KEi', Ni -->
<-- HDR(A,0), N(COOKIE')
HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
創始者応答者----------- ----------- Ni..クッキー..クッキー..Ni..無効..ペイロード..Ni..クッキー..クッキー..Ni
An additional roundtrip is needed also if the initiator includes the cookie in all retries, but the responder does not support this functionality. For instance, if the responder includes the SAi1 and KEi payloads in cookie calculation, it will reject the request by sending a new cookie (see also Section 2.5 of this document for more text about invalid cookies):
また、創始者がすべての再試行でクッキーを入れるなら、追加往復旅行が必要ですが、応答者はこの機能性を支持しません。 例えば、応答者がクッキー計算でSAi1とKEiペイロードを入れると、新しいクッキー(また、無効のクッキーに関する、より多くのテキストのためのこのドキュメントのセクション2.5を見る)を送ることによって、要求を拒絶するでしょう:
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
<-- HDR(A,0), N(COOKIE')
HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
創始者応答者----------- ----------- Ni..クッキー..クッキー..Ni..無効..ペイロード..クッキー..Ni..クッキー..クッキー..Ni
If both peers support including the cookie in all retries, a slightly shorter exchange can happen:
両方の同輩が、すべての再試行にクッキーを含んでいるのを支持するなら、わずかに短い交換は起こることができます:
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
創始者応答者----------- ----------- 'HDR(A、0)、SAi1、KEi、Ni--><--HDR(A、0)、N(クッキー)HDR(A、0)、N(クッキー)、SAi1、KEi、Ni--><--HDR(A、0)、N(無効の_KE_ペイロード)HDR(A、0)、N(クッキー)、SAi1、KEi'、Ni--><--HDR(A、B)、SAr1、KEr、Nr
This document recommends that implementations should support this shorter exchange, but it must not be assumed the other peer also supports the shorter exchange.
このドキュメントは、実現がこのより短い交換を支持するべきであることを勧めますが、また、もう片方の同輩が、より短い交換を支持すると思われてはいけません。
Eronen & Hoffman Informational [Page 7] RFC 4718 IKEv2 Clarifications October 2006
[7ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
In theory, even this exchange has one unnecessary roundtrip, as both the cookie and Diffie-Hellman group could be checked at the same time:
この交換でさえ、1つの不要な往復旅行があります、同時にクッキーとディフィー-ヘルマンが分類する両方をチェックできたとき:
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE),
N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi',Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
創始者応答者----------- ----------- 'Ni--><--HDR(A、0)、SAi1、KEi、HDR(A、0)、N(クッキー)、N(無効の_KE_ペイロード)HDR(A、0)、N(クッキー)、SAi1、KEi'、Ni--><--HDR(A、B)、SAr1、KEr、Nr
However, it is clear that this case is not allowed by the text in Section 2.6, since "all other payloads" clearly includes the KEi payload as well.
しかしながら、本件がセクション2.6のテキストによって許容されていないのは、明確です、「他のすべてのペイロード」が明確にまた、KEiペイロードを含んでいるので。
(References: "INVALID_KE_PAYLOAD and clarifications document" thread, Sep-Oct 2005.)
(参照: 「INVALID_KE_有効搭載量と明確化ドキュメント」は2005年9月-10月に縫うように通ります。)
2.5. Invalid Cookies
2.5. 無効のクッキー
There has been some confusion what should be done when an IKE_SA_INIT
request containing an invalid cookie is received ("invalid" in the
sense that its contents do not match the value expected by the
responder).
何らかの混乱がありました。無効のクッキーを含むINITが要求するイケ_SA_が受け取られているとき(内容が応答者によって予想された値に合っていないという意味で「無効」の)するべきであること。
The correct action is to ignore the cookie and process the message as if no cookie had been included (usually this means sending a response containing a new cookie). This is shown in Section 2.6 when it says "The responder in that case MAY reject the message by sending another response with a new cookie [...]".
正しい動作は、まるでクッキーが全く含まれていないかのように(通常新しいクッキーを含む応答を送るこの手段)、クッキーを無視して、メッセージを処理することです。 これはセクション2.6にそれが、いつ「応答者はその場合新しいクッキー[…]で別の応答を送ることによって、メッセージを拒絶するかもしれません」と示すかが示されます。
Other possible actions, such as ignoring the whole request (or even all requests from this IP address for some time), create strange failure modes even in the absence of any malicious attackers and do not provide any additional protection against DoS attacks.
全体の要求(または、このIPからの要求がしばらく記述するすべてさえ)を無視などなどの他の可能な動作は、どんな悪意がある攻撃者がないときでさえ奇妙な故障モードを作成して、DoS攻撃に対して少しの追加保護も提供しません。
(References: "Invalid Cookie" thread, Sep-Oct 2005.)
(参照: 「無効のクッキー」糸、2005年9月-10月)。
Eronen & Hoffman Informational [Page 8] RFC 4718 IKEv2 Clarifications October 2006
[8ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
3. Authentication
3. 認証
3.1. Data Included in AUTH Payload Calculation
3.1. AUTH有効搭載量計算に含まれていたデータ
Section 2.15 describes how the AUTH payloads are calculated; this calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The text describes the method in words, but does not give clear definitions of what is signed or MACed (i.e., protected with a message authentication code).
セクション2.15はAUTHペイロードがどう計算されるかを説明します。 'この計算がprfに値を伴う、(SK_パイ、IDi、'、)、prf、(SK_pr、IDr、'、) テキストは、単語による方法を説明しますが、サインされるものかMACed(すなわち、メッセージ確認コードで、保護される)の明確な定義を与えません。
The initiator's signed octets can be described as:
創始者のサインされた八重奏を以下と説明できます。
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData
MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
InitiatorSignedOctetsはRealMessage1と等しいです。| NonceRData| MACedIDForI GenIKEHDR=[使用するなら、4つの八重奏0が4500を移植します]| RealIKEHDR RealIKEHDRはSPIiと等しいです。| SPIr| . . . | 長さのRealMessage1はRealIKEHDRと等しいです。| RestOfMessage1 NonceRPayloadはPayloadHeaderと等しいです。| NonceRData InitiatorIDPayloadはPayloadHeaderと等しいです。| RestOfIDPayload RestOfInitIDPayloadはIDTypeと等しいです。| 予約されます。| InitIDData MACedIDForIはprfと等しいです。(SK_パイ、RestOfInitIDPayload)
The responder's signed octets can be described as:
応答者のサインされた八重奏を以下と説明できます。
ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage2 = RealIKEHDR | RestOfMessage2
NonceIPayload = PayloadHeader | NonceIData
ResponderIDPayload = PayloadHeader | RestOfIDPayload
RestOfRespIDPayload = IDType | RESERVED | InitIDData
MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
ResponderSignedOctetsはRealMessage2と等しいです。| NonceIData| MACedIDForR GenIKEHDR=[使用するなら、4つの八重奏0が4500を移植します]| RealIKEHDR RealIKEHDRはSPIiと等しいです。| SPIr| . . . | 長さのRealMessage2はRealIKEHDRと等しいです。| RestOfMessage2 NonceIPayloadはPayloadHeaderと等しいです。| NonceIData ResponderIDPayloadはPayloadHeaderと等しいです。| RestOfIDPayload RestOfRespIDPayloadはIDTypeと等しいです。| 予約されます。| InitIDData MACedIDForRはprfと等しいです。(SK_pr、RestOfRespIDPayload)
3.2. Hash Function for RSA Signatures
3.2. RSA署名のためのハッシュ関数
Section 3.8 says that RSA digital signature is "Computed as specified in section 2.15 using an RSA private key over a PKCS#1 padded hash."
セクション3.8は、RSAデジタル署名が「セクション2.15でPKCSの上でRSA秘密鍵を使用することで指定されるように計算されて、#1、は細切れ肉料理を水増しした」ということであると言います。
Unlike IKEv1, IKEv2 does not negotiate a hash function for the IKE_SA. The algorithm for signatures is selected by the signing party who, in general, may not know beforehand what algorithms the verifying party supports. Furthermore, [IKEv2ALG] does not say what algorithms implementations are required or recommended to support. This clearly has a potential for causing interoperability problems, since authentication will fail if the signing party selects an algorithm that is not supported by the verifying party, or not acceptable according to the verifying party's policy.
IKEv1と異なって、IKEv2はIKE_SAのためにハッシュ関数を交渉しません。 署名のためのアルゴリズムは一般に、あらかじめ検証パーティーがどんなアルゴリズムを支持するかを知らないかもしれない調印パーティーによって選択されます。 その上、[IKEv2ALG]は、実現がどんなアルゴリズムを支持することが必要である、または勧められるかを言いません。 これで、調印パーティーが検証パーティーによって支持されないアルゴリズムを選択すると認証が失敗するので相互運用性問題を引き起こす可能性は明確に検証パーティーの方針によると、許容できるようになります。
Eronen & Hoffman Informational [Page 9] RFC 4718 IKEv2 Clarifications October 2006
[9ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
This document recommends that all implementations support SHA-1 and use SHA-1 as the default hash function when generating the signatures, unless there are good reasons (such as explicit manual configuration) to believe that the peer supports something else.
このドキュメントは、署名を発生させるとき、すべての実現がデフォルトハッシュ関数としてSHA-1を支持して、SHA-1を使用することを勧めます、同輩が他の何かを支持すると信じるためにもっともな理由(明白な手動の構成などの)がない場合。
Note that hash function collision attacks are not important for the AUTH payloads, since they are not intended for third-party verification, and the data includes fresh nonces. See [HashUse] for more discussion about hash function attacks and IPsec.
AUTHペイロードには、ハッシュ関数衝突攻撃が重要でないことに注意してください、彼らが第三者検証のために意図しないで、データが新鮮な一回だけを含んでいるので。 ハッシュ関数の攻撃とIPsecについての、より多くの議論に関して[HashUse]を見てください。
Another reasonable choice would be to use the hash function that was used by the CA when signing the peer certificate. However, this does not guarantee that the IKEv2 peer would be able to validate the AUTH payload, because the same code might not be used to validate certificate signatures and IKEv2 message signatures, and these two routines may support a different set of hash algorithms. The peer could be configured with a fingerprint of the certificate, or certificate validation could be performed by an external entity using [SCVP]. Furthermore, not all CERT payloads types include a signature, and the certificate could be signed with some algorithm other than RSA.
別の正当な選択は同輩証明書にサインするときカリフォルニアによって使用されたハッシュ関数を使用するだろうことです。 しかしながら、これは、IKEv2同輩がAUTHペイロードを有効にすることができるのを保証しません、同じコードが証明書署名とIKEv2メッセージ署名を有効にするのに使用されないかもしれなくて、これらの2つのルーチンが異なったセットの細切れ肉料理アルゴリズムを支持するかもしれないので。証明書の指紋で同輩を構成できましたか、または外部実体で[SCVP]を使用することで証明書合法化は実行できるでしょう。 その上、すべてではなく、CERTペイロードタイプは署名を入れます、そして、RSA以外の何らかのアルゴリズムを証明書と契約できました。
Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20] signature encoding method (see next section for details), which includes the algorithm identifier for the hash algorithm. Thus, when the verifying party receives the AUTH payload it can at least determine which hash function was used.
IKEv1と異なって、IKEv2が細切れ肉料理アルゴリズムのためのアルゴリズム識別子を含んでいる方法(詳細に関して次のセクションを見る)をコード化するPKCS#1v1.5[PKCS1v20]署名を使用することに注意してください。 検証パーティーがAUTHペイロードを受け取るとき、したがって、それは、どのハッシュ関数が使用されたかを少なくとも決定できます。
(References: Magnus Alstrom's mail "RE:", 2005-01-03. Pasi Eronen's reply, 2005-01-04. Tero Kivinen's reply, 2005-01-04. "First draft of IKEv2.1" thread, Dec 2005/Jan 2006.)
2005年1月4日「RE:」という(の参照: マグヌスAlstromメール、2005年1月3日パシEronenの回答、「IKEv2.1"の最初の草稿は2006)年12月の2005/1月に糸を通す」Tero Kivinenの回答(2005年1月4日)
3.3. Encoding Method for RSA Signatures
3.3. RSA署名のための方法をコード化します。
Section 3.8 says that the RSA digital signature is "Computed as specified in section 2.15 using an RSA private key over a PKCS#1 padded hash."
セクション3.8は、RSAデジタル署名が「セクション2.15でPKCSの上でRSA秘密鍵を使用することで指定されるように計算されて、#1、は細切れ肉料理を水増しした」ということであると言います。
The PKCS#1 specification [PKCS1v21] defines two different encoding methods (ways of "padding the hash") for signatures. However, the Internet-Draft approved by the IESG had a reference to the older PKCS#1 v2.0 [PKCS1v20]. That version has only one encoding method for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity.
PKCS#1仕様[PKCS1v21]は署名のための2つの異なったコード化方法(「細切れ肉料理を水増しします」の道)を定義します。 しかしながら、IESGによって承認されたインターネット草稿は、より古いPKCS#1v2.0[PKCS1v20]の参照を持っていました。 そのバージョンには、署名(EMSA-PKCS1-v1_5)のための方法をコード化する1つしかありません、そして、その結果、あいまいさが全くありません。
Eronen & Hoffman Informational [Page 10] RFC 4718 IKEv2 Clarifications October 2006
[10ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
Note that this encoding method is different from the encoding method used in IKEv1. If future revisions of IKEv2 provide support for other encoding methods (such as EMSA-PSS), they will be given new Auth Method numbers.
このコード化方法がIKEv1で使用されるコード化方法と異なっていることに注意してください。 IKEv2の今後の改正が他のコード化方法(EMSA-PSSなどの)のサポートを提供すると、新しいAuth Method番号を彼らに与えるでしょう。
(References: Pasi Eronen's mail "RE:", 2005-01-04.)
(参照: 「RE:」というパシEronenのメール、2005年1月4日)。
3.4. Identification Type for EAP
3.4. EAPのための識別タイプ
Section 3.5 defines several different types for identification payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID. EAP [EAP] does not mandate the use of any particular type of identifier, but often EAP is used with Network Access Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like email addresses (e.g., "joe@example.com"), the syntax is not exactly the same as the syntax of email address in [RFC822]. This raises the question of which identification type should be used.
セクション3.5は例えば、識別ペイロード、包含、__ID FQDN、ID RFC822_ADDR、およびID_KEY_IDのためのいくつかの異なったタイプを定義します。 EAP[EAP]はどんな特定のタイプに関する識別子の使用も強制しませんが、しばしば、EAPは[NAI]で定義されるNetwork Access Identifiers(NAIs)と共に使用されます。 NAIsはEメールアドレス(例えば、" joe@example.com ")に少し似ていますが、構文はまさに[RFC822]のEメールアドレスの構文と同じではありません。 これは識別タイプが使用されるべきである疑問を引き起こします。
This document recommends that ID_RFC822_ADDR identification type is used for those NAIs that include the realm component. Therefore, responder implementations should not attempt to verify that the contents actually conform to the exact syntax given in [RFC822] or [RFC2822], but instead should accept any reasonable looking NAI.
このドキュメントは、ID_RFC822_ADDR識別タイプが分野コンポーネントを含んでいるそれらのNAIsに使用されることを勧めます。 したがって、応答者実現は、内容が実際に[RFC822]か[RFC2822]で与えられた正確な構文に従うことを確かめるのを試みるべきではありませんが、代わりにNAIに見えながら、いずれも妥当であると受け入れるべきです。
For NAIs that do not include the realm component, this document recommends using the ID_KEY_ID identification type.
分野コンポーネントを含んでいないNAIsに関しては、このドキュメントは、ID_KEY_ID識別タイプを使用することを勧めます。
(References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2 identifier issue with EAP" threads, Aug 2004.)
(参照: 「このIKEv2/i18n/EAPにおけるあなたの助けが発行する必要性」と「EAPのIKEv2識別子問題」糸、2004年8月)。
3.5. Identity for Policy Lookups When Using EAP
3.5. アイデンティティ、方針ルックアップいつ使用EAP
When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method (see [EAP], Sections 5.1 and 7.3).
創始者認証がEAPを使用するとき、IDiペイロードのコンテンツが、AAAルーティング目的にだけ使用されて、どのEAP方法を使用したらよいかを選択しているのは、可能です。 この値はEAP方法で認証されたアイデンティティと異なっているかもしれません([EAP]、セクション5.1と7.3を見てください)。
It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder using, e.g., RADIUS [RADEAP]. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder.
方針ルックアップとアクセス管理決定が実際の認証されたアイデンティティを使用するのは、重要です。 しばしば、EAPサーバはIKEv2応答者使用(例えば、RADIUS[RADEAP])で交信する別々のAAAサーバで実行されます。 この場合、AAAサーバからIKEv2応答者に認証されたアイデンティティを送らなければなりません。
(References: Pasi Eronen's mail "RE: Reauthentication in IKEv2", 2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748, Section 7.3.)
(が参照: パシEronen郵送する、「IKEv2"のRE:Reauthentication、2004年10月28日「方針ルックアップ」糸、2004年10月/11月のRFC3748、セクション7.3)」
Eronen & Hoffman Informational [Page 11] RFC 4718 IKEv2 Clarifications October 2006
[11ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
3.6. Certificate Encoding Types
3.6. タイプをコード化する証明書
Section 3.6 defines a total of twelve different certificate encoding types, and continues that "Specific syntax is for some of the certificate type codes above is not defined in this document." However, the text does not provide references to other documents that would contain information about the exact contents and use of those values.
セクション3.6は、タイプをコード化する合計12の異なった証明書を定義して、「特定の構文は証明書タイプにおいて、上のコードが本書では定義されないということです。」と続けています。 しかしながら、テキストはそれらの値の正確なコンテンツと使用の情報を含む他のドキュメントの参照を提供しません。
Without this information, it is not possible to develop interoperable implementations. Therefore, this document recommends that the following certificate encoding values should not be used before new specifications that specify their use are available.
この情報がなければ、共同利用できる実現を開発するのは可能ではありません。 したがって、このドキュメントは、彼らの使用を指定する新しい仕様が利用可能になる前に値をコード化する以下の証明書が使用されるべきでないことを勧めます。
PKCS #7 wrapped X.509 certificate 1
PGP Certificate 2
DNS Signed Key 3
Kerberos Token 6
SPKI Certificate 9
PKCS#7はX.509の証明書の1PGP Certificate2のDNS Signed Key3ケルベロスToken6SPKI Certificate9を包装しました。
This document recommends that most implementations should use only those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e., "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle" (13).
このドキュメントは、ほとんどの実現が[IKEv2]で“MUST"/"SHOULD"要件であるそれらの唯一の値を使用するべきであることを勧めます。 すなわち、「X.509、証明書--署名、」 (4)、「生のRSAキー」(11)、「X.509証明書の細切れ肉料理とURL」(12)、および「X.509バンドルの細切れ肉料理とURL」(13)。
Furthermore, Section 3.7 says that the "Certificate Encoding" field for the Certificate Request payload uses the same values as for Certificate payload. However, the contents of the "Certification Authority" field are defined only for X.509 certificates (presumably covering at least types 4, 10, 12, and 13). This document recommends that other values should not be used before new specifications that specify their use are available.
その上、セクション3.7は、Certificate Requestペイロードのための「証明書コード化」分野がCertificateペイロードのように同じ値を使用すると言います。 しかしながら、「認証局」分野の内容はX.509証明書のためだけに定義されます(おそらく、少なくともタイプ4、10、12、および13をカバーしていて)。 このドキュメントは、彼らの使用を指定する新しい仕様が利用可能になる前に他の値が使用されるべきでないことを勧めます。
The "Raw RSA Key" type needs one additional clarification. Section 3.6 says it contains "a PKCS #1 encoded RSA key". What this means is a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21].
「生のRSAキー」タイプは1つの追加明確化を必要とします。 セクション3.6は、「PKCS#1のコード化されたRSAキー」を含むと言います。 これが意味することはPKCS#1[PKCS1v21]からのDERによってコード化されたRSAPublicKey構造です。
3.7. Shared Key Authentication and Fixed PRF Key Size
3.7. 共有された主要な認証と固定PRF主要なサイズ
Section 2.15 says that "If the negotiated prf takes a fixed-size key, the shared secret MUST be of that fixed size". This statement is correct: the shared secret must be of the correct size. If it is not, it cannot be used; there is no padding, truncation, or other processing involved to force it to that correct size.
「交渉されたprfが固定サイズキーを取るなら、共有秘密キーはサイズが固定されたそれのものであるに違いありません。」と、セクション2.15は言います。 この声明は正しいです: 共有秘密キーは適度のサイズのものであるに違いありません。 それがそうでないなら、それを使用できません。 それをその適度のサイズまで強制するためにかかわるどんなそっと歩いているか、トランケーションの、または、他の処理もありません。
Eronen & Hoffman Informational [Page 12] RFC 4718 IKEv2 Clarifications October 2006
[12ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
This requirement means that it is difficult to use these pseudo- random functions (PRFs) with shared key authentication. The authors think this part of the specification was very poorly thought out, and using PRFs with a fixed key size is likely to result in interoperability problems. Thus, we recommend that such PRFs should not be used with shared key authentication. PRF_AES128_XCBC [RFC3664] originally used fixed key sizes; that RFC has been updated to handle variable key sizes in [RFC4434].
この要件は、共有された主要な認証があるこれらの疑似確率関数(PRFs)を使用するのが難しいことを意味します。 作者は、仕様のこの部分が非常に不十分に考え抜かれたと考えます、そして、固定主要なサイズがあるPRFsを使用するのは相互運用性問題をもたらしそうです。その結果、私たちは、そのようなPRFsが共有された主要な認証と共に使用されるべきでないことを勧めます。 XCBC[RFC3664]が元々使用したPRF_AES128_は主要なサイズを固定しました。 [RFC4434]で可変主要なサイズを扱うためにそのRFCをアップデートしました。
Note that Section 2.13 also contains text that is related to PRFs with fixed key size: "When the key for the prf function has fixed length, the data provided as a key is truncated or padded with zeros as necessary unless exceptional processing is explained following the formula". However, this text applies only to the prf+ construction, so it does not contradict the text in Section 2.15.
また、セクション2.13が固定主要なサイズがあるPRFsに関連するテキストを含むことに注意してください: 「prf機能のためのキーには固定長があって、公式に従って、例外的な処理が説明されない場合、キーとして提供されたデータは、先端を切られるか、またはゼロが必要な状態で水増しされます。」 しかしながら、本稿がprf+工事だけに適用されるので、それはセクション2.15のテキストに矛盾しません。
(References: Paul Hoffman's mail "Re: ikev2-07: last nits", 2003-05-02. Hugo Krawczyk's reply, 2003-05-12. Thread "Question about PRFs with fixed size key", Jan 2005.)
(参照: 2003年5月2日「Re: ikev2-07: 最後の夜」というポール・ホフマンのメール、ユーゴーKrawczykの回答(2003年5月12日)は「固定サイズキーがあるPRFsに関する質問」に糸を通します、2005年1月。)
3.8. EAP Authentication and Fixed PRF Key Size
3.8. EAP認証と固定PRF主要なサイズ
As described in the previous section, PRFs with a fixed key size require a shared secret of exactly that size. This restriction applies also to EAP authentication. For instance, a PRF that requires a 128-bit key cannot be used with EAP since [EAP] specifies that the MSK is at least 512 bits long.
前項で説明されるように、固定主要なサイズがあるPRFsはちょうどそのサイズに関する共有秘密キーを必要とします。 また、この制限はEAP認証に適用されます。 例えば、[EAP]が、MSKが長さ少なくとも512ビットであると指定するので、EAPと共に128ビットのキーを必要とするPRFは使用できません。
(References: Thread "Question about PRFs with fixed size key", Jan 2005.)
(参照: 2005年1月に「固定サイズキーがあるPRFsに関する質問」に糸を通してください。)
3.9. Matching ID Payloads to Certificate Contents
3.9. コンテンツを証明するためにID有効搭載量を合わせます。
In IKEv1, there was some confusion about whether or not the identities in certificates used to authenticate IKE were required to match the contents of the ID payloads. The PKI4IPsec Working Group produced the document [PKI4IPsec] which covers this topic in much more detail. However, Section 3.5 of [IKEv2] explicitly says that the ID payload "does not necessarily have to match anything in the CERT payload".
IKEv1に、何らかの混乱がIKEを認証するのに使用される証明書のアイデンティティがIDペイロードのコンテンツを合わせるのに必要であったかどうかありました。 PKI4IPsec作業部会はずっと多くの詳細にこの話題に関するドキュメント[PKI4IPsec]を製作しました。 しかしながら、[IKEv2]のセクション3.5は、IDペイロードが「必ず、CERTペイロードの何も合わせる必要はない」と明らかに言います。
Eronen & Hoffman Informational [Page 13] RFC 4718 IKEv2 Clarifications October 2006
[13ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
3.10. Message IDs for IKE_AUTH Messages
3.10. イケ_AUTHメッセージのためのメッセージID
According to Section 2.2, "The IKE_SA initial setup messages will always be numbered 0 and 1." That is true when the IKE_AUTH exchange does not use EAP. When EAP is used, each pair of messages has their message numbers incremented. The first pair of AUTH messages will have an ID of 1, the second will be 2, and so on.
セクション2.2によると、「IKE_SAの初期のセットアップメッセージは、いつも番号付の0と1になるでしょう」。 イケ_AUTH交換がEAPを使用しないとき、それは本当です。 EAPが使用されているとき、それぞれの組のメッセージで、それらのメッセージ番号を増加します。 2番目は、AUTHメッセージの最初の組には、1のIDがあって、2などになるでしょう。
(References: "Question about MsgID in AUTH exchange" thread, April 2005.)
(参照: 「AUTH交換におけるMsgIDに関する質問」糸、2005年4月)。
4. Creating CHILD_SAs
4. 子供_SAsを作成します。
4.1. Creating SAs with the CREATE_CHILD_SA Exchange
4.1. SAsを作成する、_子供_SA交換を引き起こしてください。
Section 1.3's organization does not lead to clear understanding of what is needed in which environment. The section can be reorganized with subsections for each use of the CREATE_CHILD_SA exchange (creating child SAs, rekeying IKE SAs, and rekeying child SAs.)
セクション1.3の組織はどの環境に必要であるものに関する明確な理解につながりません。 CREATE_CHILD_SA交換の各使用のために小区分でセクションを再編成できます。(子供SAs、rekeying IKE SAsを作成して、子供SAsを「再-合わせ」ます。)
The new Section 1.3 with subsections and the above changes might look like the following.
小区分がある新しいセクション1.3と上の変化は以下に似るかもしれません。
NEW-1.3 The CREATE_CHILD_SA Exchange
新しい1.3、_子供_SA交換を引き起こしてください。
The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and
to rekey both IKE_SAs and CHILD_SAs. This exchange consists of
a single request/response pair, and some of its function was
referred to as a phase 2 exchange in IKEv1. It MAY be initiated
by either end of the IKE_SA after the initial exchanges are
completed.
CREATE_CHILD_SA Exchangeは、IKE_SAsとCHILD_SAsの両方を新しいCHILD_SAsとrekeyに作成するのに使用されます。 この交換はIKEv1のフェーズ2交換と呼ばれた状態でただ一つの要求/応答組、および機能のいくつかから成ります。 初期の交換が終了した後にそれはIKE_SAのどちらの端までにも開始されるかもしれません。
All messages following the initial exchange are
cryptographically protected using the cryptographic algorithms
and keys negotiated in the first two messages of the IKE
exchange. These subsequent messages use the syntax of the
Encrypted Payload described in section 3.14. All subsequent
messages include an Encrypted Payload, even if they are referred
to in the text as "empty".
初期の交換に続くすべてのメッセージが、IKE交換に関する最初の2つのメッセージで交渉された暗号アルゴリズムとキーを使用することで暗号で保護されます。 これらのその後のメッセージはセクション3.14で説明されたEncrypted有効搭載量の構文を使用します。 それらがテキストに「空になってください」と呼ばれても、すべてのその後のメッセージがEncrypted有効搭載量を含んでいます。
The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs.
This section describes the first part of rekeying, the creation
of new SAs; Section 2.8 covers the mechanics of rekeying,
including moving traffic from old to new SAs and the deletion of
the old SAs. The two sections must be read together to
understand the entire process of rekeying.
CREATE_CHILD_SAはrekeying IKE_SAsとCHILD_SAsに使用されます。 このセクションは「再-合わせ」ることの最初の部分、新しいSAsの創造について説明します。 セクション2.8は「再-合わせ」ることの整備士を覆います、古いSAsの古いのから新しいSAsと削除までの交通を動かすのを含んでいて。 「再-合わせ」る全体の過程を理解するために2つのセクションを一緒に読まなければなりません。
Eronen & Hoffman Informational [Page 14] RFC 4718 IKEv2 Clarifications October 2006
[14ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
Either endpoint may initiate a CREATE_CHILD_SA exchange, so in
this section the term initiator refers to the endpoint
initiating this exchange. An implementation MAY refuse all
CREATE_CHILD_SA requests within an IKE_SA.
どちらの終点もCREATE_CHILD_SA交換を起こすかもしれないので、このセクションで、用語創始者はこの交換を起こす終点について言及します。 実現はIKE_SAの中で_CHILD_SA要求をすべてのCREATEに拒否するかもしれません。
The CREATE_CHILD_SA request MAY optionally contain a KE payload
for an additional Diffie-Hellman exchange to enable stronger
guarantees of forward secrecy for the CHILD_SA or IKE_SA. The
keying material for the SA is a function of SK_d established
during the establishment of the IKE_SA, the nonces exchanged
during the CREATE_CHILD_SA exchange, and the Diffie-Hellman
value (if KE payloads are included in the CREATE_CHILD_SA
exchange). The details are described in sections 2.17 and 2.18.
SAが要求するCREATE_CHILD_は任意に追加ディフィー-ヘルマンの交換がCHILD_SAかIKE_SAのために前進の秘密主義の、より強い保証を可能にするKEペイロードを含むかもしれません。 SAのための合わせることの材料はSA、CREATE_CHILD_SA交換の間に交換された一回だけ、およびディフィー-ヘルマンが評価するIKE_の設立の間に設立されたSKの機能(KEペイロードがCREATE_CHILD_SA交換に含まれているなら)です。 詳細はセクション2.17と2.18で説明されます。
If a CREATE_CHILD_SA exchange includes a KEi payload, at least
one of the SA offers MUST include the Diffie-Hellman group of
the KEi. The Diffie-Hellman group of the KEi MUST be an element
of the group the initiator expects the responder to accept
(additional Diffie-Hellman groups can be proposed). If the
responder rejects the Diffie-Hellman group of the KEi payload,
the responder MUST reject the request and indicate its preferred
Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification
payload. In the case of such a rejection, the CREATE_CHILD_SA
exchange fails, and the initiator SHOULD retry the exchange with
a Diffie-Hellman proposal and KEi in the group that the
responder gave in the INVALID_KE_PAYLOAD.
CREATE_CHILD_SA交換がKEiペイロードを含んでいるなら、少なくともSA申し出の1つはKEiのディフィー-ヘルマングループを含まなければなりません。 KEiのディフィー-ヘルマングループは受け入れる創始者が応答者を予想するグループの要素であるに違いありません(追加ディフィー-ヘルマングループを提案できます)。 応答者がKEiペイロードのディフィー-ヘルマングループを拒絶するなら、応答者は、要求を拒絶して、INVALID_KE_有効搭載量Notificationペイロードの都合のよいディフィー-ヘルマングループを示さなければなりません。 そのような拒絶の場合では、CREATE_CHILD_SA交換は失敗します、そして、創始者SHOULDは応答者がINVALID_KE_有効搭載量で与えたグループでディフィー-ヘルマンの提案とKEiとの交換を再試行します。
NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
新しい子供_SAsを作成する新しい1.3.1、_子供_SA交換を引き起こしてください。
A CHILD_SA may be created by sending a CREATE_CHILD_SA request.
The CREATE_CHILD_SA request for creating a new CHILD_SA is:
CHILD_SAは、SAが要求するCREATE_CHILD_を送ることによって、作成されるかもしれません。 SAが新しいCHILD_SAを作成するために要求するCREATE_CHILD_は以下の通りです。
Initiator Responder
----------- -----------
HDR, SK {[N+], SA, Ni, [KEi],
TSi, TSr} -->
創始者応答者----------- ----------- HDR、SK、[N+]、SA、Ni、[KEi]、TSi、TSr--、>。
The initiator sends SA offer(s) in the SA payload, a nonce in
the Ni payload, optionally a Diffie-Hellman value in the KEi
payload, and the proposed traffic selectors for the proposed
CHILD_SA in the TSi and TSr payloads. The request can also
contain Notify payloads that specify additional details for the
CHILD_SA: these include IPCOMP_SUPPORTED, USE_TRANSPORT_MODE,
ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO.
創始者はSAペイロード、Niペイロードの一回だけで任意に申し出をSAに送ります。KEiペイロードのディフィー-ヘルマン値、および提案されたCHILD_SAのためのTSiとTSrペイロードの提案された交通セレクタ。 また、要求はCHILD_SAのための追加詳細を指定するNotifyペイロードを含むことができます: これらはIPCOMP_SUPPORTED、USE_TRANSPORT_MODE、__SUPPORTEDではなく、超能力TFC_PADDING_、およびNON_FIRST_FRAGMENTS_ALSOを含んでいます。
Eronen & Hoffman Informational [Page 15] RFC 4718 IKEv2 Clarifications October 2006
[15ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
The CREATE_CHILD_SA response for creating a new CHILD_SA is:
新しいCHILD_SAを作成するためのCREATE_CHILD_SA応答は以下の通りです。
<-- HDR, SK {[N+], SA, Nr,
[KEr], TSi, TSr}
<--HDR、SK[N+]、SA、Nr、[KEr]、TSi、TSr
The responder replies with the accepted offer in an SA payload,
and a Diffie-Hellman value in the KEr payload if KEi was
included in the request and the selected cryptographic suite
includes that group. As with the request, optional Notification
payloads can specify additional details for the CHILD_SA.
応答者はSAペイロードにおける受け入れられた申し出で返答します、そして、KEiが要求と選択された暗号のスイートに含まれていたなら、KErペイロードのディフィー-ヘルマン値はそのグループを含んでいます。 要求なら、任意のNotificationペイロードはCHILD_SAのための追加詳細を指定できます。
The traffic selectors for traffic to be sent on that SA are
specified in the TS payloads in the response, which may be a
subset of what the initiator of the CHILD_SA proposed.
そのSAに送られる交通のための交通セレクタはTSペイロードで応答で指定されます。(それは、CHILD_SAの創始者が提案したことに関する部分集合であるかもしれません)。
The text about rekeying SAs can be found in Section 5.1 of this document.
このドキュメントのセクション5.1でrekeying SAsに関するテキストを見つけることができます。
4.2. Creating an IKE_SA without a CHILD_SA
4.2. 子供_SAなしでIKE_SAを作成します。
CHILD_SAs can be created either by being piggybacked on the IKE_AUTH exchange, or using a separate CREATE_CHILD_SA exchange. The specification is not clear about what happens if creating the CHILD_SA during the IKE_AUTH exchange fails for some reason.
イケ_AUTH交換のときに背負われるか、または別々のCREATE_CHILD_SA交換を使用していることによって、CHILD_SAsを作成できます。 仕様は_イケの間、CHILD_SAを作成するなら何が起こるかに関してAUTH交換がある理由で失敗するかが明確ではありません。
Our recommendation in this situation is that the IKE_SA is created as usual. This is also in line with how the CREATE_CHILD_SA exchange works: a failure to create a CHILD_SA does not close the IKE_SA.
この状況における私たちの推薦はIKE_SAが通常通りで作成されるということです。 CREATE_CHILD_SA交換がどう働いているかをもって線にはこれがあります: CHILD_SAを作成しない場合、IKE_SAを閉じません。
The list of responses in the IKE_AUTH exchange that do not prevent an IKE_SA from being set up include at least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
イケ_AUTH交換におけるIKE_SAがセットアップされるのを防がない応答のリストは少なくとも以下を含んでいます: _提案がない_が選ばれて、tの_容認できなくて、ただ一つの__必要で、内部の_の組アドレス_故障、および失敗した_CP_が必要です。
(References: "Questions about internal address" thread, April 2005.)
(参照: 「内部のアドレスに関する質問」は2005年4月に縫うように通ります。)
4.3. Diffie-Hellman for First CHILD_SA
4.3. 最初に、子供_SAのためのディフィー-ヘルマン
Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. This implies that the SA payload in IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with any other value than NONE. Implementations should probably leave the transform out entirely in this case.
セクション1.2は、イケ_AUTHメッセージがKEi/KErかNi/Nrペイロードを含まないのを示します。 これは、イケ_AUTH交換におけるSAペイロードがNONEよりいかなる他の値があるTransform Type4(ディフィー-ヘルマンGroup)も含むことができないのを含意します。 実現はこの場合たぶん変換を完全に省くべきです。
Eronen & Hoffman Informational [Page 16] RFC 4718 IKEv2 Clarifications October 2006
[16ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
4.4. Extended Sequence Numbers (ESN) Transform
4.4. 拡張配列番号(ESN)は変形します。
The description of the ESN transform in Section 3.3 has be proved difficult to understand. The ESN transform has the following meaning:
セクション3.3における、ESN変換の記述は理解しているのが難しいと立証されました。 ESN変換には、以下の意味があります:
o A proposal containing one ESN transform with value 0 means "do not
use extended sequence numbers".
o 値0に応じてESNが変える1つを含む提案は、「拡張配列番号を使用しないでください。」と意味します。
o A proposal containing one ESN transform with value 1 means "use
extended sequence numbers".
o 値1に応じてESNが変える1つを含む提案は、「拡張配列番号を使用します。」と意味します。
o A proposal containing two ESN transforms with values 0 and 1 means
"I support both normal and extended sequence numbers, you choose".
(Obviously this case is only allowed in requests; the response
will contain only one ESN transform.)
o 値0と1に応じてESNが変える2を含む提案は、「私が正常なものと同様に拡張している一連番号を支持します、とあなたは選びます。」と意味します。 (明らかに、本件は要求に許容されているだけです; 応答はESNが変える1つだけを含むでしょう。)
In most cases, the exchange initiator will include either the first or third alternative in its SA payload. The second alternative is rarely useful for the initiator: it means that using normal sequence numbers is not acceptable (so if the responder does not support ESNs, the exchange will fail with NO_PROPOSAL_CHOSEN).
多くの場合、交換創始者はSAペイロードにおける1番目か3番目の代替手段のどちらかを入れるでしょう。 2番目の代替手段はめったに創始者の役に立ちません: それは、標準の一連番号を使用するのが許容できないことを意味します(したがって、応答者がESNsを支持しないと、交換はどんな_PROPOSAL_CHOSENと共にも失敗しないでしょう)。
Note that including the ESN transform is mandatory when creating ESP/AH SAs (it was optional in earlier drafts of the IKEv2 specification).
超能力/AH SAsを作成するとき、ESN変換を含んでいるのが義務的であることに注意してください(それはIKEv2仕様の以前の草稿で任意でした)。
(References: "Technical change needed to IKEv2 before publication", "STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2" and "Results of straw poll regarding: IKEv2 interoperability issue" threads, March-April 2005.)
(参照: 「公表の前にIKEv2に必要であった技術変化」「STRAW POLL: IKEv2"でESN交渉interop問題に対処して、「非公式世論調査関係: IKEv2相互運用性問題の結果」は2005)年3月-4月に糸を通します」。
4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED
4.5. どんな_も支持しなかった_を水増しする超能力_TFC_の交渉
The description of ESP_TFC_PADDING_NOT_SUPPORTED notification in Section 3.10.1 says that "This notification asserts that the sending endpoint will NOT accept packets that contain Flow Confidentiality (TFC) padding".
「この通知は、送付終点がFlow Confidentiality(TFC)詰め物を含むパケットを受け入れないと断言します。」と、__セクション3.10.1におけるSUPPORTED通知ではなく、超能力TFC_PADDING_の記述は言います。
However, the text does not say in which messages this notification should be included, or whether the scope of this notification is a single CHILD_SA or all CHILD_SAs of the peer.
しかしながら、テキストには、この通知の範囲がこの通知がどのメッセージで含まれるべきであるか、そして、独身のCHILD_SAかそれともすべて、同輩のCHILD_SAsであるか書かれていません。
Our interpretation is that the scope is a single CHILD_SA, and thus this notification is included in messages containing an SA payload negotiating a CHILD_SA. If neither endpoint accepts TFC padding, this notification will be included in both the request proposing an SA and the response accepting it. If this notification is included
私たちの解釈は範囲が独身のCHILD_SAであり、その結果、この通知がCHILD_SAを交渉しながらSAペイロードを含むメッセージに含まれているということです。 どちらの終点もTFC詰め物を受け入れないと、この通知はSAを提案する要求とそれを受け入れる応答の両方に含まれるでしょう。 この通知が含まれているなら
Eronen & Hoffman Informational [Page 17] RFC 4718 IKEv2 Clarifications October 2006
[17ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
in only one of the messages, TFC padding can still be sent in one direction.
メッセージの1つだけでは、まだTFC詰め物を一方向に送ることができます。
4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO
4.6. 非_の最初の_断片の交渉も
NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1 simply as "Used for fragmentation control. See [RFC4301] for explanation."
NON_FIRST_FRAGMENTS_ALSO通知は単に「断片化コントロールのために、使用される」ようにセクション3.10.1で説明されます。 「説明に関して[RFC4301]を見てください。」
[RFC4301] says "Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port (or ICMP type/code or MH type) selectors MUST notify a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. The peer MUST reject this proposal if it will not accept non-initial fragments in this context. If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA."
「IKE NOTIFY NON_FIRST_FRAGMENTS_ALSOペイロードで重要なポート(ICMPタイプ/コードかMHがタイプする)セレクタを利用するトンネルモードSAで非初期の断片を伝える実現は同輩に通知しなければなりません。」と、[RFC4301]は言います。 このような関係においては非初期の断片を受け入れないなら、同輩はこの提案を拒絶しなければなりません。 「実現がそのようなSAのために首尾よく非初期の断片のトランスミッションを交渉しないなら、そのような断片をSAの上に送ってはいけません。」
However, it is not clear exactly how the negotiation works. Our interpretation is that the negotiation works the same way as for IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included in both the request proposing an SA and the response accepting it. In other words, if the peer "rejects this proposal", it only omits NON_FIRST_FRAGMENTS_ALSO notification from the response, but does not reject the whole CHILD_SA creation.
しかしながら、交渉がちょうどどのように働いているかは、明確ではありません。 私たちの解釈は交渉がIPCOMP_SUPPORTEDとUSE_TRANSPORT_MODEのように同じように働いているということです: NON_FIRST_FRAGMENTS_ALSO通知がSAを提案する要求とそれを受け入れる応答の両方に含まれている場合にだけ、非最初の断片を送るのは可能にされます。 言い換えれば、同輩が「この提案を拒絶する」なら、それは、応答からNON_FIRST_FRAGMENTS_ALSO通知を省略するだけですが、全体のCHILD_SA創造を拒絶しません。
4.7. Semantics of Complex Traffic Selector Payloads
4.7. 複雑な交通セレクタ有効搭載量の意味論
As described in Section 3.13, the TSi/TSr payloads can include one or more individual traffic selectors.
セクション3.13で説明されるように、TSi/TSrペイロードは1個以上の個々の交通セレクタを含むことができます。
There is no requirement that TSi and TSr contain the same number of individual traffic selectors. Thus, they are interpreted as follows: a packet matches a given TSi/TSr if it matches at least one of the individual selectors in TSi, and at least one of the individual selectors in TSr.
TSiとTSrが同じ数の個々の交通セレクタを含んでいるという要件が全くありません。 したがって、それらは以下の通り解釈されます: 少なくともTSiの個々のセレクタの1つ、および少なくともTSrの個々のセレクタの1つを合わせるなら、パケットは与えられたTSi/TSrに合っています。
For instance, the following traffic selectors:
例えば、以下の交通セレクタ:
TSi = ((17, 100, 192.0.1.66-192.0.1.66),
(17, 200, 192.0.1.66-192.0.1.66))
TSr = ((17, 300, 0.0.0.0-255.255.255.255),
(17, 400, 0.0.0.0-255.255.255.255))
TSi=(17、100、192.0.1.66-192.0.1.66)、(17、200、192.0.1.66-192.0.1.66)) TSr=((17, 300, 0.0.0.0-255.255.255.255), (17, 400, 0.0.0.0-255.255.255.255))
would match UDP packets from 192.0.1.66 to anywhere, with any of the four combinations of source/destination ports (100,300), (100,400), (200,300), and (200, 400).
192.0からUDPパケットを合わせるでしょう。.1 .66 どこでも、4つのもののいずれでも、ソース/目的地の組み合わせは(100,300)、(100,400)、(200,300)、および(200、400)を移植します。
Eronen & Hoffman Informational [Page 18] RFC 4718 IKEv2 Clarifications October 2006
[18ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
This implies that some types of policies may require several CHILD_SA pairs. For instance, a policy matching only source/destination ports (100,300) and (200,400), but not the other two combinations, cannot be negotiated as a single CHILD_SA pair using IKEv2.
これは、何人かのタイプの方針が数個のCHILD_SA組を必要とするかもしれないのを含意します。 例えば、1CHILD_SA組としてIKEv2を使用することで他の2つの組み合わせではなく、ソース/仕向港(100,300)と(200,400)だけに合っている方針は交渉できません。
(References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)
(参照: 「IKEv2交通セレクタ?」は2005年2月に縫うように通ります。)
4.8. ICMP Type/Code in Traffic Selector Payloads
4.8. 交通セレクタ有効搭載量におけるICMPタイプ/コード
The traffic selector types 7 and 8 can also refer to ICMP type and code fields. As described in Section 3.13.1, "For the ICMP protocol, the two one-octet fields Type and Code are treated as a single 16-bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposes of filtering based on this field."
また、交通セレクタタイプ7と8はICMPタイプとコード野原について言及できます。 セクション3.13.1で説明されるように、「ICMPプロトコルにおいて、2の1八重奏の分野のTypeとCodeはこの分野に基づくフィルタリングの目的のためにただ一つの16ビットの整数(Typeが最も重要な8ビットにあって、Codeが最も重要でない8ビットにある)ポートナンバーとして扱われます」。
Since ICMP packets do not have separate source and destination port fields, there is some room for confusion what exactly the four TS payloads (two in the request, two in the response, each containing both start and end port fields) should contain.
ICMPパケットにはポートがそこでさばく別々のソースと目的地がないので、混乱のいくらかの余地が4個のTSペイロード(要求における2、それぞれ始めと端のポート分野の両方を含む応答における2)が含むはずであるいったい何ですか?
The answer to this question can be found from [RFC4301] Section 4.4.1.3.
[RFC4301]セクション4.4.1からこの質問の答えを.3に見つけることができます。
To give a concrete example, if a host at 192.0.1.234 wants to create a transport mode SA for sending "Destination Unreachable" packets (ICMPv4 type 3) to 192.0.2.155, but is not willing to receive them over this SA pair, the CREATE_CHILD_SA exchange would look like this:
具体的な例を示すために、aを作成する.1個の.234必需品が192.0におけるホストであるなら送付の「目的地手の届かない」パケット(ICMPv4は3をタイプする)のためにモードSAを192.0に輸送する、.2、.155、このSA組の上にそれらを受けることを望んでいます、CREATE_CHILD_SA交換がこのように以下を見るだろうということではありません。
Initiator Responder
----------- -----------
HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } -->
創始者応答者----------- ----------- HDR、SK、N(使用_輸送_モード)、SA、Ni、TSi(1、0×0300 0x03FF、192.0.1.234-192.0.1.234)、TSr(1、65535-0、192.0.2.155-192.0.2.155)--、>。
<-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 65535-0, 192.0.2.155-192.0.2.155) }
<--HDR、SKN(使用_輸送_モード)、SA、Nr、TSi(1、0×0300 0x03FF、192.0.1.234-192.0.1.234)、TSr(1、65535-0、192.0.2.155-192.0.2.155)
Since IKEv2 always creates IPsec SAs in pairs, two SAs are also created in this case, even though the second SA is never used for data traffic.
IKEv2がいつもIPsec SAsを対になって作成するので、また、2SAsがこの場合作成されます、第2SAはデータ通信量に決して使用されませんが。
An exchange creating an SA pair that can be used both for sending and receiving "Destination Unreachable" places the same value in all the port:
発信と受信に「目的地手が届きません、な」状態で使用できるSA組を創設する交換は同じ値をすべてのポートに置きます:
Eronen & Hoffman Informational [Page 19] RFC 4718 IKEv2 Clarifications October 2006
[19ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
Initiator Responder
----------- -----------
HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } -->
創始者応答者----------- ----------- HDR、SK、N(使用_輸送_モード)、SA、Ni、TSi(1、0×0300 0x03FF、192.0.1.234-192.0.1.234)、TSr(1、0×0300 0x03FF、192.0.2.155-192.0.2.155)--、>。
<-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) }
<--HDR、SKN(使用_輸送_モード)、SA、Nr、TSi(1、0×0300 0x03FF、192.0.1.234-192.0.1.234)、TSr(1、0×0300 0x03FF、192.0.2.155-192.0.2.155)
(References: "ICMP and MH TSs for IKEv2" thread, Sep 2005.)
(参照: 「IKEv2"糸、2005)年9月のためのICMPとMH TSs」
4.9. Mobility Header in Traffic Selector Payloads
4.9. 交通セレクタ有効搭載量における移動性ヘッダー
Traffic selectors can use IP Protocol ID 135 to match the IPv6 mobility header [MIPv6]. However, the IKEv2 specification does not define how to represent the "MH Type" field in traffic selectors.
交通セレクタは、IPv6の移動性ヘッダー[MIPv6]を合わせるのにIPプロトコルID135を使用できます。 しかしながら、IKEv2仕様は交通セレクタの「MHタイプ」分野を表す方法を定義しません。
At some point, it was expected that this will be defined in a separate document later. However, [RFC4301] says that "For IKE, the IPv6 mobility header message type (MH type) is placed in the most significant eight bits of the 16 bit local "port" selector". The direction semantics of TSi/TSr port fields are the same as for ICMP and are described in the previous section.
何らかのポイントでは、これが後で別々のドキュメントで定義されると予想されました。 しかしながら、「IKEに関して、IPv6移動性ヘッダーメッセージタイプ(MHはタイプする)は16ビットの地方の「ポート」セレクタの最も重要な8ビットに置かれます。」と、[RFC4301]は言います。 TSi/TSrポート分野の指示意味論は、ICMPのように同じであり、前項で説明されます。
(References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header message type as selector", 2003-10-14. "ICMP and MH TSs for IKEv2" thread, Sep 2005.)
(の参照: Tero Kivinenメール「#86、を発行してください: セレクタとしてのIPv6移動性ヘッダーメッセージタイプを加える」(2003年10月14日)「IKEv2"糸、2005)年9月のためのICMPとMH TSs」
4.10. Narrowing the Traffic Selectors
4.10. 交通セレクタを狭くします。
Section 2.9 describes how traffic selectors are negotiated when creating a CHILD_SA. A more concise summary of the narrowing process is presented below.
セクション2.9はCHILD_SAを作成するとき、交通セレクタがどう交渉されるかを説明します。 狭くすることの過程の、より簡潔な概要は以下に提示されます。
o If the responder's policy does not allow any part of the traffic
covered by TSi/TSr, it responds with TS_UNACCEPTABLE.
o 応答者の方針がTSi/TSrでカバーされた交通の少しの部分も許容しないなら、それはTS_UNACCEPTABLEと共に応じます。
o If the responder's policy allows the entire set of traffic covered
by TSi/TSr, no narrowing is necessary, and the responder can
return the same TSi/TSr values.
o 応答者の方針がTSi/TSrでカバーされた全体の交通を許容するなら、狭くしないのが必要です、そして、応答者は同じTSi/TSr値を返すことができます。
o Otherwise, narrowing is needed. If the responder's policy allows
all traffic covered by TSi[1]/TSr[1] (the first traffic selectors
in TSi/TSr) but not entire TSi/TSr, the responder narrows to an
acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].
o さもなければ、狭くすることが必要です。 応答者の方針が全体のTSi/TSrではなく、TSi[1]/TSr[1](TSi/TSrにおける最初の交通セレクタ)でカバーされたすべての交通を許容するなら、応答者はTSi[1]/TSr[1]を含んでいるTSi/TSrの許容できる部分集合に狭くします。
Eronen & Hoffman Informational [Page 20] RFC 4718 IKEv2 Clarifications October 2006
[20ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
o If the responder's policy does not allow all traffic covered by
TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to
an acceptable subset of TSi/TSr.
o 応答者の方針がTSi[1]/TSr[1]でカバーされたすべての交通を許容しませんが、TSi/TSrのいくつかの部分を許容するなら、それはTSi/TSrの許容できる部分集合に狭くされます。
In the last two cases, there may be several subsets that are acceptable (but their union is not); in this case, the responder arbitrarily chooses one of them and includes ADDITIONAL_TS_POSSIBLE notification in the response.
最後の2つの場合には、いくつかの許容できる部分集合があるかもしれません(それらの組合はそうではありません)。 この場合、応答者は、任意にそれらの1つを選んで、応答におけるADDITIONAL_TS_POSSIBLE通知を入れます。
4.11. SINGLE_PAIR_REQUIRED
4.11. シングル_組_が必要です。
The description of the SINGLE_PAIR_REQUIRED notify payload in Sections 2.9 and 3.10.1 is not fully consistent.
REQUIREDがセクション2.9と3.10.1でペイロードに通知するSINGLE_PAIR_の記述は完全に一貫しているというわけではありません。
We do not attempt to describe this payload in this document either, since it is expected that most implementations will not have policies that require separate SAs for each address pair.
私たちは、このペイロードについて説明本書ではのどちらかを試みません、ほとんどの実現にはそれぞれのアドレス組のために別々のSAsを必要とする方針がないと予想されて。
Thus, if only some part (or parts) of the TSi/TSr proposed by the initiator is (are) acceptable to the responder, most responders should simply narrow TSi/TSr to an acceptable subset (as described in the last two paragraphs of Section 2.9), rather than use SINGLE_PAIR_REQUIRED.
その結果、創始者によって提案されたTSi/TSrの何らかの部分(または、部品)がそうならばさえ、よかったでしょう(あります)。応答者にとって許容できます、ほとんどの応答者がSINGLE_PAIR_REQUIREDを使用するより単にむしろ許容できる部分集合(最後の2つのパラグラフのセクション2.9で説明されるように)にTSi/TSrを狭くするべきです。
4.12. Traffic Selectors Violating Own Policy
4.12. 自己の方針に違反する交通セレクタ
Section 2.9 describes traffic selector negotiation in great detail. One aspect of this negotiation that may need some clarification is that when creating a new SA, the initiator should not propose traffic selectors that violate its own policy. If this rule is not followed, valid traffic may be dropped.
セクション2.9は丹念に交通セレクタ交渉について説明します。 何らかの明確化を必要とするかもしれないこの交渉の1つの局面は新しいSAを作成するとき、創始者がそれ自身の方針に違反する交通セレクタを提案するべきでないということです。 この規則が従われていないなら、有効な交通は落とされるかもしれません。
This is best illustrated by an example. Suppose that host A has a policy whose effect is that traffic to 192.0.1.66 is sent via host B encrypted using Advanced Encryption Standard (AES), and traffic to all other hosts in 192.0.1.0/24 is also sent via B, but encrypted using Triple Data Encryption Standard (3DES). Suppose also that host B accepts any combination of AES and 3DES.
例でこれを例証するのは最も良いです。 そのホストAに効果が192.0へのその交通である方針があるなら、.66がエー・イー・エス(AES)、およびすべてへの他の交通を使用することでコード化されたホストBを通して送られる.1は192.0でまた.0/24がBにもかかわらず、コード化にされるを通してTripleデータ暗号化規格(3DES)を使用することで送られる.1を接待します。 また、ホストBがAESと3DESのどんな組み合わせも受け入れると仮定してください。
If host A now proposes an SA that uses 3DES, and includes TSr containing (192.0.1.0-192.0.1.0.255), this will be accepted by host B. Now, host B can also use this SA to send traffic from 192.0.1.66, but those packets will be dropped by A since it requires the use of AES for those traffic. Even if host A creates a new SA only for 192.0.1.66 that uses AES, host B may freely continue to use the first SA for the traffic. In this situation, when proposing the SA, host A should have followed its own policy, and included a TSr containing ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.
.255)、これは現在ホストB.によって受け入れられるでしょう、また、ホストBが192.0から交通を送るのにこのSAを使用できます。ホストAが現在3DESを使用して、TSr含有を含んでいるSAを提案する、(192.0.1.0-192.0.1.0、.1 .66 AESのそれらの交通の使用を必要とするので、それらのパケットだけがAによって落とされるでしょう。 ホストAは192.0のためだけに新しいSAを作成します。.1 .66 用途AES、ホストBは交通に自由に最初のSAを使用し続けるかもしれません。 この状況では、SAを提案するとき、ホストAは、それ自身の方針に従って、代わりに((192.0.1.0-192.0.1.65)、(192.0.1.67-192.0.1.255))を含むTSrを入れるべきでした。
Eronen & Hoffman Informational [Page 21] RFC 4718 IKEv2 Clarifications October 2006
[21ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
In general, if (1) the initiator makes a proposal "for traffic X (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator does not actually accept traffic X' with SA, and (3) the initiator would be willing to accept traffic X' with some SA' (!=SA), valid traffic can be unnecessarily dropped since the responder can apply either SA or SA' to traffic X'.
'(1) 創始者が提案を「交通X(TSi/TSr)に、SAをしてください」にして、(2) Xの何らかの部分集合X'のために、創始者が実際にSAとの交通X'を受け入れないで、(3) 創始者が、'いくらかのSA'との交通X(=SA)を受け入れても構わないと思っているなら、応答者が'交通X'にSAかSAのどちらかを適用できるので、一般に、不必要に有効な交通を落とすことができます。
(References: "Question about "narrowing" ..." thread, Feb 2005. "IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2 Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector negotiation examples", 2004-08-08.)
「「狭くすること」に関して、質問してください」… 2005年2月、縫うように通ってください。(参照: 「IKEv2は「方針用法モード」を必要とである」… 糸、2月2005日「IKEv2交通セレクタ?」糸、2月2005日「IKEv2交通セレクタ交渉の例」、2004年8月8日。)
4.13. Traffic Selector Authorization
4.13. 交通セレクタ認可
IKEv2 relies on information in the Peer Authorization Database (PAD) when determining what kind of IPsec SAs a peer is allowed to create. This process is described in [RFC4301] Section 4.4.3. When a peer requests the creation of an IPsec SA with some traffic selectors, the PAD must contain "Child SA Authorization Data" linking the identity authenticated by IKEv2 and the addresses permitted for traffic selectors.
同輩がどういうIPsec SAsに作成できるかを決定するとき、IKEv2はPeer Authorization Database(PAD)の情報を当てにします。 この過程は[RFC4301]セクション4.4.3で説明されます。 同輩がいくつかの交通セレクタによるIPsec SAの創造を要求するとき、PADは、IKEv2によって認証されたアイデンティティと交通セレクタのために受入れられたアドレスをリンクしながら、「子供SA認可データ」を含まなければなりません。
For example, the PAD might be configured so that authenticated identity "sgw23.example.com" is allowed to create IPsec SAs for 192.0.2.0/24, meaning this security gateway is a valid "representative" for these addresses. Host-to-host IPsec requires similar entries, linking, for example, "fooserver4.example.com" with 192.0.1.66/32, meaning this identity a valid "owner" or "representative" of the address in question.
例えば、PADが構成されるかもしれないので、認証されたアイデンティティ"sgw23.example.com"は192.0のためにIPsec SAsを作成できます。.2 .0/24、このセキュリティゲートウェイを意味するのは、これらのアドレスのための有効な「代表」です。 ホストからホストへのIPsecは同様のエントリーを必要とします、192.0がアドレスの.1の意味している.66/32、このアイデンティティのa有効な「所有者」または「代表」はっきりしていなく例えば、"fooserver4.example.com"をリンクして。
As noted in [RFC4301], "It is necessary to impose these constraints on creation of child SAs to prevent an authenticated peer from spoofing IDs associated with other, legitimate peers." In the example given above, a correct configuration of the PAD prevents sgw23 from creating IPsec SAs with address 192.0.1.66 and prevents fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24.
[RFC4301]に述べられるように、「これらの規制を創造に課すために、認証された同輩が他の、そして、正統の同輩に関連しているIDをだますのを防ぎに子供SAsが必要です」。 上に出された例ではPADの正しい構成が、sgw23がアドレスでIPsec SAsを作成するのを防ぐ、192.0、.1、.66、fooserver4がアドレスで192.0からIPsec SAsを作成するのを防ぐ、.2 .0/24。
It is important to note that simply sending IKEv2 packets using some particular address does not imply a permission to create IPsec SAs with that address in the traffic selectors. For example, even if sgw23 would be able to spoof its IP address as 192.0.1.66, it could not create IPsec SAs matching fooserver4's traffic.
何らかの特定のアドレスを使用することでパケットを単にIKEv2に送るのが交通セレクタでそのアドレスでIPsec SAsを作成する許可を含意しないことに注意するのは重要です。 例えば、sgw23がそうしても、192.0としてIPアドレスをだますことができてください、そうした。.1 .66 それは、fooserver4の交通を合わせながら、IPsec SAsを作成できませんでした。
The IKEv2 specification does not specify how exactly IP address assignment using configuration payloads interacts with the PAD. Our interpretation is that when a security gateway assigns an address
IKEv2仕様は、構成ペイロードを使用するIPアドレス課題がいったいどうやってPADと対話するかを指定しません。 セキュリティゲートウェイがアドレスを割り当てるとき、私たちの解釈はそれです。
Eronen & Hoffman Informational [Page 22] RFC 4718 IKEv2 Clarifications October 2006
[22ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
using configuration payloads, it also creates a temporary PAD entry linking the authenticated peer identity and the newly allocated inner address.
構成ペイロードを使用して、また、それは、認証された同輩のアイデンティティと新たに割り当てられた内側のアドレスをリンクしながら、一時的なPADエントリーを作成します。
It has been recognized that configuring the PAD correctly may be difficult in some environments. For instance, if IPsec is used between a pair of hosts whose addresses are allocated dynamically using Dynamic Host Configuration Protocol (DHCP), it is extremely difficult to ensure that the PAD specifies the correct "owner" for each IP address. This would require a mechanism to securely convey address assignments from the DHCP server and link them to identities authenticated using IKEv2.
PADを構成するのがいくつかの環境で正しく難しいかもしれないと認められました。 例えば、IPsecがアドレスがダイナミックに割り当てられる1組のホストの間でDynamic Host Configuration Protocol(DHCP)を使用することで使用されるなら、PADが正しい「所有者」をそれぞれのIPアドレスに指定するのを保証するのは非常に難しいです。 これは、DHCPサーバからアドレス課題をしっかりと伝えて、IKEv2を使用することで認証されたアイデンティティにそれらをリンクするためにメカニズムを必要とするでしょう。
Due to this limitation, some vendors have been known to configure their PADs to allow an authenticated peer to create IPsec SAs with traffic selectors containing the same address that was used for the IKEv2 packets. In environments where IP spoofing is possible (i.e., almost everywhere) this essentially allows any peer to create IPsec SAs with any traffic selectors. This is not an appropriate or secure configuration in most circumstances. See [Aura05] for an extensive discussion about this issue, and the limitations of host-to-host IPsec in general.
この制限のため、いくつかの業者が認証された同輩が交通セレクタがIKEv2パケットに使用されたのと同じアドレスを含んでいるIPsec SAsを作成するのを許容するために彼らのPADsを構成するのが知られています。 IPスプーフィングが可能である(すなわち、ほとんどいたる所)環境で、これで、どんな同輩もどんな交通セレクタでも本質的にはIPsec SAsを作成できます。 これはほとんどの事情での適切であるか安全な構成ではありません。 この問題についての大規模な議論、および一般に、ホストからホストへのIPsecの限界に関して[Aura05]を見てください。
5. Rekeying and Deleting SAs
5. SAsをRekeyingして、削除します。
5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange
5.1. Rekeying SAs、_子供_SA交換を引き起こしてください。
Continued from Section 4.1 of this document.
このドキュメントのセクション4.1から、続けられています。
NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
新しい1.3.2Rekeying IKE_SAs、_子供_SA交換を引き起こしてください。
The CREATE_CHILD_SA request for rekeying an IKE_SA is:
SAがIKE_SAを「再-合わせ」るために要求するCREATE_CHILD_は以下の通りです。
Initiator Responder
----------- -----------
HDR, SK {SA, Ni, [KEi]} -->
創始者応答者----------- ----------- HDR、SK、SA、Ni[KEi]--、>。
The initiator sends SA offer(s) in the SA payload, a nonce in
the Ni payload, and optionally a Diffie-Hellman value in the KEi
payload.
創始者は発信します。SAは(s) SAペイロード、Niペイロードの一回だけに、任意にKEiペイロードのディフィー-ヘルマン値を提供します。
The CREATE_CHILD_SA response for rekeying an IKE_SA is:
IKE_SAを「再-合わせ」るためのCREATE_CHILD_SA応答は以下の通りです。
<-- HDR, SK {SA, Nr, [KEr]}
<--HDR、SKSA、Nr[KEr]
Eronen & Hoffman Informational [Page 23] RFC 4718 IKEv2 Clarifications October 2006
[23ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
The responder replies (using the same Message ID to respond)
with the accepted offer in an SA payload, a nonce in the Nr
payload, and, optionally, a Diffie-Hellman value in the KEr
payload.
応答者はSAペイロード、Nrペイロードの一回だけ、および任意にKErペイロードのディフィー-ヘルマン値における受け入れられた申し出で返答します(応じるのに同じMessage IDを使用します)。
The new IKE_SA has its message counters set to 0, regardless of
what they were in the earlier IKE_SA. The window size starts at
1 for any new IKE_SA. The new initiator and responder SPIs are
supplied in the SPI fields of the SA payloads.
新しいIKE_SAは以前のIKE_SAのそれらが何であったかにかかわらずメッセージカウンタを0に設定させます。 ウィンドウサイズは1時にどんな新しいIKE_SAのためにも始まります。 SAペイロードのSPI分野で新しい創始者と応答者SPIsを供給します。
NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
.3新しい1.3Rekeying子供_SAs、_子供_SA交換を引き起こしてください。
The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
SAがCHILD_SAを「再-合わせ」るために要求するCREATE_CHILD_は以下の通りです。
Initiator Responder
----------- -----------
HDR, SK {N(REKEY_SA), [N+], SA,
Ni, [KEi], TSi, TSr} -->
創始者応答者----------- ----------- HDR、SK、N(REKEY_SA)、[N+]、SA、Ni、[KEi]、TSi、TSr--、>。
The leading Notify payload of type REKEY_SA identifies the
CHILD_SA being rekeyed, and it contains the SPI that the initiator
expects in the headers of inbound packets. In addition, the
initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, optionally a Diffie-Hellman value in the KEi payload,
and the proposed traffic selectors in the TSi and TSr payloads.
The request can also contain Notify payloads that specify
additional details for the CHILD_SA.
タイプREKEY_SAの主なNotifyペイロードは「再-合わせ」られるCHILD_SAを特定します、そして、それは創始者が本国行きのパケットのヘッダーで予想するSPIを含んでいます。 さらに、創始者はSAペイロード、Niペイロードの一回だけで任意に申し出をSAに送ります。KEiペイロードのディフィー-ヘルマン値、およびTSiとTSrペイロードの提案された交通セレクタ。 また、要求はCHILD_SAのための追加詳細を指定するNotifyペイロードを含むことができます。
The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
CHILD_SAを「再-合わせ」るためのCREATE_CHILD_SA応答は以下の通りです。
<-- HDR, SK {[N+], SA, Nr,
[KEr], TSi, TSr}
<--HDR、SK[N+]、SA、Nr、[KEr]、TSi、TSr
The responder replies with the accepted offer in an SA payload,
and a Diffie-Hellman value in the KEr payload if KEi was
included in the request and the selected cryptographic suite
includes that group.
応答者はSAペイロードにおける受け入れられた申し出で返答します、そして、KEiが要求と選択された暗号のスイートに含まれていたなら、KErペイロードのディフィー-ヘルマン値はそのグループを含んでいます。
The traffic selectors for traffic to be sent on that SA are
specified in the TS payloads in the response, which may be a
subset of what the initiator of the CHILD_SA proposed.
そのSAに送られる交通のための交通セレクタはTSペイロードで応答で指定されます。(それは、CHILD_SAの創始者が提案したことに関する部分集合であるかもしれません)。
5.2. Rekeying the IKE_SA vs. Reauthentication
5.2. IKE_SA対ReauthenticationをRekeyingします。
Rekeying the IKE_SA and reauthentication are different concepts in IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and resets the Message ID counters, but it does not authenticate the parties again (no AUTH or EAP payloads are involved).
IKE_SAをRekeyingして、再認証はIKEv2の異なった概念です。 IKE_SAをRekeyingすると、新しいキーがIKE_SAのために設立されて、Message IDカウンタはリセットされますが、それは再びパーティーを認証しません(どんなAUTHもEAPペイロードもかかわりません)。
Eronen & Hoffman Informational [Page 24] RFC 4718 IKEv2 Clarifications October 2006
[24ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
While rekeying the IKE_SA may be important in some environments, reauthentication (the verification that the parties still have access to the long-term credentials) is often more important.
IKE_SAを「再-合わせ」るのはいくつかの環境で重要であるかもしれませんが、再認証(パーティーが静める検証は長期の信任状に近づく手段を持っている)はしばしばより重要です。
IKEv2 does not have any special support for reauthentication. Reauthentication is done by creating a new IKE_SA from scratch (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify payloads), creating new CHILD_SAs within the new IKE_SA (without REKEY_SA notify payloads), and finally deleting the old IKE_SA (which deletes the old CHILD_SAs as well).
IKEv2には、再認証の少しの特別なサポートもありません。 最初から新しいIKE_SAを作成することによって、Reauthenticationをします(REKEY_SAがなければ、どんなイケ_SA_INIT/イケ_AUTH交換を使用して、ペイロードに通知してください)、新しいIKE_SA(REKEY_SAがなければ、ペイロードに通知する)の中で新しいCHILD_SAsを作成して、最終的に、古いIKE_SA(また、古いCHILD_SAsを削除する)を削除して。
This means that reauthentication also establishes new keys for the IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed more often than reauthentication, the situation where "authentication lifetime" is shorter than "key lifetime" does not make sense.
これは、また、再認証がIKE_SAとCHILD_SAsのために新しいキーを設立することを意味します。 したがって、再認証よりしばしば「再-合わせ」ることを実行できる間、「認証生涯」が「主要な生涯」より短い状況は理解できません。
While creation of a new IKE_SA can be initiated by either party (initiator or responder in the original IKE_SA), the use of EAP authentication and/or configuration payloads means in practice that reauthentication has to be initiated by the same party as the original IKE_SA. IKEv2 base specification does not allow the responder to request reauthentication in this case; however, this functionality is added in [ReAuth].
何れの当事者(オリジナルのIKE_SAの創始者か応答者)は新しいIKE_SAの創造を開始できますが、EAP認証、そして/または、構成ペイロードの使用は、実際には再認証がオリジナルのIKE_SAと同じパーティーによって開始されなければならないことを意味します。 IKEv2基礎仕様で、応答者はこの場合再認証を要求できません。 しかしながら、この機能性は加えられます[ReAuth]。
(References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)
(参照: 「IKEv2"糸、2004)年10月/11月のReauthentication」
5.3. SPIs When Rekeying the IKE_SA
5.3. SPIsいつRekeying IKE_SA
Section 2.18 says that "New initiator and responder SPIs are supplied in the SPI fields". This refers to the SPI fields in the Proposal structures inside the Security Association (SA) payloads, not the SPI fields in the IKE header.
「SPI分野で新しい創始者と応答者SPIsを供給します。」と、セクション2.18は言います。 これはIKEヘッダーのSPI分野ではなく、Security Association(SA)ペイロードにおけるProposal構造のSPI野原を示します。
(References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24. Geoffrey Huang's reply, 2005-01-24.)
(2005年1月24日参照: トムStiemerlingのメール"Rekey IKE SA"、2005年1月24日のジェフリー・ホアンの回答。)
5.4. SPI When Rekeying a CHILD_SA
5.4. SPI、Rekeying a子供_SAです。
Section 3.10.1 says that in REKEY_SA notifications, "The SPI field identifies the SA being rekeyed."
セクション3.10 .1 REKEY_SA通知では、「SPI分野は「再-合わせ」られるSAを特定する」と言います。
Since CHILD_SAs always exist in pairs, there are two different SPIs. The SPI placed in the REKEY_SA notification is the SPI the exchange initiator would expect in inbound ESP or AH packets (just as in Delete payloads).
CHILD_SAsがいつも対になって存在しているので、2異なったSPIsがあります。 REKEY_SA通知に置かれたSPIは交換創始者が本国行きの超能力かAHパケットで予想するSPI(ちょうどDeleteペイロードのように)です。
Eronen & Hoffman Informational [Page 25] RFC 4718 IKEv2 Clarifications October 2006
[25ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
5.5. Changing PRFs When Rekeying the IKE_SA
5.5. Rekeying IKE_SAであるときに、PRFsを変えます。
When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for the new IKE_SA is computed using SK_d from the existing IKE_SA as follows:
IKE_SAを「再-合わせ」るとき、「新しいIKE_SAのためのSKEYSEEDは以下の既存のIKE_SAからSKを使用することで計算されます。」と、セクション2.18は言います。
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"
「SKEYSEEDがprfと等しい、(SK(古い)、[g^、不-、(新しい]| Ni| Nr、)、」
If the old and new IKE_SA selected a different PRF, it is not totally clear which PRF should be used.
古くて新しいIKE_SAが異なったPRFを選択したなら、どのPRFが使用されるべきであるかは、完全に明確であるというわけではありません。
Since the rekeying exchange belongs to the old IKE_SA, it is the old IKE_SA's PRF that is used. This also follows the principle that the same key (the old SK_d) should not be used with multiple cryptographic algorithms.
「再-合わせ」る交換が古いIKE_SAに属すので、使用されているのは、古いIKE_SAのPRFです。 また、これは複数の暗号アルゴリズムで同じキー(古いSK)を使用するべきでないという原則に従います。
Note that this may work poorly if the new IKE_SA's PRF has a fixed key size, since the output of the PRF may not be of the correct size. This supports our opinion earlier in the document that the use of PRFs with a fixed key size is a bad idea.
新しいIKE_SAのPRFに固定主要なサイズがあるならこれが不十分に働くかもしれないことに注意してください、PRFの出力が適度のサイズのものでないかもしれないので。 これは、より早くドキュメントで私たちの意見を支持します。固定主要なサイズがあるPRFsの使用は悪い考えです。
(References: "Changing PRFs when rekeying the IKE_SA" thread, June 2005.)
(参照: 「IKE_SAを「再-合わせ」るとき、PRFsを変えます」糸、2005年6月)。
5.6. Deleting vs. Closing SAs
5.6. SAsを閉じることに対する削除
The IKEv2 specification talks about "closing" and "deleting" SAs, but it is not always clear what exactly is meant. However, other parts of the specification make it clear that when local state related to a CHILD_SA is removed, the SA must also be actively deleted with a Delete payload.
IKEv2仕様はSAsが「閉じ」て、「削除」であることに関して話しますが、いったい何が意味されるかは、いつも明確であるというわけではありません。 しかしながら、仕様の他の部分は、また、CHILD_SAに関連する地方の状態を取り除くときDeleteペイロードで活発にSAを削除しなければならないと断言します。
In particular, Section 2.4 says that "If an IKE endpoint chooses to delete CHILD_SAs, it MUST send Delete payloads to the other end notifying it of the deletion". Section 1.4 also explains that "ESP and AH SAs always exist in pairs, with one SA in each direction. When an SA is closed, both members of the pair MUST be closed."
「IKE終点が、CHILD_SAsを削除するのを選ぶなら、削除についてそれに通知するもう一方の端までペイロードをDeleteに送らなければなりません。」と、特に、セクション2.4は言います。 また、「超能力とAH SAsは1SAと共に各方向にいつも対になって存在しています。」と、セクション1.4は説明します。 「SAが閉じられるとき、組の両方のメンバーは閉店しなければなりません。」
5.7. Deleting a CHILD_SA Pair
5.7. 子供_SA組を削除します。
Section 1.4 describes how to delete SA pairs using the Informational exchange: "To delete an SA, an INFORMATIONAL exchange with one or more delete payloads is sent listing the SPIs (as they would be expected in the headers of inbound packets) of the SAs to be deleted. The recipient MUST close the designated SAs."
セクション1.4はInformational交換を使用することでSA組を削除する方法を説明します: 「1以上でSA、INFORMATIONAL交換を削除する、削除、ペイロードに削除されるために、SAsのSPIs(彼らが本国行きのパケットのヘッダーで期待しているだろうというとき)を記載させる、」 「受取人は指定されたSAsを閉じなければなりません。」
Eronen & Hoffman Informational [Page 26] RFC 4718 IKEv2 Clarifications October 2006
[26ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
The "one or more delete payloads" phrase has caused some confusion. You never send delete payloads for the two sides of an SA in a single message. If you have many SAs to delete at the same time (such as the nested example given in that paragraph), you include delete payloads for the inbound half of each SA in your Informational exchange.
「ものか以上がペイロードを削除する」という句は何らかの混乱を引き起こしました。 決して発信しません。ただ一つのメッセージでSAの2つの側面にペイロードを削除してください。 同じくらいで時間(そのパラグラフで出された入れ子にされた例などの)を削除する多くのSAsを持ってください、あなた。インクルードはあなたのInformational交換における、半分のそれぞれの本国行きのSAのためにペイロードを削除します。
5.8. Deleting an IKE_SA
5.8. IKE_SAを削除します。
Since IKE_SAs do not exist in pairs, it is not totally clear what the response message should contain when the request deleted the IKE_SA.
IKE_SAsが対になって存在していないので、要求がいつIKE_SAを削除したかは、応答メッセージが何を含むべきであるかが完全に明確であるというわけではありません。
Since there is no information that needs to be sent to the other side (except that the request was received), an empty Informational response seems like the most logical choice.
反対側に送られる必要がある情報が全くないので(要求を受け取ったのを除いて)、空のInformational応答は最も論理的な選択のように見えます。
(References: "Question about delete IKE SA" thread, May 2005.)
(参照:、「質問する、削除、糸、5月2005日IKE SA」)
5.9. Who is the original initiator of IKE_SA
5.9. IKE_SAのオリジナルの創始者はだれですか?
In the IKEv2 document, "initiator" refers to the party who initiated the exchange being described, and "original initiator" refers to the party who initiated the whole IKE_SA. However, there is some potential for confusion because the IKE_SA can be rekeyed by either party.
IKEv2ドキュメントでは、「創始者」は説明される交換を起こしたパーティーを示します、そして、「オリジナルの創始者」は全体のIKE_SAを開始したパーティーを示します。 しかしながら、何れの当事者がIKE_SAを「再-合わせ」ることができるので、混乱の何らかの可能性があります。
To clear up this confusion, we propose that "original initiator" always refers to the party who initiated the exchange that resulted in the current IKE_SA. In other words, if the "original responder" starts rekeying the IKE_SA, that party becomes the "original initiator" of the new IKE_SA.
この混乱を解決するために、私たちは、「オリジナルの創始者」がいつも現在のIKE_SAをもたらした交換を起こしたパーティーを示すよう提案します。 言い換えれば、「オリジナルの応答者」がIKE_SAを「再-合わせ」始めるなら、そのパーティーは新しいIKE_SAの「オリジナルの創始者」になります。
(References: Paul Hoffman's mail "Original initiator in IKEv2", 2005-04-21.)
(が参照: ポール・ホフマン郵送する、「IKEv2"のオリジナルの創始者、2005年4月21日)。」
5.10. Comparing Nonces
5.10. 一回だけを比較します。
Section 2.8 about rekeying says that "If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it."
「そのような衝突ですが、余分なSAsが作成されるなら、閉じられて、4つの一回だけで最も低いのが2回の交換に使用されている状態で、SAはそれを作成した終点のそばでSHOULDを作成しました。」と、「再-合わせ」るのに関するセクション2.8は言います。
Eronen & Hoffman Informational [Page 27] RFC 4718 IKEv2 Clarifications October 2006
[27ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
Here "lowest" uses an octet-by-octet (lexicographical) comparison (instead of, for instance, comparing the nonces as large integers). In other words, start by comparing the first octet; if they're equal, move to the next octet, and so on. If you reach the end of one nonce, that nonce is the lower one.
ここで、「最も低いこと」は八重奏(辞書編集の)ごとの比較(例えば、大きい整数として一回だけを比較することの代わりに)を使用します。 言い換えれば、最初の八重奏を比較することによって、始まってください。 それらが等しいなら、次の八重奏などに動いてください。 あなたが1つの一回だけの端に達するなら、その一回だけは下側のものです。
(References: "IKEv2 rekeying question" thread, July 2005.)
(参照: 「IKEv2 rekeying質問」糸、2005年7月)。
5.11. Exchange Collisions
5.11. 交換衝突
Since IKEv2 exchanges can be initiated by both peers, it is possible that two exchanges affecting the same SA partly overlap. This can lead to a situation where the SA state information is temporarily not synchronized, and a peer can receive a request it cannot process in a normal fashion. Some of these corner cases are discussed in the specification, some are not.
両方の同輩がIKEv2交換を起こすことができるので、同じSAに影響する2回の交換が一部重なるのは、可能です。 これはSA州の情報が一時同期しないで、同輩がそれが正常なファッションで処理できない要求を受け取ることができる状況に通じることができます。 仕様でこれらのいくつかの角のケースについて議論して、何かはそうではありません。
Obviously, using a window size greater than one leads to infinitely more complex situations, especially if requests are processed out of order. In this section, we concentrate on problems that can arise even with window size 1.
明らかに、ウィンドウサイズ1以上を使用するのは、より複雑な状況に無限に通じます、特に要求が故障していた状態で処理されるなら。 このセクションでは、私たちはウィンドウサイズ1があっても起こることができる問題に集中します。
(References: "IKEv2: invalid SPI in DELETE payload" thread, Dec 2005/ Jan 2006. "Problem with exchanges collisions" thread, Dec 2005.)
(参照: 「IKEv2: DELETEペイロードの無効のSPI」糸、1月年日2006 2005/12月の「交換衝突に関する問題」糸、2005年12月)。
5.11.1. Simultaneous CHILD_SA Close
5.11.1. 同時の子供_SAは閉じます。
Probably the simplest case happens if both peers decide to close the same CHILD_SA pair at the same time:
両方の同輩が、同時に同じCHILD_SA組を閉じると決めるなら、たぶん最も簡単なケースは起こります:
Host A Host B
-------- --------
send req1: D(SPIa) -->
<-- send req2: D(SPIb)
--> recv req1
<-- send resp1: ()
recv resp1
recv req2
send resp2: () -->
--> recv resp2
ホストBを接待してください。-------- -------- req1を送ってください: D(SPIa)(><)はreq2を送ります: D(SPIb)(>recv req1<)はresp1を送ります: () recv resp1 recv req2はresp2を送ります: () -->-->recv resp2
This case is described in Section 1.4 and is handled by omitting the Delete payloads from the response messages.
本件は、セクション1.4で説明されて、応答メッセージからDeleteペイロードを省略することによって、扱われます。
Eronen & Hoffman Informational [Page 28] RFC 4718 IKEv2 Clarifications October 2006
[28ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
5.11.2. Simultaneous IKE_SA Close
5.11.2. 同時のIKE_SAは閉じます。
Both peers can also decide to close the IKE_SA at the same time. The desired end result is obvious; however, in certain cases the final exchanges may not be fully completed.
また、両方の同輩は、同時にIKE_SAを閉じると決めることができます。 必要な結末は明白です。 しかしながら、ある場合には、最終的な交換は完全に終了するかもしれないというわけではありません。
Host A Host B
-------- --------
send req1: D() -->
<-- send req2: D()
--> recv req1
ホストBを接待してください。-------- -------- req1を送ってください: D()(><)はreq2を送ります: D()-->recv req1
At this point, host B should reply as usual (with empty Informational response), close the IKE_SA, and stop retransmitting req2. This is because once host A receives resp1, it may not be able to reply any longer. The situation is symmetric, so host A should behave the same way.
ここに、ホストBは、いつものよう(空のInformational応答で)に返答して、IKE_SAを閉じて、req2を再送するのを止めるべきです。 これはホストAがいったんresp1を受け取ると、それがもう返答できないかもしれないからです。 状況が左右対称であるので、ホストAは同じように振る舞うべきです。
Host A Host B
-------- --------
<-- send resp1: ()
send resp2: ()
ホストBを接待してください。-------- -------- <-- resp1を送ってください: () resp2を送ってください: ()
Even if neither resp1 nor resp2 ever arrives, the end result is still correct: the IKE_SA is gone. The same happens if host A never receives req2.
resp1もresp2も届かないでも、結末はまだ正しいです: IKE_SAはありません。 ホストAがreq2を決して受け取らないなら、同じくらいは起こります。
5.11.3. Simultaneous CHILD_SA Rekeying
5.11.3. 同時の子供_SA Rekeying
Another case that is described in the specification is simultaneous rekeying. Section 2.8 says
仕様で説明される別のケースは同時の「再-合わせ」ることです。 セクション2.8は言います。
"If the two ends have the same lifetime policies, it is possible
that both will initiate a rekeying at the same time (which will
result in redundant SAs). To reduce the probability of this
happening, the timing of rekeying requests SHOULD be jittered
(delayed by a random amount of time after the need for rekeying is
noticed).
「2つの終わりに同じ生涯方針があるなら、両方が同時に(余分なSAsをもたらす)「再-合わせ」ることを開始するのは、可能です。」 この出来事の確率を減少させるために、「再-合わせ」ることのタイミングは、SHOULDがjitteredされるよう(無作為の時間までには、「再-合わせ」る必要性が気付かれた後に延着します)要求します。
This form of rekeying may temporarily result in multiple similar
SAs between the same pairs of nodes. When there are two SAs
eligible to receive packets, a node MUST accept incoming packets
through either SA. If redundant SAs are created though such a
collision, the SA created with the lowest of the four nonces used
in the two exchanges SHOULD be closed by the endpoint that created
it."
このフォームを「再-合わせ」るのは一時同じ組のノードの間の複数の同様のSAsをもたらすかもしれません。 パケットを受ける資格がある2SAsがあるとき、ノードはSAを通して入って来るパケットを受け入れなければなりません。 「そのような衝突ですが、余分なSAsが作成されるなら、閉じられて、4つの一回だけで最も低いのが2回の交換に使用されている状態で、SAはそれを作成した終点のそばでSHOULDを作成しました。」
Eronen & Hoffman Informational [Page 29] RFC 4718 IKEv2 Clarifications October 2006
[29ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
However, a better explanation on what impact this has on implementations is needed. Assume that hosts A and B have an existing IPsec SA pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same time:
しかしながら、実現のときに、これにはどんな影響力があるかに関する、より良い説明が必要です。 ホストAとBには既存のIPsec SA組がSPIs(SPIa1、SPIb1)と共にあると仮定してください。そうすれば、両方が同時に、それを「再-合わせ」始めます:
Host A Host B
-------- --------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. -->
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2,..
recv req2 <--
ホストBを接待してください。-------- -------- req1を送ってください: N(REKEY_SA、SPIa1)、SA、(SPIa2、)、Ni1 --><--req2を送ってください: N(REKEY_SA、SPIb1)、SA、(SPIb2、)、Ni2、recv req2<--
At this point, A knows there is a simultaneous rekeying going on. However, it cannot yet know which of the exchanges will have the lowest nonce, so it will just note the situation and respond as usual.
ここに、Aは、先へ進む同時の「再-合わせ」ることがあるのを知っています。 しかしながら、交換のどれに最も低い一回だけがあるかをまだ知ることができないので、それは、ただ状況に注意して、いつものように応じるでしょう。
send resp2: SA(..,SPIa3,..),Nr1,.. -->
--> recv req1
resp2を送ってください: SA、(SPIa3、)、Nr1 -->-->recv req1
Now B also knows that simultaneous rekeying is going on. Similarly as host A, it has to respond as usual.
今、また、Bは、同時の「再-合わせ」るのが先へ進むことであることを知っています。 同様に、ホストAとして、それはいつものように応じなければなりません。
<-- send resp1: SA(..,SPIb3,..),Nr2,..
recv resp1 <--
--> recv resp2
<--resp1を送ってください: SA、(SPIb3、)、Nr2、recv resp1<--、--、>recv resp2
At this point, there are three CHILD_SA pairs between A and B (the old one and two new ones). A and B can now compare the nonces. Suppose that the lowest nonce was Nr1 in message resp2; in this case, B (the sender of req2) deletes the redundant new SA, and A (the node that initiated the surviving rekeyed SA) deletes the old one.
ここに、3CHILD_SA組がAとBとの間に(1と2つの古い新しい方)あります。 AとBは現在、一回だけを比較できます。 最も低い一回だけがメッセージresp2のNr1であったと仮定してください。 この場合、B(req2の送付者)は余分な新しいSAを削除します、そして、A(生き残っているrekeyed SAを開始したノード)は古い方を削除します。
send req3: D(SPIa1) -->
<-- send req4: D(SPIb2)
--> recv req3
<-- send resp4: D(SPIb1)
recv req4 <--
send resp4: D(SPIa3) -->
req3を送ってください: D(SPIa1)(><)はreq4を送ります: D(SPIb2)(>recv req3<)はresp4を送ります: D(SPIb1)recv req4<--resp4を送ってください: D(SPIa3)-->。
The rekeying is now finished.
「再-合わせ」ることは現在、終わっています。
However, there is a second possible sequence of events that can happen if some packets are lost in the network, resulting in retransmissions. The rekeying begins as usual, but A's first packet (req1) is lost.
しかしながら、いくつかのパケットがネットワークで失われているなら起こることができる出来事の2番目の可能な系列があります、「再-トランスミッション」をもたらして。 「再-合わせ」ることはいつものように始まりますが、Aの最初のパケット(req1)は無くなっています。
Eronen & Hoffman Informational [Page 30] RFC 4718 IKEv2 Clarifications October 2006
[30ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
Host A Host B
-------- --------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. --> (lost)
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2,..
recv req2 <--
send resp2: SA(..,SPIa3,..),Nr1,.. -->
--> recv resp2
<-- send req3: D(SPIb1)
recv req3 <--
send resp3: D(SPIa1) -->
--> recv resp3
ホストBを接待してください。-------- -------- req1を送ってください: N(REKEY_SA、SPIa1)、SA、(SPIa2、)、Ni1 -->(失われている)<--req2を送ってください: N(REKEY_SA、SPIb1)、SA、(SPIb2、)、Ni2、recv req2<--resp2を送ってください: SA、(SPIa3、)、Nr1 -->(>recv resp2<)はreq3を送ります: D(SPIb1)recv req3<--resp3を送ってください: D(SPIa1)-->-->recv resp3
From B's point of view, the rekeying is now completed, and since it has not yet received A's req1, it does not even know that these was simultaneous rekeying. However, A will continue retransmitting the message, and eventually it will reach B.
ビーズ観点から、「再-合わせ」ることは今完成します、そして、まだAのreq1を受けていないので、それはこれらが「再-合わせ」ることであったのを同時の知ってさえいません。 しかしながら、Aは、メッセージを再送し続けるでしょう、そして、結局、それはBに達するでしょう。
resend req1 -->
--> recv req1
req1-->-->recv req1を再送してください。
What should B do in this point? To B, it looks like A is trying to rekey an SA that no longer exists; thus failing the request with something non-fatal such as NO_PROPOSAL_CHOSEN seems like a reasonable approach.
Bはこのポイントで何をするべきですか? Bに、Aがもう存在しないSAをrekeyに試みているように見えます。 したがって、どんな_PROPOSAL_CHOSENなどのようにも何か非致命的でないもので要求に失敗するのは合理的なアプローチのように見えます。
<-- send resp1: N(NO_PROPOSAL_CHOSEN)
recv resp1 <--
<--resp1を送ってください: N(_PROPOSAL_CHOSENがない)recv resp1<--
When A receives this error, it already knows there was simultaneous rekeying, so it can ignore the error message.
Aがこの誤りを受けるとき、同時の「再-合わせ」ることがあったのを既に知るので、それはエラーメッセージを無視できます。
5.11.4. Simultaneous IKE_SA Rekeying
5.11.4. 同時のIKE_SA Rekeying
Probably the most complex case occurs when both peers try to rekey the IKE_SA at the same time. Basically, the text in Section 2.8 applies to this case as well; however, it is important to ensure that the CHILD_SAs are inherited by the right IKE_SA.
両方の同輩が同時にIKE_SAをrekeyに試みるとき、たぶん最も複雑なケースは現れます。 基本的に、セクション2.8のテキストはまた、本件に適用されます。 しかしながら、CHILD_SAsが右のIKE_SAによって引き継がれるのを保証するのは重要です。
The case where both endpoints notice the simultaneous rekeying works the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges, three IKE_SAs exist between A and B; the one containing the lowest nonce inherits the CHILD_SAs.
両方の終点が同時の「再-合わせ」ることに気付くケースはずっとCHILD_SAsのように同じように働いています。 SAが交換するCREATE_CHILD_の後に、3IKE_SAsがAとBとの間に存在します。 含む中で一回だけ最も低いものはCHILD_SAsを引き継ぎます。
However, there is a twist to the other case where one rekeying finishes first:
しかしながら、もう片方のケースへのねじれが1「再-合わせ」ることが最初に終わるところにあります:
Eronen & Hoffman Informational [Page 31] RFC 4718 IKEv2 Clarifications October 2006
[31ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
Host A Host B
-------- --------
send req1:
SA(..,SPIa1,..),Ni1,.. -->
<-- send req2: SA(..,SPIb1,..),Ni2,..
--> recv req1
<-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <--
send req3: D() -->
--> recv req3
ホストBを接待してください。-------- -------- req1を送ってください: SA、(SPIa1、)、Ni1 --><--req2を送ってください: SA、(SPIb1、)、Ni2 -->recv req1<--resp1を送ってください: SA、(SPIb2、)、Nr2、recv resp1<--req3を送ってください: D()-->-->recv req3
At this point, host B sees a request to close the IKE_SA. There's not much more to do than to reply as usual. However, at this point host B should stop retransmitting req2, since once host A receives resp3, it will delete all the state associated with the old IKE_SA and will not be able to reply to it.
ここに、ホストBはIKE_SAを閉じるという要求を見ます。 いつものように返答するよりあるように、はるかに多くがありません。 しかしながら、ここに、ホストBは、req2を再送するのを止めるべきです、ホストAがいったんresp3を受け取ると、古いIKE_SAに関連しているすべての状態を削除して、それに答えることができないので。
<-- send resp3: ()
<--resp3を送ってください: ()
5.11.5. Closing and Rekeying a CHILD_SA
5.11.5. 閉鎖とRekeyingは子供_SAです。
A case similar to simultaneous rekeying can occur if one peer decides to close an SA and the other peer tries to rekey it:
1人の同輩が、SAを閉じると決めるなら、同時の「再-合わせ」るのと同様のケースは現れることができます、そして、もう片方の同輩はrekeyにそれを試みます:
Host A Host B
-------- --------
send req1: D(SPIa) -->
<-- send req2: N(REKEY_SA,SPIb),SA,..
--> recv req1
ホストBを接待してください。-------- -------- req1を送ってください: D(SPIa)(><)はreq2を送ります: N(REKEY_SA、SPIb)、SA。 -->recv req1
At this point, host B notices that host A is trying to close an SA that host B is currently rekeying. Replying as usual is probably the best choice:
ここに、ホストBは、ホストAがホストBが現在「再-合わせ」ているSAを閉じようとしているのに気付きます。 いつものように返答するのは、たぶん最も良い選択です:
<-- send resp1: D(SPIb)
<--resp1を送ってください: D(SPIb)
Depending on in which order req2 and resp1 arrive, host A sees either a request to rekey an SA that it is currently closing, or a request to rekey an SA that does not exist. In both cases, NO_PROPOSAL_CHOSEN is probably fine.
req2とresp1がどのオーダーに届くかによって、それはSAですが、現在閉じて、ホストAがrekeyにおいて要求を見るか、またはrekeyへの要求は存在しないSAを見ます。 どちらの場合も、どんな_PROPOSAL_CHOSENもたぶんすばらしくはありません。
recv req2
recv resp1
send resp2: N(NO_PROPOSAL_CHOSEN) -->
--> recv resp2
recv req2 recv resp1はresp2を送ります: N(_PROPOSAL_CHOSENがない)-->-->recv resp2
Eronen & Hoffman Informational [Page 32] RFC 4718 IKEv2 Clarifications October 2006
[32ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
5.11.6. Closing a New CHILD_SA
5.11.6. 新しい子供_SAを閉じます。
Yet another case occurs when host A creates a CHILD_SA pair, but soon thereafter host B decides to delete it (possible because its policy changed):
ホストAがCHILD_SA組を創設するとき、さらに別のケースは現れますが、その後すぐ、ホストBは、それ(方針が変化したので可能な)を削除すると決めます:
Host A Host B
-------- --------
send req1: [N(REKEY_SA,SPIa1)],
SA(..,SPIa2,..),.. -->
--> recv req1
(lost) <-- send resp1: SA(..,SPIb2,..),..
ホストBを接待してください。-------- -------- req1を送ってください: [N(REKEY_SA、SPIa1)]、SA、(SPIa2、)。 -->(>recv req1(失われている)<)はresp1を送ります: SA、(SPIb2、)。
<-- send req2: D(SPIb2)
recv req2
<--req2を送ってください: D(SPIb2)recv req2
At this point, host A has not yet received message resp1 (and is retransmitting message req1), so it does not recognize SPIb in message req2. What should host A do?
ここにホストAがまだメッセージresp1を受け取っていないので(再送はメッセージreq1です)、それはメッセージreq2でSPIbを認識しません。 ホストAは何をするべきですか?
One option would be to reply with an empty Informational response. However, this same reply would also be sent if host A has received resp1, but has already sent a new request to delete the SA that was just created. This would lead to a situation where the peers are no longer in sync about which SAs exist between them. However, host B would eventually notice that the other half of the CHILD_SA pair has not been deleted. Section 1.4 describes this case and notes that "a node SHOULD regard half-closed connections as anomalous and audit their existence should they persist", and continues that "if connection state becomes sufficiently messed up, a node MAY close the IKE_SA".
1つのオプションは空のInformational応答で返答するだろうことです。 しかしながら、この同じ回答は、また、ホストAがresp1を受け取ったなら送るでしょうが、既に、ただ作成されたSAを削除するという新しい要求を送りました。 これはもうSAsが彼らの間に存在する同時性でないには同輩がいる状況に通じるでしょう。 しかしながら、ホストBは、結局、CHILD_SA組のもう片方の半分が削除されていないのに気付くでしょう。 セクション1.4は、本件と「彼らが固執するなら、ノードSHOULDは半開きな接続が変則的であるとみなして、彼らの存在を監査する」というメモについて説明して、「接続状態が十分台無しにされるようになるなら、ノードはIKE_SAを閉じるかもしれません。」と続けています。
Another solution that has been proposed is to reply with an INVALID_SPI notification that contains SPIb. This would explicitly tell host B that the SA was not deleted, so host B could try deleting it again later. However, this usage is not part of the IKEv2 specification and would not be in line with normal use of the INVALID_SPI notification where the data field contains the SPI the recipient of the notification would put in outbound packets.
提案された他の解決法はSPIbを含むINVALID_SPI通知で返答することです。 これは、SAが削除されなかったのでホストBが後で再びそれを削除してみることができたと明らかにホストBに言うでしょう。 しかしながら、この用法は、IKEv2仕様の一部でなく、またINVALID_SPI通知の通常の使用に沿ってデータ・フィールドが通知の受取人が外国行きのパケットに置くSPIを含むところにないでしょう。
Yet another solution would be to ignore req2 at this time and wait until we have received resp1. However, this alternative has not been fully analyzed at this time; in general, ignoring valid requests is always a bit dangerous, because both endpoints could do it, leading to a deadlock.
しかし、他の解決法は、私たちがresp1を受け取るまで、このとき、req2を無視して、待つだろうことです。 しかしながら、この代替手段はこのとき、完全に分析されるというわけではありませんでした。 一般に、行き詰まりに通じて、両方の終点がそれをするかもしれないので、有効な要求を無視するのは少しいつも危険です。
This document recommends the first alternative.
このドキュメントは最初の代替手段を推薦します。
Eronen & Hoffman Informational [Page 33] RFC 4718 IKEv2 Clarifications October 2006
[33ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
5.11.7. Rekeying a New CHILD_SA
5.11.7. 新しい子供_SAをRekeyingします。
Yet another case occurs when a CHILD_SA is rekeyed soon after it has been created:
それを作成してあったすぐ後にCHILD_SAが「再-合わせ」られると、さらに別のケースは現れます:
Host A Host B
-------- --------
send req1: [N(REKEY_SA,SPIa1)],
SA(..,SPIa2,..),.. -->
(lost) <-- send resp1: SA(..,SPIb2,..),..
ホストBを接待してください。-------- -------- req1を送ってください: [N(REKEY_SA、SPIa1)]、SA、(SPIa2、)。 -->(失われている)<--resp1を送ってください: SA、(SPIb2、)。
<-- send req2: N(REKEY_SA,SPIb2),
SA(..,SPIb3,..),..
recv req2 <--
<--req2を送ってください: N(REKEY_SA、SPIb2)、SA、(SPIb3、)、recv req2<--
To host A, this looks like a request to rekey an SA that does not exist. Like in the simultaneous rekeying case, replying with NO_PROPOSAL_CHOSEN is probably reasonable:
Aを接待するために、これは要求のようにrekeyにおいて存在しないSAを見ます。 同時の「再-合わせ」るケースなどのように、どんな_PROPOSAL_CHOSENと共にも返答しないのはたぶん妥当です:
send resp2: N(NO_PROPOSAL_CHOSEN) -->
recv resp1
resp2を送ってください: N(_PROPOSAL_CHOSENがない)-->recv resp1
5.11.8. Collisions with IKE_SA Rekeying
5.11.8. IKE_SA Rekeyingとの衝突
Another set of cases occurs when one peer starts rekeying the IKE_SA at the same time the other peer starts creating, rekeying, or closing a CHILD_SA. Suppose that host B starts creating a CHILD_SA, and soon after, host A starts rekeying the IKE_SA:
1人の同輩がもう片方の同輩が作成し始める同時代にIKE_SAを「再-合わせ」始めると、もう1セットのケースは現れます、CHILD_SAを「再-合わせ」るか、または閉じて。 ホストBがCHILD_SAを作成し始めると仮定してください。そうすれば、すぐ後に、ホストAはIKE_SAを「再-合わせ」始めます:
Host A Host B
-------- --------
<-- send req1: SA,Ni1,TSi,TSr
send req2: SA,Ni2,.. -->
--> recv req2
ホストBを接待してください。-------- -------- <-- req1を送ってください: SA、Ni1、TSi、TSrはreq2を送ります: SA、Ni2。 -->-->recv req2
What should host B do at this point? Replying as usual would seem like a reasonable choice:
ホストBはここに何をするべきですか? いつものように返答するのは正当な選択のように見えるでしょう:
<-- send resp2: SA,Ni2,..
recv resp2 <--
send req3: D() -->
--> recv req3
<--resp2を送ってください: SA、Ni2、recv resp2<--req3を送ってください: D()-->-->recv req3
Now, a problem arises: If host B now replies normally with an empty Informational response, this will cause host A to delete state associated with the IKE_SA. This means host B should stop retransmitting req1. However, host B cannot know whether or not host A has received req1. If host A did receive it, it will move the
今、問題は起こります: ホストBが現在空のInformational応答で通常返答すると、これで、ホストAはIKE_SAに関連している状態を削除するでしょう。 これは、ホストBが、req1を再送するのを止めるべきであることを意味します。 しかしながら、ホストBは、ホストAがreq1を受け取ったかどうかを知ることができません。 ホストAがそれを受けたなら、それは動くでしょう。
Eronen & Hoffman Informational [Page 34] RFC 4718 IKEv2 Clarifications October 2006
[34ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
CHILD_SA to the new IKE_SA as usual, and the state information will then be out of sync.
通常通りの新しいIKE_SA、および州の情報へのCHILD_SAは同期して、次に、同期してください。
It seems this situation is tricky to handle correctly. Our proposal is as follows: if a host receives a request to rekey the IKE_SA when it has CHILD_SAs in "half-open" state (currently being created or rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host receives a request to create or rekey a CHILD_SA after it has started rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.
この状況が正しく扱うために扱いにくいように思えます。 私たちの提案は以下の通りです: それであるときに、ホストが要求をrekeyに受け取るなら、IKE_SAは「半開きな」状態にCHILD_SAsを持っています(現在作成されるか、または「再-合わせ」られて)、とそれはどんな_PROPOSAL_CHOSENと共にも返答するべきではありません。 ホストが作成する要求かrekeyを受け取るなら、それの後のCHILD_SAはIKE_SAを「再-合わせ」始めました、とそれがどんな_ADDITIONAL_SASと共にも返答するべきではありません。
The case where CHILD_SAs are being closed is even worse. Our recommendation is that if a host receives a request to rekey the IKE_SA when it has CHILD_SAs in "half-closed" state (currently being closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host receives a request to close a CHILD_SA after it has started rekeying the IKE_SA, it should reply with an empty Informational response. This ensures that at least the other peer will eventually notice that the CHILD_SA is still in "half-closed" state and will start a new IKE_SA from scratch.
CHILD_SAsが閉じられているケースはさらに悪いです。 私たちの推薦はそれであるときに、ホストが要求をrekeyに受け取るならIKE_SAが「半開きな」状態にCHILD_SAsを持っているという(現在閉じられて)ことです、とそれはどんな_PROPOSAL_CHOSENと共にも返答するべきではありません。 そして、ホストがIKE_SAを「再-合わせ」始めた後にCHILD_SAを閉じるという要求を受け取るなら、それは空のInformational応答で返答するべきです。 これは、少なくとももう片方の同輩が結局、CHILD_SAがまだ「半開きな」状態にあるのに気付いて、最初から新しいIKE_SAを始めるのを確実にします。
5.11.9. Closing and Rekeying the IKE_SA
5.11.9. 閉鎖とRekeying IKE_SA
The final case considered in this section occurs if one peer decides to close the IKE_SA while the other peer tries to rekey it.
1人の同輩が、もう片方の同輩がrekeyにそれを試みている間、IKE_SAを閉じると決めるなら、このセクションで考えられた最終的なケースは現れます。
Host A Host B
-------- --------
send req1: SA(..,SPIa1,..),Ni1 -->
<-- send req2: D()
--> recv req1
recv req2 <--
ホストBを接待してください。-------- -------- req1を送ってください: SA、(SPIa1、)、Ni1(><)はreq2を送ります: D()-->recv req1 recv req2<--
At this point, host B should probably reply with NO_PROPOSAL_CHOSEN, and host A should reply as usual, close the IKE_SA, and stop retransmitting req1.
ここに、Bがたぶん_いいえ、PROPOSAL_CHOSEN、およびホストAと共に返答するべきであるホストは、いつものように返答して、IKE_SAを閉じて、req1を再送するのを止めるべきです。
<-- send resp1: N(NO_PROPOSAL_CHOSEN)
send resp2: ()
<--resp1を送ってください: N(_PROPOSAL_CHOSENがない)はresp2を送ります: ()
If host A wants to continue communication with B, it can now start a new IKE_SA.
ホストAがBとのコミュニケーションを続けたいなら、それは今、新しいIKE_SAを始動できます。
5.11.10. Summary
5.11.10. 概要
If a host receives a request to rekey:
ホストが要求をrekeyに受け取るなら:
o a CHILD_SA pair that the host is currently trying to close: reply
with NO_PROPOSAL_CHOSEN.
o ホストが現在閉じようとしているCHILD_SA組: どんな_PROPOSAL_CHOSENと共にも返答しないでください。
Eronen & Hoffman Informational [Page 35] RFC 4718 IKEv2 Clarifications October 2006
[35ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
o a CHILD_SA pair that the host is currently rekeying: reply as
usual, but prepare to close redundant SAs later based on the
nonces.
o ホストが現在「再-合わせ」ているCHILD_SA組: いつものように返答しなさい、ただし、後で一回だけに基づいた余分なSAsを閉じるのを用意してください。
o a CHILD_SA pair that does not exist: reply with
NO_PROPOSAL_CHOSEN.
o 存在しないCHILD_SA組: どんな_PROPOSAL_CHOSENと共にも返答しないでください。
o the IKE_SA, and the host is currently rekeying the IKE_SA: reply
as usual, but prepare to close redundant SAs and move inherited
CHILD_SAs later based on the nonces.
o IKE_SA、ホストが現在IKE_SAを「再-合わせ」ている、: いつものように返答しなさい、ただし、余分なSAsを閉じて、後で一回だけに基づいた引き継いでいるCHILD_SAsを動かすのを用意してください。
o the IKE_SA, and the host is currently creating, rekeying, or
closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.
o _IKE_SAでありホストは現在の作成、「再-合わせ」ることであるかCHILDを閉じるのは、SAです: どんな_PROPOSAL_CHOSENと共にも返答しないでください。
o the IKE_SA, and the host is currently trying to close the IKE_SA:
reply with NO_PROPOSAL_CHOSEN.
o IKE_SA、およびホストはそうです。現在そうしようとして、IKE_SAを閉じてください: どんな_PROPOSAL_CHOSENと共にも返答しないでください。
If a host receives a request to close:
ホストが閉じるという要求を受け取るなら:
o a CHILD_SA pair that the host is currently trying to close: reply
without Delete payloads.
o ホストが現在閉じようとしているCHILD_SA組: Deleteペイロードなしで返答してください。
o a CHILD_SA pair that the host is currently rekeying: reply as
usual, with Delete payload.
o ホストが現在「再-合わせ」ているCHILD_SA組: Deleteペイロードでいつものように返答してください。
o a CHILD_SA pair that does not exist: reply without Delete
payloads.
o 存在しないCHILD_SA組: Deleteペイロードなしで返答してください。
o the IKE_SA, and the host is currently rekeying the IKE_SA: reply
as usual, and forget about our own rekeying request.
o IKE_SA、ホストが現在IKE_SAを「再-合わせ」ている、: いつものように返答してください、そして、私たち自身の「再-合わせ」る要求を忘れてください。
o the IKE_SA, and the host is currently trying to close the IKE_SA:
reply as usual, and forget about our own close request.
o IKE_SA、およびホストはそうです。現在そうしようとして、IKE_SAを閉じてください: いつものように返答してください、そして、私たち自身の厳密な要求を忘れてください。
If a host receives a request to create or rekey a CHILD_SA when it is currently rekeying the IKE_SA: reply with NO_ADDITIONAL_SAS.
現在それであるときに、ホストが作成する要求かrekeyを受け取るなら、CHILD_SAはIKE_SAを「再-合わせ」ています: どんな_ADDITIONAL_SASと共にも返答しないでください。
If a host receives a request to delete a CHILD_SA when it is currently rekeying the IKE_SA: reply without Delete payloads.
ホストが現在IKE_SAを「再-合わせ」ているときCHILD_SAを削除するという要求を受け取るなら: Deleteペイロードなしで返答してください。
5.12. Diffie-Hellman and Rekeying the IKE_SA
5.12. ディフィー-ヘルマンとRekeying IKE_SA
There has been some confusion whether doing a new Diffie-Hellman exchange is mandatory when the IKE_SA is rekeyed.
IKE_SAが「再-合わせ」られるとき、新しいディフィー-ヘルマンの交換をするのが義務的であるか否かに関係なく、何らかの混乱がありました。
It seems that this case is allowed by the IKEv2 specification. Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets. Section 3.3.3 does not contradict this when it says that including
本件がIKEv2仕様で許容されているように思えます。 セクション2.18がディフィー-ヘルマン用語を示している、(g^、不-、)、括弧で。 その包含を示すとき、セクション3.3.3はこれに矛盾しません。
Eronen & Hoffman Informational [Page 36] RFC 4718 IKEv2 Clarifications October 2006
[36ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
the D-H transform is mandatory: although including the transform is mandatory, it can contain the value "NONE".
D-H変換は義務的です: 変換を含んでいるのは義務的ですが、それは値の「なにも」を含むことができます。
However, having the option to skip the Diffie-Hellman exchange when rekeying the IKE_SA does not add useful functionality to the protocol. The main purpose of rekeying the IKE_SA is to ensure that the compromise of old keying material does not provide information about the current keys, or vice versa. This requires performing the Diffie-Hellman exchange when rekeying. Furthermore, it is likely that this option would have been removed from the protocol as unnecessary complexity had it been discussed earlier.
しかしながら、IKE_SAを「再-合わせ」るときディフィー-ヘルマンの交換をサボるオプションを持っているのは役に立つ機能性をプロトコルに追加しません。 IKE_SAを「再-合わせ」る主な目的が古い合わせることの材料の妥協が現在のキーの情報を提供しないのを保証することであるか逆もまた同様です。 これは、「再-合わせ」るとき、ディフィー-ヘルマンの交換を実行するのを必要とします。 その上、より早くそれについて議論したなら、不要な複雑さとしてプロトコルからこのオプションを取り除きそうだったでしょうに。
Given this, we recommend that implementations should have a hard- coded policy that requires performing a new Diffie-Hellman exchange when rekeying the IKE_SA. In other words, the initiator should not propose the value "NONE" for the D-H transform, and the responder should not accept such a proposal. This policy also implies that a successful exchange rekeying the IKE_SA always includes the KEi/KEr payloads.
これを考えて、私たちは、実現にはIKE_SAを「再-合わせ」るとき、新しいディフィー-ヘルマンの交換を実行するのを必要とする困難なコード化された方針があるべきであることを勧めます。 言い換えれば、創始者はD-H変換のために値の「なにも」を提案するべきではありません、そして、応答者はそのような提案を受け入れるべきではありません。 また、この方針は、IKE_SAを「再-合わせ」るうまくいっている交換がいつもKEi/KErペイロードを含んでいるのを含意します。
(References: "Rekeying IKE_SAs with the CREATE_CHILD_SA exhange" thread, Oct 2005. "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt" thread, Apr 2005.)
「CREATE_CHILD_SA exhangeとRekeying IKE_SAs」は2005年10月に縫うように通ります。(参照: 「草稿eronen-ipsec-ikev2明確化02.txtのコメント」は2005年4月に縫うように通ります。)
6. Configuration Payloads
6. 構成有効搭載量
6.1. Assigning IP Addresses
6.1. IPアドレスを割り当てます。
Section 2.9 talks about traffic selector negotiation and mentions that "In support of the scenario described in section 1.1.3, an initiator may request that the responder assign an IP address and tell the initiator what it is."
セクション2.9は、交通セレクタ交渉に関して話して、「セクション1.1.3で説明されたシナリオを支持して、創始者は、応答者がIPアドレスを割り当てるよう要求して、それが何であるかを創始者に言うかもしれません。」と言及します。
This sentence is correct, but its placement is slightly confusing. IKEv2 does allow the initiator to request assignment of an IP address from the responder, but this is done using configuration payloads, not traffic selector payloads. An address in a TSi payload in a response does not mean that the responder has assigned that address to the initiator; it only means that if packets matching these traffic selectors are sent by the initiator, IPsec processing can be performed as agreed for this SA. The TSi payload itself does not give the initiator permission to configure the initiator's TCP/IP stack with the address and use it as its source address.
この文は正しいのですが、プレースメントはわずかに混乱させられています。 IKEv2は創始者に応答者からIPアドレスの課題を要求させますが、これは交通セレクタペイロードではなく、構成ペイロードを使用し終わっています。 TSiペイロードの応答におけるアドレスは、応答者がそのアドレスを創始者に割り当てたことを意味しません。 それは、これらの交通セレクタに合っているパケットが創始者によって送られるなら、このSAのために同意されるようにIPsec処理を実行できることを意味するだけです。 TSiペイロード自体はアドレスで創始者のTCP/IPスタックを構成して、ソースアドレスとしてそれを使用する創始者許可を与えません。
In other words, IKEv2 does not have two different mechanisms for assigning addresses, but only one: configuration payloads. In the scenario described in Section 1.1.3, both configuration and traffic selector payloads are usually included in the same message, and they
言い換えれば、IKEv2には、アドレスを割り当てるための2つの異なったメカニズムではなく、1つしかありません: 構成ペイロード。 セクション1.1.3で説明されたシナリオでは、構成と交通セレクタペイロードの両方が、同じくらいが通信させる通常、含まれているコネと、彼らです。
Eronen & Hoffman Informational [Page 37] RFC 4718 IKEv2 Clarifications October 2006
[37ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
often contain the same information in the response message (see Section 6.3 of this document for some examples). However, their semantics are still different.
しばしば応答メッセージにおける同じ情報を含んでください(いくつかの例のためのこのドキュメントのセクション6.3を見てください)。 しかしながら、それらの意味論はまだ異なっています。
6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS
6.2. どんなINTERNAL_IP4/IP6_ADDRESSも要求します。
When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section 3.15.1 says that "In a request message, the address specified is a requested address (or zero if no specific address is requested)". The question here is whether "zero" means an address "0.0.0.0" or a zero-length string.
または、INTERNAL_IP4/IP6_ADDRESS属性について説明するセクション3.15.1がそれを言う、「指定されたアドレスが要求メッセージでは、要求されたアドレスである、(どんな特定のアドレスも要求されないならゼロに合わせる、)、」 「ゼロ」が「0.0の.0の0インチかa無の長さが結ぶ」アドレスを意味するかどうかという質問がここにあります。
Earlier, the same section also says that "If an attribute in the CFG_REQUEST Configuration Payload is not zero-length, it is taken as a suggestion for that attribute". Also, the table of configuration attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0 or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17 octets".
また、より早く、「CFG_REQUEST Configuration有効搭載量における属性がゼロ・レングスでないなら、それはその属性のための提案としてみなされます。」と、同じセクションは言います。 また、構成属性のテーブルはINTERNAL_IP4_ADDRESSの長さが「0か4つの八重奏」であり、同様に、INTERNAL_IP6_ADDRESSが「0か17の八重奏」であると示します。
Thus, if the client does not request a specific address, it includes a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute containing an all-zeroes address. The example in 2.19 is thus incorrect, since it shows the attribute as "INTERNAL_ADDRESS(0.0.0.0)".
したがって、クライアントが特定のアドレスを要求しないなら、それはオールゼロアドレスを含む属性ではなく、ゼロ・レングスINTERNAL_IP4/IP6_ADDRESS属性を含んでいます。 その結果、属性を示しているので2.19における例が不正確である、「内部の_アドレス、(0.0、.0、.0)、」
However, since the value is only a suggestion, implementations are recommended to ignore suggestions they do not accept; or in other words, to treat the same way a zero-length INTERNAL_IP4_ADDRESS, "0.0.0.0", and any other addresses the implementation does not recognize as a reasonable suggestion.
しかしながら、値が提案にすぎないので、実現が受け入れないという提案を無視することが勧められます。 または、言い換えれば、同じように無の長さのINTERNAL_IP4_ADDRESSを扱うために「0.0、.0、実現が道理に適った提案として認識しない0インチ、およびいかなる他のアドレス、も」
6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET
6.3. 内部の_IP4_サブネット/内部の_IP6_サブネット
Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected sub-networks that this edge-device protects. This attribute is made up of two fields: the first is an IP address and the second is a netmask. Multiple sub-networks MAY be requested. The responder MAY respond with zero or more sub-network attributes." INTERNAL_IP6_SUBNET is defined in a similar manner.
セクション3.15 .1 「このエッジデバイスが保護する保護されたサブネットワーク」としてINTERNAL_IP4_SUBNETを記述します。 この属性は2つの分野で作られます: 1番目はIPアドレスです、そして、2番目はネットマスクです。 複数のサブネットワークが要求されているかもしれません。 「応答者はゼロか、より多くのサブネットワーク属性で応じるかもしれません。」 INTERNAL_IP6_SUBNETは同じように定義されます。
This raises two questions: first, since this information is usually included in the TSr payload, what functionality does this attribute add? And second, what does this attribute mean in CFG_REQUESTs?
これは2つの疑問を引き起こします: まず最初に、この属性は通常、この情報がTSrペイロードに含まれていて以来のどんな機能性を加えますか? そして、2番目に、この属性はCFG_REQUESTsで何を意味しますか?
For the first question, there seem to be two sensible interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA response) indicates which subnets are accessible through the SA that was just created.
最初の質問に関しては、分別がある2つの解釈があるように思えます。 明確に、TSr(イケ_AUTHかCREATE_CHILD_SA応答における)は、どのサブネットがただ作成されたSAを通してアクセスしやすいかを示します。
Eronen & Hoffman Informational [Page 38] RFC 4718 IKEv2 Clarifications October 2006
[38ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is that they indicate additional subnets that can be reached through this gateway, but need a separate SA. According to this interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful mainly when they contain addresses not included in TSr.
INTERNAL_IP4/6_SUBNET属性の最初の解釈は彼らがこのゲートウェイを通して達することができる追加サブネットを示しますが、別々のSAを必要とするということです。 主にTSrに含まれていなかったアドレスを含むとき、この解釈によると、INTERNAL_IP4/6_SUBNET属性は役に立ちます。
The second interpretation is that the INTERNAL_IP4/6_SUBNET attributes express the gateway's policy about what traffic should be sent through the gateway. The client can choose whether other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent through the gateway or directly to the destination. According to this interpretation, the attributes are useful mainly when TSr contains addresses not included in the INTERNAL_IP4/6_SUBNET attributes.
2番目の解釈はINTERNAL_IP4/6_SUBNET属性がゲートウェイを通してどんな交通を送るべきであるかに関するゲートウェイの方針を言い表すということです。 クライアントは、他の交通(TSrで覆われますが、INTERNAL_IP4/6_SUBNETで覆われるというわけではない)がゲートウェイを通して、または、直接目的地に送られるかどうかを選ぶことができます。 主にTSrがINTERNAL_IP4/6_SUBNET属性に含まれていなかったアドレスを含むとき、この解釈によると、属性は役に立ちます。
It turns out that these two interpretations are not incompatible, but rather two sides of the same principle: traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via this gateway. If there are no existing IPsec SAs whose traffic selectors cover the address in question, new SAs have to be created.
これらの2つの解釈が両立しなくないと判明して、むしろ同じくらいの2つの側だけが原則です: このゲートウェイを通してINTERNAL_IP4/6_SUBNET属性で記載されたアドレスへの交通を送るべきです。 交通セレクタが問題のアドレスをカバーするどんな既存のIPsec SAsもなければ、新しいSAsは作成されなければなりません。
A couple of examples are given below. For instance, if there are two subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request contains the following:
2、3の例が以下に出されます。 例えば、そこである、2つのサブネット、192.0.1 26と.0/192.0.2.0/は24です、そして、クライアントの要求は以下を含んでいます:
CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
CP(CFG_要求)は内部の_IP4_アドレス()TSi=(0、0-65535、0.0.0.0-255.255.255.255)TSr=と等しいです。(0, 0-65535, 0.0.0.0-255.255.255.255)
Then a valid response could be the following (in which TSr and INTERNAL_IP4_SUBNET contain the same information):
次に、有効回答は以下であるかもしれません(IP4_SUBNETはそのTSrとINTERNAL_に同じ情報を含みます):
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63),
(0, 0-65535, 192.0.2.0-192.0.2.255))
CP(CFG_回答)が内部の_IP4_アドレスと等しい、(192.0、.1、.234の)内部の_IP4_サブネット、(192.0.1.0/255.255.255、.192の)内部の_IP4_サブネット、(192.0.2.0/255.255.255.0)TSi=(0、0-65535、192.0.1.234-192.0.1.234)TSrは等しいです。((0, 0-65535, 192.0.1.0-192.0.1.63), (0, 0-65535, 192.0.2.0-192.0.2.255))
In these cases, the INTERNAL_IP4_SUBNET does not really carry any useful information. Another possible reply would have been this:
これらの場合では、INTERNAL_IP4_SUBNETは本当に少しの役に立つ情報も運びません。 別の可能な回答はこれでしょう:
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
CP(CFG_回答)が内部の_IP4_アドレスと等しい、(192.0、.1、.234の)内部の_IP4_サブネット、(192.0.1.0/255.255.255、.192の)内部の_IP4_サブネット(192.0.2.0/255.255.255.0)
Eronen & Hoffman Informational [Page 39] RFC 4718 IKEv2 Clarifications October 2006
[39ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSiはTSr=と等しいです(0、0-65535、192.0.1.234-192.0.1.234)。(0, 0-65535, 0.0.0.0-255.255.255.255)
This would mean that the client can send all its traffic through the gateway, but the gateway does not mind if the client sends traffic not included by INTERNAL_IP4_SUBNET directly to the destination (without going through the gateway).
これは、クライアントがゲートウェイを通してすべての交通を送ることができることを意味するでしょうが、クライアントがINTERNAL_IP4_SUBNETによって直接目的地(ゲートウェイを通ることのない)に含まれなかった交通を送るなら、ゲートウェイは気にされません。
A different situation arises if the gateway has a policy that requires the traffic for the two subnets to be carried in separate SAs. Then a response like this would indicate to the client that if it wants access to the second subnet, it needs to create a separate SA:
ゲートウェイに2つのサブネットが別々のSAsで運ばれるために交通を必要とする方針があるなら、異なった状況は起こります。 次に、このような応答は、2番目のサブネットへのアクセスが欲しいなら、別々のSAを作成するのが必要であることをクライアントに示すでしょう:
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)
CP(CFG_回答)が内部の_IP4_アドレスと等しい、(192.0、.1、.234の)内部の_IP4_サブネット、(192.0.1.0/255.255.255、.192の)内部の_IP4_サブネット、(192.0.2.0/255.255.255.0)TSi=(0、0-65535、192.0.1.234-192.0.1.234)TSrは等しいです。(0, 0-65535, 192.0.1.0-192.0.1.63)
INTERNAL_IP4_SUBNET can also be useful if the client's TSr included only part of the address space. For instance, if the client requests the following:
また、クライアントのTSrがアドレス空間の一部だけを含んでいたなら、INTERNAL_IP4_SUBNETも役に立つ場合があります。 例えば、クライアントが以下を要求するなら:
CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
CP(CFG_要求)は内部の_IP4_アドレス()TSi=(0、0-65535、0.0.0.0-255.255.255.255)TSr=と等しいです。(0, 0-65535, 192.0.2.155-192.0.2.155)
Then the gateway's reply could be this:
次に、ゲートウェイの回答はこれであるかもしれません:
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
CP(CFG_回答)が内部の_IP4_アドレスと等しい、(192.0、.1、.234の)内部の_IP4_サブネット、(192.0.1.0/255.255.255、.192の)内部の_IP4_サブネット、(192.0.2.0/255.255.255.0)TSi=(0、0-65535、192.0.1.234-192.0.1.234)TSrは等しいです。(0, 0-65535, 192.0.2.155-192.0.2.155)
It is less clear what the attributes mean in CFG_REQUESTs, and whether other lengths than zero make sense in this situation (but for INTERNAL_IP6_SUBNET, zero length is not allowed at all!). This document recommends that implementations should not include INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in CFG_REQUESTs.
属性がCFG_REQUESTsで何を意味するか、そして、ゼロ以外の長さがこの状況で理解できるかどうかは(INTERNAL_IP6_SUBNETに関して、ゼロ・レングスは全く許容されていません!)、それほど明確ではありません。 このドキュメントは、実現がCFG_REQUESTsにINTERNAL_IP4_SUBNETかINTERNAL_IP6_SUBNET属性を含むべきでないことを勧めます。
For the IPv4 case, this document recommends using only netmasks consisting of some amount of "1" bits followed by "0" bits; for
IPv4ケースのために、このドキュメントが、いくつかから成るのが達するネットマスクだけを使用することを勧める、「「0インチのビット」に従って、1インチのビットは続きました。 for
Eronen & Hoffman Informational [Page 40] RFC 4718 IKEv2 Clarifications October 2006
[40ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
instance, "255.0.255.0" would not be a valid netmask for INTERNAL_IP4_SUBNET.
例、「255.0、0インチが内部の_に、有効なネットマスクがIP4_サブネットであるならそうしない.255、」
It is also worthwhile to note that the contents of the INTERNAL_IP4/ 6_SUBNET attributes do not imply link boundaries. For instance, a gateway providing access to a large company intranet using addresses from the 10.0.0.0/8 block can send a single INTERNAL_IP4_SUBNET attribute (10.0.0.0/255.0.0.0) even if the intranet has hundreds of routers and separate links.
また、INTERNAL_IP4/ 6_SUBNET属性の内容がリンク境界を含意しないことに注意する価値があります。 例えば、a大企業イントラネット使用へのアクセスが10.0から.0/8が妨げる.0を記述するならゲートウェイがただ一つのINTERNAL_IP4_SUBNET属性を送ることができる、(10.0、.0.0/、255.0 .0 .0) イントラネットに何百個ものルータと別々のリンクがあっても。
(References: Tero Kivinen's mail "Intent of couple of attributes in Configuration Payload in IKEv2?", 2004-11-19. Srinivasa Rao Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in IKEv2", 2004-09-10. Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and Implementation Guidelines", 2005-02-07. "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
「「明確化未解決の問題: INTERNAL_IP4_SUBNET/NETMASK」という「Re: 新しいI-D: IKEv2明確化と実施要綱」(2005年2月7日)という内部の_IP4_サブネットとIKEv2"の内部の_IP6_サブネット、2004年9月10日Yoavニールのメールは縫うように通ります、2005)年4月」という「IKEv2のConfiguration有効搭載量における2、3の属性の意図?」(2004年11月19日)という(の参照: Tero KivinenメールSrinivasaラオAddepalliのメール
6.4. INTERNAL_IP4_NETMASK
6.4. 内部の_IP4_ネットマスク
Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute and says that "The internal network's netmask. Only one netmask is allowed in the request and reply messages (e.g., 255.255.255.0) and it MUST be used only with an INTERNAL_IP4_ADDRESS attribute".
セクション3.15 .1 INTERNAL_IP4_NETMASK属性を定義して、その「内部のネットワークのネットマスク」を言います。 「1つのネットマスクだけが要求と応答メッセージに許容されている、(例えば、255.255、.255、INTERNAL_IP4_ADDRESS属性だけと共に.0と)それを使用しなければならない、」
However, it is not clear what exactly this attribute means, as the concept of "netmask" is not very well defined for point-to-point links (unlike multi-access links, where it means "you can reach hosts inside this netmask directly using layer 2, instead of sending packets via a router"). Even if the operating system's TCP/IP stack requires a netmask to be configured, for point-to-point links it could be just set to 255.255.255.255. So, why is this information sent in IKEv2?
しかしながら、この属性がいったい何を意味するかは、明確ではありません、「ネットマスク」の概念がそれほどポイントツーポイント接続(それが「直接層2を使用することであなたはこのネットマスクでホストに連絡できます、ルータでパケットを送ることの代わりに」と意味するところでマルチアクセスリンクと異なって)とよく定義されないとき。 オペレーティングシステムのTCP/IPスタックが、ネットマスクが構成されるのを必要としても、それがポイントツーポイント接続であることができたには、ただ.255に255.255に.255を設定してください。 それで、送られたこの情報はなぜIKEv2ですか?
One possible interpretation would be that the host is given a whole block of IP addresses instead of a single address. This is also what Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed- IPv6-Prefix attribute does in [RADIUS6]. However, nothing in the specification supports this interpretation, and discussions on the IPsec WG mailing list have confirmed it was not intended. Section 3.15.1 also says that multiple addresses are assigned using multiple INTERNAL_IP4/6_ADDRESS attributes.
1つの可能な解釈はただ一つのアドレスの代わりにIPアドレスの全体のブロックをホストに与えるということでしょう。 また、これはFramed IPネットマスクが[RADIUS]、「サブネットマスク」拡大がPPP[IPCPSubnet]でするIPCPでして、IPv6 Framed- IPv6-接頭語属性における接頭語の長さが[RADIUS6]ですることです。 しかしながら、仕様による何もこの解釈を支持しません、そして、IPsec WGメーリングリストについての議論はそれが意図しなかったと確認しました。 セクション3.15 .1 また、複数のアドレスが複数のINTERNAL_IP4/6_ADDRESS属性を使用することで割り当てられると言います。
Currently, this document's interpretation is the following:
INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as
INTERNAL_IP4_SUBNET containing the same information ("send traffic to
these addresses through me"), but also implies a link boundary. For
現在、このドキュメントの解釈は以下です: INTERNAL_IP4_NETMASKは同じ情報(「私を通してこれらのアドレスに交通を送る」)を含んでいて、CFG_REPLYでおよそINTERNAL_IP4_SUBNETと同じものを意味しますが、リンク境界をまた含意します。 for
Eronen & Hoffman Informational [Page 41] RFC 4718 IKEv2 Clarifications October 2006
[41ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
instance, the client could use its own address and the netmask to calculate the broadcast address of the link. (Whether the gateway will actually deliver broadcast packets to other VPN clients and/or other nodes connected to this link is another matter.)
例、クライアントは、リンクの放送演説について計算するのにそれ自身のアドレスとネットマスクを使用できました。 (ゲートウェイが実際に他のVPNクライアント、そして/または、このリンクに接続された他のノードに放送パケットを届けるかどうかが、別の問題です。)
An empty INTERNAL_IP4_NETMASK attribute can be included in a CFG_REQUEST to request this information (although the gateway can send the information even when not requested). However, it seems that non-empty values for this attribute do not make sense in CFG_REQUESTs.
この情報を要求するためにCFG_REQUESTに空のINTERNAL_IP4_NETMASK属性を含むことができます(要求されないと、ゲートウェイは情報を送ることができますが)。 しかしながら、この属性のための非空の値がCFG_REQUESTsで理解できないように思えます。
Fortunately, Section 4 clearly says that a minimal implementation does not need to include or understand the INTERNAL_IP4_NETMASK attribute, and thus this document recommends that implementations should not use the INTERNAL_IP4_NETMASK attribute or assume that the other peer supports it.
幸い、セクション4は、最小限の器具がINTERNAL_IP4_NETMASK属性を含んでいるか、または理解する必要はないと明確に言って、その結果、このドキュメントは、実現が、INTERNAL_IP4_NETMASK属性を使用するべきではありませんし、またもう片方の同輩がそれを支持すると仮定するべきでないことを勧めます。
(References: Charlie Kaufman's mail "RE: Proposed Last Call based revisions to IKEv2", 2004-05-27. Email discussion with Tero Kivinen, Jan 2005. Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and Implementation Guidelines", 2005-02-07. "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
RE: Proposed Last Callは改正をIKEv2"に基礎づけました、2004年5月27日。「Yoavニールの「Re: 新しいI-D: IKEv2明確化と実施要綱」(2005年2月7日)というメール「明確化未解決の問題: INTERNAL_IP4_SUBNET/NETMASK」糸をTero Kivinen(2005年1月)との議論にメールしてください、2005)年4月」という(の参照: チャーリー・カウフマンメール
6.5. Configuration Payloads for IPv6
6.5. IPv6のための構成有効搭載量
IKEv2 also defines configuration payloads for IPv6. However, they are based on the corresponding IPv4 payloads and do not fully follow the "normal IPv6 way of doing things".
また、IKEv2はIPv6のために構成ペイロードを定義します。 しかしながら、彼らは、対応するIPv4ペイロードに基づいていて、完全に「標準のIPv6物事のやり方」に続くというわけではありません。
A client can be assigned an IPv6 address using the INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange could look like this:
INTERNAL_IP6_ADDRESS構成ペイロードを使用することでIPv6アドレスをクライアントに割り当てることができます。 最小量の交換はこれに似るかもしれません:
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
CP(CFG_要求)が内部の_IP6_アドレス()の内部の_IP6_DNS() TSi=と等しい、(0、0-65535: : --FFFF:FFFF:FFFF:FFFF:FFFF: FFFF: FFFF:、FFFF) TSrは等しいです。(0、0-65535: : --FFFF:FFFF:FFFF:FFFF:FFFF: FFFF: FFFF:、FFFF)
CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
回答..等しい..内部..アドレス..内部..等しい..等しい(0、0-65535: : --FFFF:FFFF:FFFF:FFFF:FFFF: FFFF: FFFF:、FFFF)
In particular, IPv6 stateless autoconfiguration or router advertisement messages are not used; neither is neighbor discovery.
IPv6の国がない自動構成かルータ通知メッセージが特に、使用されていません。 隣人発見もそうではありません。
Eronen & Hoffman Informational [Page 42] RFC 4718 IKEv2 Clarifications October 2006
[42ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST to request a specific address or interface identifier. The gateway first checks if the specified address is acceptable, and if it is, returns that one. If the address was not acceptable, the gateway will attempt to use the interface identifier with some other prefix; if even that fails, the gateway will select another interface identifier.
また、クライアントは、特定のアドレスかインタフェース識別子を要求するためにCFG_REQUESTで非空のINTERNAL_IP6_ADDRESS属性を送ることができます。 ゲートウェイは最初に指定されたアドレスが許容できるかどうかと、それが許容できるかどうかチェックして、リターンはその1つです。 アドレスが許容できなかったなら、ゲートウェイは、ある他の接頭語があるインタフェース識別子を使用するのを試みるでしょう。 それさえ失敗すると、ゲートウェイは別のインタフェース識別子を選択するでしょう。
The INTERNAL_IP6_ADDRESS attribute also contains a prefix length field. When used in a CFG_REPLY, this corresponds to the INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft). See the previous section for more details.
また、INTERNAL_IP6_ADDRESS属性は接頭語長さの分野を含んでいます。 CFG_REPLYで使用されると、これはIPv4場合におけるINTERNAL_IP4_NETMASK属性に対応しています(_本当に、呼ばれたINTERNAL_IP6はIKEv2草稿の以前のバージョンのNETMASKでした)。 その他の詳細に関して前項を見てください。
While this approach to configuring IPv6 addresses is reasonably simple, it has some limitations: IPsec tunnels configured using IKEv2 are not fully-featured "interfaces" in the IPv6 addressing architecture [IPv6Addr] sense. In particular, they do not necessarily have link-local addresses, and this may complicate the use of protocols that assume them, such as [MLDv2]. (Whether they are called "interfaces" in some particular operating system is a different issue.)
IPv6アドレスを構成することへのこのアプローチは合理的に簡単ですが、それには、いくつかの制限があります: IKEv2を使用することで構成されたIPsecトンネルはIPv6アドレッシング体系[IPv6Addr]意味で完全な特集された「インタフェース」であるというわけではありません。 彼らには、特に、リンクローカルのアドレスが必ずあるというわけではありません、そして、これはそれらを仮定するプロトコルの使用を複雑にするかもしれません、[MLDv2]などのように。 (それらが何らかの特定のオペレーティングシステムで「インタフェース」と呼ばれるかどうかが、別問題です。)
(References: "VPN remote host configuration IPv6 ?" thread, May 2004. "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
2004年5月に縫うように通ってください。(参照: 「VPNのリモートホスト構成IPv6--」 「明確化未解決の問題: INTERNAL_IP4_SUBNET/NETMASK」は2005年4月に縫うように通ります。)
6.6. INTERNAL_IP6_NBNS
6.6. 内部の_IP6_NBNS
Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending the IPv6 address of NetBIOS name servers.
セクション3.15 .1 NetBIOSネームサーバのIPv6アドレスを送るためにINTERNAL_IP6_NBNS属性を定義します。
However, NetBIOS is not defined for IPv6 and probably never will be. Thus, this attribute most likely does not make much sense.
しかしながら、NetBIOSはIPv6のために定義されないで、またたぶん決してないでしょう。 したがって、この属性はたぶんあまり理解できません。
(Pointed out by Bernard Aboba in the IP Configuration Security (ICOS) BoF at IETF62.)
(IETF62のIP構成セキュリティ(ICOS)転炉でバーナードAbobaによって指摘されます。)
6.7. INTERNAL_ADDRESS_EXPIRY
6.7. 内部の_アドレス_満期
Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as "Specifies the number of seconds that the host can use the internal IP address. The host MUST renew the IP address before this expiry time. Only one of these attributes MAY be present in the reply."
セクション3.15 .1 「ホストが内部のIPアドレスを使用できる秒の数を指定する」ときEXPIRYが結果と考えるINTERNAL_ADDRESS_を定義します。 ホストはこの満期時の前にIPアドレスを更新しなければなりません。 「これらの属性の1つだけが回答で存在しているかもしれません。」
Expiry times and explicit renewals are primarily useful in environments like DHCP, where the server cannot reliably know when
満期回と明白な更新はDHCPのような環境で主として役に立ちます。(そこでは、サーバがいつかを確かに知ることができません)。
Eronen & Hoffman Informational [Page 43] RFC 4718 IKEv2 Clarifications October 2006
[43ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
the client has gone away. However, in IKEv2 this is known, and the gateway can simply free the address when the IKE_SA is deleted.
クライアントは立ち去りました。 しかしながら、IKEv2では、これは知られています、そして、IKE_SAが削除されるとき、ゲートウェイは単にアドレスを解放できます。
Also, Section 4 says that supporting renewals is not mandatory. Given that this functionality is usually not needed, we recommend that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute. (And since this attribute does not seem to make much sense for CFG_REQUESTs, clients should not send it either.)
また、セクション4は、更新をサポートするのが義務的でないと言います。 この機能性は通常必要でないなら、私たちは、ゲートウェイがINTERNAL_ADDRESS_EXPIRY属性を送るはずがないことを勧めます。 (そして、この属性がCFG_REQUESTsのために多くを理解できるように思えないので、クライアントはそれを送るべきではありません。)
Note that according to Section 4, clients are required to understand INTERNAL_ADDRESS_EXPIRY if they receive it. A minimum implementation would use the value to limit the lifetime of the IKE_SA.
セクション4に従って、それに注意してください、そして、彼らがそれを受けるなら、クライアントはINTERNAL_ADDRESS_EXPIRYを理解しなければなりません。 最小の実装は、IKE_SAの生涯を制限するのに値を使用するでしょう。
(References: Tero Kivinen's mail "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05. "Questions about internal address" thread, April 2005.)
(参照: 2005年4月5日「草稿eronen-ipsec-ikev2明確化02.txtのコメント」というTero Kivinenのメール、「内部のアドレスに関する質問」は2005年4月に縫うように通ります。)
6.8. Address Assignment Failures
6.8. アドレス課題失敗
If the responder encounters an error while attempting to assign an IP address to the initiator, it responds with an INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1. However, there are some more complex error cases.
IPアドレスを創始者に割り当てるのを試みている間、応答者が誤りに遭遇するなら、それはセクション3.10.1で説明されるようにINTERNAL_ADDRESS_FAILURE通知で応じます。 しかしながら、それ以上の複雑な誤り事件があります。
First, if the responder does not support configuration payloads at all, it can simply ignore all configuration payloads. This type of implementation never sends INTERNAL_ADDRESS_FAILURE notifications. If the initiator requires the assignment of an IP address, it will treat a response without CFG_REPLY as an error.
まず最初に、応答者が全く構成ペイロードを支えないなら、それは単にすべての構成ペイロードを無視できます。 このタイプの実装は_ADDRESS_FAILURE通知をINTERNALに決して送りません。 創始者がIPアドレスの課題を必要とすると、それはCFG_REPLYのない応答を誤りとして扱うでしょう。
A second case is where the responder does support configuration payloads, but only for particular type of addresses (IPv4 or IPv6). Section 4 says that "A minimal IPv4 responder implementation will ignore the contents of the CP payload except to determine that it includes an INTERNAL_IP4_ADDRESS attribute". If, for instance, the initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the IPv6 part and process the IPv4 request as usual.
応答者が構成ペイロードを支えるところですが、特定のタイプのアドレス(IPv4かIPv6)のためだけに2番目のケースはそうです。 「INTERNAL_IP4_ADDRESS属性を含んでいることを決定するのを除いて、最小量のIPv4応答者実装はCPペイロードのコンテンツを無視するでしょう。」と、セクション4は言います。 例えば、創始者がCFG_REQUESTでINTERNAL_IP4_ADDRESSとINTERNAL_IP6_ADDRESSの両方を入れるなら、その結果、IPv4だけ応答者は単にIPv4がいつものように要求するIPv6部分とプロセスを無視できます。
A third case is where the initiator requests multiple addresses of a type that the responder supports: what should happen if some (but not all) of the requests fail? It seems that an optimistic approach would be the best one here: if the responder is able to assign at least one address, it replies with those; it sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
3番目のケースは創始者が応答者がサポートするタイプの複数のアドレスを要求するところです: 要求のいくつか(すべてでない)が失敗するなら、何が起こるべきですか? 楽観的なアプローチがここの最も良い方であるように思えます: 応答者が少なくとも1つのアドレスを割り当てることができるなら、それらで、返答します。 アドレスを全く割り当てることができない場合にだけ、それはINTERNAL_ADDRESS_FAILUREを送ります。
(References: "ikev2 and internal_ivpn_address" thread, June 2005.)
(参照: 「ikev2と内部の_ivpn_アドレス」は2005年6月に縫うように通ります。)
Eronen & Hoffman Informational [Page 44] RFC 4718 IKEv2 Clarifications October 2006
[44ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
7. Miscellaneous Issues
7. 種々雑多な問題
7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR
7.1. _合っているID IPV4_ADDRと_ID IPV6_ADDR
When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match anything in the TSi/TSr payloads. For example, in a site-to-site VPN between two security gateways, the gateways could authenticate each other as ID_IPV4_ADDR(192.0.1.1) and ID_IPV4_ADDR(192.0.2.1), and then create a CHILD_SA for protecting traffic between 192.0.1.55/32 (a host behind the first security gateway) and 192.0.2.240/28 (a network behind the second security gateway). The authenticated identities (IDi/IDr) are linked to the authorized traffic selectors (TSi/TSr) using "Child SA Authorization Data" in the Peer Authorization Database (PAD).
IDi/IDrペイロードでID_IPV4_ADDR/ID_IPV6_ADDRアイデンティティタイプを使用するとき、IKEv2は、TSi/TSrペイロードの何も合わせるためにこのアドレスを必要としません。 そして、例えば、2セキュリティ門の間のサイトからサイトへのVPNでは、ゲートウェイが_ID IPV4_ADDRとして互いを認証するかもしれない、(192.0、.1の.1と)ID_IPV4_ADDR、(192.0、.2、.1)、次に、保護が192.0の間で.1.55/を取引するのでCHILD_SAを作成してください、32(最初のセキュリティゲートウェイの後ろのホスト)、192.0 .2 .240/28(2番目のセキュリティゲートウェイの後ろのネットワーク)。 認証されたアイデンティティ(IDi/IDr)は、Peer Authorization Database(PAD)の「子供SA承認データ」を使用することで認可されたトラフィックセレクタ(TSi/TSr)にリンクされます。
Furthermore, IKEv2 does not require that the addresses in ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the IKE packets. However, other specifications may place additional requirements regarding this. For example, [PKI4IPsec] requires that implementation must be capable of comparing the addresses in the ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the IKE packets, and this comparison must be enabled by default.
その上、IKEv2は、_ID_IPV4_ADDR/ID IPV6_ADDRのアドレスがIKEパケットのIPヘッダーでアドレスに合っているのを必要としません。 しかしながら、他の仕様はこれに関する追加要件を置くかもしれません。 例えば、[PKI4IPsec]は、実装がIKEパケットのIPヘッダーの_ID_IPV4_ADDR/ID IPV6_ADDRのアドレスがあるアドレスを比較できなければならないのを必要とします、そして、デフォルトでこの比較を可能にしなければなりません。
(References: "Identities types IP address,FQDN/user FQDN and DN and its usage in preshared key authentication" thread, Jan 2005. "Matching ID_IPV4_ADDR and ID_IPV6_ADDR" thread, May 2006.)
(参照: 「前共有された主要な認証におけるタイプIPが扱うアイデンティティ、FQDN/ユーザFQDN、DN、およびその用法」は縫うように通ります、1月2005日の「_合っているID IPV4_ADDRと_ID IPV6_ADDR」スレッド、2006年5月。)
7.2. Relationship of IKEv2 to RFC 4301
7.2. RFC4301へのIKEv2の関係
The IKEv2 specification refers to [RFC4301], but it never clearly defines the exact relationship.
IKEv2仕様は[RFC4301]について言及しますが、それは明確に正確な関係を決して定義しません。
However, there are some requirements in the specification that make it clear that IKEv2 requires [RFC4301]. In other words, an implementation that does IPsec processing strictly according to [RFC2401] cannot be compliant with the IKEv2 specification.
しかしながら、IKEv2が[RFC4301]を必要とすると断言する仕様によるいくつかの要件があります。 言い換えれば、[RFC2401]に従って厳密にIPsecに処理をする実装はIKEv2仕様で対応するはずがありません。
One such example can be found in Section 2.24: "Specifically, tunnel encapsulators and decapsulators for all tunnel-mode SAs created by IKEv2 [...] MUST implement the tunnel encapsulation and decapsulation processing specified in [RFC4301] to prevent discarding of ECN congestion indications."
セクション2.24でその一例を見つけることができます: 「明確に、IKEv2[…]によって作成されたすべてのトンネルモードSAsのためにencapsulatorsとdecapsulatorsにトンネルを堀ってください」 「トンネルカプセル化と被膜剥離術が電子証券取引ネットワークの混雑指摘を捨てるのを防ぐために[RFC4301]で指定された処理であると実装しなければなりません。」
Nevertheless, the changes required to existing [RFC2401] implementations are not very large, especially since supporting many of the new features (such as Extended Sequence Numbers) is optional.
それにもかかわらず、既存の[RFC2401]実装に必要である変化はそれほど大きくはありません、特に新機能(Extended Sequence民数記などの)の多くをサポートするのが任意であるので。
Eronen & Hoffman Informational [Page 45] RFC 4718 IKEv2 Clarifications October 2006
[45ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
7.3. Reducing the Window Size
7.3. ウィンドウサイズを減少させます。
In IKEv2, the window size is assumed to be a (possibly configurable) property of a particular implementation and is not related to congestion control (unlike the window size in TCP, for instance).
IKEv2では、ウィンドウサイズは、特定の実装の(ことによると構成可能)の特性であると思われて、輻輳制御(TCPのウィンドウサイズと異なって例えば)に関連しません。
In particular, it is not defined what the responder should do when it receives a SET_WINDOW_SIZE notification containing a smaller value than is currently in effect. Thus, there is currently no way to reduce the window size of an existing IKE_SA. However, when rekeying an IKE_SA, the new IKE_SA starts with window size 1 until it is explicitly increased by sending a new SET_WINDOW_SIZE notification.
特に、現在有効であるより小さい値を含むSET_WINDOW_SIZE通知を受け取るとき、応答者が何をするべきであるかは定義されません。 したがって、現在、既存のIKE_SAのウィンドウサイズを減少させる方法が全くありません。 しかしながら、IKE_SAを「再-合わせ」るとき、それが_WINDOW_SIZE通知を新しいSETに送ることによって明らかに増強されるまで、新しいIKE_SAはウィンドウサイズ1から始まります。
(References: Tero Kivinen's mail "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
(参照: 「草稿eronen-ipsec-ikev2明確化02.txtのコメント」というTero Kivinenのメール、2005年4月5日)。
7.4. Minimum Size of Nonces
7.4. 一回だけの最小規模
Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST be at least half the key size of the negotiated prf."
「IKEv2で使用される一回だけは、手当たりしだいに選ばなければならなくて、サイズにおける少なくとも128ビットでなければならなく、少なくとも交渉されたprfの主要なサイズの半分であるに違いありません。」と、セクション2.10は言います。
However, the initiator chooses the nonce before the outcome of the negotiation is known. In this case, the nonce has to be long enough for all the PRFs being proposed.
しかしながら、交渉の結果が知られている前に創始者は一回だけを選びます。 この場合、提案されるすべてのPRFsには、一回だけは十分長くなければなりません。
7.5. Initial Zero Octets on Port 4500
7.5. ポート4500の上で八重奏に全く頭文字をつけないでください。
It is not clear whether a peer sending an IKE_SA_INIT request on port 4500 should include the initial four zero octets. Section 2.23 talks about how to upgrade to tunneling over port 4500 after message 2, but it does not say what to do if message 1 is sent on port 4500.
INITが4500が含むべきであるポートの上で要求するイケ_SA_に初期の4を送る同輩が八重奏のゼロに合っているかどうかは、明確ではありません。 セクション2.23はどうメッセージ2の後にポート4500の上でトンネルを堀るのにアップグレードするかに関して話しますが、それは、メッセージ1を転送するならするべきことが4500を移植することを示しません。
IKE MUST listen on port 4500 as well as port 500.
イケは、ポート4500の上で聴いて、500を移植しなければなりません。
[...]
[...]
The IKE initiator MUST check these payloads if present and if
they do not match the addresses in the outer packet MUST tunnel
all future IKE and ESP packets associated with this IKE_SA over
UDP port 4500.
存在しているなら、IKE創始者はこれらのペイロードをチェックしなければなりません、そして、合っていないなら、外側のパケットのアドレスはすべての未来にIKEにトンネルを堀らなければなりません、そして、UDPの上のこのIKE_SAに関連している超能力パケットは4500を移植します。
To tunnel IKE packets over UDP port 4500, the IKE header has four
octets of zero prepended and the result immediately follows the
UDP header. [...]
IKEヘッダーはゼロの4つの八重奏をprependedさせます、そして、UDPの上でIKEパケットにトンネルを堀るために、4500を移植してください、そして、結果はすぐに、UDPヘッダーに続きます。 [...]
Eronen & Hoffman Informational [Page 46] RFC 4718 IKEv2 Clarifications October 2006
[46ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
The very beginning of Section 2 says "... though IKE messages may also be received on UDP port 4500 with a slightly different format (see section 2.23)."
「また、UDPポート4500の上にわずかに異なった形式でIKEメッセージを受け取るかもしれませんが(セクション2.23を見てください)、セクション2の非常に始まるのは」 …を言います。」
That "slightly different format" is only described in discussing what to do after changing to port 4500. However, [RFC3948] shows clearly the format has the initial zeros even for initiators on port 4500. Furthermore, without the initial zeros, the processing engine cannot determine whether the packet is an IKE packet or an ESP packet.
4500を移植するために変化した後に何をしたらよいかを議論する際にその「わずかに異なった形式」は説明されるだけです。 しかしながら、[RFC3948]は、形式がポート4500の上に創始者さえのための初期のゼロを持っているのを明確に示します。 その上、初期のゼロがなければ、処理エンジンは、パケットがIKEパケットかそれとも超能力パケットであるかを決定できません。
Thus, all packets sent on port 4500 need the four-zero prefix; otherwise, the receiver won't know how to handle them.
したがって、転送されたすべてのパケットが4-ゼロが前に置く4500年の必要性を移植します。 さもなければ、受信機はそれらを扱う方法を知らないでしょう。
7.6. Destination Port for NAT Traversal
7.6. NAT縦断のための仕向港
Section 2.23 says that "an IPsec endpoint that discovers a NAT between it and its correspondent MUST send all subsequent traffic to and from port 4500".
「それとその通信員の間のNATを発見するIPsec終点はポートとポート4500からすべてのその後のトラフィックを送らなければなりません。」と、セクション2.23は言います。
This sentence is misleading. The peer "outside" the NAT uses source port 4500 for the traffic it sends, but the destination port is, of course, taken from packets sent by the peer behind the NAT. This port number is usually dynamically allocated by the NAT.
この文は紛らわしいです。 それが送るトラフィックのためのNATが使用する「外同輩」のソースポート4500、もちろんNATの後ろの同輩によって送られたパケットから仕向港だけを取ります。 通常、NATはダイナミックにこのポートナンバーを割り当てます。
7.7. SPI Values for Messages outside an IKE_SA
7.7. IKE_SAの外のMessagesのためのSPI Values
The IKEv2 specification is not quite clear what SPI values should be used in the IKE header for the small number of notifications that are allowed to be sent outside an IKE_SA. Note that such notifications are explicitly not Informational exchanges; Section 1.5 makes it clear that these are one-way messages that must not be responded to.
IKEv2仕様はどんなSPI値がIKE_SAの外で送ることができる通知の少ない数にIKEヘッダーで使用されるべきであるかが全く明確であるというわけではありません。 Informational交換ではなく、そのような通知が明らかにそうであるというメモ。 セクション1.5はそれをこれらが反応させてはいけない一方向メッセージであることが明確にします。
There are two cases when such a one-way notification can be sent: INVALID_IKE_SPI and INVALID_SPI.
そのような一方向通知を送ることができるとき、2つのケースがあります: _病人のIKE_SPIと病人_SPI。
In case of INVALID_IKE_SPI, the message sent is a response message, and Section 2.21 says that "If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied."
INVALID_IKE_SPIの場合には、送られたメッセージは応答メッセージです、そして、「応答を送るなら、応答を同じIKE SPIsとMessage IDがコピーされている状態でそれが来させた起源からIPアドレスとポートに送らなければなりません。」と、セクション2.21は言います。
In case of INVALID_SPI, however, there are no IKE SPI values that would be meaningful to the recipient of such a notification. Also, the message sent is now an INFORMATIONAL request. A strict interpretation of the specification would require the sender to invent garbage values for the SPI fields. However, we think this was not the intention, and using zero values is acceptable.
しかしながら、INVALID_SPIの場合には、どんなそのような通知の受取人にとって、重要なIKE SPI値もありません。 また、現在、送られたメッセージはINFORMATIONAL要求です。 仕様の厳しい解釈は、送付者がSPI分野にゴミ値を発明するのを必要とするでしょう。 しかしながら、私たちは、これが意志でなかったと思います、そして、値を全く使用しないのは許容できます。
(References: "INVALID_IKE_SPI" thread, June 2005.)
(参照: 「無効の_イケ_SPI」は2005年6月に縫うように通ります。)
Eronen & Hoffman Informational [Page 47] RFC 4718 IKEv2 Clarifications October 2006
[47ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
7.8. Protocol ID/SPI Fields in Notify Payloads
7.8. プロトコルID/SPI分野は中で有効搭載量に通知します。
Section 3.10 says that the Protocol ID field in Notify payloads "For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt". However, the specification does not clearly say which notifications are related to existing SAs and which are not.
セクション3.10は、Protocol IDが「既存のSAに関連しないでください、ゼロとしてこの野原を送らなければならなくて、領収書の上で無視しなければならないという通知」のためにNotifyでペイロードをさばくと言います。 しかしながら、仕様はどの通知が既存のSAsに関連するか、そして、どれが関連されないかを明確に言いません。
Since the main purpose of the Protocol ID field is to specify the type of the SPI, our interpretation is that the Protocol ID field should be non-zero only when the SPI field is non-empty.
プロトコルID分野の主な目的がSPIのタイプを指定することであるので、私たちの解釈はSPI分野が非人影がないときにだけ、プロトコルID分野が非ゼロであるべきであるということです。
There are currently only two notifications where this is the case: INVALID_SELECTORS and REKEY_SA.
現在、2つの通知しかこれがそうであるところにありません: 無効の_セレクタとREKEY_SA。
7.9. Which message should contain INITIAL_CONTACT
7.9. どのメッセージがINITIAL_CONTACTを含むべきですか。
The description of the INITIAL_CONTACT notification in Section 3.10.1 says that "This notification asserts that this IKE_SA is the only IKE_SA currently active between the authenticated identities". However, neither Section 2.4 nor 3.10.1 says in which message this payload should be placed.
「この通知は、このIKE_SAが現在認証されたアイデンティティの間でアクティブな唯一のIKE_SAであると断言します。」と、セクション3.10.1における、INITIAL_CONTACT通知の記述は言います。 しかしながら、どちらのセクション2.4と3.10.1も、このペイロードがどのメッセージに置かれるべきであるかを言いません。
The general agreement is that INITIAL_CONTACT is best communicated in the first IKE_AUTH request, not as a separate exchange afterwards.
一般協定はその後の別々の交換でコミュニケートするのではなく、AUTHが要求する最初のイケ_でINITIAL_CONTACTを伝えるのが最も良いということです。
(References: "Clarifying the use of INITIAL_CONTACT in IKEv2" thread, April 2005. "Initial Contact messages" thread, December 2004. "IKEv2 and Initial Contact" thread, September 2004 and April 2005.)
(参照: 「IKEv2"スレッドと、4月2005日の「初期のContactメッセージ」スレッドと、12月2004日の「IKEv2と初期接触」でのCONTACTが糸を通すINITIAL_、2004年9月、および2005)年4月の使用をはっきりさせます」
7.10. Alignment of Payloads
7.10. 有効搭載量の整列
Many IKEv2 payloads contain fields marked as "RESERVED", mostly because IKEv1 had them, and partly because they make the pictures easier to draw. In particular, payloads in IKEv2 are not, in general, aligned to 4-octet boundaries. (Note that payloads were not aligned to 4-octet boundaries in IKEv1 either.)
多くのIKEv2ペイロードが「予約される」ように示される分野を含んでいます、IKEv1にはそれらがほとんどあって、一部画像を描くのをより簡単にするので。 一般に、特に、IKEv2のペイロードは4八重奏の境界に並べられません。 (ペイロードがIKEv1における4八重奏の境界に並べられなかったことに注意してください。)
(References: "IKEv2: potential 4-byte alignment problem" thread, June 2004.)
(参照: 「IKEv2: 潜在的4バイトの整列問題」は2004年6月に縫うように通ります。)
7.11. Key Length Transform Attribute
7.11. キー長変換属性
Section 3.3.5 says that "The only algorithms defined in this document that accept attributes are the AES based encryption, integrity, and pseudo-random functions, which require a single attribute specifying key width."
セクション3.3 .5 「属性を受け入れる本書では定義された唯一のアルゴリズムが、AESのベースの暗号化と、保全と、擬似ランダム機能です。」と言います。(機能は主要な幅を指定するただ一つの属性を必要とします)。
Eronen & Hoffman Informational [Page 48] RFC 4718 IKEv2 Clarifications October 2006
[48ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
This is incorrect. The AES-based integrity and pseudo-random functions defined in [IKEv2] always use a 128-bit key. In fact, there are currently no integrity or PRF algorithms that use the key length attribute (and we recommend that they should not be defined in the future either).
これは不正確です。 [IKEv2]で定義されたAESベースの保全と擬似ランダム機能はいつも128ビットのキーを使用します。 事実上、現在、キー長属性を使用するどんな保全もPRFアルゴリズムもありません(私たちは、それらが将来定義されるべきでないことを勧めます)。
For encryption algorithms, the situation is slightly more complex since there are three different types of algorithms:
暗号化アルゴリズムにおいて、3つの異なったタイプのアルゴリズムがあるので、状況はわずかに複雑です:
o The key length attribute is never used with algorithms that use a
fixed length key, such as DES and IDEA.
o キー長属性はDESやIDEAのように主要な固定長を使用するアルゴリズムで決して使用されません。
o The key length attribute is always included for the currently
defined AES-based algorithms (Cipher Block Chaining (CBC), Counter
(CTR) Mode, Counter with CBC-MAC (CCM), and Galois/Counter Mode
(GCM)). Omitting the key length attribute is not allowed; if the
proposal does not contain it, the proposal has to be rejected.
o キー長属性は現在定義されたAESベースのアルゴリズム(暗号Block Chaining(CBC)、Counter(CTR)モード、CBC-MACとCounter(CCM)、およびガロア/カウンタMode(GCM))のためにいつも含まれています。 キー長属性を省略するのは許されていません。 提案がそれを含んでいないなら、提案は拒絶されなければなりません。
o For other algorithms, the key length attribute can be included but
is not mandatory. These algorithms include, e.g., RC5, CAST, and
BLOWFISH. If the key length attribute is not included, the
default value specified in [RFC2451] is used.
o 他のアルゴリズムには、キー長属性は、含むことができますが、義務的ではありません。 アルゴリズムが含むこれら、例えば、RC5、キャスト、およびBLOWFISH。 キー長属性が含まれていないなら、[RFC2451]で指定されたデフォルト値は使用されています。
7.12. IPsec IANA Considerations
7.12. IPsec IANA問題
There are currently three different IANA registry files that contain important numbers for IPsec: ikev2-registry, isakmp-registry, and ipsec-registry. Implementers should note that IKEv2 may use numbers different from those of IKEv1 for a particular algorithm.
現在、IPsecの重要な数を含む3個の異なったIANA登録ファイルがあります: ikev2-登録、isakmp-登録、およびipsec-登録。 Implementersは、IKEv2が特定のアルゴリズムにおいて、IKEv1のものと異なった数を使用するかもしれないことに注意するはずです。
For instance, an encryption algorithm can have up to three different numbers: the IKEv2 "Transform Type 1" identifier in ikev2-registry, the IKEv1 phase 1 "Encryption Algorithm" identifier in ipsec- registry, and the IKEv1 phase 2 "IPSEC ESP Transform Identifier" isakmp-registry. Although some algorithms have the same number in all three registries, the registries are not identical.
例えば、暗号化アルゴリズムは最大3つの異なった番号を持つことができます: IKEv2は「ipsec登録、およびIKEv1フェーズ2「IPSEC ESP変換識別子」isakmp-登録でikev2-登録のタイプの1インチの識別子、IKEv1フェーズ1「暗号化アルゴリズム」識別子を変えます」。 いくつかのアルゴリズムがすべての3つの登録に同じ数を持っていますが、登録は同じではありません。
Similarly, an integrity algorithm can have at least the IKEv2 "Transform Type 3" identifier in ikev2-registry, the IKEv1 phase 2 "IPSEC AH Transform Identifier" in isakmp-registry, and the IKEv1 phase 2 ESP "Authentication Algorithm Security Association Attribute" identifier in isakmp-registry. And there is also the IKEv1 phase 1 "Hash Algorithm" list in ipsec-registry.
同様に、保全アルゴリズムは、少なくともIKEv2が「ikev2-登録のタイプの3インチの識別子、isakmp-登録のIKEv1フェーズ2「IPSEC AH変換識別子」、およびisakmp-登録のIKEv1フェーズ2超能力「認証アルゴリズムセキュリティ協会属性」識別子を変えること」を持つことができます。 そして、また、IKEv1フェーズ1「ハッシュアルゴリズム」リストがipsec-登録にあります。
This issue needs special care also when writing a specification for how a new algorithm is used with IPsec.
新しいアルゴリズムがIPsecと共にどう使用されるか仕様を書くとき、この問題は特別な注意も必要とします。
Eronen & Hoffman Informational [Page 49] RFC 4718 IKEv2 Clarifications October 2006
[49ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
7.13. Combining ESP and AH
7.13. そして、超能力を結合する、ああ。
The IKEv2 specification contains some misleading text about how ESP and AH can be combined.
IKEv2仕様はどう超能力とAHを結合できるかに関する何らかの紛らわしいテキストを含んでいます。
IKEv2 is based on [RFC4301], which does not include "SA bundles" that were part of [RFC2401]. While a single packet can go through IPsec processing multiple times, each of these passes uses a separate SA, and the passes are coordinated by the forwarding tables. In IKEv2, each of these SAs has to be created using a separate CREATE_CHILD_SA exchange. Thus, the text in Section 2.7 about a single proposal containing both ESP and AH is incorrect.
IKEv2は[RFC4301]に基づいています。(それは、[RFC2401]の一部であった「SAバンドル」を含んでいません)。 単一のパケットは複数の回IPsec処理に直面できますが、それぞれのこれらは別々のSAを用途に渡します、そして、パスは推進テーブルによって調整されます。 IKEv2では、それぞれのこれらのSAsは、別々のCREATE_CHILD_SA交換を使用することで作成されなければなりません。 したがって、セクション2.7の超能力とAHの両方を含むただ一つの提案に関するテキストは不正確です。
Moreover, the combination of ESP and AH (between the same endpoints) had already become largely obsolete in 1998 when RFC 2406 was published. Our recommendation is that IKEv2 implementations should not support this combination, and implementers should not assume the combination can be made to work in an interoperable manner.
そのうえ、超能力とAH(同じ終点の間の)の組み合わせはRFC2406が発行された1998年に既に主に時代遅れになりました。 私たちの推薦はIKEv2実装がこの組み合わせをサポートするべきでなくて、implementersが、共同利用できる方法で働くのを組み合わせをすることができると仮定するはずがないということです。
(References: "Rekeying SA bundles" thread, Oct 2005.)
(参照: 「Rekeying SAバンドル」は2005年10月に縫うように通ります。)
8. Implementation Mistakes
8. 実装誤り
Some implementers at the early IKEv2 bakeoffs didn't do everything correctly. This may seem like an obvious statement, but it is probably useful to list a few things that were clear in the document, but that some implementers didn't do. All of these things caused interoperability problems.
前のIKEv2 bakeoffsのいくらかのimplementersは正しくすべてをしませんでした。 これは明白な声明のように見えるかもしれませんが、ドキュメントで明確でしたが、いくらかのimplementersがしなかったいくつかのことを記載するのはたぶん役に立ちます。 これらのもののすべてが相互運用性問題を引き起こしました。
o Some implementations continued to send traffic on a CHILD_SA after
it was rekeyed, even after receiving an DELETE payload.
o DELETEペイロードを受けた後にさえそれが「再-合わせ」られた後にいくつかの実装が、CHILD_SAにトラフィックを送り続けていました。
o After rekeying an IKE_SA, some implementations did not reset their
message counters to zero. One set the counter to 2, another did
not reset the counter at all.
o IKE_SAを「再-合わせ」た後に、いくつかの実装はそれらのメッセージカウンタをゼロにリセットしませんでした。 1つは2にカウンタを設定して、別のものは全くカウンタをリセットしませんでした。
o Some implementations could only handle a single pair of traffic
selectors or would only process the first pair in the proposal.
o いくつかの実装が、1組のトラフィックセレクタを扱うことができただけであるか、または提案における最初の組を処理するだけでしょう。
o Some implementations responded to a delete request by sending an
empty INFORMATIONAL response and then initiated their own
INFORMATIONAL exchange with the pair of SAs to delete.
o aに反応するいくつかの実装が、削除するSAsの組と共に空のINFORMATIONALに応答を送って、それら自身のINFORMATIONAL交換を開始されたその時に送ることによって、要求を削除します。
o Although this did not happen at the bakeoff, from the discussion
there, it is clear that some people had not implemented message
window sizes correctly. Some implementations might have sent
o これはそこでbakeoffで議論から起こりませんでしたが、何人かの人々が正しくメッセージウィンドウサイズを実装していなかったのは、明確です。 いくつかの実装が発信したかもしれません。
Eronen & Hoffman Informational [Page 50] RFC 4718 IKEv2 Clarifications October 2006
[50ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
messages that did not fit into the responder's message windows,
and some implementations may not have torn down an SA if they did
not ever receive a message that they know they should have.
それがしたメッセージは応答者のメッセージウィンドウに収まりません、そして、彼らがかつて持つべきであるのを知っているというメッセージを受け取らなかったなら、いくつかの実装はSAを取りこわしていないかもしれません。
9. Security Considerations
9. セキュリティ問題
This document does not introduce any new security considerations to IKEv2. If anything, clarifying complex areas of the specification can reduce the likelihood of implementation problems that may have security implications.
このドキュメントはどんな新しいセキュリティ問題もIKEv2に紹介しません。 どちらかと言えば、仕様の複雑な領域をはっきりさせるのはセキュリティ意味を持っているかもしれない実装問題の見込みを減少させることができます。
10. Acknowledgments
10. 承認
This document is mainly based on conversations on the IPsec WG mailing list. The authors would especially like to thank Bernard Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Francis Dupont, Alfred Hoenes, Mika Joutsenvirta, Charlie Kaufman, Stephen Kent, Tero Kivinen, Yoav Nir, Michael Richardson, and Joel Snyder for their contributions.
このドキュメントはIPsec WGメーリングリストにおける会話に主に基づいています。 作者は彼らの貢献についてバーナードAboba、ヤリArkko、ビジェイDevarapalli、ウィリアム・ディクソン、フランシス・デュポン、アルフレッドHoenes、ミカJoutsenvirta、チャーリー・カウフマン、スティーブン・ケント、Tero Kivinen、Yoavニール、マイケル・リチャードソン、およびジョエル・スナイダーに特に感謝したがっています。
In addition, the authors would like to thank all the participants of the first public IKEv2 bakeoff, held in Santa Clara in February 2005, for their questions and proposed clarifications.
さらに、作者は彼らの質問と提案された明確化について2005年2月にサンタクララで持たれていた最初の公共のIKEv2 bakeoffの参加者各位に感謝したがっています。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[IKEv2] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[IKEv2ALG] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[IKEv2ALG] シラー、J.、「インターネット・キー・エクスチェンジバージョン2(IKEv2)における使用のための暗号アルゴリズム」、RFC4307、2005年12月。
[PKCS1v20] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", RFC 2437, October 1998.
[PKCS1v20] Kaliski、B.、およびJ.Staddon、「PKCS#1:」 RSA暗号仕様バージョン2インチ、RFC2437、10月1998日
[PKCS1v21] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[PKCS1v21] イェンソン、J.、およびB.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
Eronen & Hoffman Informational [Page 51] RFC 4718 IKEv2 Clarifications October 2006
[51ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
11.2. Informative References
11.2. 有益な参照
[Aura05] Aura, T., Roe, M., and A. Mohammed, "Experiences with
Host-to-Host IPsec", 13th International Workshop on
Security Protocols, Cambridge, UK, April 2005.
[Aura05] 香気、T.、魚卵、M.、およびA.モハメッド、「ホストからホストへのIPsecの経験」、セキュリティプロトコル、ケンブリッジ、イギリス(2005年4月)に関する第13国際ワークショップ。
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[EAP]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[HashUse] Hoffman, P., "Use of Hash Algorithms in IKE and IPsec",
Work in Progress, July 2006.
[HashUse] ホフマン、P.、「IKEとIPsecにおけるハッシュアルゴリズムの使用」が進歩、2006年7月に働いています。
[IPCPSubnet] Cisco Systems, Inc., "IPCP Subnet Mask Support
Enhancements", http://www.cisco.com/univercd/cc/td/
doc/product/software/ios121/121newft/121limit/121dc/
121dc3/ipcp_msk.htm, January 2003.
[IPCPSubnet]シスコシステムズInc.、「IPCPサブネットマスクサポート増進」、 http://www.cisco.com/univercd/cc/td/ doc/製品/ソフトウェア/ios121/121newft/121limit/121dc/121dc3/ipcp_msk.htm、1月2003日
[IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[IPv6Addr] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[MIPv6] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
そして、[MLDv2]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
2005年12月の[NAI]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[PKI4IPsec] Korver, B., "Internet PKI Profile of IKEv1/ISAKMP,
IKEv2, and PKIX", Work in Progress, April 2006.
B.と、「PKIが輪郭を描くIKEv1/ISAKMPのインターネット、IKEv2、およびPKIX」という[PKI4IPsec]Korverは進歩、2006年4月に働いています。
[RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote
Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)", RFC 3579,
September 2003.
[RADEAP]Aboba、B.とP.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(2003年9月)。
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[半径]Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RADIUS6] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RADIUS6] AbobaとB.とゾルン、G.とD.ミットンと「半径とIPv6"、RFC3162、2001年8月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
Eronen & Hoffman Informational [Page 52] RFC 4718 IKEv2 Clarifications October 2006
[52ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC2451] ペレイラとR.とR.アダムス、「超能力CBC-モード暗号アルゴリズム」、RFC2451、1998年11月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 3664,
January 2004.
[RFC3664] ホフマン、P.、「インターネット・キー・エクスチェンジプロトコル(IKE)のためのAES-XCBC-PRF-128アルゴリズム」、RFC3664、2004年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC3948]HuttunenとA.とSwanderとB.とボルペとV.とDiBurro、L.とM.Stenberg、「IPsec超能力パケットのUDPカプセル化」RFC3948(2005年1月)。
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434,
February 2006.
[RFC4434] ホフマン、P.、「インターネット・キー・エクスチェンジプロトコル(IKE)のためのAES-XCBC-PRF-128アルゴリズム」、RFC4434、2006年2月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet
text messages", RFC 822, August 1982.
[RFC822] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、RFC822、1982年8月。
[ReAuth] Nir, Y., "Repeated Authentication in Internet Key
Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[ReAuth]ニール、Y.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコルにおける繰り返された認証」、RFC4478、2006年4月。
[SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and
T. Polk, "Simple Certificate Validation Protocol
(SCVP)", Work in Progress, June 2006.
[SCVP]フリーマン、T.、R.、Malpani、A.、クーパー、D.、およびT.ポーク、「簡単な証明書合法化プロトコル(SCVP)」というHousleyは進行中(2006年6月)で働いています。
Eronen & Hoffman Informational [Page 53] RFC 4718 IKEv2 Clarifications October 2006
[53ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
Appendix A. Exchanges and Payloads
付録A.交換と有効搭載量
This appendix contains a short summary of the IKEv2 exchanges, and what payloads can appear in which message. This appendix is purely informative; if it disagrees with the body of this document or the IKEv2 specification, the other text is considered correct.
この付録はIKEv2交換、およびペイロードがどのメッセージで見えることができることに関する要約を含んでいます。 この付録は純粋に有益です。 このドキュメントかIKEv2仕様のボディーと意見を異にするなら、もう片方のテキストは正しいと考えられます。
Vendor-ID (V) payloads may be included in any place in any message. This sequence shows what are, in our opinion, the most logical places for them.
業者ID(V)ペイロードはどんなメッセージのどんな場所にも含まれるかもしれません。 この系列は、それらのために何が私たちの意見で最も論理的な場所であるかを示します。
The specification does not say which messages can contain N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is not yet shown below.
仕様は、どのメッセージがN(SET_WINDOW_SIZE)を含むことができるかを言いません。 どんなメッセージにもそれを含むことができますが、それは以下にまだ示されていません。
A.1. IKE_SA_INIT Exchange
A.1。 イケ_SA_イニット交換
request --> [N(COOKIE)],
SA, KE, Ni,
[N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP)],
[V+]
要求-->[N(COOKIE)]、SA、KE、Ni[N(NAT_DETECTION_SOURCE_IP)+、N(NAT_DETECTION_DESTINATION_IP)][+に対する]
normal response <-- SA, KE, Nr,
(no cookie) [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[V+]
通常の応答<--SA、KE、Nr(クッキーがありません)[N(NAT_DETECTION_SOURCE_IP)、N(NAT_DETECTION_DESTINATION_IP]、[N(HTTP_CERT_LOOKUP_SUPPORTED)]、CERTREQ+][+に対する]
A.2. IKE_AUTH Exchange without EAP
A.2。 EAPのないイケ_AUTH交換
request --> IDi, [CERT+],
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
AUTH,
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[V+]
要求..HTTP..超能力[+に対する]
Eronen & Hoffman Informational [Page 54] RFC 4718 IKEv2 Clarifications October 2006
[54ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
response <-- IDr, [CERT+],
AUTH,
[CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)],
[V+]
応答<--IDr、[CERT+]、AUTH、[CP(CFG_REPLY)]、[N(IPCOMP_SUPPORTED)]、[N(USE_TRANSPORT_MODE)]、[N(__SUPPORTEDではなく、超能力TFC_PADDING_)]、[N(NON_FIRST_FRAGMENTS_ALSO)]、SA、TSi、TSr[N(ADDITIONAL_TS_POSSIBLE)][+に対する]
A.3. IKE_AUTH Exchange with EAP
A.3。 EAPとのイケ_AUTH交換
first request --> IDi,
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[V+]
要求..HTTP..超能力[+に対する]
first response <-- IDr, [CERT+], AUTH,
EAP,
[V+]
最初に、応答<--IDr、[CERT+]、AUTH、EAP[+に対する]
/ --> EAP
repeat 1..N times |
\ <-- EAP
/-->EAPは1を繰り返します。N回| \<--EAP
last request --> AUTH
最後の要求-->AUTH
last response <-- AUTH,
[CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)],
[V+]
最後の応答<--AUTH、[CP(CFG_REPLY)]、[N(IPCOMP_SUPPORTED)]、[N(USE_TRANSPORT_MODE)]、[N(__SUPPORTEDではなく、超能力TFC_PADDING_)]、[N(NON_FIRST_FRAGMENTS_ALSO)]、SA、TSi、TSr[N(ADDITIONAL_TS_POSSIBLE)][+に対する]
Eronen & Hoffman Informational [Page 55] RFC 4718 IKEv2 Clarifications October 2006
[55ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying CHILD_SAs
A.4。 _作成/Rekeying子供_SAsへの子供_SA交換を引き起こしてください。
request --> [N(REKEY_SA)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Ni, [KEi], TSi, TSr
要求-->[N(REKEY_SA)]、[N(IPCOMP_SUPPORTED)+]、[N(USE_TRANSPORT_MODE)]、[N(__SUPPORTEDではなく、超能力TFC_PADDING_)]、[N(NON_FIRST_FRAGMENTS_ALSO)]、SA、Ni、[KEi]、TSi、TSr
response <-- [N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Nr, [KEr], TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)]
応答<--[N(IPCOMP_SUPPORTED)]、[N(USE_TRANSPORT_MODE)]、[N(__SUPPORTEDではなく、超能力TFC_PADDING_)]、[N(NON_FIRST_FRAGMENTS_ALSO)]、SA、Nr、[KEr]、TSi、TSr[N(可能な追加_t_)]
A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA
A.5。 _Rekeying IKE_SAへの子供_SA交換を引き起こしてください。
request --> SA, Ni, [KEi]
要求-->SA、Ni[KEi]
response <-- SA, Nr, [KEr]
応答<--SA、Nr[KEr]
A.6. INFORMATIONAL Exchange
A.6。 情報の交換
request --> [N+],
[D+],
[CP(CFG_REQUEST)]
要求-->[N+]、[D+][CP(CFG_要求)]
response <-- [N+],
[D+],
[CP(CFG_REPLY)]
応答<--[N+]、[D+][CP(CFG_回答)]
Eronen & Hoffman Informational [Page 56] RFC 4718 IKEv2 Clarifications October 2006
[56ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
Authors' Addresses
作者のアドレス
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
パシEronenノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド
EMail: pasi.eronen@nokia.com
メール: pasi.eronen@nokia.com
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポールホフマンVPN共同体127セグレ・Placeカリフォルニア95060サンタクルス(米国)
EMail: paul.hoffman@vpnc.org
メール: paul.hoffman@vpnc.org
Eronen & Hoffman Informational [Page 57] RFC 4718 IKEv2 Clarifications October 2006
[57ページ]RFC4718IKEv2明確化2006年10月の情報のEronenとホフマン
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)によって提供されます。
Eronen & Hoffman Informational [Page 58]
Eronenであって、ホフマンInformationalです。[58ページ]
一覧
スポンサーリンク
