Network Working Group P. Eronen
Request for Comments: 4718 Nokia
Category: Informational P. Hoffman
VPN Consortium
October 2006
IKEv2 Clarifications and Implementation Guidelines
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).
著作権（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の仕様の多くの分野を明確にしています。これは、プロトコルへの変更を導入しないのではなく、あいまいな解釈が少ない傾向にある説明を提供します。このドキュメントの目的は、相互運用可能な実装の開発を奨励することです。
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
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
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ベースのリモートアクセスを含む、いくつかの異なる目的のために使用することができ、（時には「道路戦士」ケースと呼ばれる）、サイトツーサイトの仮想プライベートネットワーク（VPN）、およびアプリケーショントラフィックのホスト間の保護。このドキュメントはこれらの用途の全てを考慮しようとしますが、リモートアクセスのシナリオは、おそらくここで他の用途よりも多くの注目を集めています。
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].
この文書は、誰にどの要件を配置しないと、元のIKEv2文書からの引用を除いて、そのような「MUST」と「SHOULD」として[RFC2119]のキーワードを使用していません。要件は、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>.
この文書では、（例えば、「セクション2.15」など）の番号のセクションへの言及は、セクション[のIKEv2]であることを意味します。メーリングリストのメッセージまたはスレッドへの参照はipsec@ietf.orgでのIPsec WGメーリングリストを参照してください。メーリングリストのアーカイブは、<http://www.ietf.org/mail-archive/web/ipsec/index.html>で見つけることができます。
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メッセージは、IKEヘッダに、開始剤の非ゼロでどちらもレスポンダのセキュリティパラメータインデックス（SPIを）、が挙げられます。しかし、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節は、レスポンダのSPIと言う（IKE_SA_INIT交換の最初のメッセージより）「...他のメッセージにゼロであるはずがありません」。しかしながら、セクション2.6の図3.1のテキストを矛盾、 "HDR（A、0）、N（COOKIE）" として第2のIKE_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は、応答者が保有するセキュリティ関連の状態を識別し、この場合には何の状態が作成されないので、ゼロ値を送信することは合理的であると思われます。
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?
IKE_SA_INIT交換がIKE_SA（例えば、INVALID_KE_PAYLOADまたはNO_PROPOSAL_CHOSEN）の作成にはならないときに、第2、クッキーに加えて、他のいくつかの例があります。どのような応答者のSPI値は、この場合、IKE_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.
IKE_SA_INIT要求は常にゼロレスポンダSPIを有するので、値が実際にイニシエータによって使用されません。したがって、我々はゼロ値を送信すると、この場合にも正しいと思います。
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を送信した場合、イニシエータはその理由のための応答を拒否してはなりません。セクション3.1で説明されているようしかし、再試行IKE_SA_INIT要求は、イニシエータが、ゼロレスポンダSPIを使用する場合：「レスポンダのSPI [...]この値は、（その反復を含むIKE初期取引の最初のメッセージでゼロでなければなりませんクッキーを含むメッセージ）[...]」。私たちは、意図が原因のようなだけでなくINVALID_KE_PAYLOAD、などの他の理由にそのメッセージの繰り返しをカバーするためだったと信じています。
(References: "INVALID_KE_PAYLOAD and clarifications document" thread, Sep-Oct 2005.)
（参考文献：「INVALID_KE_PAYLOADと説明文書」のスレッド、9月 - 10月、2005年）
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.
IKE_SA_INITメッセージのメッセージIDは常にゼロです。これは、そのようなCOOKIEやINVALID_KE_PAYLOADとして回答へのメッセージの再試行を含んでいます。
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.
メッセージIDは、IKE_SAの状態の一部であり、レスポンダは、N（COOKIE）またはN（INVALID_KE_PAYLOAD）で要求をIKE_SA_INITする返信するとき、応答者がどのような状態を割り当てないためです。
(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_PAYLOAD）の組み合わせ" のスレッド、10月2004 TERO Kivinenのメール "ドラフト-eronen-のipsec-のIKEv2-明確化-02.txtのコメント"、2005-04-05。）
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).
レスポンダは、IKE_SA_INIT要求を受信すると、パケットが既存の「半開」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 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).
仕様では、この決定がどのように行われるかを詳細に説明していません。特に、この目的のために、イニシエータのSPIおよび/またはIPアドレスを使用するには十分ではない：単一のNATの背後にある二つの異なるピアが同じイニシエータSPIを選択することができます（とのIKEv2にはないので、この出来事の確率は、必ずしも小さくはありませんランダムに選択されるのSPI）が必要です。代わりに、応答者は、パケット全体またはそのハッシュ（または最低でも、常にランダムに選択された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).
IKE_SA_INIT要求以外の他のすべてのパケットのために、ルックアップ右IKE_SAはもちろん、受信者のSPIに基づいて行われる（どちらかIKEヘッダ内のイニシエータビットの値に応じて、イニシエータまたはレスポンダSPI）。
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.
イニシエータは、IKE_SA_INIT交換を再試行する必要があり、なぜ2つの共通の理由があります：レスポンダはクッキーを要求したり慶ペイロードに含まれていたよりも異なるのDiffie-Hellmanグループを望んでいます。これらの例はどちらも一人で非常に簡単ですが、彼らはつまり、IKE_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:
それは同様IKE_SA_INIT要求の唯一の次の再試行中に、またはそれ以降のすべての再試行にクッキーを含める必要があり、イニシエータは、レスポンダからクッキーを受信した場合：メインの質問は、次のしているようですか？セクション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通知が初期応答に含まれていた場合は、この通知は、IKE_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."
「そのような応答を受信開始剤は第一ペイロードと変わらず、他の全てのペイロードとしてレスポンダ供給されるクッキーデータを含む型クッキーの通知ペイロードを持つIKE_SA_INITを再試行しなければなりません」。
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.
「他のすべてのペイロード変わらない」制限は、後続の再試行にのみ最初の再試行に適用されますが、ない場合にのみ、以降の再試行で同じCookieを含めることは理にかなっています。
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:
両方の解釈が平和的に共存できるようです。イニシエータは、次の再試行でのみクッキーが含まれている場合、一つの追加の往復は、いくつかのケースで必要になることがあります。
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
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
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
This document recommends that implementations should support this shorter exchange, but it must not be assumed the other peer also supports the shorter exchange.
この文書では、実装は、この短い交換をサポートする必要があることを推奨していますが、他のピアも短い交換をサポート想定してはいけません。
In theory, even this exchange has one unnecessary roundtrip, as both the cookie and Diffie-Hellman group could be checked at the same time:
クッキーおよびDiffie-Hellmanグループの両方を同時に確認することができよう理論的には、これでも交換は、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
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節のテキストによって許可されていないことは明らかです。
(References: "INVALID_KE_PAYLOAD and clarifications document" thread, Sep-Oct 2005.)
（参考文献：「INVALID_KE_PAYLOADと説明文書」のスレッド、9月 - 10月、2005年）
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).
無効なクッキーを含むIKE_SA_INIT要求は、（その内容は、応答者によって期待値と一致しないという意味で「無効」）受信したときにどうすべきか、いくつかの混乱がありました。
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月）
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_pi、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)
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)
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デジタル署名は、「PKCS＃1パディングされたハッシュを超えるRSA秘密鍵を使用して、セクション2.15で指定されたとして計算。」されると述べています
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]実装が必要かをサポートするために推奨されているアルゴリズム何を言っていません。署名者は、検証党の方針に従った検証当事者によってサポートされていない、または許容されていないアルゴリズムを選択した場合、認証は失敗しますので、これは明らかに、相互運用性の問題を起こす可能性があります。
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.
もう一つの合理的な選択は、ピア証明書に署名する際にCAによって使用されたハッシュ関数を用いることであろう。しかしながら、これは、同じコードが証明書の署名とのIKEv2メッセージの署名を検証するために使用されない可能性があるためのIKEv2ピアは、AUTHペイロードを検証することができるであろうし、これら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＃1 V1.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.)
（参考文献：マグナスアルストレームのメール "RE："、2005-01-03パシEronenの返答、2005-01-04 TERO Kivinenの返答、2005-01-04スレッド "IKEv2.1の最初のドラフト"、2005年12月/。。。月2006）
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デジタル署名があることを述べている「PKCS＃1パディングされたハッシュを超えるRSA秘密鍵を使用して、セクション2.15で指定されたとして計算。」
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＃1 v2.0の[PKCS1v20]への参照を持っていました。そのバージョンは、署名のための唯一の1つの符号化法（EMSA-PKCS1-v1_5の）を有し、したがって、曖昧さはありません。
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のような）他の符号化方法をサポートする場合、それらは新しい認証メソッドの番号が与えられます。
(References: Pasi Eronen's mail "RE:", 2005-01-04.)
（参考文献：パシEronenのメール "RE："。2005年1月4日）
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]で定義されたネットワークアクセス識別子（のNAI）で使用されています。 NAIは、ビットの電子メールアドレスのように見えますが（例えば、「joe@example.com」）、構文は正確に[RFC822]にメールアドレスの構文と同じではありません。これは、識別タイプが使用されるべきという問題を提起します。
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識別タイプは、領域成分を含むこれらのNAIのために使用されることをお勧めします。したがって、レスポンダの実装は、コンテンツが実際に[RFC822]または[RFC2822]、代わりに任意の合理的な探しNAIを受け入れるべきで与えられた正確な構文に準拠していることを確認しようとはなりません。
For NAIs that do not include the realm component, this document recommends using the ID_KEY_ID identification type.
レルム成分を含まないのNAIのために、この文書はID_KEY_ID識別タイプを使用することをお勧めします。
(References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2 identifier issue with EAP" threads, Aug 2004.)
（参考文献：スレッド「EAPとIKEv2の識別子問題」、2004年8月「このIKEv2の/ I18N / 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]、セクション5.1および7.3を参照）EAPメソッドによって認証されたIDと異なっていてもよいです。
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.
ポリシーの検索とアクセス制御の決定は、実際の認証されたIDを使用することが重要です。多くの場合、EAPサーバが使用してレスポンダのIKEv2と通信別AAAサーバに実装され、例えば、RADIUS [RADEAP]。この場合、認証されたアイデンティティは、IKEv2のレスポンダにAAAサーバから送信する必要があります。
(References: Pasi Eronen's mail "RE: Reauthentication in IKEv2", 2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748, Section 7.3.)
（参考文献：パシEronenのメール。 "RE：IKEv2の中に再認証"、2004年10月28日 "ポリシーの検索" スレッド、10月/ 11月2004 RFC 3748、セクション7.3。）
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
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」/「すべきである」要件でのみ、これらの値を使用することをお勧めします。すなわち、 "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節には、証明書要求ペイロードのための「証明書エンコーディング」フィールドには、証明書ペイロードと同じ値を使用することを言います。しかし、「証明機関」フィールドの内容は、（おそらく、種類4、10、少なくとも12、および13を覆う）のみX.509証明書のために定義されています。この文書は、その使用を指定する新しい仕様が利用可能になる前に他の値を使用すべきではないことをお勧めします。
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キー」タイプは、一つの追加の明確化が必要です。セクション3.6は、「PKCS＃1エンコードされたRSAキー」を含んでいると言います。これが意味する[PKCS1v21] PKCS＃1からDERエンコードのRSAPublicKey構造です。
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.
セクション2.15は、「交渉されたprfが固定サイズキーを取る場合、共有秘密は、その固定サイズのものでなければならない」と述べています。この文は正しいです：共有シークレットは、正しいサイズのものでなければなりません。そうでない場合は、それを使用することはできません。その正確なサイズに強制的に関与しないパディング、切り捨て、または他の処理が存在しません。
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].
この要件は、共有鍵認証でこれらの擬似ランダム関数（のPRF）を使用することは困難であることを意味します。著者は、仕様書のこの部分は非常に悪い考え抜かれ、固定キーサイズでのPRFを使用すると、相互運用性の問題が発生する可能性がありましたね。したがって、我々は、そのようなのPRFは共有鍵認証で使用すべきではないことをお勧めします。 PRF_AES128_XCBC [RFC3664]は、もともと固定キーサイズを使用します。そのRFCは、[RFC4434]で変数のキーサイズを処理するように更新されました。
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は、固定鍵サイズとのPRFに関連するテキストが含まれているセクションに注意してください。「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.)
（参考文献：ポール・ホフマンのメール「日時：ikev2-07：最後のシラミ」、2003-05-02ヒューゴKrawczykの応答、2003年5月12日、月2005スレッド「固定サイズのキーとの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.
前のセクションで説明したように、固定されたキーサイズを有するのPRFは、正確にサイズの共有秘密を必要とします。この制限は、EAP認証にも適用されます。 [EAP] MSKは、少なくとも512ビット長であることを指定するので、例えば、128ビットの鍵を必要とするPRFはEAPで使用することができません。
(References: Thread "Question about PRFs with fixed size key", Jan 2005.)
（参考資料：スレッド「固定サイズのキーとのPRFについての質問」、月2005）
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ペイロードには何も一致している必要はありません」と言います。
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番されます」 IKE_AUTH交換は、EAPを使用しないときには真です。 EAPを使用する場合は、メッセージの各ペアは、彼らのメッセージ番号がインクリメントしています。 AUTHメッセージの最初のペアは2番目は2になり、1のIDを有し、あろう。
(References: "Question about MsgID in AUTH exchange" thread, April 2005.)
（参考資料：スレッド「AUTH交換でのMsgIDについてのご質問」、2005年4月）
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交換の各使用するためのサブセクションで再編成することができる（IKE SAを再入力、子SAを作成し、リキー子のSA。）
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
NEW-1.3 CREATE_CHILD_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.
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交換の最初の二つのメッセージで交渉暗号化アルゴリズムとキーを使用して保護されています。これらの後続のメッセージは、セクション3.14で説明した暗号化されたペイロードの構文を使用します。後続のすべてのメッセージは、それらが「空」などのテキストで言及されている場合でも、暗号化されたペイロードが含まれます。
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は、キーの再発行のIKE_SAsとのCHILD_SAsのために使用されています。このセクションでは、鍵の変更、新しいSAの創造の最初の部分を説明します。 2.8節では、古いから新しいSAと古いSAの削除にトラフィックを移動するなど、鍵の再生成の仕組みを、カバーしています。 2つのセクションでは、鍵の再生成のプロセス全体を理解するために一緒に読まれなければなりません。
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内のすべてのCREATE_CHILD_SA要求を拒否することができます。
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.
CREATE_CHILD_SA要求は、必要に応じてCHILD_SAまたはIKE_SAのための順方向秘密の強力な保証を可能にするための追加のDiffie-Hellman交換のためのKEペイロードを含むかもしれません。 SAのためのキーイング材料は、IKE_SAの確立の間に確立SK_dの関数である（KEペイロードがCREATE_CHILD_SA交換に含まれている場合）、ナンスは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交換は慶ペイロードが含まれている場合は、SAの提供の少なくとも一方がkeiののDiffie-Hellmanグループを含まなければなりません。たKEiののDiffie-Hellmanグループは、イニシエータがレスポンダが受け入れることを期待グループの要素でなければならない（追加のDiffie-Hellmanグループを提案することができます）。レスポンダが慶ペイロードのDiffie-Hellmanグループを拒否した場合、応答は要求を拒否しINVALID_KE_PAYLOAD通知ペイロードにその好ましいのDiffie-Hellmanグループを指定する必要があります。そのような拒絶反応の場合には、CREATE_CHILD_SA交換は失敗し、イニシエータがレスポンダがINVALID_KE_PAYLOADに与えたグループでのDiffie-Hellman提案やたKEiとの交換を再試行すべきです。
NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
CREATE_CHILD_SA Exchangeとの新しいのCHILD_SAsを作成するNEW-1.3.1
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:
Initiator Responder
----------- -----------
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のペイロードにノンス啓ペイロードにおける随意のDiffie-Hellman値、とをTSiおよびTSrをペイロードに提案されたCHILD_SAのために提案されたトラフィックセレクタにSAオファー（単数または複数）を送信します。リクエストはCHILD_SAのための追加の詳細を指定するペイロードを通知も含めることができます。これらはIPCOMP_SUPPORTED、USE_TRANSPORT_MODE、ESP_TFC_PADDING_NOT_SUPPORTED、およびNON_FIRST_FRAGMENTS_ALSOが含まれます。
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}
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.
たKEiが要求に含まれた、選択された暗号スイートは、その基を含む場合、レスポンダは、SAペイロードに受け入れオファーで応答し、そしてKERペイロード内のDiffie-Hellman値。リクエストと同様に、オプションの通知ペイロードは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上で送信されるトラフィックのためのトラフィックセレクタは、CHILD_SAのイニシエータが提案されているもののサブセットであり得る応答してTSペイロードで指定されています。
The text about rekeying SAs can be found in Section 5.1 of this document.
SAを再入力についてのテキストは、このドキュメントのセクション5.1に記載されています。
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.
CHILD_SAsをIKE_AUTH交換にピギーバック、または別個のCREATE_CHILD_SA交換を使用することによってのいずれかで作成することができます。仕様は、IKE_AUTH交換中CHILD_SAを作成すると、何らかの理由で失敗した場合に何が起こるかについては明らかではありません。
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.
NO_PROPOSAL_CHOSEN、TS_UNACCEPTABLE、SINGLE_PAIR_REQUIRED、INTERNAL_ADDRESS_FAILURE、およびFAILED_CP_REQUIRED：設定されているからIKE_SAを防ぐことはできませんIKE_AUTH交換における応答のリストには、少なくとも以下のものを含みます。
(References: "Questions about internal address" thread, April 2005.)
（参考資料：スレッド「内部アドレスについての質問」、2005年4月）
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は、IKE_AUTHメッセージ圭/ KER又はNi / Nrのペイロードを含んでいないことを示しています。これは、IKE_AUTH交換におけるSAペイロードがNONE以外の値とタイプ4（ディフィー - ヘルマングループ）を形質転換含むことができないことを意味します。実装は、おそらくこのような場合には完全にアウト変換ままにしておきます。
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 1 ESNを含む提案は、「拡張されたシーケンス番号を使用していない」という意味値0に変換します。
o A proposal containing one ESN transform with value 1 means "use extended sequence numbers".
1 ESNを含む提案が値1で変換oをする「の拡張シーケンス番号を使用する」を意味します。
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 2 ESNを含む提案は、値が0に変換し、1は「私は、あなたが選択した両方の正常および拡張シーケンス番号をサポートする」という意味します。 （もちろん、この場合は、要求だけに許され、応答が唯一のESN変換を含みます。）
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ペイロードの最初の又は第3の選択肢のいずれかを含むことになります。第二の代替は、イニシエータのためまれに有用である：それは通常のシーケンス番号を使用することは許されない（ので、レスポンダはのESNをサポートしていない場合、交換はNO_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).
（それはIKEv2の仕様の以前のドラフトではオプションだった）ESP / AH SAを作成するときにESN変換を含むことは必須であることに注意してください。
(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交渉相互運用の問題に対処する」と「に関するわらの世論調査の結果：IKEv2の相互運用性の問題」スレッド、3月〜2005年4月）
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".
3.10.1項でESP_TFC_PADDING_NOT_SUPPORTED通知の説明は「この通知が送信エンドポイントは、機密性（TFC）パディングを含むパケットフローを受け付けないことを主張する」と述べています。
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 in only one of the messages, TFC padding can still be sent in one direction.
私たちの解釈は、スコープは、単一のCHILD_SAであり、したがって、この通知はCHILD_SAを交渉SAペイロードを含むメッセージに含まれていることです。どちらのエンドポイントがTFCパディングを受け入れる場合、この通知はSAを提案し、要求し、それを受け入れる応答の両方に含まれます。この通知は、一つだけのメッセージの中に含まれている場合は、TFCパディングは、まだ一方向に送信することができます。
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通知は、「断片化制御のために使用します。説明については、[RFC4301]を参照してください。」単に3.10.1項で説明されています
[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."
[RFC4301]は非自明なポート（またはICMPタイプ/コード又はMHタイプ）を利用するトンネルモードSA上の非初期フラグメントを送信する「実装セレクタNON_FIRST_FRAGMENTS_ALSOペイロードをNOTIFY IKEを介してピアに通知しなければならないと言う。ピアツーピアそれは、この文脈で非初期フラグメントを受け入れない場合は、この提案を拒絶しなければなりません。実装は成功し、そのような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の作成を拒否しません。
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の個々のセレクタのうちの少なくとも一つ、及びTSRの個々のセレクタのうち少なくとも一つと一致する場合、パケットは、所与を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))
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).
ソース/宛先ポートの4つの組み合わせ（100,300）、（100,400）、（200,300）のいずれかと、どこに192.0.1.66からUDPパケットを一致、及び（200、400）であろう。
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のペアを必要とするかもしれないことを示唆しています。例えば、唯一のソース/宛先ポート（100,300）および（200,400）はなく、他の二つの組み合わせに一致するポリシーは、のIKEv2を使用して単一のCHILD_SAペアとしてネゴシエートすることはできません。
(References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)
（参考文献：「？のIKEv2トラフィックセレクタ」スレッド、2月2005）
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オクテットフィールドは、タイプおよびコードは（最下位8ビットでコードの最上位8ビットおよびタイプの）1つの16ビット整数として扱われこのフィールドに基づいたフィルタリングの目的のポート番号。」
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:
192.0.1.234のホストは、192.0.2.155に「宛先到達不能」パケット（ICMPv4のタイプ3）を送信するためのトランスポートモードSAを作成したいと考えていますが、この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(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) }
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 SAを作成するので、2つのSAは、第二SAは、データトラフィックのために使用されることはありませんにもかかわらず、このような場合に作成されます。
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のペアを作成する交換は、すべてのポートで同じ値を配置します。
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(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) }
(References: "ICMP and MH TSs for IKEv2" thread, Sep 2005.)
（参考文献：「IKEv2のためのICMPとMHのTS」のスレッド、2005年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プロトコルID 135を使用することができます。しかし、IKEv2の仕様では、トラフィックセレクタに「MH Type」フィールドを表現する方法を定義していません。
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.
いくつかの点で、これは、後に別の文書で定義されるであろうことが予想されました。しかしながら、[RFC4301]はポート「セレクタ 『』 IKEについて、IPv6のモビリティヘッダのメッセージタイプ（MHタイプ）は、16ビットのローカルの最上位8ビットに配置される」と述べています。 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日「ICMPとMHのTS IKEv2のための」スレッド、2005年9月）
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.
応答者の方針はをTSi / TSrをによってカバーされたトラフィックの一部を許可していない場合は、O、それは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.
応答者の方針はをTSi / TSrをによってカバーされたトラフィックのセット全体を許可している場合、O、何の狭小化は必要ありませんし、応答者は同じを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によってカバーされるすべてのトラフィックを許可する場合、[1] / TSrを[1]ではなく全体をTSi / TSrを（TSI / TSRの最初のトラフィックセレクタ）は、レスポンダはをTSiを[含まをTSi /のTSRに許容可能なサブセットに狭め1] / TSrを[1]。
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.
応答者の方針はをTSiによってカバーされるすべてのトラフィックは、[1] / TSRが[1]、しかしをTSi /のTSR一部を許可しない許可しない場合は、O、それはを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つの場合に、（それらの組合ではない）許容されるいくつかのサブセットが存在してもよいです。この場合、応答者は任意にそれらのいずれかを選択し、それに応答してADDITIONAL_TS_POSSIBLE通知を含みます。
The description of the SINGLE_PAIR_REQUIRED notify payload in Sections 2.9 and 3.10.1 is not fully consistent.
SINGLE_PAIR_REQUIREDの説明は、セクション2.9でペイロードを通知し、3.10.1は完全に一致しません。
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.
私たちは、ほとんどの実装は、各アドレスのペアのために別々のSAを必要とするポリシーを持っていないことが期待されているので、どちらかこの文書では、このペイロードを記述しようとしないでください。
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のみ一部（又は部品）レスポンダに許容される（されている）されている場合したがって、ほとんどの応答は、単に狭いをTSi / TSRは許容されるサブセットにすべきである（セクションの最後の2つの段落に記載したように2.9）ではなく、SINGLE_PAIR_REQUIREDを使用しています。
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節は非常に詳細にトラフィックセレクタ交渉を説明しています。いくつかの明確化が必要な場合があり、この交渉の一の態様は、新しい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がホストBを介してその効果192.0.1.66にトラフィックが送信されることであるポリシーを持っている高度暗号化標準（AES）を使用して暗号化され、および192.0.1.0/24内の他のすべてのホストへのトラフィックはまた、Bを介して送信されるが、暗号化されていると仮定トリプルデータ暗号化標準（3DES）を使用。そのホスト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.
ホストAは現在3DESを使用してSAを提案し、TSRが含有（192.0.1.0-192.0.1.0.255）を含む場合、これは今、ホストBによって受理されると、ホストBはまた、192.0からのトラフィックを送信するために、このSAを使用することができます。それは、これらのトラフィックのためにAESを使用する必要があるため1.66が、これらのパケットはAによって破棄されます。ホストAが唯一のAESを使用しています192.0.1.66のための新しいSAを作成した場合でも、ホストBは自由にトラフィックのための最初のSAを使用し続けることができます。 SAを提案したときに、このような状況では、ホストAは自身の政策を踏襲し、代わりに（（192.0.1.0-192.0.1.65）、（192.0.1.67-192.0.1.255））を含むTSrをが含まれている必要があります。
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のために、SAと「Xの、イニシエータは、実際の交通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.)
（参考文献：「質問について 『狭く』 ...」スレッド、2月2005ポリシー使用モード「のIKEv2が必要 『』 ...」スレッド、2月2005「？のIKEv2トラフィックセレクタ」スレッド、2月2005「のIKEv2トラフィックセレクタ交渉の例」、2004年8月8日。）
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 SAの種類を決定する際のIKEv2ピア認証データベース（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.
認証されたアイデンティティ「sgw23.example.comが」このセキュリティゲートウェイは、これらのアドレスの有効な「代表」である意味、192.0.2.0/24のためのIPsec SAを作成するために許可されているように、例えば、PADが設定されている可能性があります。ホスト間のIPsecは、リンク、類似したエントリーが必要ですが、例えば、「fooserver4.example.com」192.0.1.66/32で、このアイデンティティの有効な「所有者」または問題のアドレスの「代表」を意味。
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をスプーフィングから認証されたピアを防止するために、子SAの作成時にこれらの制約を課すことが必要です。」上記の例では、パッドの正確な構成は、アドレス192.0.1.66とのIPsec SAを作成からsgw23を防止し、192.0.2.0/24のアドレスとのIPsec SAを作成からfooserver4を防止します。
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 SAを作成する権限を意味するものではないことに注意することは重要です。例えば、sgw23は192.0.1.66としてそのIPアドレスを詐称することができるだろうとしても、それはfooserver4のトラフィックに一致するIPSec SAを作成できませんでした。
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 using configuration payloads, it also creates a temporary PAD entry linking the authenticated peer identity and the newly allocated inner address.
IKEv2の仕様は、コンフィギュレーション・ペイロードを使用してIPアドレスの割り当ては、PADとどのように相互作用するかを正確に指定されていません。私たちの解釈は、セキュリティゲートウェイは、構成ペイロードを使用してアドレスを割り当てたときに、それはまた、認証されたピアのIDと新たに割り当てられた内部アドレスを結ぶ一時的なパッドのエントリを作成することです。
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はアドレスDHCP（Dynamic Host Configuration Protocol）を使用して動的に割り当てられている一対のホスト間で使用されている場合たとえば、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 SAを作成できるように自分のパッドを設定することが知られています。 IPスプーフィング（すなわち、ほぼどこにでも）ことが可能である環境では、これは本質的に任意のトラフィックセレクタとのIPsec SAを作成するために、任意のピアを可能にします。これは、ほとんどの状況で適切なまたは安全な構成ではありません。この問題について広範な議論、および一般的なホスト間のIPsecの制限について[Aura05]を参照してください。
Continued from Section 4.1 of this document.
このドキュメントのセクション4.1から続きます。
NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
CREATE_CHILD_SA交換とNEW-1.3.2キーの再発行のIKE_SAs
The CREATE_CHILD_SA request for rekeying an IKE_SA is:
IKE_SAを再入力するためのCREATE_CHILD_SA要求は次のようになります。
Initiator Responder
----------- -----------
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ペイロードにおけるSAオファー（単数または複数）、慶ペイロードのNiペイロードにナンス、および任意のDiffie-Hellman値を送信します。
The CREATE_CHILD_SA response for rekeying an IKE_SA is:
IKE_SAを再入力するためのCREATE_CHILD_SA応答は次のとおりです。
<-- HDR, SK {SA, Nr, [KEr]}
< - HDR、SK {SA、番号[KBr法]}
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ペイロードで必要に応じて、ディフィー・ヘルマン値で（対応する同じメッセージ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に設定され、そのメッセージカウンタを持っています。ウィンドウサイズは、新しいIKE_SAのために1から始まります。新しいイニシエータとレスポンダのSPIは、SAペイロードのSPIフィールドに供給されています。
NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
CREATE_CHILD_SA交換とNEW-1.3.3キーの再発行のCHILD_SAs
The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
CHILD_SAを再入力するためのCREATE_CHILD_SA要求は次のようになります。
Initiator Responder
----------- -----------
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のペイロードにノンス啓ペイロードにおける随意のDiffie-Hellman値、とをTSiおよびTSrをペイロードに提案されたトラフィックセレクタにSAオファー（単数または複数）を送信します。要求は、CHILD_SAのための追加の詳細を指定するペイロードを通知含めることができます。
The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
CHILD_SAを再入力するためのCREATE_CHILD_SA応答は次のとおりです。
<-- 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.
たKEiが要求に含まれた、選択された暗号スイートは、その基を含む場合、レスポンダは、SAペイロードに受け入れオファーで応答し、そしてKERペイロード内のDiffie-Hellman値。
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上で送信されるトラフィックのためのトラフィックセレクタは、CHILD_SAのイニシエータが提案されているもののサブセットであり得る応答してTSペイロードで指定されています。
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と再認証がIKEv2の中に異なる概念です。再キーイングIKE_SAはIKE_SAのための新しいキーを確立し、メッセージIDカウンタをリセットしますが、それは（ないAUTHまたはEAPペイロードが関与していない）、再びパーティーを認証しません。
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のは、再認証のための特別なサポートがありません。再認証が（ペイロードを通知REKEY_SAせず）新しいIKE_SA内新しいのCHILD_SAsを作成し、最後に古いのCHILD_SAsを削除古いIKE_SAを（削除、（ペイロードを通知する任意REKEY_SAことなく、IKE_SA_INIT / IKE_AUTH交換を使用して）最初から新しいIKE_SAを作成することによって行われます同じように）。
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で」スレッド、10月/ 11月、2004年）
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.
セクション2.18「新規イニシエータとレスポンダのSPIは、SPIフィールドに供給されている」と述べています。これは、セキュリティアソシエーション（SA）ペイロード内の提案構造ではなく、IKEヘッダ内のSPIフィールドにSPIフィールドを指します。
(References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24. Geoffrey Huang's reply, 2005-01-24.)
（参考文献：トムStiemerlingのメール「リキーIKE SA」、2005年1月24日ジェフリー・黄の応答、2005年1月24日。。）
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が常に対になって存在しているので、二つの異なるSPIがあります。 REKEY_SA通知に配置されたSPIは、SPI交換イニシエータは、（単に削除ペイロードのように）インバウンドESPまたはAHパケットに期待です。
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を再入力すると、セクション2.18はSKEYSEEDは、新しいIKE_SAのために、次のように既存のIKE_SAからSK_dを使用して計算された」と述べています：
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"
SKEYSEED = PRF（SK_d（旧）、[G ^ IR（新しい）] |ニッケル| 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_d）は、複数の暗号アルゴリズムを使用してはならないという原則に従います。
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.
PRFの出力は、正しいサイズのものではないかもしれないので、新しいIKE_SAのPRFは、固定キーのサイズを持っている場合、これは十分に機能しないことがあります。これは、固定キーサイズのPRFの使用は悪い考えであることを以前の文書の我々の意見をサポートしています。
(References: "Changing PRFs when rekeying the IKE_SA" thread, June 2005.)
（参考資料：スレッド「IKE_SAを再入力するときのPRFの変更」を、2005年6月）
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.
「クローズ」とSAを「削除」、正確に何を意味するかは必ずしも明確ではない程度のIKEv2仕様会談。しかし、明細書の他の部分は、それが明確CHILD_SAに関連するローカル状態が除去されると、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."
具体的には、2.4節には、「IKE終点はのCHILD_SAsを削除することを選択した場合、それは削除のそれを通知するもう一方の端に削除ペイロードを送らなければなりません」と述べています。セクション1.4は、「ESPとAH SAが常に各方向に1 SAと、ペアで存在する。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は、情報の交換を使用してSAのペアを削除する方法について説明します：「SAを削除するには、一つ以上の削除ペイロードを持つINFORMATIONAL交換は、SAのSPIの（彼らはインバウンドパケットのヘッダに予想されるように）への上場送られ、受信者が指定されたSAを閉じる必要があります。削除されます。」
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の両側のためのペイロードを削除送ることはありません。あなたは、同時に削除するには多くのSAを持っている場合（たとえば、その段落に与えられた、ネストされた例のように）、あなたはあなたの情報交換で、各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.
（リクエストを受信したことを除いて）相手側に送信する必要が情報がないので、空の情報応答が最も論理的な選択のように思えます。
(References: "Question about delete IKE SA" thread, May 2005.)
（参考文献：「質問についてのIKE SA削除」のスレッドを、2005年5月）
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日。）
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."
鍵の変更について2.8節では、「冗長SAが、このような衝突かかわらず作成された場合、2つの取引所で使用される4つのナンスの最低で作成したSAは、それを作成したエンドポイントによって閉鎖されるべきである。」と述べています
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ナンスの最後に到達した場合、そのnonceが低く一つです。
(References: "IKEv2 rekeying question" thread, July 2005.)
（参考文献：「IKEv2のキーの再発行質問」スレッド、2005年7月）
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」スレッド、12月2005糸、2005年12月/月、2006年「交流の衝突を通報します」）
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
This case is described in Section 1.4 and is handled by omitting the Delete payloads from the response messages.
この場合は、セクション1.4に記載されており、応答メッセージから削除ペイロードを省略することによって処理されます。
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
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は、（空の通知応答を有する）通常通り応答IKE_SAを閉じ、およびREQ2を再送信を停止すべきです。ホストAはresp1を受信すると、もはや返信することができないかもしれないからです。ホストAは、同じように動作する必要がありますので状況は、対称です。
Host A Host B
-------- --------
<-- send resp1: ()
send 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を受信しなかった場合も同じことが起こります。
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).
両端が同じ寿命ポリシーを持っている場合」、それは両方とも（冗長SAをもたらすであろう）を同時にキー更新を開始することが可能である。この出来事の確率を低減するために、リキー要求のタイミングはジッターされるべきです（再入力の必要性が注目された後）ランダムな時間だけ遅れます。
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."
リキーのこの形態は、一時的にノードの同一の対の間の複数の同様のSAをもたらすことができます。 2つのSAがパケットを受信する資格がある場合、ノードは、SAのいずれかを介して着信パケットを受け入れなければなりません。冗長SAがそのような衝突も作成されている場合、2回の交換に使用される4つのナンスの最低で作成されたSAは、それを作成したエンドポイントによって閉じられるべきです「。
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は、のSPI（SPIa1、SPIb1）で既存のIPsec SAのペアを有し、両方が同時にそれを再入力開始ホストと仮定する。
Host A Host B
-------- --------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. -->
<-- send 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が起こっ同時再入力があると知っています。しかし、それはまだ最低nonceを持つことになります交換のかを知ることができないので、それだけの状況に注意し、いつものように応答します。
send resp2: SA(..,SPIa3,..),Nr1,.. --> --> recv req1
> - - >のrecv REQ1 SA（..、SPIa3、...）、NR1、..：RESP2を送信
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
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.
この時点で、AとB（古いものと新しいもの2）との間に3 CHILD_SAのペアがあります。 AとBは今ナンスを比較することができます。最低ノンスは、メッセージRESP2におけるNR1たと仮定する。この場合には、B（REQ2の送信者）は、冗長新しいSAを削除し、（生存を開始したノードは、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.
しかし、いくつかのパケットを再送信して、その結果、ネットワーク内で失われた場合に発生するイベントの第二の可能なシーケンスがあります。鍵の再生成は、いつものように始まるが、（REQ1）Aの最初のパケットが失われています。
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
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.
ビューの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はこの時点で何をすべき？ Aはもはや存在しないSAキーを再生成しようとしているようにBに、それが見えます。これNO_PROPOSAL_CHOSENなどの非致命的な何かが合理的なアプローチのように思えるで要求を失敗。
<-- send resp1: N(NO_PROPOSAL_CHOSEN) recv resp1 <--
< - resp1を送信：N（NO_PROPOSAL_CHOSEN）RECV resp1 < -
When A receives this error, it already knows there was simultaneous rekeying, so it can ignore the error message.
Aはこのエラーを受信した場合、それはすでに同時再入力があった知っているので、エラーメッセージを無視することができます。
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キーを再生成しようとすると、おそらく最も複雑なケースが発生します。基本的には、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と同じように動作します。 CREATE_CHILD_SA交換後三件のIKE_SAsはAとBとの間に存在します。最低nonceを含むものは、のCHILD_SAsを継承します。
However, there is a twist to the other case where one rekeying finishes first:
しかし、1つのキーの再発行が最初に終了し、他のケースにねじれがあります：
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
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を閉じるための要求を見ています。いつものように返信するよりも行うことがはるかにはありません。一度Aはresp3を受信するホストしかし、この時点で、ホストBで、REQ2を再送停止する必要があり、それは古いIKE_SAに関連するすべての状態を削除し、それに返信することはできません。
<-- send resp3: ()
< - resp3を送信します（）
A case similar to simultaneous rekeying can occur if one peer decides to close an SA and the other peer tries to rekey it:
一方のピアがSAを閉鎖することを決定し、他のピアがそれをリキーしようとした場合、同時リキーと同様ケースが発生する可能性があります。
Host A Host B
-------- --------
send req1: D(SPIa) -->
<-- send 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が到着したに応じて、ホストAは、それが現在閉じていることをSAキーを再生成するための要求、または存在しないSAキーを再生成するための要求のいずれかを見ています。どちらの場合も、NO_PROPOSAL_CHOSENはおそらく大丈夫です。
recv req2 recv resp1 send resp2: N(NO_PROPOSAL_CHOSEN) --> --> recv resp2
recv REQ2のrecv resp1送るRESP2：N（NO_PROPOSAL_CHOSEN） - > - >のrecv RESP2
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,..),..
<-- 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を認識しません。何をホストする必要がありますか？
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つのオプションは、空の情報応答を返信するだろう。ホストAはresp1を受信した場合は、この同じ返事も送信されますが、すでに作成されたばかりのSAを削除するための新しい要求を送信しました。これは、ピアがSAは、それらの間に存在するかについて同期されなくなった状況をもたらすことになります。しかし、ホストBは、最終的にはCHILD_SA組の残りの半分が削除されていないことに気づくでしょう。セクション1.4は、この場合について説明し、「ノードが異常と半分閉じた接続を考えると、彼らの存在は、彼らが持続すべき監査すべきである」と指摘し、「接続状態が十分に台無しになった場合、ノードは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の仕様の一部ではなく、データフィールドは、通知の受信者が送信パケットに置くSPIが含まれているINVALID_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.
さらに別の解決策は、この時点でREQ2を無視し、私たちはresp1を受信するまで待つことであろう。しかし、この代替は、完全にこの時点で分析されていません。両方のエンドポイントがデッドロックにつながる、それを行う可能性があるため、一般的には、有効な要求を無視することは、常に少し危険です。
This document recommends the first alternative.
この文書では、最初の選択肢を推奨しています。
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,..),..
<-- 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:
ホストするには、これは存在しないSAキーを再生成するための要求のように見えます。同時キーの再発行の場合のように、NO_PROPOSAL_CHOSENで返信することは、おそらく合理的です：
send resp2: N(NO_PROPOSAL_CHOSEN) --> recv resp1
> recvのresp1 - N（NO_PROPOSAL_CHOSEN）：RESP2を送信
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:
一方のピアは他のピアは、キー更新を作成する、またはCHILD_SAを閉じ始めると同時に、IKE_SAを再入力開始時にケースの別のセットが生じます。 ：ホストBはCHILD_SAの作成を開始し、すぐ後に、ホストAはIKE_SAを再入力を開始すると仮定
Host A Host B
-------- --------
<-- send req1: SA,Ni1,TSi,TSr
send 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は現在空情報応答で正常に応答した場合、これはホストAがIKE_SAに関連した状態を削除するようになります。これは、ホストBはREQ1を再送止めるべきであることを意味します。しかし、ホストBは、AがREQ1を受信したホストかどうかを知ることができません。ホストAがそれを受け取った場合は、それが移動します
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.
この状況が正しく処理するのが難しいようです。次のように私たちの提案は次のとおりです。ホストはそれは（現在作成またはリキーされている）、「ハーフオープン」状態でのCHILD_SAsを持っているときIKE_SAキーを再生成するための要求を受信した場合、それはNO_PROPOSAL_CHOSENで応答する必要があります。ホストはそれはIKE_SAを再入力を開始した後CHILD_SAを作成したり、キーの再生成するための要求を受信した場合、それはNO_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が閉じられている場合はさらに悪くなります。私たちの推薦はホストは、それが「半閉」の状態は、（現在は閉鎖されている）でのCHILD_SAsを持っているときIKE_SAキーを再生成するための要求を受信した場合、それはNO_PROPOSAL_CHOSENで応答すべきであるということです。ホストはそれはIKE_SAを再入力を開始した後CHILD_SAをクローズするための要求を受信した場合、それは空の情報応答で応答しなければなりません。これは、少なくとも他のピアは、最終的にCHILD_SAが「半閉」の状態のままであり、最初から新しい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.
他のピアがそれをリキーしようとし、一方のピアはIKE_SAを閉鎖することを決定した場合、このセクションで考え最後のケースが発生します。
Host A Host B
-------- --------
send req1: SA(..,SPIa1,..),Ni1 -->
<-- send 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は、おそらくNO_PROPOSAL_CHOSENで応答する必要があり、ホストAは、いつものように返信IKE_SAを閉じ、REQ1を再送停止する必要があります。
<-- send resp1: N(NO_PROPOSAL_CHOSEN) send resp2: ()
< - resp1を送信：N（NO_PROPOSAL_CHOSEN）RESP2を送信します（）
If host A wants to continue communication with B, it can now start a new IKE_SA.
ホストAは、Bとの通信を継続したい場合、それは今、新しいIKE_SAを開始することができます。
If a host receives a request to rekey:
ホストが要求を受信した場合リキーします：
o a CHILD_SA pair that the host is currently trying to close: reply with NO_PROPOSAL_CHOSEN.
Oホストは現在閉鎖しようとしているCHILD_SA組：NO_PROPOSAL_CHOSENとの返事。
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は、ホストが現在再入力されていることをペア：いつものように応答が、ナンスに基づいて後冗長SAを閉じるために準備します。
o a CHILD_SA pair that does not exist: reply with NO_PROPOSAL_CHOSEN.
存在しないCHILD_SA組○：NO_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.
いつものように応答が、冗長なSAを閉じ、以降のナンスに基づいて継承のCHILD_SAsを移動するための準備：O IKE_SA、ホストは現在IKE_SAが再入力されます。
o the IKE_SA, and the host is currently creating, rekeying, or closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.
IKE_SA、ホストは現在、キー更新を作成またはCHILD_SAを閉じてO：NO_PROPOSAL_CHOSENと返信。
o the IKE_SA, and the host is currently trying to close the IKE_SA: reply with NO_PROPOSAL_CHOSEN.
NO_PROPOSAL_CHOSENと回答：IKE_SA O、およびホストは現在、IKE_SAを閉じるしようとしています。
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.
返信を削除ペイロードなし：CHILD_SA組oをホストは現在閉鎖しようとしています。
o a CHILD_SA pair that the host is currently rekeying: reply as usual, with Delete payload.
Oホストが現在再入力されていることをCHILD_SAペアは：削除ペイロードと、いつものように返信。
o a CHILD_SA pair that does not exist: reply without Delete payloads.
削除ペイロードなしの返信：存在しないCHILD_SA組O。
o the IKE_SA, and the host is currently rekeying the IKE_SA: reply as usual, and forget about our own rekeying request.
IKE_SA O、およびホストは現在、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.
いつものように回答し、私たち自身のクローズ要求を忘れる：IKE_SA O、およびホストは現在、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.
ホストが作成またはそれが現在IKE_SAを再入力されたCHILD_SAキーを再生成するための要求を受信した場合：NO_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を削除する要求を受信した場合。
There has been some confusion whether doing a new Diffie-Hellman exchange is mandatory when the IKE_SA is rekeyed.
IKE_SAがリキーされたときに新しいDiffie-Hellman交換を行っているかどうかは必須であるいくつかの混乱がありました。
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は、括弧内のDiffie-Hellman用語（G ^ IR）を示しています。それが含むことを言うとき、セクション3.3.3には、この矛盾しません
the D-H transform is mandatory: although including the transform is mandatory, it can contain the value "NONE".
D-Hは変換必須である：変換を含むことは必須であるが、それは値「NONE」を含むことができます。
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を再入力するときのDiffie-Hellman交換をスキップするオプションを持つことは、プロトコルに便利な機能を追加しません。 IKE_SAを再入力の主な目的は、古い鍵素材の妥協が現在のキー、またはその逆の情報を提供しないことを確実にするためです。これは、再入力するとき、Diffie-Hellman交換を実行する必要です。さらに、不必要な複雑さは、それが先に議論されていたとして、このオプションはプロトコルから削除されていたであろうと思われます。
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を再入力するときに、新しいDiffie-Hellman交換を実行する必要がハードコーディングされたポリシーを持っていなければならないことをお勧めします。換言すれば、イニシエータは、D-Hは、「NONE」は変換しない値を提案してはならない、と応答者はそのような提案を受け入れるべきではありません。また、このポリシーは、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.)
（参考文献：スレッド、10月2005スレッド "ドラフト-eronen-のipsec-のIKEv2-明確化-02.txtのコメント"、2005年4月 "CREATE_CHILD_SAのexhangeとキーの再発行のIKE_SAs"）
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 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.
換言すれば、IKEv2のは、アドレスを割り当てるための2つの異なる機構を有しているが、一方のみない：設定ペイロード。セクション1.1.3で説明したシナリオでは、両方の構成およびトラフィックセレクタペイロードは、通常、同じメッセージに含まれ、それらは、しばしば、（いくつかの例については、この文書のセクション6.3を参照）は、応答メッセージに同じ情報が含まれています。しかし、その意味はまだ異なっています。
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」または長さゼロの文字列を意味するかどうかです。
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設定ペイロード内の属性がゼロ長でない場合、それはその属性の提案として取られる」と述べています。また、構成属性のテーブルは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属性ではなく、すべてゼロのアドレスを含む属性を含んでいます。それは「INTERNAL_ADDRESS（0.0.0.0）」などの属性を示しているので、2.19の例では、このように誤っています。
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」、および任意の他のアドレスを治療するための実装は、合理的な提案として認識されません。
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を説明し、この属性は、二つのフィールドで構成されています。最初は、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?
これは、二つの問題を提起：まず、この情報は通常のTSRペイロードに含まれているため、この属性は、どのような機能を追加しますか？そして第二に、この属性は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つの賢明な解釈があるように思われます。明らかに（IKE_AUTHまたはCREATE_CHILD_SA応答して）TSRは作成されたばかりのSAを通じてアクセス可能なサブネットを示しています。
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.
第二の解釈は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.
これは、これら二つの解釈に互換性はないことが判明したが、同じ原理のではなく両側：INTERNAL_IP4 / 6_SUBNET属性にリストされたアドレスへのトラフィックは、このゲートウェイを介して送信されなければなりません。そのトラフィックセレクタ問題のアドレスをカバーする既存のIPsec SAが存在しない場合は、新しいSAを作成する必要があります。
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つのサブネット、192.0.1.0/26と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)
Then a valid response could be the following (in which TSr and INTERNAL_IP4_SUBNET contain the same information):
そして、有効な応答は、（ここでTSrをして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)
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)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
=（0、0〜65535、192.0.1.234-192.0.1.234）TSrを=（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:
ゲートウェイは別のSAに実施される2つのサブネットのトラフィックを必要とするポリシーを有する場合、異なる状況が生じます。そして、このような応答は、第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)
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)
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)
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のために、ゼロの長さがすべてでは許可されていません！）。この文書では、実装がINTERNAL_IP4_SUBNETまたはINTERNAL_IP6_SUBNET CFG_REQUESTsの属性を含めるべきではないことをお勧めします。
For the IPv4 case, this document recommends using only netmasks consisting of some amount of "1" bits followed by "0" bits; for instance, "255.0.255.0" would not be a valid netmask for INTERNAL_IP4_SUBNET.
IPv4のケースのために、この文書は、「0」ビットに続く「1」のビットのある量からなるネットマスクを使用することをお勧めします。例えば、「255.0.255.0」INTERNAL_IP4_SUBNETの有効なネットマスクではありません。
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属性の内容がリンクの境界を意味するものではないことに注意することも価値があります。例えば、10.0.0.0/8ブロックからアドレスを使用して、大企業のイントラネットへのアクセスを提供するゲートウェイは、イントラネットはルータや個別のリンクの数百を持っている場合でも、単一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.)
（参考文献：TERO Kivinenのメール、2004-11-19スリニヴァサラオAddepalliのメール「INTERNAL_IP4_SUBNETとIKEv2の中INTERNAL_IP6_SUBNET」、2004年9月10日ヨアフニールのメール「再「のIKEv2で設定ペイロード内の属性のカップルの意向？」。。：新しいID：IKEv2の明確化と実装のガイドライン」、2005年2月7日。 『明確化未解決の問題：INTERNAL_IP4_SUBNET /ネットマスクの』スレッド、2005年4月）
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属性を定義しているという「内部ネットワークのネットマスク。一つだけネットマスクはリクエストで許可されるとメッセージを返信される（例えば、255.255.255.0）と、それが唯一のINTERNAL_IP4_ADDRESS属性を使用しなければなりません」。
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.
一つの可能な解釈は、ホストではなく、単一のアドレスのIPアドレスのブロック全体を与えているということでしょう。これは、フレームを選ぶ-IP-ネットマスクは、IPCP "サブネットマスク" の拡張子がPPP [IPCPSubnet]にし、[RADIUS]に何もあり、およびIPv6 Framed-IPv6-Prefixアトリビュートでのプレフィックス長は、[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 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.)
現在、このドキュメントの解釈は以下の通りです：CFG_REPLYでINTERNAL_IP4_NETMASKはほぼ同じ情報を含むINTERNAL_IP4_SUBNETと同じことを（「私を通してこれらのアドレスにトラフィックを送信」）を意味するだけでなく、リンクの境界を意味します。例えば、クライアントは、リンクのブロードキャストアドレスを計算するために、独自のアドレスとネットマスクを使用することができます。 （ゲートウェイが実際にこのリンクに接続された他の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.
空INTERNAL_IP4_NETMASK属性は、（ゲートウェイが要求されていない情報を送信することができるが）、この情報を要求するCFG_REQUESTに含めることができます。しかし、この属性の空でない値が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：IKEv2のために提案ラストコールベースの改正」、2004年5月27日TERO Kivinen、月2005ヨアフニールのメールと電子メールの議論。「日時：新ID：IKEv2の明確化と実装のガイドライン」、2005 -02-07「明確化未解決の問題：INTERNAL_IP4_SUBNET /ネットマスク」。糸、2005年4月）
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_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)
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）
In particular, IPv6 stateless autoconfiguration or router advertisement messages are not used; neither is neighbor discovery.
具体的には、IPv6ステートレス自動設定またはルータ広告メッセージは使用されません。どちらも近隣探索ではありません。
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属性を送ることができます。ゲートウェイは、最初に確認指定されたアドレスが許容され、それがある場合に、あることを返した場合。アドレスが許容可能でなかった場合、ゲートウェイは、いくつかの他のプレフィックスとインタフェース識別子を使用しようとします。でも、それが失敗した場合、ゲートウェイは、別のインタフェース識別子を選択します。
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属性に対応する（実際、IKEv2のドラフトの以前のバージョンでINTERNAL_IP6_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トンネルアーキテクチャ[IPv6Addr]センスをIPv6アドレスではないフル機能の「インターフェイス」です。特に、それらは必ずしもリンクローカルアドレスを持っていない、これは、このような[のMLDv2]としてそれらを想定したプロトコルの使用を複雑にする可能性があります。 （彼らはいくつかの特定のオペレーティング・システムでは「インターフェース」と呼ばれているかどうかは別の問題です。）
(References: "VPN remote host configuration IPv6 ?" thread, May 2004. "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
（参考文献：「VPNリモートホストの設定IPv6の？」スレッド、2004年5月「明確化未解決の問題：INTERNAL_IP4_SUBNET /ネットマスクの」スレッド、2005年4月）
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.)
（IP構成セキュリティIETF62で（ICOS）のBoFにバーナードAbobaによって指摘。）
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."
「ホストが内部IPアドレスを使用できること。ホストは、この有効期限前にIPアドレスを更新する必要があります。一つだけ、これらの属性の返信中に存在することができる秒数を指定します。」と、セクション3.15.1はINTERNAL_ADDRESS_EXPIRY属性を定義します
Expiry times and explicit renewals are primarily useful in environments like DHCP, where the server cannot reliably know when 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.
有効期限の時間と明示的な更新は、クライアントがなくなったときに、サーバが確実に知ることができないDHCP、のような環境では、主に便利です。しかし、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.)
（参考文献：TERO Kivinenのメールは、 "ドラフトeronen-のipsec-のIKEv2-明確化-02.txtのコメント"、2005-04-05スレッド "内部アドレスについての質問"、2005年4月）
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.
レスポンダは、すべてのコンフィギュレーション・ペイロードをサポートしていない場合はまず、それは単に、すべての構成ペイロードを無視することができます。実装のこのタイプは、INTERNAL_ADDRESS_FAILUREの通知を送信することはありません。イニシエータは、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）の特定のタイプのために。第4章では、「それはINTERNAL_IP4_ADDRESS属性が含まれていることを決定する場合を除き、最小限のIPv4応答の実装はCPペイロードの内容を無視します」と述べています。例えば、イニシエータがCFG_REQUESTの両方のINTERNAL_IP4_ADDRESSとINTERNAL_IP6_ADDRESSが含まれている場合、IPv4のみの応答は、従って、単にIPv6の部分を無視して、通常どおりのIPv4要求を処理することができます。
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.
イニシエータはレスポンダがサポートしているタイプの複数のアドレスを要求したところ第三の場合は、次のとおりです（すべてではない）の要求の一部に障害が発生した場合にどうしますか？楽観的なアプローチは、ここで最高のものであろうと思われる：応答者が少なくとも1つのアドレスを割り当てることができれば、それはそれらを返信。それは何のアドレスが割り当てられていないことができる場合にのみ、INTERNAL_ADDRESS_FAILUREを送信します。
(References: "ikev2 and internal_ivpn_address" thread, June 2005.)
（参考文献： "IKEv2のとinternal_ivpn_address" スレッド、2005年6月）
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のIDタイプを使用する場合は、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）は、ピア認証データベース（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および事前共有鍵認証におけるその使用」スレッド、月2005年「マッチングID_IPV4_ADDRとID_IPV6_ADDR」スレッド、2006年5月）
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]を必要とすることを確認仕様では、いくつかの要件があります。換言すれば、IPsec処理を行う実装は厳密に[RFC2401]に記載の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によって作成されたすべてのトンネルモードSAの「具体的には、トンネルカプセル化装置とdecapsulators [...] ECN輻輳の廃棄を防ぐために[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]の実装に必要な変更はオプションで、特に（例えば、拡張シーケンス番号など）の新機能の多くをサポートするため、非常に大きくありません。
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を再入力するとき、それが明示的に新しいSET_WINDOW_SIZE通知を送信することにより増加されるまでしかし、新しいIKE_SAは、ウィンドウサイズ1から始まります。
(References: Tero Kivinen's mail "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
（参考文献：TERO Kivinenのメール "ドラフト-eronen-のipsec-のIKEv2-明確化-02.txtのコメント"、2005-04-05。）
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."
2.10「はサイズが少なくとも128ビットでなければなりません、と交渉されたprfの少なくとも半分のキーサイズでなければなりません。、IKEv2のに使用されるナンスは、ランダムに選択されなければならない」と述べています
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.
しかし、イニシエータは、交渉の結果が知られる前にnonceを選択します。この場合、ナンスは、すべてのPRFが提案されているために十分に長くなければなりません。
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.
ポート4500上のIKE_SA_INIT要求を送信するピアは最初の4ゼロ個のオクテットを含めるべきかどうかは明らかではありません。第2のメッセージの後にポート4500を介してトンネリングにアップグレードするが、それはメッセージ1がポート4500上で送信された場合にどうするかを言っていない方法については2.23会談。
IKE MUST listen on port 4500 as well as port 500.
IKEは、ポート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.
現在、彼らは外側のパケットMUSTトンネルにUDPポート4500を介して、このIKE_SAに関連するすべての将来のIKEおよびESPパケットのアドレスと一致しない場合場合IKEイニシエータは、これらのペイロードをチェックしなければなりません。
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. [...]
UDPポート4500上のトンネルのIKEパケットに、IKEヘッダはゼロプリペンドの4つのオクテットを有しており、結果が直ちにUDPヘッダの後に続きます。 [...]
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)."
第2節の冒頭には、「IKEメッセージもわずかに異なる形式でUDPポート4500で受信してもよいが...（セクション2.23を参照してください）。」と言います
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パケットまたはESPパケットであるかどうかを判断することはできません。
Thus, all packets sent on port 4500 need the four-zero prefix; otherwise, the receiver won't know how to handle them.
このように、ポート4500上で送信されるすべてのパケットは、4-ゼロプレフィックスを必要とします。そうでない場合、受信機は、それらを処理する方法を知ることができません。
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".
セクション2.23「は、その通信員の間でNATを発見するのIPsecエンドポイントがポート4500へとから後続のすべてのトラフィックを送信しなければならない」と述べています。
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によって割り当てられます。
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ヘッダに使用すべきか全く明らかではありません。このような通知は、明示的に情報交換していないことに注意してください。セクション1.5は、それを明確にこれらのに反応してはいけない一方向のメッセージであることを明らかにしています。
There are two cases when such a one-way notification can be sent: INVALID_IKE_SPI and INVALID_SPI.
INVALID_IKE_SPIとINVALID_SPI：そのよう片道通知を送ることができる2つのケースがあります。
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の場合は、送信されたメッセージは、応答メッセージであり、セクション2.21には、応答が送信されると、それは同じIKEのSPIとコピーされたメッセージIDに付属そこから、応答がIPアドレスとポートに送らなければならない」と述べています。」
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.)
（参考文献： "INVALID_IKE_SPI" スレッド、2005年6月）
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でペイロードを通知するプロトコルIDフィールドと言い、「既存のSAに関連していない通知の場合、このフィールドはゼロとして送らなければならなくて、領収書で無視しなければなりません」。ただし、仕様は明らかに既存のSAに関連するとされていないされている通知言いません。
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の種類を指定することですので、私たちの解釈は、プロトコルIDフィールドは、SPIフィールドが空の場合にのみ非ゼロでなければならないことです。
There are currently only two notifications where this is the case: INVALID_SELECTORS and REKEY_SA.
INVALID_SELECTORSとREKEY_SA：このような場合は2つだけの通知は現在ありません。
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.
第3.10.1項でINITIAL_CONTACT通知の説明は「この通知は、このIKE_SAが認証されたアイデンティティの間で現在アクティブのみIKE_SAであることを主張する」と述べています。しかし、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.
一般的な合意はINITIAL_CONTACTがベストではない、その後、別の交換として、最初のIKE_AUTH要求に伝達されていることです。
(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の中INITIAL_CONTACTの使用を明確化」スレッド、2005年4月「初期コンタクトメッセージ」スレッド、2004年12月「のIKEv2と最初の接触」のスレッド、2004年9月と2005年4月）
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のがそれらを持っていた主な理由は、「RESERVED」としてマークされ、それらが描画する画像を容易に一因が含まれています。特に、IKEv2の中のペイロードは、一般的に、4オクテット境界に整列していません。 （ペイロードのいずれかのIKEv1 4オクテット境界に整列されていなかったことに注意してください。）
(References: "IKEv2: potential 4-byte alignment problem" thread, June 2004.)
（参考文献：「のIKEv2：潜在的な4バイトアライメントの問題」スレッド、2004年6月）
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暗号化、整合性、およびキーの幅を指定する単一の属性を必要とする擬似ランダム機能をベースにしています。」と述べています
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ベースのアルゴリズムのために含まれている（暗号ブロック連鎖（CBC）、カウンタ（CTR）モード、CBC-MAC（CCM）、およびガロア/カウンタ・モード（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、CAST、およびフグが挙げられます。キーの長さ属性が含まれていない場合は、[RFC2451]で指定されたデフォルト値が使用されます。
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.
IKEv2の-レジストリ、ISAKMP-レジストリ、およびIPSec-レジストリ：IPsecのための重要な数字を含む3つの異なるIANAレジストリファイルは現在ありません。実装者は、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はIKEv2の-レジストリに識別子「タイプ1のトランスフォーム」、IKEv1のフェーズが1、「暗号化アルゴリズム」のipsec-レジストリ内の識別子、およびIKEv1のフェーズ2「IPSEC ESPトランスフォーム識別子」ISAKMP-レジストリ。いくつかのアルゴリズムは、すべての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の「タイプ3の変換」のIKEv2-レジストリ、IKEv1のフェーズ2 ISAKMP-レジストリに「IPSEC AHは、識別子を変換」、およびIKEv1のフェーズ2 ESP「認証アルゴリズムセキュリティアソシエーション属性」内の識別子ISAKMP-レジストリ内の識別子。そして、IPSec-レジストリ内のIKEv1フェーズ1「ハッシュアルゴリズム」リストもあります。
This issue needs special care also when writing a specification for how a new algorithm is used with IPsec.
新しいアルゴリズムは、IPsecのに使用される方法の仕様を記述するとき、この問題は、特別な注意が必要です。
The IKEv2 specification contains some misleading text about how ESP and AH can be combined.
IKEv2の仕様は、ESPと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のは、[RFC2401]の一部であった「SAバンドル」を含まない、[RFC4301]に基づいています。単一のパケットを複数回処理したIPsecを通過することができますが、これらのパスのそれぞれが別々のSAを使用して、パスを転送テーブルによって調整されています。 IKEv2のでは、これらのSAの各々は、別々のCREATE_CHILD_SA交換を使用して作成されなければなりません。このように、ESPとAHの両方を含む単一の提案について2.7節内のテキストが正しくありません。
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.
また、（同じエンドポイント間）ESPとAHの組み合わせは、すでにRFC 2406が発行された1998年の大部分が時代遅れになっていました。私たちの推薦はIKEv2の実装は、この組み合わせをサポートしていなければならないことである、との組み合わせを想定してはならない実装は、相互運用可能な方法で動作させることができます。
(References: "Rekeying SA bundles" thread, Oct 2005.)
（参考文献：「鍵の再生成SAバンドル」スレッド、10月2005）
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でいくつかの実装は、すべてを正しくしませんでした。これは明白な文のように見えるかもしれませんが、おそらく、文書で明確にしたいくつかのことをリストアップするのに便利ですが、いくつかの実装がそうしなかったこと。これらの事のすべては、相互運用性の問題を引き起こしました。
o Some implementations continued to send traffic on a CHILD_SA after it was rekeyed, even after receiving an DELETE payload.
Oいくつかの実装では、それがリキーされた後でも削除ペイロードを受信した後、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を再入力した後、いくつかの実装はゼロに彼らのメッセージカウンタをリセットしませんでした。一つは、他のすべてでカウンタをリセットしませんでした、2にカウンタを設定します。
o Some implementations could only handle a single pair of traffic selectors or would only process the first pair in the proposal.
Oいくつかの実装では、唯一のトラフィックセレクタの単一のペアを扱うことができるかだけの提案で最初のペアを処理します。
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一部の実装では、空のINFORMATIONAL応答を送信することにより、削除要求に応答して、削除するには、SAのペアで、独自の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 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.
これはそこの議論から、bakeoffで実現しなかったが、O、一部の人々は正しくメッセージウィンドウサイズを実現していなかったことは明らかです。いくつかの実装では、応答者のメッセージウィンドウに収まらなかったメッセージを送ったかもしれない、と彼らはこれまで彼らが持っている必要があります知っているメッセージを受信しなかった場合にはいくつかの実装は、SAを取り壊さいない可能性があります。
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のに任意の新しいセキュリティの考慮事項を導入しません。どちらかといえば、仕様の複雑な領域を明確にすることは、セキュリティ上の影響を有することができる、実装上の問題の可能性を減らすことができます。
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、ヨアフニール、マイケル・リチャードソン、とジョエル・スナイダーに感謝したいと思います。
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、すべての参加者に感謝したいと思います。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[IKEv2ALG] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[IKEv2ALG]シラー、J.、 "インターネット鍵交換バージョン2（IKEv2の）での使用のための暗号アルゴリズム"、RFC 4307、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.0"、RFC 2437、1998年10月。
[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"、RFC 3447、2003年2月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[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.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、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]シスコシステムズ社の "IPCPサブネットマスクのサポートの強化"、http://www.cisco.com/univercd/cc/td/のdoc /製品/ソフトウェア/ ios121 / 121newft / 121limit / 121dc / 121dc3 / ipcp_msk .htmを、2003年1月。
[IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[IPv6Addr] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[MIPv6の]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[のMLDv2]ヴィーダ、R.とL.コスタ、 "IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）"、RFC 3810、2004年6月。
[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[NAI] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[PKI4IPsec] Korver, B., "Internet PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Work in Progress, April 2006.
[PKI4IPsec]コーバー、B.、 "IKEv1の/ ISAKMP、IKEv2の、およびPKIXのインターネットPKIプロファイル"、進歩、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.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RADIUS] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RADIUS6] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
【RADIUS6] Aboba、B.、ゾルン、G.、およびD.ミットン、 "RADIUSとIPv6"、RFC 3162、2001年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]ペレイラ、R.とR.アダムス、 "ESP CBCモード暗号アルゴリズム"、RFC 2451、1998年11月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 3664, January 2004.
[RFC3664]ホフマン、P.、 "インターネット鍵交換プロトコルのためのAES-XCBC-PRF-128アルゴリズム（IKE）"、RFC 3664、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.ステンバーグ、 "IPsecのESPパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4434, February 2006.
[RFC4434]ホフマン、P.、 "インターネット鍵交換プロトコルのためのAES-XCBC-PRF-128アルゴリズム（IKE）"、RFC 4434、2006年2月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", RFC 822, August 1982.
[RFC822]クロッカー、D.、RFC 822 "標準ARPAインターネットテキストメッセージの形式について"、1982年8月。
[ReAuth] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[REAUTH]ニール、Y.は、RFC 4478、2006年4月 "インターネットキーエクスチェンジ（IKEv2の）プロトコルで認証を繰り返し"。
[SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and T. Polk, "Simple Certificate Validation Protocol (SCVP)", Work in Progress, June 2006.
[SCVP]フリーマン、T.、Housley氏、R.、Malpani、A.、クーパー、D.、およびT.ポーク、 "簡単な証明書の検証プロトコル（SCVP）"、進歩、2006年6月に作業。
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。 IKE_SA_INIT交換
request --> [N(COOKIE)], SA, KE, Ni, [N(NAT_DETECTION_SOURCE_IP)+, N(NAT_DETECTION_DESTINATION_IP)], [V+]
要求 - > [N（COOKIE）]、SA、KE、ニッケル、[N（NAT_DETECTION_SOURCE_IP）+、N（NAT_DETECTION_DESTINATION_IP）]、[Vの+]
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と、（NOクッキー）[N（NAT_DETECTION_SOURCE_IP）、N（NAT_DETECTION_DESTINATION_IP）]、[N（HTTP_CERT_LOOKUP_SUPPORTED）]、CERTREQの+]、[Vの+]
A.2. IKE_AUTH Exchange without EAP
A.2。 EAPなしIKE_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+]
要求 - > 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の+]
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（ESP_TFC_PADDING_NOT_SUPPORTED）]、[N（NON_FIRST_FRAGMENTS_ALSO）]、SA、をTSi TSR、[N（ADDITIONAL_TS_POSSIBLE）]、[V +]
A.3. IKE_AUTH Exchange with EAP
A.3。 EAPとIKE_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+]
最初の要求 - > 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の+]
first response <-- IDr, [CERT+], AUTH, EAP, [V+]
最初の応答< - IDR [CERT +]、AUTH、EAP、[Vの+]
/ --> 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（ESP_TFC_PADDING_NOT_SUPPORTED）]、[N（NON_FIRST_FRAGMENTS_ALSO）]、SA、をTSi、TSrを、[N （ADDITIONAL_TS_POSSIBLE）]、[V +]
A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying CHILD_SAs
A.4。 CREATE_CHILD_SA交換/鍵の再生成のCHILD_SAsを作成するための
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（ESP_TFC_PADDING_NOT_SUPPORTED）]、[N（NON_FIRST_FRAGMENTS_ALSO）]、SA、ニッケル、[た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（ESP_TFC_PADDING_NOT_SUPPORTED）]、[N（NON_FIRST_FRAGMENTS_ALSO）]、SA、Nrと、[KER]をTSi、TSrを、[N（ADDITIONAL_TS_POSSIBLE）]
A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA
A.5。 IKE_SAを再入力するためのCREATE_CHILD_SA交換
request --> SA, Ni, [KEi]
れくえｓｔ ーー＞ さ、 に、 「けい」
response <-- SA, Nr, [KEr]
応答「 - SA、Nrの[KER]
A.6. INFORMATIONAL Exchange
A.6。 Informational交換
request --> [N+], [D+], [CP(CFG_REQUEST)]
要求 - > [N +]、[D +]、[CP（CFG_REQUEST）]
response <-- [N+], [D+], [CP(CFG_REPLY)]
応答< - [N +]、[D +]、[CP（CFG_REPLY）]
Authors' Addresses
著者のアドレス
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
ノキア・リサーチセンター私書箱のパシEronenボックス407 FIN-00045 Nokiaのグループフィンランド
EMail: pasi.eronen@nokia.com
メールアドレス：pasi.eronen@nokia.com
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポール・ホフマンVPNコンソーシアムセグレ127場所サンタクルス、CA 95060 USA
EMail: paul.hoffman@vpnc.org
メールアドレス：paul.hoffman@vpnc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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エディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。