[要約] RFC 7383は、IKEv2メッセージのフラグメンテーションに関する標準化されたプロトコルであり、大きなメッセージを複数の小さなフラグメントに分割することを可能にします。その目的は、ネットワーク上の制約や制限によって引き起こされるメッセージのサイズ制限を克服し、効率的な通信を実現することです。
Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 7383 ELVIS-PLUS
Category: Standards Track November 2014
ISSN: 2070-1721
Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation
インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）メッセージの断片化
Abstract
概要
This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through.
このドキュメントでは、大規模なInternet Key Exchange Protocolバージョン2（IKEv2）メッセージのIP断片化を回避する方法について説明します。これにより、IKEv2メッセージは、IPフラグメントの通過を許可しないネットワークデバイスを通過できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7383.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7383で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Problem Description ........................................2
1.2. Proposed Solution ..........................................3
1.3. Conventions Used in This Document ..........................4
2. Protocol Details ................................................4
2.1. Overview ...................................................4
2.2. Limitations ................................................4
2.3. Negotiation ................................................5
2.4. Using IKE Fragmentation ....................................5
2.5. Fragmenting Message ........................................6
2.5.1. Selecting Fragment Size .............................8
2.5.2. PMTU Discovery ......................................9
2.5.3. Fragmenting Messages Containing Unprotected
Payloads ...........................................11
2.6. Receiving IKE Fragment Message ............................11
2.6.1. Replay Detection and Retransmissions ...............13
3. Interaction with Other IKE Extensions ..........................14
4. Transport Considerations .......................................14
5. Security Considerations ........................................15
6. IANA Considerations ............................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................16
Appendix A. Design Rationale ......................................19
Appendix B. Correlation between IP Datagram Size and Encrypted
Payload Content Size ..................................19
Acknowledgements ..................................................20
Author's Address ..................................................20
The Internet Key Exchange Protocol version 2 (IKEv2), specified in [RFC7296], uses UDP as a transport for its messages. Most IKEv2 messages are relatively small, usually below several hundred bytes. A notable exception is the IKE_AUTH exchange, which requires fairly large messages, up to several KB, especially when certificates are transferred. When the IKE message size exceeds the path MTU, it gets fragmented at the IP level. The problem is that some network devices, specifically some NAT boxes, do not allow IP fragments to pass through. This apparently blocks IKE communication and, therefore, prevents peers from establishing an IPsec Security Association (SA). Section 2 of [RFC7296] discusses the impact of IP fragmentation on IKEv2 and acknowledges this problem.
[RFC7296]で指定されているInternet Key Exchange Protocolバージョン2（IKEv2）は、メッセージのトランスポートとしてUDPを使用します。ほとんどのIKEv2メッセージは比較的小さく、通常は数百バイト未満です。注目すべき例外はIKE_AUTH交換です。これは、特に証明書が転送される場合、数KBまでのかなり大きなメッセージを必要とします。 IKEメッセージのサイズがパスMTUを超えると、IPレベルでフラグメント化されます。問題は、一部のネットワークデバイス、特に一部のNATボックスがIPフラグメントの通過を許可しないことです。これは明らかにIKE通信をブロックするため、ピアがIPsec Security Association（SA）を確立するのを妨げます。 [RFC7296]のセクション2では、IPフラグメンテーションがIKEv2に与える影響について説明し、この問題を認めています。
Widespread deployment of Carrier-Grade NATs (CGNs) introduces new challenges. [RFC6888] describes requirements for CGNs. It states that CGNs must comply with Section 11 of [RFC4787], which requires NATs to support receiving IP fragments (REQ-14). In real life, fulfillment of this requirement creates an additional burden in terms of memory, especially for high-capacity devices used in CGNs. It was found by people deploying IKE that more and more ISPs use equipment that drops IP fragments, thereby violating this requirement.
Carrier-Grade NAT（CGN）の普及により、新たな課題が生じています。 [RFC6888]は、CGNの要件について説明しています。 CGNは[RFC4787]のセクション11に準拠する必要があると述べており、NATはIPフラグメントの受信をサポートする必要があります（REQ-14）実際には、この要件を満たすことで、特にCGNで使用される大容量デバイスの場合、メモリの面で追加の負担が生じます。 IKEを展開している人々が、IPフラグメントをドロップする機器を使用するISPが増えていることが判明したため、この要件に違反しています。
Security researchers have found, and continue to find, attack vectors that rely on IP fragmentation. For these reasons, and also as articulated in [FRAGDROP], many network operators filter all IPv6 fragments. Also, the default behavior of many currently deployed firewalls is to discard IPv6 fragments.
セキュリティ研究者は、IPフラグメンテーションに依存する攻撃ベクトルを発見し、発見し続けています。これらの理由から、また[FRAGDROP]で規定されているように、多くのネットワークオペレーターはすべてのIPv6フラグメントをフィルター処理します。また、現在デプロイされている多くのファイアウォールのデフォルトの動作では、IPv6フラグメントが破棄されます。
In one recent study [BLACKHOLES], two researchers utilized a measurement network to measure fragment filtering. They sent packets, fragmented to the minimum MTU of 1280, to 502 IPv6-enabled and reachable probes. They found that during any given trial period, ten percent of the probes did not receive fragmented packets.
最近の1つの研究[BLACKHOLES]では、2人の研究者が測定ネットワークを利用してフラグメントフィルタリングを測定しました。彼らは、最小MTU 1280にフラグメント化されたパケットを、502 IPv6対応の到達可能なプローブに送信しました。彼らは、特定の試行期間中、プローブの10％が断片化されたパケットを受信しなかったことを発見しました。
Thus, this problem is valid for both IPv4 and IPv6 and may be caused by either deficiency of network devices or operational choice.
したがって、この問題はIPv4とIPv6の両方に有効であり、ネットワークデバイスの不足または運用上の選択が原因である可能性があります。
The solution to the problem described in this document is to perform fragmentation of large messages by IKEv2 itself and replace them with a series of smaller messages. In this case, the resulting IP datagrams will be small enough so that no fragmentation at the IP level will take place.
このドキュメントで説明されている問題の解決策は、IKEv2自体によって大きなメッセージの断片化を実行し、それらを一連の小さなメッセージに置き換えることです。この場合、結果のIPデータグラムは十分に小さいため、IPレベルでの断片化は発生しません。
The primary goal of this solution is to allow IKEv2 to operate in environments that might block IP fragments. This goal does not assume that IP fragmentation should be avoided completely, but only in those cases when it interferes with IKE operations. However, this solution could be used to avoid IP fragmentation in all situations where fragmentation within IKE is applicable, as recommended in Section 3.2 of [RFC5405]. Avoiding IP fragmentation would be beneficial for IKEv2 in general. The Security Considerations section of [RFC7296] mentions exhaustion of the IP reassembly buffers as one of the possible attacks on the protocol. In [DOSUDPPROT], several aspects of attacks on IKE using IP fragmentation are discussed, and one of the defenses it proposes is to perform fragmentation within IKE, similar to the solution described in this document.
このソリューションの主な目的は、IPフラグメントをブロックする可能性のある環境でIKEv2が動作できるようにすることです。この目標は、IPフラグメンテーションが完全に回避されるべきであるとは想定していませんが、IKEオペレーションに干渉する場合のみです。ただし、このソリューションは、[RFC5405]のセクション3.2で推奨されているように、IKE内のフラグメンテーションが適用されるすべての状況でIPフラグメンテーションを回避するために使用できます。 IPフラグメンテーションを回避することは、IKEv2にとって一般的に有益です。 [RFC7296]のセキュリティに関する考慮事項セクションでは、プロトコルへの攻撃の可能性の1つとして、IP再構成バッファーの枯渇について言及しています。 [DOSUDPPROT]では、IPフラグメンテーションを使用したIKEへの攻撃のいくつかの側面が説明されており、提案する防御策の1つは、このドキュメントで説明されているソリューションと同様に、IKE内でフラグメンテーションを実行することです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The idea of the protocol described in this document is to split large IKEv2 messages into a set of smaller ones, called IKE Fragment messages. Fragmentation takes place before the original message is encrypted and authenticated, so that each IKE Fragment message receives individual protection. On the receiving side, IKE Fragment messages are collected, verified, decrypted, and merged together to get the original message before encryption. See Appendix A for details on design rationale.
このドキュメントで説明するプロトコルの考え方は、大きなIKEv2メッセージを、IKEフラグメントメッセージと呼ばれる小さなメッセージのセットに分割することです。フラグメンテーションは元のメッセージが暗号化および認証される前に行われるため、各IKEフラグメントメッセージは個別に保護されます。受信側では、IKEフラグメントメッセージが収集、検証、復号化、およびマージされて、暗号化前の元のメッセージが取得されます。設計根拠の詳細については、付録Aを参照してください。
Since IKE Fragment messages are cryptographically protected, SK_a and SK_e must already be calculated. In general, it means that the original message can be fragmented if and only if it contains an Encrypted payload.
IKEフラグメントメッセージは暗号で保護されているため、SK_aおよびSK_eはすでに計算されている必要があります。一般に、暗号化されたペイロードが含まれている場合にのみ、元のメッセージをフラグメント化できることを意味します。
This implies that messages of the IKE_SA_INIT exchange cannot be fragmented. In most cases, this is not a problem because IKE_SA_INIT messages are usually small enough to avoid IP fragmentation. But in some cases (advertising a badly structured long list of algorithms, using large Modular Exponentiation (MODP) groups, etc.), these messages may become fairly large and get fragmented at the IP level. In this case, the solution described in this document will not help.
これは、IKE_SA_INIT交換のメッセージをフラグメント化できないことを意味します。ほとんどの場合、IKE_SA_INITメッセージは通常、IPフラグメンテーションを回避するのに十分なほど小さいので、これは問題ではありません。ただし、場合によっては（不適切に構造化されたアルゴリズムの長いリストをアドバタイズする、大きなModular Exponentiation（MODP）グループを使用するなど）、これらのメッセージがかなり大きくなり、IPレベルで断片化されることがあります。この場合、このドキュメントで説明されているソリューションは役に立ちません。
Among existing IKEv2 extensions, messages of an IKE_SESSION_RESUME exchange, as defined in [RFC5723], cannot be fragmented either. See Section 3 for details.
既存のIKEv2拡張の中で、[RFC5723]で定義されているIKE_SESSION_RESUME交換のメッセージもフラグメント化できません。詳細については、セクション3を参照してください。
Another limitation is that the minimum size of an IP datagram bearing an IKE Fragment message is about 100 bytes, depending on the algorithms employed. According to [RFC0791], the minimum IPv4 datagram size that is guaranteed not to be further fragmented is 68 bytes. So, even the smallest IKE Fragment messages could be fragmented at the IP level in some circumstances. But such extremely small Path MTU (PMTU) sizes are very rare in real life.
もう1つの制限は、IKEフラグメントメッセージを保持するIPデータグラムの最小サイズが、使用するアルゴリズムに応じて約100バイトであることです。 [RFC0791]によると、これ以上フラグメント化されないことが保証されている最小のIPv4データグラムサイズは68バイトです。したがって、状況によっては、最小のIKEフラグメントメッセージでもIPレベルでフラグメント化される可能性があります。しかし、そのような非常に小さいパスMTU（PMTU）サイズは、実際には非常にまれです。
The initiator indicates its support for IKE fragmentation and willingness to use it by including a Notification payload of type IKEV2_FRAGMENTATION_SUPPORTED in the IKE_SA_INIT request message. If the responder also supports this extension and is willing to use it, it includes this notification in the response message.
イニシエーターは、IKE_SA_INIT要求メッセージにタイプIKEV2_FRAGMENTATION_SUPPORTEDの通知ペイロードを含めることにより、IKEフラグメンテーションのサポートとそれを使用する意思を示します。レスポンダもこの拡張機能をサポートしており、それを使用したい場合は、この通知を応答メッセージに含めます。
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni,
[N(IKEV2_FRAGMENTATION_SUPPORTED)] -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ], [N(IKEV2_FRAGMENTATION_SUPPORTED)]
<-HDR、SAr1、KEr、Nr、[CERTREQ]、[N（IKEV2_FRAGMENTATION_SUPPORTED）]
The Notify payload is formatted as follows:
Notifyペイロードの形式は次のとおりです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) - MUST be 0.
o プロトコルID（1オクテット）-0でなければなりません。
o SPI Size (1 octet) - MUST be 0, meaning no Security Parameter Index (SPI) is present.
o SPIサイズ（1オクテット）-0でなければなりません。つまり、セキュリティパラメータインデックス（SPI）は存在しません。
o Notify Message Type (2 octets) - MUST be 16430, the value assigned for the IKEV2_FRAGMENTATION_SUPPORTED notification.
o 通知メッセージタイプ（2オクテット）-IKEV2_FRAGMENTATION_SUPPORTED通知に割り当てられた値である16430である必要があります。
This notification contains no data.
この通知にはデータが含まれていません。
IKE fragmentation MUST NOT be used unless both peers have indicated their support for it. After that, it is up to the initiator of each exchange to decide whether or not to use it. The responder usually replies in the same form as the request message, but other considerations might override this.
IKEフラグメンテーションは、両方のピアがサポートを示さない限り、使用してはなりません（MUST NOT）。その後、それを使用するかどうかを決定するのは、各交換の開始側です。応答側は通常、要求メッセージと同じ形式で応答しますが、他の考慮事項がこれをオーバーライドする場合があります。
The initiator can employ various policies regarding the use of IKE fragmentation. It might first try to send an unfragmented message and resend it as fragmented only if no complete response is received even after several retransmissions. Alternatively, it might choose to always send fragmented messages (however, see Section 3), or it might fragment only large messages and messages that are expected to result in large responses.
イニシエータは、IKEフラグメンテーションの使用に関するさまざまなポリシーを使用できます。最初にフラグメント化されていないメッセージを送信し、数回の再送信の後でも完全な応答が受信されない場合にのみ、フラグメント化されたメッセージを再送信しようとします。あるいは、常に断片化されたメッセージを送信することを選択することもできます（ただし、セクション3を参照）。または、大きなメッセージと、大きな応答をもたらすと予想されるメッセージのみを断片化する場合があります。
The following general guidelines apply:
次の一般的なガイドラインが適用されます。
o If either peer has information that a part of the transaction is likely to be fragmented at the IP layer, causing interference with the IKE exchange, that peer SHOULD use IKE fragmentation. This information might be passed from a lower layer, provided by configuration, or derived through heuristics. Examples of heuristics are the lack of a complete response after several retransmissions for the initiator, and receiving repeated retransmissions of the request for the responder.
o いずれかのピアが、トランザクションの一部がIP層でフラグメント化され、IKE交換に干渉する可能性があるという情報を持っている場合、そのピアはIKEフラグメンテーションを使用する必要があります（SHOULD）。この情報は、下位層から渡されるか、構成によって提供されるか、またはヒューリスティックによって導出されます。ヒューリスティックの例としては、イニシエーターに対して数回の再送信を行った後の完全な応答の欠如、およびレスポンダーに対する要求の再送の繰り返しの受信があります。
o If either peer knows that IKE fragmentation has been used in a previous exchange in the context of the current IKE SA, that peer SHOULD continue to use IKE fragmentation for the messages that are larger than the current fragmentation threshold (see Section 2.5.1).
o いずれかのピアが、現在のIKE SAのコンテキストで以前の交換でIKEフラグメンテーションが使用されていることを知っている場合、そのピアは、現在のフラグメンテーションしきい値より大きいメッセージに対してIKEフラグメンテーションを引き続き使用する必要があります（セクション2.5.1を参照）。
o IKE fragmentation SHOULD NOT be used in cases where IP-layer fragmentation of both the request and response messages is unlikely. For example, there is no point in fragmenting liveness check messages.
o IKEメッセージの断片化は、要求メッセージと応答メッセージの両方のIP層の断片化が発生する可能性が低い場合には使用しないでください。たとえば、活性チェックメッセージをフラグメント化しても意味がありません。
o If none of the above apply, the responder SHOULD respond in the same form (fragmented or not) as the request message to which it is responding. Note that the other guidelines might override this because of information or heuristics available to the responder.
o 上記のいずれにも当てはまらない場合、レスポンダは、応答するリクエストメッセージと同じ形式（断片化されているかどうかにかかわらず）で応答する必要があります（SHOULD）。他のガイドラインは、レスポンダが利用できる情報またはヒューリスティックのためにこれを上書きする可能性があることに注意してください。
In most cases, IKE fragmentation will be used in the IKE_AUTH exchange, especially if certificates are employed.
ほとんどの場合、特に証明書が採用されている場合、IKEフラグメンテーションはIKE_AUTH交換で使用されます。
Only messages that contain an Encrypted payload are subject to IKE fragmentation. For the purpose of construction of IKE Fragment messages, the original (unencrypted) content of the Encrypted payload is split into chunks. The content is treated as a binary blob and is split regardless of the boundaries of inner payloads. Each of the resulting chunks is treated as an original content of the Encrypted Fragment payload and is then encrypted and authenticated. Thus, the Encrypted Fragment payload contains a chunk of the original content of the Encrypted payload in encrypted form. The cryptographic processing of the Encrypted Fragment payload is identical to that described in Section 3.14 of [RFC7296], as well as documents updating such processing for particular algorithms or modes, such as [RFC5282].
暗号化されたペイロードを含むメッセージのみがIKEフラグメンテーションの対象になります。 IKE Fragmentメッセージを作成する目的で、暗号化されたペイロードの元の（暗号化されていない）コンテンツがチャンクに分割されます。コンテンツはバイナリBLOBとして扱われ、内部ペイロードの境界に関係なく分割されます。結果のチャンクのそれぞれは、暗号化されたフラグメントペイロードの元のコンテンツとして扱われ、暗号化および認証されます。したがって、暗号化フラグメントペイロードには、暗号化された形式の暗号化ペイロードの元のコンテンツのチャンクが含まれています。暗号化フラグメントペイロードの暗号化処理は、[RFC7296]のセクション3.14で説明されているものと同じです。また、[RFC5282]などの特定のアルゴリズムまたはモードでそのような処理を更新するドキュメントも同じです。
As is the case for the Encrypted payload, the Encrypted Fragment payload, if present in a message, MUST be the last payload in the message.
暗号化されたペイロードの場合と同様に、暗号化されたフラグメントのペイロードは、メッセージに存在する場合、メッセージの最後のペイロードでなければなりません。
The Encrypted Fragment payload is denoted SKF{...}, and its payload type is 53. This payload is also called the "Encrypted and Authenticated Fragment" payload.
暗号化フラグメントペイロードはSKF {...}で示され、そのペイロードタイプは53です。このペイロードは、「暗号化および認証済みフラグメント」ペイロードとも呼ばれます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Number | Total Fragments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted content ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encrypted Fragment Payload
暗号化されたフラグメントペイロード
o Next Payload (1 octet) - in the very first fragment (with Fragment Number equal to 1), this field MUST be set to the payload type of the first inner payload (the same as for the Encrypted payload). In the rest of the Fragment messages (with Fragment Number greater than 1), this field MUST be set to zero.
o 次のペイロード（1オクテット）-最初のフラグメント（フラグメント番号が1に等しい）では、このフィールドを最初の内部ペイロードのペイロードタイプに設定する必要があります（暗号化されたペイロードと同じ）。残りのフラグメントメッセージ（フラグメント番号が1より大きい）では、このフィールドをゼロに設定する必要があります。
o Fragment Number (2 octets, unsigned integer) - current Fragment message number, starting from 1. This field MUST be less than or equal to the next field (Total Fragments). This field MUST NOT be zero.
o フラグメント番号（2オクテット、符号なし整数）-1から始まる現在のフラグメントメッセージ番号。このフィールドは、次のフィールド（合計フラグメント）以下でなければなりません。このフィールドはゼロであってはなりません。
o Total Fragments (2 octets, unsigned integer) - number of Fragment messages into which the original message was divided. This field MUST NOT be zero. With PMTU discovery, this field plays an additional role. See Section 2.5.2 for details.
o Total Fragments（2 octets、unsigned integer）-元のメッセージが分割されたFragmentメッセージの数。このフィールドはゼロであってはなりません。 PMTUディスカバリーでは、このフィールドは追加の役割を果たします。詳細については、セクション2.5.2を参照してください。
The other fields are identical to those specified in Section 3.14 of [RFC7296].
その他のフィールドは、[RFC7296]のセクション3.14で指定されているフィールドと同じです。
When prepending the IKE header to the IKE Fragment messages, it MUST be taken intact from the original message, except for the Length and Next Payload fields. The Length field is adjusted to reflect the length of the IKE Fragment message being constructed, and the Next Payload field is set to the payload type of the first payload in that message (in most cases, it will be the Encrypted Fragment payload). After prepending the IKE header and all payloads that possibly precede the Encrypted payload in the original message (if any; see Section 2.5.3), the resulting messages are sent to the peer.
IKEフラグメントメッセージにIKEヘッダーを付加する場合、LengthおよびNext Payloadフィールドを除いて、元のメッセージからそのまま取得する必要があります。長さフィールドは、構築されるIKEフラグメントメッセージの長さを反映するように調整され、次のペイロードフィールドは、そのメッセージの最初のペイロードのペイロードタイプに設定されます（ほとんどの場合、暗号化されたフラグメントペイロードになります）。 IKEヘッダーと、元のメッセージの暗号化されたペイロードの前にある可能性のあるすべてのペイロード（存在する場合。セクション2.5.3を参照）を付加すると、結果のメッセージがピアに送信されます。
Below is an example of fragmenting a message.
以下は、メッセージをフラグメント化する例です。
HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN}
Original Message
オリジナルメッセージ
HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...},
HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...},
...
HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...}
IKE Fragment Messages
IKEフラグメントメッセージ
When splitting the content of an Encrypted payload into chunks, the sender SHOULD choose their size so that the resulting IP datagrams will be smaller than some fragmentation threshold. Implementations may calculate the fragmentation threshold using various sources of information.
暗号化されたペイロードのコンテンツをチャンクに分割する場合、送信者はサイズを選択して、結果のIPデータグラムが断片化のしきい値より小さくなるようにする必要があります（SHOULD）。実装では、さまざまな情報源を使用して断片化のしきい値を計算できます。
If the sender has information about the PMTU size, it SHOULD use it. The responder in the exchange may use the maximum size of the received IKE Fragment message IP datagrams as a threshold when constructing a fragmented response. Successful completion of previous exchanges (including those exchanges that cannot employ IKE fragmentation, e.g., IKE_SA_INIT) may be an indication that the fragmentation threshold can be set to the size of the largest message of those messages already sent.
送信者がPMTUサイズに関する情報を持っている場合は、それを使用する必要があります（SHOULD）。交換のレスポンダは、フラグメント化された応答を構築するときに、受信したIKEフラグメントメッセージIPデータグラムの最大サイズをしきい値として使用できます。以前の交換（IKEフラグメンテーションを使用できない交換（IKE_SA_INITなど）を含む）が正常に完了すると、フラグメンテーションしきい値を、すでに送信されたメッセージの最大メッセージのサイズに設定できることを示している可能性があります。
Otherwise, for messages to be sent over IPv6, it is RECOMMENDED that a value of 1280 bytes as a maximum IP datagram size be used ([RFC2460]). For messages to be sent over IPv4, it is RECOMMENDED that a value of 576 bytes as a maximum IP datagram size be used. The presence of tunnels on the path may reduce these values. Implementations may use other values if they are appropriate in the current environment.
それ以外の場合、IPv6を介して送信されるメッセージの場合、最大IPデータグラムサイズとして1280バイトの値を使用することをお勧めします（[RFC2460]）。 IPv4を介して送信されるメッセージの場合、最大IPデータグラムサイズとして576バイトの値を使用することをお勧めします。パスにトンネルが存在すると、これらの値が減少する可能性があります。実装は、現在の環境で適切であれば、他の値を使用できます。
According to [RFC0791], the minimum IPv4 datagram size that is guaranteed not to be further fragmented is 68 bytes, but it is generally impossible to use such a small value for the solution described in this document. Using 576 bytes is a compromise -- the value is large enough for the presented solution and small enough to avoid IP fragmentation in most situations. Several other UDP-based protocols (Syslog, DNS, etc.) use 576 bytes as a safe low limit for IP datagram size.
[RFC0791]によれば、これ以上フラグメント化されないことが保証されているIPv4データグラムの最小サイズは68バイトですが、このドキュメントで説明されているソリューションにこのような小さな値を使用することは一般に不可能です。 576バイトの使用は妥協案です。この値は、提示されたソリューションには十分な大きさであり、ほとんどの状況でIPフラグメンテーションを回避するのに十分なほど小さくなっています。他のいくつかのUDPベースのプロトコル（Syslog、DNSなど）は、IPデータグラムサイズの安全な下限として576バイトを使用します。
See Appendix B for correlation between IP datagram size and Encrypted payload content size.
IPデータグラムサイズと暗号化されたペイロードコンテンツサイズの相関については、付録Bを参照してください。
The amount of traffic that the IKE endpoint produces during the lifetime of an IKE SA is fairly modest -- it is usually below 100 KB within a period of several hours. Most of this traffic consists of relatively short messages -- usually below several hundred bytes. In most cases, the only time when IKE endpoints exchange messages of several KB in size is IKE SA establishment, and often each endpoint sends exactly one such message.
IKE SAのライフタイム中にIKEエンドポイントが生成するトラフィックの量はかなり少なく、通常、数時間で100 KB未満になります。このトラフィックのほとんどは、比較的短いメッセージ（通常は数百バイト未満）で構成されています。ほとんどの場合、IKEエンドポイントが数KBのサイズのメッセージを交換する唯一の時間はIKE SAの確立であり、多くの場合、各エンドポイントはそのようなメッセージを1つだけ送信します。
For the reasons articulated above, implementing PMTU discovery in IKE is OPTIONAL. It is believed that using the values recommended in Section 2.5.1 as a fragmentation threshold will be sufficient in most cases. Using these values could lead to suboptimal fragmentation, but it is acceptable given the amount of traffic IKE produces. Implementations may support PMTU discovery if there are good reasons to do it (for example, if they are intended to be used in environments where the MTU size might be less than the values listed in Section 2.5.1).
上記の理由により、IKEでのPMTU検出の実装はオプションです。ほとんどの場合、断片化のしきい値としてセクション2.5.1で推奨されている値を使用すれば十分であると考えられています。これらの値を使用すると、断片化が最適化されない可能性がありますが、IKEが生成するトラフィックの量を考慮すると許容範囲です。実装は、正当な理由がある場合（たとえば、MTUサイズがセクション2.5.1に記載されている値よりも小さい可能性がある環境での使用を意図している場合）、PMTU検出をサポートする場合があります。
PMTU discovery in IKE follows recommendations given in Section 10.4 of [RFC4821] with some modifications, induced by the distinctive features of IKE listed above. The difference is that the PMTU search is performed downward, while in [RFC4821] it is performed upward. The reason for this change is that IKE usually sends large messages only when the IKE SA is being established, and in many cases there is only one such message. If the probing were performed upward, this message would be fragmented using the smallest allowable threshold, and usually all other messages are small enough to avoid IP fragmentation, so continued probing would be of little value.
IKEでのPMTUの検出は、[RFC4821]のセクション10.4に示されている推奨事項に従い、上記のIKEの特徴的な機能によっていくつかの変更が加えられています。違いは、PMTU検索が下向きに実行されるのに対し、[RFC4821]では上向きに実行されることです。この変更の理由は、IKEは通常、IKE SAが確立されているときにのみ大きなメッセージを送信し、多くの場合、そのようなメッセージは1つしかないためです。プローブが上方に実行された場合、このメッセージは最小許容しきい値を使用してフラグメント化されます。通常、他のすべてのメッセージはIPフラグメンテーションを回避するのに十分小さいので、プローブを継続してもほとんど意味がありません。
It is the initiator of the exchange who performs PMTU discovery. This is done by probing several values of fragmentation threshold. Implementations MUST be prepared to probe in every exchange that utilizes IKE fragmentation to deal with possible changes in path MTU over time. While doing probes, it MUST start from larger values and refragment the original message, using the next smaller value of the threshold if it did not receive a response in a reasonable time after several retransmissions. The exact number of retransmissions and length of timeouts are not covered in this specification because they do not affect interoperability. However, the timeout interval is supposed to be relatively short, so that unsuccessful probes would not delay IKE operations too much. Performing a few retries within several seconds for each probe seems appropriate, but different environments may require different rules. When starting a new probe, the node MUST reset its retransmission timers so that if it employs exponential back-off the timers will start over. After reaching the smallest allowed value for the fragmentation threshold, an implementation MUST continue retransmitting until the exchange either completes or times out using some timeout interval as discussed in Section 2.4 of [RFC7296].
PMTUディスカバリーを実行するのは、交換の開始者です。これは、断片化しきい値のいくつかの値を調べることによって行われます。実装は、時間の経過に伴うパスMTUの変化の可能性に対処するためにIKEフラグメンテーションを利用するすべての交換を調査するように準備する必要があります。プローブを実行している間、数回の再送信後、妥当な時間内に応答を受信しなかった場合は、大きい値から開始して元のメッセージを再断片化し、しきい値の次に小さい値を使用する必要があります。再送信の正確な数とタイムアウトの長さは相互運用性に影響を与えないため、この仕様では説明していません。ただし、タイムアウト間隔は比較的短いと想定されているため、プローブが失敗してもIKE操作の遅延はそれほど長くなりません。各プローブに対して数秒以内に数回の再試行を実行することは適切と思われますが、環境が異なると異なるルールが必要になる場合があります。新しいプローブを開始するとき、ノードは再送信タイマーをリセットする必要があるため、指数バックオフを使用する場合、タイマーは最初からやり直します。 [RFC7296]のセクション2.4で説明されているように、実装は断片化しきい値の最小許容値に達した後、交換が完了するか、タイムアウト間隔を使用してタイムアウトになるまで再送信を継続する必要があります。
PMTU discovery in IKE is supposed to be coarse-grained, i.e., it is expected that a node will try only a few fragmentation thresholds in order to minimize delays caused by unsuccessful probes. If path MTU information is not yet available, the endpoint may use the link MTU size when it starts probing. In subsequent exchanges, the node should start with the current value of the fragmentation threshold.
IKEでのPMTUの検出は大まかなものであると想定されています。つまり、ノードは、プローブの失敗による遅延を最小限に抑えるために、いくつかの断片化しきい値のみを試すことが予想されます。パスMTU情報がまだ利用できない場合、エンドポイントはプローブを開始するときにリンクMTUサイズを使用する可能性があります。以降の交換では、ノードはフラグメンテーションしきい値の現在の値から開始する必要があります。
If an implementation is capable of receiving ICMP error messages, it can additionally utilize classic PMTU discovery methods, as described in [RFC1191] and [RFC1981]. In particular, if the initiator receives a Packet Too Big error in response to the probe, and it contains a smaller value than the current fragmentation threshold, then the initiator SHOULD stop retransmitting the probe and SHOULD select a new value for the fragmentation threshold that is less than or equal to the value from the ICMP message and meets the requirements listed below.
実装がICMPエラーメッセージを受信できる場合、[RFC1191]および[RFC1981]で説明されているように、従来のPMTU検出方法をさらに利用できます。特に、イニシエーターがプローブに応答してパケットが大きすぎるエラーを受信し、現在の断片化しきい値よりも小さい値が含まれている場合、イニシエーターはプローブの再送信を停止し（SHOULD）、断片化しきい値に新しい値を選択する必要があります（SHOULD）。 ICMPメッセージの値以下で、以下にリストされている要件を満たしています。
In the case of PMTU discovery, the Total Fragments field is used to distinguish between different sets of fragments, i.e., the sets that were created by fragmenting the original message using different fragmentation thresholds. Since the sender starts from larger fragments and then makes them smaller, the value in the Total Fragments field increases with each new probe. When selecting the next smaller value for the fragmentation threshold, the sender MUST ensure that the value in the Total Fragments field is really increased. This requirement should not be a problem for the sender, because PMTU discovery in IKE is supposed to be coarse-grained, so the difference between previous and next fragmentation thresholds should be significant anyway. The need to distinguish between the sets is vital for the receiver, since receiving a valid fragment from a newer set means that it has to start the reassembly process over and not mix fragments from different sets.
PMTUディスカバリーの場合、Total Fragmentsフィールドは、異なるフラグメントのセット、つまり異なるフラグメント化しきい値を使用して元のメッセージをフラグメント化することによって作成されたセットを区別するために使用されます。送信側は大きいフラグメントから開始して、次にそれらを小さくするので、Total Fragmentsフィールドの値は新しいプローブごとに増加します。フラグメンテーションしきい値に次に小さい値を選択する場合、送信者は、Total Fragmentsフィールドの値が実際に増加していることを確認する必要があります。 IKEでのPMTUの検出は大まかなものであるため、この要件は送信者にとって問題にはなりません。そのため、前のフラグメント化しきい値と次のフラグメント化しきい値の差はとにかく大きくなるはずです。新しいセットから有効なフラグメントを受信することは、異なるセットからのフラグメントを混合せずに再アセンブリプロセスを開始する必要があることを意味するため、セットを区別する必要はレシーバにとって不可欠です。
Currently, there are no IKEv2 exchanges that define messages, containing both unprotected payloads and payloads, that are protected by the Encrypted payload. However, IKEv2 does not prohibit such construction. If some future IKEv2 extension defines such a message and it needs to be fragmented, all unprotected payloads MUST be placed in the first fragment (with the Fragment Number field equal to 1), along with the Encrypted Fragment payload, which MUST be present in every IKE Fragment message and be the last payload in it.
現在、保護されていないペイロードと暗号化されたペイロードによって保護されているペイロードの両方を含むメッセージを定義するIKEv2交換はありません。ただし、IKEv2はそのような構成を禁止していません。将来のIKEv2拡張機能がそのようなメッセージを定義し、それをフラグメント化する必要がある場合、保護されていないすべてのペイロードは、最初にフラグメント（フラグメント番号フィールドが1に等しい）とともに、暗号化されたフラグメントペイロードとともに配置されなければなりません。 IKE Fragmentメッセージで、最後のペイロードになります。
Below is an example of a fragmenting message that contains both protected and unprotected payloads.
以下は、保護されたペイロードと保護されていないペイロードの両方を含む断片化メッセージの例です。
HDR(MID=n), PLD0, SK(NextPld=PLD1) {PLD1 ... PLDN}
Original Message
オリジナルメッセージ
HDR(MID=n), PLD0, SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...},
HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...},
...
HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...}
IKE Fragment Messages
IKEフラグメントメッセージ
Note that the size of each IP datagram bearing IKE Fragment messages should not exceed the fragmentation threshold, including the first one, that contains unprotected payloads. This will reduce the size of the Encrypted Fragment payload content in the first IKE Fragment message to accommodate all unprotected payloads. In an extreme case, the Encrypted Fragment payload will contain no data, but it still must be present in the message, because only its presence allows the receiver to determine that the sender has used IKE fragmentation.
IKE Fragmentメッセージを含む各IPデータグラムのサイズは、保護されていないペイロードを含む、最初のしきい値を含めて、フラグメンテーションしきい値を超えてはなりません。これにより、最初のIKE Fragmentメッセージの暗号化フラグメントペイロードコンテンツのサイズが小さくなり、保護されていないすべてのペイロードに対応できます。極端な場合、暗号化されたフラグメントペイロードにはデータが含まれませんが、その存在だけで受信者は送信者がIKEフラグメンテーションを使用したと判断できるため、メッセージに存在する必要があります。
The receiver identifies the IKE Fragment message by the presence of an Encrypted Fragment payload in it. In most cases, it will be the first and only payload in the message; however, this may not be true for some hypothetical IKE exchanges (see Section 2.5.3).
受信者は、暗号化されたフラグメントペイロードが含まれていることにより、IKEフラグメントメッセージを識別します。ほとんどの場合、それはメッセージの最初で唯一のペイロードになります。ただし、これは一部の架空のIKE交換には当てはまらない場合があります（セクション2.5.3を参照）。
Upon receiving the IKE Fragment message, the following actions are performed:
IKE Fragmentメッセージを受信すると、次のアクションが実行されます。
o Check message validity - in particular, check whether the values in the Fragment Number and the Total Fragments fields in the Encrypted Fragment payload are valid. The following tests need to be performed.
o メッセージの有効性を確認します。特に、暗号化されたフラグメントペイロードのFragment NumberおよびTotal Fragmentsフィールドの値が有効かどうかを確認します。次のテストを実行する必要があります。
* check that the Fragment Number and the Total Fragments fields contain non-zero values
* Fragment NumberおよびTotal Fragmentsフィールドにゼロ以外の値が含まれていることを確認します
* check that the value in the Fragment Number field is less than or equal to the value in the Total Fragments field
* Fragment Numberフィールドの値がTotal Fragmentsフィールドの値以下であることを確認します
* if reassembling has already started, check that the value in the Total Fragments field is equal to or greater than the Total Fragments field in the fragments that have already been stored in the reassembling queue
* 再構成がすでに開始されている場合は、[Total Fragments]フィールドの値が、再構成キューにすでに格納されているフラグメントの[Total Fragments]フィールド以上であることを確認します
If any of these tests fail, the message MUST be silently discarded.
これらのテストのいずれかが失敗した場合、メッセージは黙って破棄されなければなりません（MUST）。
o Check that this IKE Fragment message is new for the receiver and not a replay. If an IKE Fragment message with the same Message ID, Fragment Number, and Total Fragments fields is already present in the reassembling queue, this message is considered a replay and MUST be silently discarded.
o このIKE Fragmentメッセージが受信側にとって新しいものであり、リプレイではないことを確認してください。同じメッセージID、フラグメント番号、および合計フラグメントのフィールドを持つIKEフラグメントメッセージが再構成キューに既に存在する場合、このメッセージは再生と見なされ、メッセージなしで破棄する必要があります。
o Verify IKE Fragment message authenticity by checking the Integrity Check Value (ICV) in the Encrypted Fragment payload. If the ICV check fails, the message MUST be silently discarded.
o 暗号化フラグメントペイロードの整合性チェック値（ICV）をチェックして、IKEフラグメントメッセージの信頼性を確認します。 ICVチェックが失敗した場合、メッセージは黙って破棄されなければならない（MUST）。
o If reassembling is not finished yet and the Total Fragments field in the received fragment is greater than the Total Fragments field in those fragments that are in the reassembling queue, the receiver MUST discard all received fragments and start the reassembly process over with just the received IKE Fragment message.
o 再構成がまだ完了しておらず、受信フラグメントのTotal Fragmentsフィールドが再構成キューにあるフラグメントのTotal Fragmentsフィールドより大きい場合、受信者は受信したすべてのフラグメントを破棄し、受信したIKEだけで再構成プロセスを開始する必要がありますフラグメントメッセージ。
o Store the message in the reassembling queue waiting for the rest of the fragments to arrive.
o 残りのフラグメントが到着するのを待って、メッセージを再構成キューに格納します。
When all IKE Fragment messages (as indicated in the Total Fragments field) are received, the decrypted content of all Encrypted Fragment payloads is merged together to form the content of the original Encrypted payload and, therefore, along with the IKE header and unprotected payloads (if any), the original message. Then, it is processed as if it was received, verified, and decrypted as a regular IKE message.
すべてのIKEフラグメントメッセージ（「合計フラグメント」フィールドに示されている）が受信されると、すべての暗号化フラグメントペイロードの復号化されたコンテンツが結合され、元の暗号化ペイロードのコンテンツが形成されます。したがって、IKEヘッダーと保護されていないペイロード（あれば）、元のメッセージ。次に、受信、検証、および復号化されたかのように通常のIKEメッセージとして処理されます。
If the receiver does not get all IKE fragments needed to reassemble the original message within a timeout interval, it MUST discard all IKE Fragment messages received so far for the exchange. The next actions depend on the role of the receiver in the exchange.
受信者がタイムアウト間隔内に元のメッセージを再構成するために必要なすべてのIKEフラグメントを取得しない場合、交換のためにこれまでに受信したすべてのIKEフラグメントメッセージを破棄する必要があります。次のアクションは、交換における受信者の役割によって異なります。
o The initiator acts as described in Section 2.1 of [RFC7296]. It either retransmits the fragmented request message or deems the IKE SA to have failed and deletes it. The number of retransmits and length of timeouts for the initiator are not covered in this specification, since they are assumed to be the same as in a regular IKEv2 exchange and are discussed in Section 2.4 of [RFC7296].
o イニシエーターは、[RFC7296]のセクション2.1の説明に従って動作します。フラグメント化された要求メッセージを再送信するか、IKE SAが失敗したと見なして削除します。イニシエーターの再送信の回数とタイムアウトの長さは、通常のIKEv2交換と同じであると想定され、[RFC7296]のセクション2.4で説明されているため、この仕様ではカバーされていません。
o The responder in this case acts as if no request message was received. It would delete any memory of the incomplete request message and not treat it as an IKE SA failure. It is RECOMMENDED that the reassembling timeout for the responder be equal to the time interval that the implementation waits before completely giving up when acting as the initiator of an exchange. Section 2.4 of [RFC7296] gives recommendations for selecting this interval. Implementations can use a shorter timeout to conserve memory.
o この場合のレスポンダは、リクエストメッセージが受信されなかったかのように動作します。不完全な要求メッセージのメモリを削除し、IKE SA障害としては扱いません。レスポンダの再構成タイムアウトは、実装が交換のイニシエータとして機能するときに完全に諦める前に待機する時間間隔と同じにすることをお勧めします。 [RFC7296]のセクション2.4は、この間隔を選択するための推奨事項を示しています。実装では、短いタイムアウトを使用してメモリを節約できます。
According to Section 2.2 of [RFC7296], the Message ID is used, in particular, to identify retransmissions of IKE messages. Each request or response message, sent by either side, must have a unique Message ID, or be considered a retransmission otherwise. This logic has already been updated by [RFC6311], which deliberately allows any number of messages with zero Message ID. This document also updates this logic for those situations where IKE fragmentation is in use.
[RFC7296]のセクション2.2によると、メッセージIDは、特にIKEメッセージの再送信を識別するために使用されます。どちらかの側から送信される各要求メッセージまたは応答メッセージは、一意のメッセージIDを持っているか、そうでなければ再送信と見なされる必要があります。このロジックはすでに[RFC6311]によって更新されており、ゼロのメッセージIDを持つ任意の数のメッセージを意図的に許可しています。このドキュメントでは、IKEフラグメンテーションが使用されている状況についても、このロジックを更新しています。
If an incoming message contains an Encrypted Fragment payload, the values of the Fragment Number and Total Fragments fields MUST be used along with the Message ID to detect retransmissions and replays.
着信メッセージに暗号化されたフラグメントペイロードが含まれている場合は、フラグメントIDと合計フラグメントのフィールドの値をメッセージIDと共に使用して、再送信とリプレイを検出する必要があります。
If the responder receives a retransmitted fragment of a request when it has already processed that request and has sent back a response, that event MUST only trigger a retransmission of the response message (fragmented or not) if the Fragment Number field in the received fragment is set to 1; otherwise, it MUST be ignored.
応答側が要求の再送信フラグメントを受信し、その要求をすでに処理して応答を返送した場合、受信したフラグメントのフラグメント番号フィールドが次の場合にのみ、そのイベントは応答メッセージの再送信（フラグメント化されているかどうかにかかわらず）をトリガーする必要があります（MUST）。 1に設定。それ以外の場合は、無視する必要があります。
IKE fragmentation is compatible with most IKE extensions, such as IKE Session Resumption ([RFC5723]), the Quick Crash Detection Method ([RFC6290]), and so on. It neither affects their operation nor is affected by them. It is believed that IKE fragmentation will also be compatible with future IKE extensions, if they follow general principles of formatting, sending, and receiving IKE messages, as described in [RFC7296].
IKEフラグメンテーションは、IKEセッション再開（[RFC5723]）、Quick Crash Detection Method（[RFC6290]）などのほとんどのIKE拡張と互換性があります。それは彼らの活動にも影響もしません。 [RFC7296]で説明されているように、IKEメッセージのフォーマット、送信、および受信の一般原則に従う場合、IKEフラグメンテーションも将来のIKE拡張と互換性があると考えられています。
When IKE fragmentation is used with IKE Session Resumption ([RFC5723]), messages of an IKE_SESSION_RESUME exchange cannot be fragmented, since they do not contain an Encrypted payload. These messages may be large due to the ticket size. To avoid IP fragmentation in this situation, it is recommended that smaller tickets be used, e.g., by utilizing a "ticket by reference" approach instead of "ticket by value".
IKEフラグメント化がIKEセッション再開（[RFC5723]）で使用される場合、暗号化されたペイロードが含まれていないため、IKE_SESSION_RESUME交換のメッセージはフラグメント化できません。これらのメッセージは、チケットのサイズが原因で大きくなる可能性があります。この状況でIPの断片化を回避するには、「値によるチケット」ではなく「参照によるチケット」アプローチを利用するなどして、より小さいチケットを使用することをお勧めします。
Protocol Support for High Availability of IKEv2/IPsec, described in [RFC6311], requires special care when deciding whether to fragment an IKE message or not. Since it deliberately allows any number of synchronization exchanges to have the same Message ID, namely zero, standard IKEv2 replay detection logic, based on checking the Message ID, is not applicable for such messages, and the receiver has to check message content to detect replays. When implementing IKE fragmentation along with [RFC6311], IKE Message ID Synchronization messages MUST NOT be sent fragmented, to simplify the receiver's task of detecting replays. Fortunately, these messages are small, and there is no point in fragmenting them anyway.
[RFC6311]で説明されている、IKEv2 / IPsecの高可用性のプロトコルサポートでは、IKEメッセージをフラグメント化するかどうかを決定する際に特別な注意が必要です。意図的に任意の数の同期交換で同じメッセージID、つまりゼロを使用できるため、メッセージIDのチェックに基づく標準のIKEv2リプレイ検出ロジックはそのようなメッセージには適用できず、受信者はメッセージコンテンツをチェックしてリプレイを検出する必要があります。 。 IKEフラグメンテーションを[RFC6311]とともに実装する場合、受信者のリプレイ検出タスクを簡略化するために、IKEメッセージID同期メッセージをフラグメント化して送信してはなりません（MUST NOT）。幸い、これらのメッセージは小さく、とにかくそれらを断片化しても意味がありません。
With IKE fragmentation, if any single IKE Fragment message gets lost, the receiver becomes unable to reassemble the original message. So, in general, using IKE fragmentation implies a higher probability that the message will not be delivered to the peer. Although in most network environments the difference will be insignificant, on some lossy networks it may become noticeable. When using IKE fragmentation, implementations MAY use longer timeouts and do more retransmits than usual before considering the peer dead.
IKEフラグメンテーションを使用すると、単一のIKEフラグメントメッセージが失われた場合、受信者は元のメッセージを再構成できなくなります。したがって、一般に、IKEフラグメンテーションを使用すると、メッセージがピアに配信されない可能性が高くなります。ほとんどのネットワーク環境では違いはわずかですが、一部の損失の多いネットワークでは、それが顕著になる場合があります。 IKEフラグメンテーションを使用する場合、実装は、ピアが停止していると見なす前に、通常より長いタイムアウトを使用し、通常より多くの再送信を実行できます（MAY）。
Note that Fragment messages are not individually acknowledged. The response Fragment messages are all sent back together only when all fragments of the request are received, and the original request message is reassembled and successfully processed.
フラグメントメッセージは個別に確認応答されないことに注意してください。応答フラグメントメッセージはすべて、要求のすべてのフラグメントが受信されたときにのみ一緒に送り返され、元の要求メッセージが再構成されて正常に処理されます。
Most of the security considerations for IKE fragmentation are the same as those for the base IKEv2 protocol described in [RFC7296]. This extension introduces the Encrypted Fragment payload to protect the content of an IKE Message Fragment. This allows the receiver to individually check the authenticity of fragments, thus protecting peers from a DoS attack.
IKEフラグメンテーションのセキュリティに関する考慮事項のほとんどは、[RFC7296]で説明されているベースIKEv2プロトコルの場合と同じです。この拡張機能は、暗号化フラグメントペイロードを導入して、IKEメッセージフラグメントのコンテンツを保護します。これにより、受信者はフラグメントの信頼性を個別にチェックできるため、ピアをDoS攻撃から保護できます。
The Security Considerations section of [RFC7296] mentions a possible attack on IKE where an attacker could prevent an exchange from completing by exhausting the IP reassembly buffers. The mechanism described in this document allows IKE to avoid IP fragmentation and therefore increases its robustness to DoS attacks.
[RFC7296]のセキュリティに関する考慮事項のセクションでは、攻撃者がIP再構成バッファーを使い果たして交換が完了するのを阻止できる、IKEへの攻撃の可能性について言及しています。このドキュメントで説明するメカニズムにより、IKEはIPフラグメンテーションを回避できるため、DoS攻撃に対する堅牢性が向上します。
The following attack is possible with IKE fragmentation. An attacker can initiate an IKE_SA_INIT exchange, complete it, compute SK_a and SK_e, and then send a large but still incomplete set of IKE_AUTH fragments. These fragments will pass the ICV check and will be stored in reassembly buffers, but since the set is incomplete, the reassembling will never succeed and eventually will time out. If the set is large, this attack could potentially exhaust the receiver's memory resources.
次の攻撃は、IKEフラグメンテーションで可能です。攻撃者は、IKE_SA_INIT交換を開始し、それを完了し、SK_aおよびSK_eを計算してから、IKE_AUTHフラグメントの大規模であるが不完全なセットを送信できます。これらのフラグメントはICVチェックに合格し、再構成バッファーに格納されますが、セットが不完全であるため、再構成は成功せず、最終的にタイムアウトになります。セットが大きい場合、この攻撃は受信者のメモリリソースを使い果たす可能性があります。
To mitigate the impact of this attack, it is RECOMMENDED that the receiver limit the number of fragments it stores in the reassembling queue so that the sum of the sizes of Encrypted Fragment payload contents (after decryption) for fragments that are already placed into the reassembling queue is less than some value that is reasonable for the implementation. If the peer sends so many fragments that the above condition is not met, the receiver can consider this situation to be either an attack or a broken sender implementation. In either case, the receiver SHOULD drop the connection and discard all the received fragments.
この攻撃の影響を緩和するために、受信者が再構築キューに格納するフラグメントの数を制限し、再構築にすでに配置されているフラグメントの暗号化フラグメントペイロードコンテンツ（復号化後）のサイズの合計が制限されるようにすることをお勧めしますキューは、実装に適した値よりも小さいです。ピアが上記の条件を満たさないほど多くのフラグメントを送信する場合、受信者はこの状況を攻撃または壊れた送信者の実装と見なすことができます。どちらの場合でも、受信者は接続をドロップし、受信したすべてのフラグメントを破棄する必要があります（SHOULD）。
This value can be predefined, can be a configurable option, or can be calculated dynamically, depending on the receiver's memory load. Some care should be taken when selecting this value because if it is too small it might prevent a legitimate peer from establishing an IKE SA if the size of messages it sends exceeds this value. It is NOT RECOMMENDED for this value to exceed 64 KB because any IKE message before fragmentation would likely be shorter than that.
この値は、事前に定義することも、構成可能なオプションにすることも、レシーバーのメモリ負荷に応じて動的に計算することもできます。この値を選択するときは注意が必要です。小さすぎると、送信するメッセージのサイズがこの値を超えると、正当なピアがIKE SAを確立できなくなる可能性があります。この値が64 KBを超えることはお勧めしません。断片化前のIKEメッセージはおそらくそれよりも短いためです。
If IKE fragments arrive in order, it is possible, but not advised, for the receiver to parse the beginning of the message that is being reassembled and extract the already-available payloads before the reassembly is complete. It can be dangerous to take any action based on the content of these payloads, because the fragments that have not yet been received might contain payloads that could change the meaning of them (or could even make the whole message invalid), and this can potentially be exploited by an attacker. It is important to address this threat by ensuring that all the fragments are received prior to parsing the reassembled message, as described in Section 2.6.
IKEフラグメントが順番に到着した場合、再構成が完了する前に、受信側が再構成中のメッセージの先頭を解析し、すでに利用可能なペイロードを抽出することは可能ですが、お勧めできません。まだ受信されていないフラグメントには、それらの意味を変更する（またはメッセージ全体を無効にする）可能性があるペイロードが含まれている可能性があるため、これらのペイロードの内容に基づいてアクションを実行するのは危険であり、攻撃者に悪用される。セクション2.6で説明されているように、再構成されたメッセージを解析する前にすべてのフラグメントが受信されるようにすることで、この脅威に対処することが重要です。
This document defines a new payload in the "IKEv2 Payload Types" registry:
このドキュメントでは、「IKEv2 Payload Types」レジストリで新しいペイロードを定義しています。
53 Encrypted and Authenticated Fragment SKF
53暗号化および認証済みのフラグメントSKF
This document also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry:
このドキュメントでは、「IKEv2通知メッセージタイプ-ステータスタイプ」レジストリで新しい通知メッセージタイプも定義しています。
16430 IKEV2_FRAGMENTATION_SUPPORTED
16430 IKEV2_FRAGMENTATION_SUPPORTED
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、STD 79、RFC 7296、2014年10月、< http://www.rfc-editor.org/info/rfc7296>。
[RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. Zhang, "Protocol Support for High Availability of IKEv2/ IPsec", RFC 6311, July 2011, <http://www.rfc-editor.org/info/rfc6311>.
[RFC6311] Singh、R.、Kalyani、G.、Nir、Y.、Sheffer、Y。、およびD. Zhang、「IKEv2 / IPsecの高可用性のためのプロトコルサポート」、RFC 6311、2011年7月、<http：/ /www.rfc-editor.org/info/rfc6311>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、1990年11月、<http://www.rfc-editor.org/info/rfc1191>。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「Path MTU Discovery for IP version 6」、RFC 1981、1996年8月、<http://www.rfc-editor.org/info/rfc1981 >。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月、<http://www.rfc-editor.org/info/rfc2460>。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC4787] Audet、F。およびC. Jennings、「ネットワークアドレス変換（NAT）ユニキャストUDPの動作要件」、BCP 127、RFC 4787、2007年1月、<http://www.rfc-editor.org/info/ rfc4787>。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月、<http://www.rfc-editor.org/info/rfc4821>。
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008, <http://www.rfc-editor.org/info/rfc5282>.
[RFC5282] Black、D.、D。McGrew、「Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2（IKEv2）Protocol」、RFC 5282、2008年8月、<http：//www.rfc-editor .org / info / rfc5282>。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、2008年11月、<http://www.rfc-editor.org/info/rfc5405>。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010, <http://www.rfc-editor.org/info/rfc5723>.
[RFC5723] Sheffer、Y。およびH. Tschofenig、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）セッションの再開」、RFC 5723、2010年1月、<http://www.rfc-editor.org/info/rfc5723>。
[RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)", RFC 6290, June 2011, <http://www.rfc-editor.org/info/rfc6290>.
[RFC6290] Nir、Y.、Wierbowski、D.、Detienne、F。、およびP. Sethi、「インターネットキー交換プロトコル（IKE）の迅速なクラッシュ検出方法」、RFC 6290、2011年6月、<http：/ /www.rfc-editor.org/info/rfc6290>。
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC6888]ペロー、S、山形、I、宮川、S、中川、A、および芦田H、「キャリアグレードNAT（CGN）の共通要件」、BCP 127、RFC 6888、2013年4月、 <http://www.rfc-editor.org/info/rfc6888>。
[FRAGDROP] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, M., and T. Taylor, "Why Operators Filter Fragments and What It Implies", Work in Progress, draft-taylor-v6ops-fragdrop-02, December 2013.
[FRAGDROP] Jaeggli、J.、Colitti、L.、Kumari、W.、Vyncke、E.、Kaeo、M。、およびT. Taylor、「なぜ演算子はフラグメントをフィルタリングし、何を意味するのか」、作業中、ドラフト- taylor-v6ops-fragdrop-02、2013年12月。
[BLACKHOLES] De Boer, M. and J. Bosma, "Discovering Path MTU black holes on the Internet using RIPE Atlas", July 2012, <http://www.nlnetlabs.nl/downloads/publications/ pmtu-black-holes-msc-thesis.pdf>.
[ブラックホール] De Boer、M.、J。Bosma、「RIPE Atlasを使用してインターネット上のパスMTUブラックホールを発見する」、2012年7月、<http://www.nlnetlabs.nl/downloads/publications/ pmtu-black-holes -msc-thesis.pdf>。
[DOSUDPPROT] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security, October 2003.
[DOSUDPPROT] Kaufman、C.、Perlman、R。、およびB. Sommerfeld、「UDPベースのプロトコルのDoS保護」、ACM Conference on Computer and Communications Security、2003年10月。
The simplest approach to IKE fragmentation would have been to fragment a message that is fully formed and ready to be sent. However, if a message got fragmented after being encrypted and authenticated, this could make a simple DoS attack possible. The attacker could infrequently emit forged but valid-looking fragments into the network, and some of these fragments would be fetched by the receiver into the reassembling queue. The receiver would not be able to distinguish forged fragments from valid ones and would only be able to determine that some of the received fragments were forged after the whole message was reassembled and its authenticity check failed.
IKEフラグメンテーションへの最も簡単なアプローチは、完全に形成され、送信の準備ができているメッセージをフラグメント化することでした。ただし、メッセージが暗号化および認証された後に断片化された場合、これにより単純なDoS攻撃が可能になる可能性があります。攻撃者はまれに、偽造されたが有効に見えるフラグメントをネットワークに送信する可能性があり、これらのフラグメントの一部は受信側によって再構成キューにフェッチされます。受信者は偽造されたフラグメントを有効なフラグメントと区別できず、メッセージ全体が再構成されてその信頼性チェックが失敗した後で、受信されたフラグメントの一部が偽造されたと判断できるだけです。
To prevent this kind of attack and also reduce vulnerability to some other kinds of DoS attacks, it was decided to perform fragmentation before applying cryptographic protection to the message. In this case, each Fragment message becomes individually encrypted and authenticated; this allows the receiver to determine forged fragments and not store them in the reassembling queue.
この種の攻撃を防止し、他の種類のDoS攻撃に対する脆弱性を減らすために、メッセージに暗号化保護を適用する前に断片化を実行することが決定されました。この場合、各フラグメントメッセージは個別に暗号化および認証されます。これにより、受信者は偽造されたフラグメントを判別し、それらを再構成キューに格納しないようにすることができます。
Appendix B. Correlation between IP Datagram Size and Encrypted Payload Content Size
付録B. IPデータグラムサイズと暗号化されたペイロードコンテンツサイズの相関関係
In the case of IPv4, the content size of the Encrypted Payload is less than the IP datagram size by the sum of the following values:
IPv4の場合、暗号化されたペイロードのコンテンツサイズは、IPデータグラムのサイズよりも次の値の合計だけ小さくなります。
o IPv4 header size (typically 20 bytes, up to 60 if IP options are present)
o IPv4ヘッダーサイズ（通常20バイト、IPオプションが存在する場合は最大60バイト）
o UDP header size (8 bytes)
o UDPヘッダーサイズ（8バイト）
o non-ESP (Encapsulating Security Payload) marker size (4 bytes if present)
o 非ESP（カプセル化セキュリティペイロード）マーカーサイズ（存在する場合は4バイト）
o IKE header size (28 bytes)
o IKEヘッダーサイズ（28バイト）
o Encrypted payload header size (4 bytes)
o 暗号化されたペイロードヘッダーサイズ（4バイト）
o initialization vector (IV) size (variable)
o 初期化ベクトル（IV）サイズ（変数）
o padding and its size (at least 1 byte)
o パディングとそのサイズ（少なくとも1バイト）
o ICV size (variable)
o ICVサイズ（可変）
The sum may be estimated as 61..105 bytes + IV + ICV + padding.
合計は、61..105バイト+ IV + ICV +パディングと見積もられます。
In the case of IPv6, the content size of the Encrypted Payload is less than the IP datagram size by the sum of the following values:
IPv6の場合、暗号化されたペイロードのコンテンツサイズは、IPデータグラムのサイズよりも次の値の合計だけ小さくなります。
o IPv6 header size (40 bytes)
o IPv6ヘッダーサイズ（40バイト）
o IPv6 extension headers (optional; size varies)
o IPv6拡張ヘッダー（オプション、サイズは異なります）
o UDP header size (8 bytes)
o UDPヘッダーサイズ（8バイト）
o non-ESP marker size (4 bytes if present)
o 非ESPマーカーサイズ（存在する場合は4バイト）
o IKE header size (28 bytes)
o IKEヘッダーサイズ（28バイト）
o Encrypted payload header size (4 bytes)
o 暗号化されたペイロードヘッダーサイズ（4バイト）
o IV size (variable)
o IVサイズ（可変）
o padding and its size (at least 1 byte)
o パディングとそのサイズ（少なくとも1バイト）
o ICV size (variable)
o ICVサイズ（可変）
If no extension header is present, the sum may be estimated as 81..85 bytes + IV + ICV + padding. If extension headers are present, the payload content size is further reduced by the sum of the size of the extension headers. The length of each extension header can be calculated as 8 * (Hdr Ext Len) bytes, except for the fragment header, which is always 8 bytes in length.
拡張ヘッダーが存在しない場合、合計は81..85バイト+ IV + ICV +パディングと見積もられます。拡張ヘッダーが存在する場合、ペイロードコンテンツサイズは、拡張ヘッダーのサイズの合計によってさらに削減されます。各拡張ヘッダーの長さは、常に8バイトの長さのフラグメントヘッダーを除いて、8 *（Hdr Ext Len）バイトとして計算できます。
Acknowledgements
謝辞
The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters, Yaron Sheffer, Joe Touch, Derek Atkins, Ole Troan, and others for their reviews and valuable comments. Thanks to Ron Bonica for contributing text to the Introduction section. Thanks to Paul Hoffman and Barry Leiba for improving text clarity.
著者は、レビューと貴重なコメントを提供してくれたTero Kivinen、Yoav Nir、Paul Wouters、Yaron Sheffer、Joe Touch、Derek Atkins、Ole Troanなどに感謝します。概要セクションにテキストを提供してくれたRon Bonicaに感謝します。テキストの明瞭さを改善してくれたPaul HoffmanとBarry Leibaに感謝します。
Author's Address
著者のアドレス
Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation
Valery Smyslov ELVIS-PLUS PO Boxing 81モスクワ（ゼレノグラード）124460ロシア連邦
Phone: +7 495 276 0211
EMail: svan@elvis.ru