[要約] 要約：RFC 4718は、IKEv2（Internet Key Exchange version 2）プロトコルの明確化と実装ガイドラインを提供しています。 目的：このRFCの目的は、IKEv2の仕様の不明確な点を明確化し、実装者に対してガイドラインを提供することです。
Network Working Group P. Eronen
Request for Comments: 4718 Nokia
Category: Informational P. Hoffman
VPN Consortium
October 2006
IKEv2 Clarifications and Implementation Guidelines
IKEV2の明確化と実装ガイドライン
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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ベースのリモートアクセス（「Road Warrior」ケースと呼ばれることもあります）、サイトからサイトへの仮想プライベートネットワーク（VPNS）、ホストからホストのアプリケーショントラフィックのホスト保護など、いくつかの異なる目的に使用できます。。このドキュメントはこれらすべての使用を検討しようとしますが、リモートアクセスシナリオは、おそらく他の用途よりも多くの注目を集めています。
This document does not place any requirements on anyone and does not use [RFC2119] keywords such as "MUST" and "SHOULD", except in quotations from the original IKEv2 documents. The requirements are given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic algorithms document [IKEv2ALG].
このドキュメントは、誰にも要件を掲載せず、元のIKEV2ドキュメントからの引用を除き、「必須」や「必須」などの[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@itef.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では、ResponderのSPI「...他のメッセージではゼロではない」（IKE_SA_INIT Exchangeの最初のメッセージよりも）。ただし、セクション2.6の図は、2番目のIKE_SA_INITメッセージを「HDR（a、0）、n（cookie）」として示しており、3.1のテキストと矛盾しています。
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.
ResponderのSPIは、Responderが保有するセキュリティ関連の状態を識別し、この場合はゼロ値を送信することは合理的であると思われます。
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?
第二に、Cookieに加えて、IKE_SA_INIT ExchangeがIKE_SAの作成につながらない場合（たとえば、Invalid_ke_Payloadまたはno_proposal_chosen）他のいくつかのケースがあります。この場合、IKE_SA_INIT応答でどのレスポンダーSPI値を使用する必要がありますか？
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を送信する場合、イニシエーターはその理由のためにのみ応答を拒否すべきではありません。ただし、IKE_SA_INITリクエストを再試行する場合、イニシエーターはセクション3.1で説明されているように、ゼロレスポンダーSPIを使用します。クッキーを含むメッセージ）[...] "。Invalid_ke_Payloadなど、他の理由により、そのメッセージの繰り返しもカバーすることであると考えています。
(References: "INVALID_KE_PAYLOAD and clarifications document" thread, Sep-Oct 2005.)
（参考文献： "Invalid_ke_payload and clarifications document" Thread、2005年9月。）
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状態の一部であり、Responderが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）の組み合わせに関する質問」スレッド、2004年10月。TeroKivinen'sMail "ドラフトエロネン-IPSEC-YIPEC-AIKEV2-CLAIFATIONS-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).
Responderが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の後ろの2つの異なるピアが同じイニシエーター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リクエスト以外のすべてのパケットについては、もちろん受信者のSPI（IKEヘッダーのイニシエータービットの値に応じて、イニシエーターまたはレスポンダーSPIのいずれか）に基づいて、正しいIKE_SAを検索します。
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 Exchangeを再試行しなければならない場合がある2つの一般的な理由があります。レスポンダーはCookieを要求するか、KEIペイロードに含まれていたものとは異なるDiffie-Hellmanグループを望んでいます。これらのケースは両方とも単独で非常に単純ですが、同時に発生したときに何が起こるか、つまりIKE_SA_INIT Exchangeが何度か再試行されることは完全に明白ではありません。
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:
主な質問は次のとおりです。イニシエーターがレスポンダーからCookieを受け取った場合、IKE_SA_INITリクエストの次の再試行のみにCookieを含める必要がありますか、それとも後続のすべての再試行にも含まれる必要がありますか？セクション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."
「そのような応答を受け取ったイニシエーターは、最初のペイロードとしてレスポンダーで提供されたCookieデータを含むタイプCookieおよび他のすべてのペイロードを変更しないタイプCookieの通知を使用して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:
両方の解釈が平和的に共存できるようです。イニシエーターに次の再試行でのみCookieが含まれている場合、場合によっては1つの追加の往復が必要になる場合があります。
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):
イニシエーターにすべての再試行にCookieが含まれているが、レスポンダーがこの機能をサポートしていない場合は、追加の往復が必要です。たとえば、レスポンダーにCookie計算にSAI1とKEIのペイロードが含まれている場合、新しいCookieを送信してリクエストを拒否します（このドキュメントのセクション2.5も参照して、無効なCookieに関する詳細については、詳細については、このドキュメントも参照してください）：
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:
すべてのレトリでCookieを含む両方のピアがサポートする場合、わずかに短い交換が発生する可能性があります。
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:
理論的には、Cookieと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.
ただし、「他のすべてのペイロード」にはKEIペイロードも明確に含まれているため、セクション2.6のテキストではこのケースが許可されていないことは明らかです。
(References: "INVALID_KE_PAYLOAD and clarifications document" thread, Sep-Oct 2005.)
（参考文献： "Invalid_ke_payload and clarifications document" Thread、2005年9月。）
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).
無効なCookieを含む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 [...]".
正しいアクションは、Cookieを無視し、Cookieが含まれていないかのようにメッセージを処理することです（通常、これは新しいCookieを含む応答を送信することを意味します）。これは、「その場合の応答者は、新しい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.)
（参照：「Invalid Cookie」スレッド、2005年9月。）
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では、認証ペイロードの計算方法について説明します。この計算には、値PRF（SK_PI、IDI '）およびPRF（SK_PR、IDR'）が含まれます。テキストは言葉でメソッドを説明していますが、署名またはマッケージの明確な定義を示していません（つまり、メッセージ認証コードで保護されています）。
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.
もう1つの合理的な選択は、ピア証明書に署名するときにCAが使用したハッシュ関数を使用することです。ただし、これは、同じコードが証明書署名とIKEV2メッセージ署名を検証するために使用されない可能性があるため、IKEV2ピアが認証ペイロードを検証できることを保証するものではありません。ピアは、証明書の指紋で構成することができます。または、[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]シグネチャエンコーディング方法（詳細については次のセクションを参照）を使用します。これには、ハッシュアルゴリズムのアルゴリズム識別子が含まれています。したがって、検証者が認証ペイロードを受信すると、少なくともどのハッシュ関数が使用されたかを決定できます。
(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。PasiEronen'sReply、2005-01-04。TeroKivinen'sReply、2005-01-04。2006年1月。）
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]への参照がありました。そのバージョンには、署名のエンコード方法（EMSA-PKCS1-V1_5）のみが1つしかないため、あいまいさはありません。
Note that this encoding method is different from the encoding method used in IKEv1. If future revisions of IKEv2 provide support for other encoding methods (such as EMSA-PSS), they will be given new Auth Method numbers.
このエンコード方法は、IKEV1で使用されるエンコードメソッドとは異なることに注意してください。IKEV2の将来の改訂版が他のエンコード方法（EMSA-PSSなど）をサポートする場合、新しいAUTHメソッド番号が与えられます。
(References: Pasi Eronen's mail "RE:", 2005-01-04.)
（参考文献：Pasi Eronenのメール「Re： "、2005-01-04。）
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]で定義されたネットワークアクセス識別子（NAIS）で使用されます。NAISはメールアドレスのように見えますが（例：「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識別タイプが、レルムコンポーネントを含むNAISに使用されることを推奨しています。したがって、レスポンダーの実装は、[RFC822]または[RFC2822]で与えられた正確な構文に内容が実際に適合していることを確認しようとするべきではなく、代わりに合理的な見た目のNAIを受け入れる必要があります。
For NAIs that do not include the realm component, this document recommends using the ID_KEY_ID identification type.
レルムコンポーネントを含まないNAISの場合、このドキュメントでは、ID_KEY_ID識別タイプを使用することをお勧めします。
(References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2 identifier issue with EAP" threads, Aug 2004.)
（参考文献：「このIKEV2/I18N/EAPの問題に関する助けが必要」および「IEPのIKEV2識別子の問題」スレッド、2004年8月。）
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メソッドによって認証されたIDとは異なる場合があります（[EAP]、セクション5.1および7.3を参照）。
It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder using, e.g., RADIUS [RADEAP]. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder.
ポリシーの検索とアクセス制御の決定が実際の認証されたアイデンティティを使用することが重要です。多くの場合、EAPサーバーは、radius [radeap]を使用してIKEV2レスポンダーと通信する別のAAAサーバーに実装されます。この場合、認証されたアイデンティティをAAAサーバーからIKEV2レスポンダーに送信する必要があります。
(References: Pasi Eronen's mail "RE: Reauthentication in IKEv2", 2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748, Section 7.3.)
（参考文献：Pasi Eronenのメール「Re：Ikev2の再認可」、2004-10-28。「ポリシー検索」スレッド、2004年10月/11月。RFC3748、セクション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]の「必要」/「必要」要件である値のみを使用することが推奨されます。つまり、「X.509証明書 - 署名」（4）、「RAW RSAキー」（11）、「ハッシュとX.509証明書」（12）、および「ハッシュとURLのX.509バンドル」（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には、証明書リクエストの「証明書をエンコードする」フィールドは、証明書のペイロードと同じ値を使用していると述べています。ただし、「認定機関」フィールドの内容は、X.509証明書のみで定義されます（おそらく、少なくとも4、10、12、および13のカバーをカバーしています）。このドキュメントでは、使用が利用可能であることを指定する新しい仕様の前に、他の値を使用しないことを推奨しています。
The "Raw RSA Key" type needs one additional clarification. Section 3.6 says it contains "a PKCS #1 encoded RSA key". What this means is a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21].
「RAW RSAキー」タイプには、追加の明確化が必要です。セクション3.6には、「PKCS＃1エンコードされたRSAキー」が含まれています。これが意味するのは、PKCS＃1 [PKCS1v21]からの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]は元々固定キーサイズを使用していました。[RFC4434]の可変キーサイズを処理するためにRFCが更新されました。
Note that Section 2.13 also contains text that is related to PRFs with fixed key size: "When the key for the prf function has fixed length, the data provided as a key is truncated or padded with zeros as necessary unless exceptional processing is explained following the formula". However, this text applies only to the prf+ construction, so it does not contradict the text in Section 2.15.
セクション2.13には、固定キーサイズの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.)
（参考文献：ポール・ホフマンのメール「Re：IKEV2-07：LAST NITS」、2003-05-02。HugoKrawczykの返信、2003-05-12。
As described in the previous section, PRFs with a fixed key size require a shared secret of exactly that size. This restriction applies also to EAP authentication. For instance, a PRF that requires a 128-bit key cannot be used with EAP since [EAP] specifies that the MSK is at least 512 bits long.
前のセクションで説明したように、固定キーサイズを持つPRFSには、そのサイズの正確な秘密が共有される必要があります。この制限は、EAP認証にも適用されます。たとえば、[EAP]はMSKの長さが少なくとも512ビットであることを指定するため、128ビットキーを必要とするPRFをEAPで使用できません。
(References: Thread "Question about PRFs with fixed size key", Jan 2005.)
（参考文献：「固定サイズのキーを持つPRFに関する質問」、2005年1月。）
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が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 ExchangeがEAPを使用しない場合、それは当てはまります。EAPを使用すると、メッセージの各ペアにメッセージ番号が増加します。Authメッセージの最初のペアには1のIDがあり、2番目は2になります。
(References: "Question about MsgID in AUTH exchange" thread, April 2005.)
（参考文献：「Auth Exchangeにおける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 Exchange（Child SASの作成、Ike SASの再キーイング、および子SASの再キーを使用するたびにサブセクションで再編成できます。
The new Section 1.3 with subsections and the above changes might look like the following.
サブセクションと上記の変更を備えた新しいセクション1.3は、次のように見える場合があります。
NEW-1.3 The CREATE_CHILD_SA Exchange
new-1.3 create_child_sa Exchange
The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and to rekey both IKE_SAs and CHILD_SAs. This exchange consists of a single request/response pair, and some of its function was referred to as a phase 2 exchange in IKEv1. It MAY be initiated by either end of the IKE_SA after the initial exchanges are completed.
create_child_sa Exchangeは、新しいchild_sasを作成し、ike_sasとchild_sasの両方を再キーするために使用されます。この交換は単一の要求/応答ペアで構成されており、その機能の一部はIKEV1のフェーズ2エクスチェンジと呼ばれていました。最初の交換が完了した後、IKE_SAのいずれかの端によって開始される場合があります。
All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the first two messages of the IKE exchange. These subsequent messages use the syntax of the Encrypted Payload described in section 3.14. All subsequent messages include an Encrypted Payload, even if they are referred to in the text as "empty".
最初の交換に続くすべてのメッセージは、IKE Exchangeの最初の2つのメッセージで交渉された暗号化アルゴリズムとキーを使用して暗号的に保護されています。これらの後続のメッセージは、セクション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の再キーに使用されます。このセクションでは、新しいSASの作成の最初の部分について説明します。セクション2.8では、古いSASから新しいSASへのトラフィックの移動や古いSASの削除など、再キーイングの仕組みについて説明します。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 Exchangeを開始する場合があるため、このセクションでは、イニシエーターという用語は、この交換を開始するエンドポイントを参照します。実装は、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の関数、Create_Child_Sa Exchange中に交換されたNonces、およびDiffie-Hellman値（KEペイロードがCreate_Child_Sa Exchangeに含まれている場合）。詳細については、セクション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 ExchangeにKEIペイロードが含まれている場合、SAの提供の少なくとも1つには、KEIのdiffie-hellmanグループが含まれている必要があります。KEIのdiffie-hellmanグループは、イニシエーターがレスポンダーが受け入れることを期待するグループの要素でなければなりません（追加のdiffie-hellmanグループを提案できます）。ResponderがKEIペイロードのdiffie-hellmanグループを拒否した場合、Responderはリクエストを拒否し、Invalid_ke_payload通知ペイロードで優先されるdiffie-hellmanグループを示す必要があります。このような拒否の場合、create_child_sa Exchangeは失敗し、イニシエーターは、ResponderがInvalid_ke_Payloadで与えたグループのDiffie-Hellmanの提案とKEIと交換を再試行する必要があります。
NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
new-1.3.1 create_child_sa Exchangeを使用して新しいchild_sasを作成します
A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The CREATE_CHILD_SA request for creating a new CHILD_SA is:
Child_saは、create_child_saリクエストを送信することで作成できます。新しいchild_saを作成するためのcreate_child_saリクエストは次のとおりです。
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ペイロードのSAオファー、NIペイロードのNonCE、オプションではKEIペイロードのdiffie-hellman値、およびTSIおよびTSRペイロードで提案されているchild_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.
Responderは、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に送信されるトラフィックセレクターは、応答のTSペイロードで指定されています。これは、子どものイニシエーターが提案したもののサブセットである可能性があります。
The text about rekeying SAs can be found in Section 5.1 of this document.
SASの再キーイングに関するテキストは、このドキュメントのセクション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 Exchangeでピギーバックされるか、個別のcreate_child_sa Exchangeを使用して作成できます。IKE_AUTH Exchange中に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 Exchangeがどのように機能するかにも沿っています。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.
IKE_SAのセットアップを妨げないIKE_AUTH Exchangeの応答のリストには、少なくとも次のものが含まれます。NO_PROPOSAL_CHOSEN、TS_UNACCEPTABLE、single_pair_required、internal_address_failure、およびfailed_cp_requedが含まれます。
(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メッセージにKEI/KERまたはNI/NRペイロードが含まれていないことを示しています。これは、IKE_AUTH ExchangeのSAペイロードに、他の値であるType Type 4（Diffie-Hellman Group）が含まれないことを意味します。この場合、実装はおそらく変換を完全に除外する必要があります。
The description of the ESN transform in Section 3.3 has be proved difficult to understand. The ESN transform has the following meaning:
セクション3.3のESN変換の説明は、理解が困難であることが証明されています。ESN変換には次の意味があります。
o A proposal containing one ESN transform with value 0 means "do not use extended sequence numbers".
o 値0の1つのESN変換を含む提案は、「拡張シーケンス番号を使用しないでください」を意味します。
o A proposal containing one ESN transform with value 1 means "use extended sequence numbers".
o 値1の1つのESN変換を含む提案は、「拡張シーケンス番号を使用」を意味します。
o A proposal containing two ESN transforms with values 0 and 1 means "I support both normal and extended sequence numbers, you choose". (Obviously this case is only allowed in requests; the response will contain only one ESN transform.)
o 値0と1の2つのESN変換を含む提案は、「選択した通常と拡張シーケンス番号の両方をサポートする」を意味します。（明らかに、このケースはリクエストでのみ許可されています。応答には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).
ほとんどの場合、Exchangeイニシエーターには、SAペイロードに1つ目または3番目の代替品が含まれます。2番目の代替案は、イニシエーターにとってめったに役立つことはありません。これは、通常のシーケンス番号を使用することが受け入れられないことを意味します（したがって、レスポンダーが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).
ESP/AH SASを作成するときにESN変換を含めることは必須であることに注意してください（IKEV2仕様の以前のドラフトではオプションでした）。
(References: "Technical change needed to IKEv2 before publication", "STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2" and "Results of straw poll regarding: IKEv2 interoperability issue" threads, March-April 2005.)
（参考文献：「公開前にIKEV2に必要な技術的変更」、「ストロー投票：IKEV2でのESN交渉間の問題への対処」および「IKEV2相互運用性の問題」スレッド、2005年3月。
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を提案するリクエストとそれを受け入れる応答の両方に含まれます。この通知がメッセージの1つのみに含まれている場合、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の通知は、セクション3.10.1で「断片化制御に使用されます。説明については[RFC4301]を参照」として説明されています。
[RFC4301] says "Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port (or ICMP type/code or MH type) selectors MUST notify a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. The peer MUST reject this proposal if it will not accept non-initial fragments in this context. If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA."
[RFC4301]は、「非文書ポート（またはICMPタイプ/コードまたはMHタイプ）セレクターを使用するトンネルモードSAで非独創的なフラグメントを送信する実装は、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の個々のセレクターの少なくとも1つと一致する場合、特定のTSI/TSRと一致します。
For instance, the following traffic selectors:
たとえば、次のトラフィックセレクター：
TSi = ((17, 100, 192.0.1.66-192.0.1.66),
(17, 200, 192.0.1.66-192.0.1.66))
TSr = ((17, 300, 0.0.0.0-255.255.255.255),
(17, 400, 0.0.0.0-255.255.255.255))
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).
ソース/宛先ポート（100,300）、（100,400）、（200,300）、および（200、400）の4つの組み合わせのいずれかで、192.0.1.66からどこにでもUDPパケットを一致させます。
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）のみを一致させるポリシーは、他の2つの組み合わせではなく、IKEV2を使用して単一のchild_saペアとして交渉することはできません。
(References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)
（参照：「IKEV2トラフィックセレクター？」スレッド、2005年2月。）
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オクテットフィールドタイプとコードは、単一の16ビット整数（最も重要な8ビットのタイプと最も重要な8ビットのコード）として扱われます。このフィールドに基づいたフィルタリングの目的のためのポート番号。」
Since ICMP packets do not have separate source and destination port fields, there is some room for confusion what exactly the four TS payloads (two in the request, two in the response, each containing both start and end port fields) should contain.
ICMPパケットには個別のソースと宛先ポートフィールドがないため、4つのTSペイロード（リクエストの2つ、応答の2つ、開始ポートフィールドとエンドポートフィールドの両方を含む）が正確に含まれることがあります。
The answer to this question can be found from [RFC4301] Section 4.4.1.3.
この質問に対する答えは、[RFC4301]セクション4.4.1.3から見つけることができます。
To give a concrete example, if a host at 192.0.1.234 wants to create a transport mode SA for sending "Destination Unreachable" packets (ICMPv4 type 3) to 192.0.2.155, but is not willing to receive them over this SA pair, the CREATE_CHILD_SA exchange would look like this:
具体的な例を挙げると、192.0.1.234のホストが「宛先の到達不可能な」パケット（ICMPV4タイプ3）を192.0.2.155に送信するためのトランスポートモードSAを作成したいが、このSAペアでそれらを受け取ることをいとわない場合、create_child_sa Exchangeは次のようになります：
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 SASを作成するため、2番目のSAがデータトラフィックに使用されない場合でも、この場合には2つの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.)
（参考文献：「IKMPおよびMH TSS for IKEV2」スレッド、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.
トラフィックセレクターは、IPプロトコルID 135を使用して、IPv6モビリティヘッダー[MIPV6]に一致させることができます。ただし、IKEV2仕様は、トラフィックセレクターの「MHタイプ」フィールドを表す方法を定義していません。
At some point, it was expected that this will be defined in a separate document later. However, [RFC4301] says that "For IKE, the IPv6 mobility header message type (MH type) is placed in the most significant eight bits of the 16 bit local "port" selector". The direction semantics of TSi/TSr port fields are the same as for ICMP and are described in the previous section.
ある時点で、これは後で別のドキュメントで定義されると予想されていました。ただし、[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's Mail "Issue＃86：IPv6 Mobility Headerメッセージタイプをセレクターとして追加する"、2003-10-14。
Section 2.9 describes how traffic selectors are negotiated when creating a CHILD_SA. A more concise summary of the narrowing process is presented below.
セクション2.9では、Child_Saを作成する際にトラフィックセレクターがどのようにネゴシエートされるかについて説明します。狭窄プロセスのより簡潔な要約を以下に示します。
o If the responder's policy does not allow any part of the traffic covered by TSi/TSr, it responds with TS_UNACCEPTABLE.
o ResponderのポリシーがTSI/TSRの対象となるトラフィックの一部を許可していない場合、TS_Unactepableで応答します。
o If the responder's policy allows the entire set of traffic covered by TSi/TSr, no narrowing is necessary, and the responder can return the same TSi/TSr values.
o ResponderのポリシーがTSI/TSRでカバーされるトラフィックのセット全体を許可する場合、狭窄は必要ありません。また、レスポンダーは同じTSI/TSR値を返すことができます。
o Otherwise, narrowing is needed. If the responder's policy allows all traffic covered by TSi[1]/TSr[1] (the first traffic selectors in TSi/TSr) but not entire TSi/TSr, the responder narrows to an acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].
o それ以外の場合は、狭窄が必要です。Responderのポリシーで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.
o ResponderのポリシーでTSI [1]/TSR [1]でカバーされているすべてのトラフィックが許可されていないが、TSI/TSRの一部を許可する場合、TSI/TSRの許容可能なサブセットに狭くなります。
In the last two cases, there may be several subsets that are acceptable (but their union is not); in this case, the responder arbitrarily chooses one of them and includes ADDITIONAL_TS_POSSIBLE notification in the response.
最後の2つのケースでは、許容できるいくつかのサブセットがある場合があります（ただし、彼らの組合はそうではありません）。この場合、応答者は任意にそれらのいずれかを選択し、応答に追加の_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.
ほとんどの実装には、各アドレスペアに個別のSASを必要とするポリシーがないと予想されるため、このドキュメントでもこのペイロードを説明しようとはしません。
Thus, if only some part (or parts) of the TSi/TSr proposed by the initiator is (are) acceptable to the responder, most responders should simply narrow TSi/TSr to an acceptable subset (as described in the last two paragraphs of Section 2.9), rather than use SINGLE_PAIR_REQUIRED.
したがって、イニシエーターによって提案されたTSI/TSRの一部（または部分）のみがレスポンダーに許容される場合、ほとんどのレスポンダーは、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では、トラフィックセレクターのネゴシエーションについて非常に詳細に説明します。いくつかの明確化が必要なこの交渉の1つの側面は、新しいSAを作成する際に、イニシエーターが独自のポリシーに違反するトラフィックセレクターを提案すべきではないということです。このルールに従わない場合、有効なトラフィックが削除される場合があります。
This is best illustrated by an example. Suppose that host A has a policy whose effect is that traffic to 192.0.1.66 is sent via host B encrypted using Advanced Encryption Standard (AES), and traffic to all other hosts in 192.0.1.0/24 is also sent via B, but encrypted using Triple Data Encryption Standard (3DES). Suppose also that host B accepts any combination of AES and 3DES.
これは、例で最もよく示されています。ホストAには、192.0.1.66へのトラフィックが高度な暗号化標準（AES）を使用して暗号化されたホストBを介して送信されるという効果があるというポリシーがあり、192.0.1.0/24の他のすべてのホストへのトラフィックもBを介して送信されますが、暗号化された暗号化トリプルデータ暗号化標準（3DES）を使用します。また、ホストBがAEと3DEの任意の組み合わせを受け入れると仮定します。
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を使用し、TSRを含む（192.0.1.0-192.0.1.0.255）を含むSAを提案するようになりました。これはホストBによって受け入れられます。現在、ホストBはこのSAを使用して192.0からトラフィックを送信できます。1.66ですが、これらのパケットは、それらのトラフィックにAEを使用する必要があるため、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のサブセットx 'のサブセットx'の提案を行うと、イニシエーターは実際にはSAでトラフィックxを受け入れません。（3）イニシエーターは、ResponderがSAまたはSA 'のいずれかをトラフィックXに適用できるため、トラフィックX（！= SA）を受け入れる意思があります。
(References: "Question about "narrowing" ..." thread, Feb 2005. "IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2 Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector negotiation examples", 2004-08-08.)
（参考文献：「絞り込み」についての質問...「スレッド、2005年2月。」「IKEV2には「ポリシー使用モード」...」スレッド、2005年2月。「IKEV2トラフィックセレクター？」スレッド、2005年2月。セレクター交渉の例」、2004-08-08。）
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.
IKEV2は、ピアが作成できるIPSEC SASの種類を決定する際に、ピア認証データベース（PAD）の情報に依存しています。このプロセスは、[RFC4301]セクション4.4.3で説明されています。ピアがいくつかのトラフィックセレクターを使用してIPSEC SAの作成を要求する場合、パッドには、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.
たとえば、パッドは、192.0.2.0/24の認証アイデンティティ「SGW23.Example.com」がIPSEC SASを作成できるように構成されている場合があります。つまり、このセキュリティゲートウェイはこれらのアドレスの有効な「代表」です。ホストツーホストIPSECには、例えば「Fooserver4.example.com」を192.0.1.66/32にリンクする同様のエントリが必要です。これは、このIDは、問題の住所の有効な「所有者」または「代表」です。
As noted in [RFC4301], "It is necessary to impose these constraints on creation of child SAs to prevent an authenticated peer from spoofing IDs associated with other, legitimate peers." In the example given above, a correct configuration of the PAD prevents sgw23 from creating IPsec SAs with address 192.0.1.66 and prevents fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24.
[RFC4301]に記載されているように、「認証されたピアが他の正当なピアに関連付けられたスプーフィングIDを防ぐために、子SASの作成にこれらの制約を課す必要があります。」上記の例では、PADの正しい構成により、SGW23はアドレス192.0.1.66のIPSEC SASの作成を防ぎ、Fooserver4が192.0.2.0/24のアドレスを持つIPSEC SASの作成を防ぎます。
It is important to note that simply sending IKEv2 packets using some particular address does not imply a permission to create IPsec SAs with that address in the traffic selectors. For example, even if sgw23 would be able to spoof its IP address as 192.0.1.66, it could not create IPsec SAs matching fooserver4's traffic.
特定のアドレスを使用してIKEV2パケットを送信するだけでは、トラフィックセレクターにそのアドレスを使用してIPSEC SASを作成する許可を意味するものではないことに注意することが重要です。たとえば、SGW23が192.0.1.66としてIPアドレスを吸うことができたとしても、Fooserver4のトラフィックを一致させるIPSEC SASを作成できませんでした。
The IKEv2 specification does not specify how exactly IP address assignment using configuration payloads interacts with the PAD. Our interpretation is that when a security gateway assigns an address using configuration payloads, it also creates a temporary PAD entry linking the authenticated peer identity and the newly allocated inner address.
IKEV2仕様は、構成ペイロードを使用したIPアドレスの割り当てがパッドと対話する方法を正確に指定していません。私たちの解釈は、セキュリティゲートウェイが構成ペイロードを使用してアドレスを割り当てると、認証されたピアアイデンティティと新しく割り当てられた内部アドレスをリンクする一時的なパッドエントリも作成するということです。
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.
一部の環境では、パッドを正しく構成することが難しい場合があることが認識されています。たとえば、アドレスが動的ホスト構成プロトコル（DHCP）を使用して動的に割り当てられるホストのペア間でIPSecが使用される場合、各IPアドレスの正しい「所有者」をパッドが指定することを保証することは非常に困難です。これには、DHCPサーバーからアドレス割り当てを安全に伝え、IKEV2を使用して認証されたアイデンティティにリンクするメカニズムが必要です。
Due to this limitation, some vendors have been known to configure their PADs to allow an authenticated peer to create IPsec SAs with traffic selectors containing the same address that was used for the IKEv2 packets. In environments where IP spoofing is possible (i.e., almost everywhere) this essentially allows any peer to create IPsec SAs with any traffic selectors. This is not an appropriate or secure configuration in most circumstances. See [Aura05] for an extensive discussion about this issue, and the limitations of host-to-host IPsec in general.
この制限により、一部のベンダーは、IKEV2パケットに使用された同じアドレスを含むトラフィックセレクターを使用して、認証されたピアがIPSEC SASを作成できるようにパッドを構成することが知られています。IPスプーフィングが可能な環境（つまり、ほぼすべての場所）では、これにより、ピアがトラフィックセレクターを使用してIPSEC SASを作成することができます。これは、ほとんどの状況では適切または安全な構成ではありません。この問題についての広範な議論、および一般的なホストからホストへの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
new-1.3.2 create_child_sa Exchangeで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ペイロードのNonCE、およびOptionalがKEIペイロードにDiffie-Hellman値を送信します。
The CREATE_CHILD_SA response for rekeying an IKE_SA is:
IKE_SAを再キーするためのcreate_child_sa応答は次のとおりです。
<-- HDR, SK {SA, Nr, [KEr]}
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ペイロードのdiffie-hellman値を使用して（同じメッセージ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
new-1.3.3 create_child_sa Exchangeで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.
タイプReke_SAの主要な通知のペイロードは、cild_saが再キーにされていることを識別し、開始者がインバウンドパケットのヘッダーに期待するSPIが含まれています。さらに、イニシエーターは、SAペイロードのSAオファー、NIペイロードの非CE、オプションでKEIペイロードのdiffie-hellman値、およびTSIおよびTSRペイロードで提案されたトラフィックセレクターを送信します。リクエストには、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.
Responderは、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に送信されるトラフィックセレクターは、応答の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には、再認可に対する特別なサポートはありません。再認証は、ゼロから新しいIKE_SAを作成することによって行われます（REKEY_SAがペイロードを通知することなく、IKE_SA_INIT/IKE_AUTH交換を使用して）、新しいIKE_SA内の新しいCHILD_SAを作成し（REKEY_SAがペイロードを通知する）、最終的に古いIKE_SA（古い子どものDELETES）をデレットすることによって行われます。同じように）。
This means that reauthentication also establishes new keys for the IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed more often than reauthentication, the situation where "authentication lifetime" is shorter than "key lifetime" does not make sense.
これは、IKE_SAとChild_Sasの新しいキーも確立することを意味します。したがって、再認可よりも頻繁に再キーリングすることができますが、「認証寿命」が「キーライフタイム」よりも短い状況は意味がありません。
While creation of a new IKE_SA can be initiated by either party (initiator or responder in the original IKE_SA), the use of EAP authentication and/or configuration payloads means in practice that reauthentication has to be initiated by the same party as the original IKE_SA. IKEv2 base specification does not allow the responder to request reauthentication in this case; however, this functionality is added in [ReAuth].
新しいIKE_SAの作成は、いずれかの当事者（元のIKE_SAのイニシエーターまたはレスポンダー）によって開始できますが、EAP認証および/または構成ペイロードの使用は、実際には元のIKE_SAと同じパーティによって再認可を開始する必要があることを意味します。IKEV2ベース仕様では、この場合は応答者が再認可を要求することはできません。ただし、この機能は[Reauth]に追加されています。
(References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)
（参照：「IKEV2の再認証」スレッド、2004年10月/11月。）
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フィールドに提供されている」と述べています。これは、IKEヘッダーのSPIフィールドではなく、セキュリティ協会（SA）ペイロード内の提案構造のSPIフィールドを指します。
(References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24. Geoffrey Huang's reply, 2005-01-24.)
（参考文献：Tom Stiemerlingのメール「Rekey Ike SA」、2005-01-24。GeoffreyHuangの返信、2005-01-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).
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は、「新しいIKE_SAのSKEYSEEDは、既存のIKE_SAのSK_Dを使用して次のように計算されます。
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"
If the old and new IKE_SA selected a different PRF, it is not totally clear which PRF should be used.
古いIKE_SAと新しい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.
IKEV2仕様では、SASの「閉鎖」と「削除」について説明していますが、正確に何を意味するのかは常に明確ではありません。ただし、仕様の他の部分では、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 SASが常にペアで存在し、各方向に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." 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.
セクション1.4では、情報交換を使用してSAペアを削除する方法について説明します。削除されます。受信者は、指定されたSASを閉じる必要があります。」「1つ以上の削除ペイロード」フレーズは、いくらかの混乱を引き起こしました。SAの双方の削除ペイロードを1つのメッセージで送信することはありません。同時に削除する多くの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.)
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." 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.
(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：ペイロードの削除における無効なSPI」スレッド、2005年12月/ 2006年1月。「交換衝突の問題」スレッド、2005年12月。
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).
「2つの目的が同じ生涯のポリシーを持っている場合、両方が同時に再キーを開始する可能性があります（これは冗長なSASにつながります）。これが起こる可能性を減らすために、リクエストのタイミングをジッタにする必要があります（再キーイングの必要性が発生した後、ランダムな時間によって遅れます）。
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を介して着信パケットを受け入れる必要があります。このような衝突で冗長なSASが作成された場合、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には、SPIS（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は同時に再キーイングが行われていることを知っています。ただし、どの交換が最も低いものを持っているかはまだわからないため、状況に注意して通常どおりに対応するだけです。
send resp2: SA(..,SPIa3,..),Nr1,.. -->
--> recv req1
Now B also knows that simultaneous rekeying is going on. Similarly as host A, it has to respond as usual.
今、Bは同時に再キーイングが続いていることも知っています。同様にホストAと同様に、通常どおり応答する必要があります。
<-- send resp1: SA(..,SPIb3,..),Nr2,..
recv resp1 <--
--> recv resp2
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は、Noncesを比較できるようになりました。最低のノンセがメッセージresp2でNR1であったと仮定します。この場合、B（Req2の送信者）は冗長な新しいSAを削除し、A（生き残った再キー付きSAを開始したノード）は古いものを削除します。
send req3: D(SPIa1) -->
<-- send req4: D(SPIb2)
--> recv req3
<-- send resp4: D(SPIb1)
recv req4 <--
send resp4: D(SPIa3) -->
The rekeying is now finished.
再キーイングが終了しました。
However, there is a second possible sequence of events that can happen if some packets are lost in the network, resulting in retransmissions. The rekeying begins as usual, but A's first packet (req1) is lost.
ただし、ネットワークで一部のパケットが失われた場合に発生する可能性のあるイベントの2番目のシーケンスがあり、その結果、再送信が行われます。再キーイングはいつものように始まりますが、Aの最初のパケット（REQ1）は失われます。
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
What should B do in this point? To B, it looks like A is trying to rekey an SA that no longer exists; thus failing the request with something non-fatal such as NO_PROPOSAL_CHOSEN seems like a reasonable approach.
この点でBは何をすべきですか？Bにとって、Aはもはや存在しないSAを再キーにしようとしているようです。したがって、no_proposal_chosenなどの非致命的なものでリクエストに失敗すると、合理的なアプローチのように思えます。
<-- send 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.
このエラーを受信すると、同時に再キーリングがあったことがすでにわかっているため、エラーメッセージを無視できます。
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交換の後、AとBの間に3つのIKE_SAが存在します。最低の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を閉じるリクエストを見ています。いつものように返信する以上のことはありません。ただし、この時点でホストBはReq2の再送信を停止するはずです。ホストAがRESP3を受信すると、古い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がHost Bが現在再キーリングしているSAを閉じようとしていることに気付きます。いつものように返信することはおそらく最良の選択です：
<-- send 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が到着する順序に応じて、Host Aは、現在閉鎖されているSAを再キーするためのリクエストか、存在しないSAを再キーするリクエストのいずれかを確認します。どちらの場合も、no_proposal_chosenはおそらく問題ありません。
recv req2
recv resp1
send 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.
提案されているもう1つのソリューションは、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 <--
To host A, this looks like a request to rekey an SA that does not exist. Like in the simultaneous rekeying case, replying with NO_PROPOSAL_CHOSEN is probably reasonable:
Aをホストするために、これは存在しないSAを再キーするリクエストのように見えます。同時に再キーキングケースのように、no_proposal_chosenで返信することはおそらく合理的です。
send resp2: N(NO_PROPOSAL_CHOSEN) -->
recv resp1
Another set of cases occurs when one peer starts rekeying the IKE_SA at the same time the other peer starts creating, rekeying, or closing a CHILD_SA. Suppose that host B starts creating a CHILD_SA, and soon after, host A starts rekeying the IKE_SA:
1つのピアがIKE_SAの再キーを開始すると同時に、もう1つのピアがChild_Saの作成、再キーリング、または閉鎖を開始すると同時に、別のケースセットが発生します。ホストBがchild_saの作成を開始し、すぐに、ホストAがike_saの再キーイングを開始すると仮定します。
Host A Host B
-------- --------
<-- send req1: SA,Ni1,TSi,TSr
send req2: SA,Ni2,.. -->
--> recv req2
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
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 CHILD_SA to the new IKE_SA as usual, and the state information will then be out of sync.
現在、問題が発生します。ホストBが通常の情報応答で通常応答した場合、これによりホストAがIKE_SAに関連付けられた状態を削除します。これは、ホストBがReq1の再送信を停止することを意味します。ただし、ホストBは、ホストAがReq1を受信したかどうかを知ることができません。ホストAがそれを受け取った場合、それは通常どおりChild_Saを新しいIKE_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: ()
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ペア：いつものように返信しますが、Noncesに基づいて後で冗長なSASを閉じる準備をします。
o a CHILD_SA pair that does not exist: reply with NO_PROPOSAL_CHOSEN.
o 存在しない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.
o IKE_SA、およびホストは現在IKE_SA：通常どおり返信していますが、冗長なSASを閉じて継承されたChild_SASを閉鎖して、Noncesに基づいて後で移動する準備をしています。
o the IKE_SA, and the host is currently creating, rekeying, or closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.
o IKE_SA、およびホストは現在、CHILD_SA：NO_PROPOSAL_CHOSENを使用して作成、再キーリング、または閉鎖しています。
o the IKE_SA, and the host is currently trying to close the IKE_SA: reply with NO_PROPOSAL_CHOSEN.
o IKE_SA、およびホストは現在、IKE_SA：NO_PROPOSAL_CHOSENで返信しようとしています。
If a host receives a request to close:
ホストが閉じるリクエストを受け取った場合：
o a CHILD_SA pair that the host is currently trying to close: reply without Delete payloads.
o ホストが現在閉じようとしているchild_saペア：ペイロードを削除せずに返信します。
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.
o 存在しないchild_saペア：ペイロードを削除せずに返信します。
o the IKE_SA, and the host is currently rekeying the IKE_SA: reply as usual, and forget about our own rekeying request.
o IKE_SA、およびホストは現在、IKE_SA：通常どおり返信して、私たち自身の再キーイングリクエストを忘れています。
o the IKE_SA, and the host is currently trying to close the IKE_SA: reply as usual, and forget about our own close request.
o IKE_SA、およびホストは現在、IKE_SA：通常どおり返信を閉じようとしています。
If a host receives a request to create or rekey a CHILD_SA when it is currently rekeying the IKE_SA: reply with NO_ADDITIONAL_SAS.
ホストが現在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 Exchangeを行うことが必須であるかどうかは混乱がありました。
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 the D-H transform is mandatory: although including the transform is mandatory, it can contain the value "NONE".
このケースは、IKEV2仕様によって許可されているようです。セクション2.18は、括弧内のdiffie-hellman項（g^ir）を示しています。セクション3.3.3は、D-H変換を含めることが必須であると言われている場合、これと矛盾しません。変換を含めることは必須ですが、値「なし」を含めることができます。
However, having the option to skip the Diffie-Hellman exchange when rekeying the IKE_SA does not add useful functionality to the protocol. The main purpose of rekeying the IKE_SA is to ensure that the compromise of old keying material does not provide information about the current keys, or vice versa. This requires performing the Diffie-Hellman exchange when rekeying. Furthermore, it is likely that this option would have been removed from the protocol as unnecessary complexity had it been discussed earlier.
ただし、IKE_SAを再キーするときにDiffie-Hellman Exchangeをスキップするオプションを持つことは、プロトコルに有用な機能を追加しません。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 Exchangeを実行する必要があるハードコード化されたポリシーがあることをお勧めします。言い換えれば、イニシエーターはD-H変換の値「なし」を提案すべきではなく、レスポンダーはそのような提案を受け入れるべきではありません。また、このポリシーは、IKE_SAを再ケイする成功した交換には常にKEI/KERペイロードが含まれていることを意味します。
(References: "Rekeying IKE_SAs with the CREATE_CHILD_SA exhange" thread, Oct 2005. "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt" thread, Apr 2005.)
（参照：「create_child_sa exhangeでike_sasをrekeing」スレッド、2005年10月。
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ペイロード自体は、イニシエーターのInitiatorの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.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)".
したがって、クライアントが特定のアドレスを要求しない場合、全ゼロアドレスを含む属性ではなく、ゼロの長さの内部_IP4/IP6_Address属性が含まれます。したがって、2.19の例は、属性を「internal_address（0.0.0.0）」と表示するため、間違っています。
However, since the value is only a suggestion, implementations are recommended to ignore suggestions they do not accept; or in other words, to treat the same way a zero-length INTERNAL_IP4_ADDRESS, "0.0.0.0", and any other addresses the implementation does not recognize as a reasonable suggestion.
ただし、値は提案にすぎないため、受け入れない提案を無視するために実装が推奨されます。または、言い換えれば、ゼロの長さの内部_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を「このエッジデバイスが保護する保護されたサブネットワーク。この属性は2つのフィールドで構成されています。1つ目はIPアドレスで、2番目はネットマスクです。複数のサブネットワークは要求される場合があります。。レスポンダーは、ゼロ以上のサブネットワーク属性で応答する場合があります。」internal_ip6_subnetも同様の方法で定義されています。
This raises two questions: first, since this information is usually included in the TSr payload, what functionality does this attribute add? And second, what does this attribute mean in CFG_REQUESTs?
これは2つの疑問を提起します。最初に、この情報は通常TSRペイロードに含まれているため、この属性はどの機能を追加しますか？第二に、この属性はCFG_REQUESTSで何を意味しますか？
For the first question, there seem to be two sensible interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA response) indicates which subnets are accessible through the SA that was just created.
最初の質問では、2つの賢明な解釈があるようです。明らかにTSR（IKE_AUTHまたはCREATE_CHILD_SA応答）は、作成されたばかりの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が必要な追加のサブネットを示していることです。この解釈によれば、内部_IP4/6_SUBNET属性は、主にTSRに含まれていないアドレスが含まれている場合に役立ちます。
The second interpretation is that the INTERNAL_IP4/6_SUBNET attributes express the gateway's policy about what traffic should be sent through the gateway. The client can choose whether other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent through the gateway or directly to the destination. According to this interpretation, the attributes are useful mainly when TSr contains addresses not included in the INTERNAL_IP4/6_SUBNET attributes.
2番目の解釈は、internal_ip4/6_subnet属性が、ゲートウェイを介して送信されるトラフィックに関するゲートウェイのポリシーを表していることです。クライアントは、他のトラフィック（TSRでカバーされているが、内部_IP4/6_Subnetではなく）をゲートウェイから直接送信するか、宛先に送信できるかどうかを選択できます。この解釈によれば、属性は、主にTSRに内部_IP4/6_SUBNET属性に含まれていないアドレスが含まれている場合に役立ちます。
It turns out that these two interpretations are not incompatible, but rather two sides of the same principle: traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via this gateway. If there are no existing IPsec SAs whose traffic selectors cover the address in question, new SAs have to be created.
これらの2つの解釈は互換性がないのではなく、同じ原則の2つの側面です。内部_IP4/6_SUBNET属性にリストされているアドレスへのトラフィックは、このゲートウェイを介して送信する必要があります。トラフィックセレクターが問題のアドレスをカバーする既存のIPSEC SASがない場合、新しいSASを作成する必要があります。
A couple of examples are given below. For instance, if there are two subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request contains the following:
いくつかの例を以下に示します。たとえば、192.0.1.0/26と192.0.2.0/24の2つのサブネットがある場合、クライアントのリクエストには以下が含まれています。
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)
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.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)
This would mean that the client can send all its traffic through the gateway, but the gateway does not mind if the client sends traffic not included by INTERNAL_IP4_SUBNET directly to the destination (without going through the gateway).
これは、クライアントがゲートウェイを介してすべてのトラフィックを送信できることを意味しますが、ゲートウェイは、クライアントがinternal_ip4_subnetに含まれていないトラフィックを宛先に直接送信しないかどうかを気にしません（ゲートウェイを通過せずに）。
A different situation arises if the gateway has a policy that requires the traffic for the two subnets to be carried in separate SAs. Then a response like this would indicate to the client that if it wants access to the second subnet, it needs to create a separate SA:
ゲートウェイに、2つのサブネットを別々のSASで携帯するためのトラフィックを要求するポリシーがある場合、別の状況が生じます。次に、このような応答は、2番目のサブネットへのアクセスを望む場合、別のSAを作成する必要があることをクライアントに示します。
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)
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:
内部_IP4_Subnetは、クライアントのTSRにアドレス空間の一部のみを含めた場合にも役立ちます。たとえば、クライアントが以下を要求した場合：
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で属性が何を意味するのか、そしてゼロ以外の長さがこの状況で意味があるかどうかはあまり明確ではありません（ただし、内部_IP6_Subnetでは、ゼロの長さはまったく許可されません！）。このドキュメントでは、実装には、CFG_REQUESTSのinternal_ip4_subnetまたはinternal_ip6_subnet属性を含めるべきではないことが推奨されます。
For the IPv4 case, this document recommends using only netmasks consisting of some amount of "1" bits followed by "0" bits; for instance, "255.0.255.0" would not be a valid netmask for 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ブロックのアドレスを使用して大規模な企業イントラネットにアクセスできるゲートウェイは、イントラネットに数百のルーターと個別のリンクがある場合でも、単一の内部_IP4_SUBNET属性（10.0.0/255.0.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のメール「IKEV2の構成ペイロードにおけるいくつかの属性の意図」、2004-11-19。SrinivasaRaoAddepalliのメール「Internal_ip4_subnet and Internal_ip6_subnet in ikev2」、2004-09-10。New I-D：IKEV2の明確化と実装ガイドライン」、2005-02-07。
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は、内部_IP4_NETMASK属性を定義し、「内部ネットワークのネットマスク。リクエストと返信メッセージ（例：255.255.255.0）で1つのネットマスクのみが許可されており、内部_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.
可能な解釈の1つは、ホストに単一のアドレスの代わりにIPアドレスのブロック全体が与えられることです。これはまた、[RADIUS]でフレーム化されたIP-NetMaskが行うもの、IPCP「サブネットマスク」拡張機能がPPP [IPCPSUBNET]で行うもの、および[RADIUS6]ではIPv6 Framed-IPv6-Prefix属性のプレフィックスの長さも行うものです。ただし、仕様の何もこの解釈をサポートしておらず、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は、同じ情報を含む内部_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では、最小限の実装では内部_IP4_NETMASK属性を含めるか理解する必要はないことを明確に述べているため、このドキュメントでは、実装が内部_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-05-27。TeroKivinenとの電子メールディスカッション、2005年1月。-02-07。 "clarifications open Issue：internal_ip4_subnet/netmask"スレッド、2005年。）
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:
クライアントは、内部_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)
In particular, IPv6 stateless autoconfiguration or router advertisement messages are not used; neither is neighbor discovery.
特に、IPv6 Stateless AutoconfigurationまたはRouter Advertisementメッセージは使用されていません。隣人の発見もありません。
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ケースの内部_IP4_NETMASK属性に対応します（実際、IKEV2ドラフトの以前のバージョンでは内部_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トンネルは、IPv6アドレス指定アーキテクチャ[IPv6Addr]センスで完全に機能する「インターフェイス」ではありません。特に、それらは必ずしもリンクローカルアドレスを持っているわけではなく、これは[MLDV2]などのそれらを想定するプロトコルの使用を複雑にする可能性があります。（特定のオペレーティングシステムで「インターフェイス」と呼ばれるかどうかは、別の問題です。）
(References: "VPN remote host configuration IPv6 ?" thread, May 2004. "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
（参照：「VPNリモートホスト構成IPv6？」スレッド、2004年5月。
Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending the IPv6 address of NetBIOS name servers.
セクション3.15.1は、NetBIOS名サーバーのIPv6アドレスを送信するための内部_IP6_NBNS属性を定義しています。
However, NetBIOS is not defined for IPv6 and probably never will be. Thus, this attribute most likely does not make much sense.
ただし、netBiosはIPv6で定義されておらず、おそらく決して定義されません。したがって、この属性はほとんど意味がありません。
(Pointed out by Bernard Aboba in the IP Configuration Security (ICOS) BoF at IETF62.)
（IETF62のIP構成セキュリティ（ICOS）BOFでBernard 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."
セクション3.15.1では、内部_Address_Expiry属性を「ホストが内部IPアドレスを使用できる秒数を指定します。ホストは、この有効期限の前にIPアドレスを更新する必要があります。これらの属性の1つだけが返信に存在する可能性があります。」
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では、更新のサポートは必須ではないと述べています。通常、この機能が必要ではないことを考えると、Gatewaysは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のメール「ドラフトエロネン-Ipsec-yikev2-clarifations-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.
Responderがイニシエーターに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.
2番目のケースは、レスポンダーが構成ペイロードをサポートする場合ですが、特定のタイプのアドレス（IPv4またはIPv6）に対してのみです。セクション4では、「最小限のIPv4レスポンダーの実装は、内部_IP4_Address属性が含まれていると判断する場合を除き、CPペイロードの内容を無視します」と述べています。たとえば、イニシエーターにCFG_REQUESTに内部_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.
3番目のケースは、イニシエーターが応答者がサポートするタイプの複数のアドレスを要求する場合です。リクエストの一部（すべてではない）が失敗した場合はどうなりますか？ここでは、楽観的なアプローチが最良のアプローチであるように思われます。応答者が少なくとも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アイデンティティタイプを使用する場合、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]では、実装がID_IPV4_ADDR/ID_IPV6_ADDRのアドレスをIKEパケットのIPヘッダーのアドレスと比較できる必要があり、この比較をデフォルトで有効にする必要があります。
(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.)
（参照：「IDタイプIPアドレス、FQDN/ユーザーFQDNおよびDNおよびその使用法とその使用法でのキー認証 "スレッド、2005年1月。" 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]が必要であることを明確にする仕様には、いくつかの要件があります。言い換えれば、[RFC2401]に従って厳密に処理するIPSEC処理を行う実装は、IKEV2仕様に準拠することはできません。
One such example can be found in Section 2.24: "Specifically, tunnel encapsulators and decapsulators for all tunnel-mode SAs created by IKEv2 [...] MUST implement the tunnel encapsulation and decapsulation processing specified in [RFC4301] to prevent discarding of ECN congestion indications."
そのような例の1つは、セクション2.24にあります。「具体的には、IKEV2 [...]によって作成されたすべてのトンネルモードSAのトンネルカプセル因子とデカプセーター[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を再キーすると、新しいIKE_SAは、新しいset_window_size通知を送信することにより、明示的に増加するまでウィンドウサイズ1で開始します。
(References: Tero Kivinen's mail "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
（参考文献：Tero Kivinen's Mail "ドラフトエロネン-IPSEC-yikev2-clarifations-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には、「IKEV2で使用されている非筋はランダムに選択され、少なくとも128ビットである必要があり、交渉済みのPRFのキーサイズの少なくとも半分でなければなりません。」
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を選択します。この場合、非CEはすべての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.23では、メッセージ2の後にポート4500をトンネリングするためにアップグレードする方法について説明しますが、メッセージ1がポート4500で送信された場合は何をすべきかについては言いません。
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.
IKEイニシエーターは、存在する場合はこれらのペイロードを確認する必要があり、外側パケットのアドレスと一致しない場合は、UDPポート4500を介してこのIKE_SAに関連するすべての将来のIKEおよびESPパケットをトンネルする必要があります。
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仕様は、IKE_SAの外部で送信される少数の通知のために、IKEヘッダーで使用する必要があるSPI値を明確にしていません。そのような通知は明示的に情報交換ではないことに注意してください。セクション1.5では、これらが応答してはならない一方通行メッセージであることを明らかにしています。
There are two cases when such a one-way notification can be sent: INVALID_IKE_SPI and INVALID_SPI.
そのような一方通行通知を送信できる場合、2つのケースがあります：invalid_ike_spiとinvalid_spi。
In case of INVALID_IKE_SPI, the message sent is a response message, and Section 2.21 says that "If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied."
Invalid_ike_spiの場合、送信されたメッセージは応答メッセージであり、セクション2.21は「応答が送信された場合、応答は同じIke Spisとメッセージ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値はありません。また、送信されたメッセージは情報リクエストになりました。仕様の厳格な解釈では、送信者が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には、「既存のSAに関連しない通知について、ペイロードに通知するプロトコルIDフィールド」は、このフィールドをゼロとして送信し、受領時に無視する必要がある」と述べています。ただし、仕様では、どの通知が既存のSASに関連していて、どの通知が関連していないかを明確に示していません。
Since the main purpose of the Protocol ID field is to specify the type of the SPI, our interpretation is that the Protocol ID field should be non-zero only when the SPI field is non-empty.
プロトコルIDフィールドの主な目的はSPIのタイプを指定することであるため、私たちの解釈は、SPIフィールドが空でない場合にのみ、プロトコルIDフィールドがゼロではないことです。
There are currently only two notifications where this is the case: INVALID_SELECTORS and REKEY_SA.
現在、これが当てはまる2つの通知のみがあります：invalid_selectorsとreke_sa。
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月。
Many IKEv2 payloads contain fields marked as "RESERVED", mostly because IKEv1 had them, and partly because they make the pictures easier to draw. In particular, payloads in IKEv2 are not, in general, aligned to 4-octet boundaries. (Note that payloads were not aligned to 4-octet boundaries in IKEv1 either.)
多くのIKEV2ペイロードには、「予約済み」とマークされたフィールドが含まれています。これは、主にIKEV1が持っていたため、写真を描画しやすくするためです。特に、IKEV2のペイロードは、一般に、4-OCTET境界に整列していません。（Payloadsは、IKEV1の4-OCTET境界にも位置合わせされていないことに注意してください。）
(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." 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).
セクション3.3.5は、「属性を受け入れるこのドキュメントで定義されている唯一のアルゴリズムは、AESベースの暗号化、整合性、および擬似ランダム関数であり、キー幅を指定する単一の属性を必要とするものです。」これは間違っています。[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ベースのアルゴリズム（CIPHERブロックチェーン（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、キャスト、ブローフィッシュが含まれます。キー長属性が含まれていない場合、[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.
現在、IPSECの重要な数字を含む3つの異なるIANAレジストリファイルがあります：IKEV2-Registry、ISAKMP-Registry、およびIPSEC-Registry。実装者は、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 "Transform Type 1"識別子IKEV2-Registry、IKEV1フェーズ1 "暗号化アルゴリズム" IPSec-Registryの識別子、およびIKEV1フェーズ2 "IPSEC ESP変換識別子 "isakmp-registry。一部のアルゴリズムは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-REGISTRISTRYのIKEV2 "transform 3"識別子、ISAKMP-RegistryのIKEV1フェーズ2 "IPSEC AH変換識別子"、およびIKEV1フェーズ2 ESP "認証アルゴリズムセキュリティ協会属性"ISAKMP-Registryの識別子。また、IPSEC-Registryには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は[RFC4301]に基づいており、[RFC2401]の一部である「SAバンドル」は含まれていません。単一のパケットはIPSEC処理を複数回通過できますが、これらの各パスは個別のSAを使用し、パスは転送テーブルによって調整されます。IKEV2では、これらのSASのそれぞれを、個別のcreate_child_sa Exchangeを使用して作成する必要があります。したがって、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 bundles」スレッド、2005年10月。）
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を再キーした後、一部の実装ではメッセージカウンターをゼロにリセットしませんでした。1つはカウンターを2に設定し、もう1つはカウンターをまったくリセットしませんでした。
o Some implementations could only handle a single pair of traffic selectors or would only process the first pair in the proposal.
o 一部の実装は、トラフィックセレクターの1つのペアのみを処理するか、提案の最初のペアのみを処理することができます。
o Some implementations responded to a delete request by sending an empty INFORMATIONAL response and then initiated their own INFORMATIONAL exchange with the pair of SAs to delete.
o いくつかの実装は、空の情報応答を送信することにより、削除要求に応答し、その後、SASのペアと独自の情報交換を開始して削除しました。
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.
o これはBakeoffでは発生しませんでしたが、そこでの議論から、一部の人々がメッセージウィンドウサイズを正しく実装していないことは明らかです。いくつかの実装では、Responderのメッセージウィンドウに収まらないメッセージが送信された場合があり、一部の実装は、自分が持っているべきであると知っているメッセージを受け取っていない場合、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メーリングリストの会話に基づいています。著者は、特にバーナード・アボバ、ジャリ・アークコ、ヴィジェイ・デヴァラパリ、ウィリアム・ディクソン、フランシス・デュポン、アルフレッド・ホーネス、ミカ・ジュッテンヴィルタ、チャーリー・カウフマン、スティーブン・ケント、テロ・キビネン、ヨーブ・ニール、マイケル・リチャードン、ジョエル・スニーデデンのために感謝します。
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] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、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] Jonsson、J.およびB. Kaliski、「Public-Key Cryptography Standards（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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、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] Aura、T.、Roe、M。、およびA. Mohammed、「Host-to-Host Ipsecの経験」、2005年4月、英国ケンブリッジ、セキュリティプロトコルに関する第13回国際ワークショップ。
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[HashUse] Hoffman, P., "Use of Hash Algorithms in IKE and IPsec", Work in Progress, July 2006.
[Hashuse] Hoffman、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] Cisco Systems、Inc。、「IPCP Subnet Mask Support Enhancements」、http://www.cisco.com/univercd/cc/cc/td/ doc/product/software/ios121/121Newft/121Limit/121DC/121DC3/IPCP_MSKK3/IPCP_MSK.htm、2003年1月。
[IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[IPv6Addr] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[Mipv6] Johnson、D.、Perkins、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] Vida、R。およびL. Costa、「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] Korver、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. Calhoun、「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.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RADIUS6] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[Radius6] Aboba、B.、Zorn、G。、およびD. Mitton、「Radius and IPv6」、RFC 3162、2001年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、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] Hoffman、P。、「インターネットキーエクスチェンジプロトコル（IKE）のAES-XCBC-PRF-128アルゴリズム」、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.、Volpe、V.、Diburro、L。、およびM. Stenberg、「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] Hoffman、P。、「インターネットキーエクスチェンジプロトコル（IKE）のAES-XCBC-PRF-128アルゴリズム」、RFC 4434、2006年2月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", RFC 822, August 1982.
[RFC822] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、RFC 822、1982年8月。
[ReAuth] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[Reauth] Nir、Y。、「インターネットキーエクスチェンジ（IKEV2）プロトコルでの繰り返し認証」、RFC 4478、2006年4月。
[SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and T. Polk, "Simple Certificate Validation Protocol (SCVP)", Work in Progress, June 2006.
[SCVP] Freeman、T.、Housley、R.、Malpani、A.、Cooper、D。、およびT. Polk、「Simple証明書検証プロトコル（SCVP）」、2006年6月の作業。
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.
Vendor-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）を含めることができるかは示されていません。メッセージに含まれる可能性がありますが、以下にまだ表示されていません。
request --> [N(COOKIE)],
SA, KE, Ni,
[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+]
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+]
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、[cpg_reply）]、[n（ipcomp_supported）]、[n（use_transport_mode）]、[n（esp_tfc_padding_not_supported）]]、[n（non_first_fragments_also）、sa、tsi、tsr、[n（addational_ts_possible）]、[v]
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+]
first response <-- IDr, [CERT+], AUTH, EAP, [V+]
最初の応答<-idr、[cert]、auth、eap、[v]
/ --> EAP repeat 1..N times | \ <-- EAP
/ - > EAP Repeat 1..n times |\ <-EAP
last request --> 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）（Addational_ts_possible）]、[v]
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
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、
request --> SA, Ni, [KEi]
response <-- SA, Nr, [KEr]
応答<-Sa、nr、[ker]
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
Pasi Eronen Nokia Research Center P.O.Box 407 Fin-00045 Nokia Group Finland
EMail: pasi.eronen@nokia.com
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポールホフマンVPNコンソーシアム127セグレプレイスサンタクルス、カリフォルニア95060 USA
EMail: paul.hoffman@vpnc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。