[要約] 要約：RFC 8019は、分散型サービス拒否（DDoS）攻撃からInternet Key Exchange Protocol Version 2（IKEv2）実装を保護するためのガイドラインを提供します。 目的：このRFCの目的は、IKEv2実装の脆弱性を特定し、DDoS攻撃からの保護策を提案することです。
Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 8019 Check Point
Category: Standards Track V. Smyslov
ISSN: 2070-1721 ELVIS-PLUS
November 2016
Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks
分散型サービス拒否攻撃からのインターネットキー交換プロトコルバージョン2（IKEv2）実装の保護
Abstract
概要
This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial-of-Service and Distributed Denial-of-Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that helps accomplish this task.
このドキュメントでは、インターネットキー交換プロトコルバージョン2（IKEv2）レスポンダの実装および構成のベストプラクティスを推奨し、サービス拒否攻撃および分散型サービス拒否攻撃に対抗できるようにします。さらに、このドキュメントでは、このタスクの実行に役立つ「クライアントパズル」と呼ばれる新しいメカニズムを紹介しています。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8019.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8019で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3
4. Defense Measures While the IKE SA Is Being Created . . . . . 6
4.1. Retention Periods for Half-Open SAs . . . . . . . . . . . 6
4.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 7
4.3. The Stateless Cookie . . . . . . . . . . . . . . . . . . 8
4.4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 11
4.6. Keeping Computed Shared Keys . . . . . . . . . . . . . . 11
4.7. Preventing "Hash and URL" Certificate Encoding Attacks . 11
4.8. IKE Fragmentation . . . . . . . . . . . . . . . . . . . . 12
5. Defense Measures after an IKE SA Is Created . . . . . . . . . 12
6. Plan for Defending a Responder . . . . . . . . . . . . . . . 14
7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 16
7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 16
7.1.1. Presenting a Puzzle . . . . . . . . . . . . . . . . . 17
7.1.2. Solving a Puzzle and Returning the Solution . . . . . 19
7.1.3. Computing a Puzzle . . . . . . . . . . . . . . . . . 20
7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 21
7.1.5. Deciding Whether to Serve the Request . . . . . . . . 22
7.2. Puzzles in an IKE_AUTH Exchange . . . . . . . . . . . . . 23
7.2.1. Presenting the Puzzle . . . . . . . . . . . . . . . . 24
7.2.2. Solving the Puzzle and Returning the Solution . . . . 24
7.2.3. Computing the Puzzle . . . . . . . . . . . . . . . . 25
7.2.4. Receiving the Puzzle Solution . . . . . . . . . . . . 25
8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 26
8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 27
9. Operational Considerations . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 31
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Denial-of-Service (DoS) attacks have always been considered a serious threat. These attacks are usually difficult to defend against since the amount of resources the victim has is always bounded (regardless of how high it is) and because some resources are required for distinguishing a legitimate session from an attack.
サービス拒否（DoS）攻撃は常に深刻な脅威と見なされてきました。これらの攻撃は、被害者が持つリソースの量が常に（高さに関係なく）制限されており、正当なセッションと攻撃を区別するために必要なリソースがあるため、通常は防御するのが困難です。
The Internet Key Exchange Protocol version 2 (IKEv2) described in [RFC7296] includes defense against DoS attacks. In particular, there is a cookie mechanism that allows the IKE Responder to defend itself against DoS attacks from spoofed IP addresses. However, botnets have become widespread, allowing attackers to perform Distributed Denial-of-Service (DDoS) attacks, which are more difficult to defend against. This document presents recommendations to help the Responder counter DoS and DDoS attacks. It also introduces a new mechanism -- "puzzles" -- that can help accomplish this task.
[RFC7296]で説明されているInternet Key Exchange Protocolバージョン2（IKEv2）には、DoS攻撃に対する防御が含まれています。特に、IKEレスポンダーがスプーフィングされたIPアドレスからのDoS攻撃から身を守ることができるCookieメカニズムがあります。しかし、ボットネットが広まり、攻撃者が防御するのがより難しい分散サービス拒否（DDoS）攻撃を実行できるようになっています。このドキュメントでは、レスポンダがDoSおよびDDoS攻撃に対抗するのに役立つ推奨事項を示します。また、このタスクの実行に役立つ新しいメカニズム「パズル」も導入されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
The IKE_SA_INIT exchange described in Section 1.2 of [RFC7296] involves the Initiator sending a single message. The Responder replies with a single message and also allocates memory for a structure called a half-open IKE Security Association (SA). This half-open SA is later authenticated in the IKE_AUTH exchange. If that IKE_AUTH request never comes, the half-open SA is kept for an unspecified amount of time. Depending on the algorithms used and implementation, such a half-open SA will use from around one hundred to several thousand bytes of memory.
[RFC7296]のセクション1.2で説明されているIKE_SA_INIT交換では、イニシエーターが単一のメッセージを送信します。レスポンダは単一のメッセージで応答し、ハーフオープンIKE Security Association（SA）と呼ばれる構造にメモリを割り当てます。このハーフオープンSAは、IKE_AUTH交換で後で認証されます。そのIKE_AUTH要求が来ない場合、ハーフオープンSAは指定されていない期間保持されます。使用されるアルゴリズムと実装に応じて、このようなハーフオープンSAは約100〜数千バイトのメモリを使用します。
This creates an easy attack vector against an IKE Responder. Generating the IKE_SA_INIT request is cheap. Sending large amounts of IKE_SA_INIT requests can cause a Responder to use up all its resources. If the Responder tries to defend against this by throttling new requests, this will also prevent legitimate Initiators from setting up IKE SAs.
これにより、IKE Responderに対する簡単な攻撃ベクトルが作成されます。 IKE_SA_INIT要求の生成は安価です。大量のIKE_SA_INIT要求を送信すると、レスポンダがすべてのリソースを使い果たす可能性があります。レスポンダが新しいリクエストを抑制してこれを防御しようとする場合、これも正当なイニシエータがIKE SAをセットアップするのを防ぎます。
An obvious defense, which is described in Section 4.2, is limiting the number of half-open SAs opened by a single peer. However, since all that is required is a single packet, an attacker can use multiple spoofed source IP addresses.
セクション4.2で説明されている明らかな防御策は、単一のピアによって開かれるハーフオープンSAの数を制限することです。ただし、必要なのは1つのパケットだけなので、攻撃者は複数の偽装された送信元IPアドレスを使用できます。
If we break down what a Responder has to do during an initial exchange, there are three stages:
最初の交換中にレスポンダが実行する必要があることを分析すると、3つの段階があります。
1. When the IKE_SA_INIT request arrives, the Responder:
1. IKE_SA_INIT要求が到着すると、レスポンダは次のことを行います。
* Generates or reuses a Diffie-Hellman (DH) private part.
* Diffie-Hellman（DH）プライベートパーツを生成または再利用します。
* Generates a Responder Security Parameter Index (SPI).
* Responder Security Parameter Index（SPI）を生成します。
* Stores the private part and peer public part in a half-open SA database.
* プライベート部分とピアパブリック部分をハーフオープンSAデータベースに格納します。
2. When the IKE_AUTH request arrives, the Responder:
2. IKE_AUTH要求が到着すると、レスポンダは次のことを行います。
* Derives the keys from the half-open SA.
* ハーフオープンSAからキーを取得します。
* Decrypts the request.
* リクエストを復号化します。
3. If the IKE_AUTH request decrypts properly, the Responder:
3. IKE_AUTH要求が適切に復号化すると、レスポンダは次のことを行います。
* Validates the certificate chain (if present) in the IKE_AUTH request.
* IKE_AUTH要求の証明書チェーン（存在する場合）を検証します。
The fourth stage where the Responder creates the Child SA is not reached by attackers who cannot pass the authentication step.
レスポンダが子SAを作成する4番目の段階は、認証ステップを通過できない攻撃者が到達することはありません。
Stage #1 is pretty light on CPU usage, but requires some storage, and it's very light for the Initiator as well. Stage #2 includes private-key operations, so it is much heavier CPU-wise. Stage #3 may include public key operations if certificates are involved. These operations are often more computationally expensive than those performed at stage #2.
ステージ＃1は、CPU使用率はかなり軽いですが、ある程度のストレージを必要とし、イニシエーターにとっても非常に軽いです。ステージ＃2には秘密鍵の操作が含まれるため、CPUの面ではるかに重いです。証明書が含まれる場合、ステージ＃3には公開鍵操作が含まれる場合があります。これらの操作は、多くの場合、ステージ2で実行される操作よりも計算コストが高くなります。
To attack such a Responder, an attacker can attempt to exhaust either memory or CPU. Without any protection, the most efficient attack is to send multiple IKE_SA_INIT requests and exhaust memory. This is easy because IKE_SA_INIT requests are cheap.
このようなレスポンダを攻撃するために、攻撃者はメモリまたはCPUを使い果たすことを試みることができます。保護がなければ、最も効率的な攻撃は、複数のIKE_SA_INIT要求を送信してメモリを使い果たすことです。 IKE_SA_INIT要求は安価なので、これは簡単です。
There are obvious ways for the Responder to protect itself without changes to the protocol. It can reduce the time that an entry remains in the half-open SA database, and it can limit the amount of concurrent half-open SAs from a particular address or prefix. The attacker can overcome this by using spoofed source addresses.
レスポンダがプロトコルを変更せずに自身を保護する明白な方法があります。エントリがハーフオープンSAデータベースに残る時間を短縮でき、特定のアドレスまたはプレフィックスからの同時ハーフオープンSAの量を制限できます。攻撃者は、なりすましの送信元アドレスを使用することでこれを克服できます。
The stateless cookie mechanism from Section 2.6 of [RFC7296] prevents an attack with spoofed source addresses. This doesn't completely solve the issue, but it makes the limiting of half-open SAs by address or prefix work. Puzzles, introduced in Section 4.4,
[RFC7296]のセクション2.6のステートレスCookieメカニズムは、偽装された送信元アドレスによる攻撃を防ぎます。これで問題が完全に解決するわけではありませんが、アドレスまたはプレフィックスによるハーフオープンSAの制限が機能します。セクション4.4で導入されたパズル
accomplish the same thing -- only more of it. They make it harder for an attacker to reach the goal of getting a half-open SA. Puzzles do not have to be so hard that an attacker cannot afford to solve a single puzzle; it is enough that puzzles increase the cost of creating half-open SAs, so the attacker is limited in the amount they can create.
同じことを達成します-それだけです。これらは、攻撃者がハーフオープンSAを取得するという目標を達成することを困難にします。パズルは、攻撃者が1つのパズルを解く余裕がないほど難しいものである必要はありません。パズルでハーフオープンSAを作成するコストが増えるだけで十分なので、攻撃者は作成できる量に制限があります。
Reducing the lifetime of an abandoned half-open SA also reduces the impact of such attacks. For example, if a half-open SA is kept for 1 minute and the capacity is 60,000 half-open SAs, an attacker would need to create 1,000 half-open SAs per second. If the retention time is reduced to 3 seconds, the attacker would need to create 20,000 half-open SAs per second to get the same result. By introducing a puzzle, each half-open SA becomes more expensive for an attacker, making it more likely to prevent an exhaustion attack against Responder memory.
放棄されたハーフオープンSAのライフタイムを短縮すると、このような攻撃の影響も軽減されます。たとえば、ハーフオープンSAが1分間保持され、容量が60,000のハーフオープンSAである場合、攻撃者は1秒あたり1,000のハーフオープンSAを作成する必要があります。保持時間が3秒に短縮された場合、攻撃者が同じ結果を得るには、毎秒20,000のハーフオープンSAを作成する必要があります。パズルを導入することで、ハーフオープンSAは攻撃者にとってより高価になり、レスポンダーのメモリに対する枯渇攻撃を防ぐ可能性が高くなります。
At this point, filling up the half-open SA database is no longer the most efficient DoS attack. The attacker has two alternative attacks to do better:
この時点で、ハーフオープンSAデータベースを埋めることは、最も効率的なDoS攻撃ではなくなりました。攻撃者には、2つの代替攻撃があり、より効果的です。
1. Go back to spoofed addresses and try to overwhelm the CPU that deals with generating cookies, or
1. スプーフィングされたアドレスに戻り、Cookieの生成を処理するCPUを圧倒するか、または
2. Take the attack to the next level by also sending an IKE_AUTH request.
2. IKE_AUTHリクエストも送信して、攻撃を次のレベルに引き上げます。
If an attacker is so powerful that it is able to overwhelm the Responder's CPU that deals with generating cookies, then the attack cannot be dealt with at the IKE level and must be handled by means of the Intrusion Prevention System (IPS) technology.
攻撃者が非常に強力で、Cookieの生成を処理するレスポンダーのCPUを圧倒できる場合、攻撃はIKEレベルでは処理できず、侵入防止システム（IPS）テクノロジーを使用して処理する必要があります。
On the other hand, the second alternative of sending an IKE_AUTH request is very cheap. It requires generating a proper IKE header with the correct IKE SPIs and a single Encrypted payload. The content of the payload is irrelevant and might be junk. The Responder has to perform the relatively expensive key derivation, only to find that the Message Authentication Code (MAC) on the Encrypted payload on the IKE_AUTH request fails the integrity check. If a Responder does not hold on to the calculated SKEYSEED and SK_* keys (which it should in case a valid IKE_AUTH comes in later), this attack might be repeated on the same half-open SA. Puzzles make attacks of such sort more costly for an attacker. See Section 7.2 for details.
一方、IKE_AUTHリクエストを送信する2番目の方法は非常に安価です。正しいIKE SPIと単一の暗号化されたペイロードで適切なIKEヘッダーを生成する必要があります。ペイロードの内容は無関係であり、ジャンクである可能性があります。レスポンダは、IKE_AUTH要求の暗号化されたペイロードのメッセージ認証コード（MAC）が整合性チェックに失敗したことを見つけるだけで、比較的高価なキーの導出を実行する必要があります。レスポンダが計算されたSKEYSEEDおよびSK_ *キーを保持しない場合（有効なIKE_AUTHが後で入ってくる場合に備えて）、この攻撃は同じハーフオープンSAで繰り返される可能性があります。パズルは、そのような種類の攻撃を攻撃者にとってより高価なものにします。詳細については、セクション7.2を参照してください。
Here too, the number of half-open SAs that the attacker can achieve is crucial, because each one allows the attacker to waste some CPU time. So making it hard to make many half-open SAs is important.
ここでも、攻撃者がCPU時間を浪費できるため、攻撃者が達成できるハーフオープンSAの数は重要です。したがって、多くのハーフオープンSAを作成することを困難にすることが重要です。
A strategy against DDoS has to rely on at least 4 components:
DDoSに対する戦略は、少なくとも4つのコンポーネントに依存する必要があります。
1. Hardening the half-open SA database by reducing retention time.
1. 保持時間を短縮することにより、ハーフオープンSAデータベースを強化します。
2. Hardening the half-open SA database by rate-limiting single IPs/ prefixes.
2. 単一IP /プレフィックスをレート制限することにより、ハーフオープンSAデータベースを強化します。
3. Guidance on what to do when an IKE_AUTH request fails to decrypt.
3. IKE_AUTHリクエストが復号化に失敗した場合の対処法に関するガイダンス。
4. Increasing the cost of half-open SAs up to what is tolerable for legitimate clients.
4. ハーフオープンSAのコストを正当なクライアントが許容できる範囲まで増やします。
Puzzles are used as a solution for strategy #4.
パズルは戦略＃4のソリューションとして使用されます。
As a UDP-based protocol, IKEv2 has to deal with packet loss through retransmissions. Section 2.4 of [RFC7296] recommends "that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up." Many retransmission policies in practice wait one or two seconds before retransmitting for the first time.
UDPベースのプロトコルとして、IKEv2は再送信によるパケット損失を処理する必要があります。 [RFC7296]のセクション2.4は、「あきらめる前に、少なくとも数分間にわたってメッセージを少なくとも12回再送信すること」を推奨しています。実際の多くの再送信ポリシーは、最初に再送信する前に1〜2秒待機します。
Because of this, setting the timeout on a half-open SA too low will cause it to expire whenever even one IKE_AUTH request packet is lost. When not under attack, the half-open SA timeout SHOULD be set high enough that the Initiator will have enough time to send multiple retransmissions, minimizing the chance of transient network congestion causing an IKE failure.
このため、ハーフオープンSAのタイムアウトの設定が低すぎると、IKE_AUTH要求パケットが1つでも失われるたびにタイムアウトになります。攻撃を受けていない場合、ハーフオープンSAタイムアウトは、イニシエーターが複数の再送信を送信するのに十分な時間を確保できるように十分に高く設定する必要があります。これにより、一時的なネットワークの輻輳がIKE障害を引き起こす可能性を最小限に抑えます。
When the system is under attack, as measured by the amount of half-open SAs, it makes sense to reduce this lifetime. The Responder should still allow enough time for the round-trip, for the Initiator to derive the DH shared value, and to derive the IKE SA keys and create the IKE_AUTH request. Two seconds is probably as low a value as can realistically be used.
システムが攻撃を受けているとき、ハーフオープンSAの量で測定すると、この寿命を短縮することは理にかなっています。レスポンダーは、イニシエーターがDH共有値を導出し、IKE SAキーを導出してIKE_AUTH要求を作成するために、往復に十分な時間を確保する必要があります。 2秒は、現実的に使用できるほどの低い値です。
It could make sense to assign a shorter value to half-open SAs originating from IP addresses or prefixes that are considered suspect because of multiple concurrent half-open SAs.
複数の同時ハーフオープンSAが原因で疑わしいと見なされるIPアドレスまたはプレフィックスから発信されたハーフオープンSAに、より短い値を割り当てることは意味があります。
Even with DDoS, the attacker has only a limited amount of nodes participating in the attack. By limiting the amount of half-open SAs that are allowed to exist concurrently with each such node, the total amount of half-open SAs is capped, as is the total amount of key derivations that the Responder is forced to complete.
DDoSがあっても、攻撃者が攻撃に参加するノードの数は限られています。このような各ノードと同時に存在できるハーフオープンSAの量を制限することにより、レスポンダーが完了を強制されるキー派生の合計量と同様に、ハーフオープンSAの合計量が制限されます。
In IPv4, it makes sense to limit the number of half-open SAs based on IP address. Most IPv4 nodes are either directly attached to the Internet using a routable address or hidden behind a NAT device with a single IPv4 external address. For IPv6, ISPs assign between a /48 and a /64, so it does not make sense for rate limiting to work on single IPv6 IPs. Instead, rate limits should be done based on either the /48 or /64 of the misbehaving IPv6 address observed.
IPv4では、IPアドレスに基づいてハーフオープンSAの数を制限することは理にかなっています。ほとんどのIPv4ノードは、ルーティング可能なアドレスを使用してインターネットに直接接続されているか、単一のIPv4外部アドレスを持つNATデバイスの背後に隠されています。 IPv6の場合、ISPは/ 48と/ 64の間に割り当てるため、レート制限が単一のIPv6 IPで機能することは意味がありません。代わりに、レート制限は、観察された不正なIPv6アドレスの/ 48または/ 64に基づいて行う必要があります。
The number of half-open SAs is easy to measure, but it is also worthwhile to measure the number of failed IKE_AUTH exchanges. If possible, both factors should be taken into account when deciding which IP address or prefix is considered suspicious.
ハーフオープンSAの数は簡単に測定できますが、失敗したIKE_AUTH交換の数を測定することも価値があります。可能であれば、疑わしいと見なされるIPアドレスまたはプレフィックスを決定するときに、両方の要素を考慮する必要があります。
There are two ways to rate limit a peer address or prefix:
ピアアドレスまたはプレフィックスをレート制限するには、2つの方法があります。
1. Hard Limit -- where the number of half-open SAs is capped, and any further IKE_SA_INIT requests are rejected.
1. ハード制限-ハーフオープンSAの数に上限があり、それ以降のIKE_SA_INIT要求は拒否されます。
2. Soft Limit -- where if a set number of half-open SAs exist for a particular address or prefix, any IKE_SA_INIT request will be required to solve a puzzle.
2. ソフトリミット-特定のアドレスまたはプレフィックスに設定された数のハーフオープンSAが存在する場合、パズルを解くためにIKE_SA_INITリクエストが必要になります。
The advantage of the hard limit method is that it provides a hard cap on the amount of half-open SAs that the attacker is able to create. The disadvantage is that it allows the attacker to block IKE initiation from small parts of the Internet. For example, if a network service provider or some establishment offers Internet connectivity to its customers or employees through an IPv4 NAT device, a single malicious customer can create enough half-open SAs to fill the quota for the NAT device external IP address. Legitimate Initiators on the same network will not be able to initiate IKE.
ハードリミット方式の利点は、攻撃者が作成できるハーフオープンSAの量にハードキャップを提供することです。欠点は、攻撃者がインターネットの小さな部分からのIKEの開始をブロックできることです。たとえば、ネットワークサービスプロバイダーまたは一部の施設がIPv4 NATデバイスを介して顧客または従業員にインターネット接続を提供している場合、悪意のある単一の顧客が、NATデバイスの外部IPアドレスのクォータを満たすのに十分なハーフオープンSAを作成できます。同じネットワーク上の正当なイニシエーターはIKEを開始できません。
The advantage of a soft limit is that legitimate clients can always connect. The disadvantage is that an adversary with sufficient CPU resources can still effectively DoS the Responder.
ソフトリミットの利点は、正当なクライアントが常に接続できることです。欠点は、十分なCPUリソースを持つ敵が依然としてレスポンダーを効果的にDoSできることです。
Regardless of the type of rate limiting used, legitimate Initiators that are not on the same network segments as the attackers will not be affected. This is very important as it reduces the adverse impact caused by the measures used to counteract the attack and allows most Initiators to keep working even if they do not support puzzles.
使用されるレート制限のタイプに関係なく、攻撃者と同じネットワークセグメント上にない正当なイニシエーターは影響を受けません。これは、攻撃に対抗するために使用される対策によって引き起こされる悪影響を軽減し、ほとんどのイニシエーターがパズルをサポートしていない場合でも作業を続けることができるため、非常に重要です。
Section 2.6 of [RFC7296] offers a mechanism to mitigate DoS attacks: the stateless cookie. When the server is under load, the Responder responds to the IKE_SA_INIT request with a calculated "stateless cookie" -- a value that can be recalculated based on values in the IKE_SA_INIT request without storing Responder-side state. The Initiator is expected to repeat the IKE_SA_INIT request, this time including the stateless cookie. This mechanism prevents DoS attacks from spoofed IP addresses, since an attacker needs to have a routable IP address to return the cookie.
[RFC7296]のセクション2.6は、DoS攻撃を軽減するメカニズムであるステートレスCookieを提供します。サーバーに負荷がかかると、レスポンダはIKE_SA_INIT要求に計算された「ステートレスCookie」で応答します。この値は、レスポンダ側の状態を保存せずにIKE_SA_INIT要求の値に基づいて再計算できます。イニシエーターはIKE_SA_INIT要求を繰り返すことが期待されますが、今回はステートレスCookieが含まれます。このメカニズムは、攻撃者がCookieを返すためにルーティング可能なIPアドレスを持っている必要があるため、なりすましIPアドレスからのDoS攻撃を防ぎます。
Attackers that have multiple source IP addresses with return routability, such as in the case of botnets, can fill up a half-open SA table anyway. The cookie mechanism limits the amount of allocated state to the number of attackers, multiplied by the number of half-open SAs allowed per peer address, multiplied by the amount of state allocated for each half-open SA. With typical values, this can easily reach hundreds of megabytes.
ボットネットの場合のように、リターンルーティングが可能な複数の送信元IPアドレスを持つ攻撃者は、とにかくハーフオープンSAテーブルをいっぱいにすることができます。 Cookieメカニズムは、割り当てられた状態の量を攻撃者の数に制限し、ピアアドレスごとに許可されたハーフオープンSAの数を掛け、各ハーフオープンSAに割り当てられた状態の量を掛けます。典型的な値では、これは数百メガバイトに簡単に達する可能性があります。
The puzzle introduced here extends the cookie mechanism of [RFC7296]. It is loosely based on the proof-of-work technique used in Bitcoin [BITCOINS]. Puzzles set an upper bound, determined by the attacker's CPU, to the number of negotiations the attacker can initiate in a unit of time.
ここで紹介するパズルは、[RFC7296]のCookieメカニズムを拡張したものです。これは、ビットコイン[BITCOINS]で使用されている作業証明技術に大まかに基づいています。パズルは、攻撃者のCPUによって決定される上限を、攻撃者が時間単位で開始できるネゴシエーションの数に設定します。
A puzzle is sent to the Initiator in two cases:
パズルは次の2つの場合にイニシエーターに送信されます。
o The Responder is so overloaded that no half-open SAs may be created without solving a puzzle, or
o レスポンダーが過負荷になっているため、パズルを解かずにハーフオープンSAを作成することはできません。
o The Responder is not too loaded, but the rate-limiting method described in Section 4.2 prevents half-open SAs from being created with this particular peer address or prefix without first solving a puzzle.
o レスポンダの負荷が高すぎませんが、セクション4.2で説明されているレート制限方法により、最初にパズルを解かなくても、この特定のピアアドレスまたはプレフィックスでハーフオープンSAが作成されなくなります。
When the Responder decides to send the challenge to solve a puzzle in response to an IKE_SA_INIT request, the message includes at least three components:
レスポンダーがIKE_SA_INITリクエストへの応答としてパズルを解くためのチャレンジを送信することを決定した場合、メッセージには少なくとも3つのコンポーネントが含まれます。
1. Cookie -- this is calculated the same as in [RFC7296], i.e., the process of generating the cookie is not specified.
1. Cookie-これは[RFC7296]と同じように計算されます。つまり、Cookieの生成プロセスは指定されていません。
2. Algorithm, this is the identifier of a Pseudorandom Function (PRF) algorithm, one of those proposed by the Initiator in the SA payload.
2. アルゴリズム。これは、SAペイロードでイニシエーターによって提案されたアルゴリズムの1つである、疑似ランダム関数（PRF）アルゴリズムの識別子です。
3. Zero-Bit Count (ZBC). This is a number between 8 and 255 (or a special value - 0; see Section 7.1.1.1) that represents the length of the zero-bit run at the end of the output of the PRF function calculated over the cookie that the Initiator is to send. The values 1-8 are explicitly excluded, because they create a puzzle that is too easy to solve. Since the mechanism is supposed to be stateless for the Responder, either the same ZBC is used for all Initiators or the ZBC is somehow encoded in the cookie. If it is global, then it means that this value is the same for all the Initiators who are receiving puzzles at any given point of time. The Responder, however, may change this value over time depending on its load.
3. ゼロビットカウント（ZBC）。これは、8〜255の数値（または特別な値-0。7.1.1.1を参照）であり、イニシエーターであるCookieに対して計算されたPRF関数の出力の最後に実行されるゼロビットの長さを表します。送信します。 1から8の値は、簡単に解決できないパズルを作成するため、明示的に除外されます。メカニズムはレスポンダに対してステートレスであると想定されているため、すべてのイニシエータに同じZBCが使用されるか、ZBCが何らかの方法でCookieにエンコードされます。グローバルである場合、この値は、任意の時点でパズルを受け取っているすべてのイニシエーターで同じであることを意味します。ただし、レスポンダは、その負荷に応じて、時間の経過とともにこの値を変更する場合があります。
Upon receiving this challenge, the Initiator attempts to calculate the PRF output using different keys. When enough keys are found such that the resulting PRF output calculated using each of them has a sufficient number of trailing zero bits, that result is sent to the Responder.
このチャレンジを受信すると、イニシエーターはさまざまなキーを使用してPRF出力を計算しようとします。それらのそれぞれを使用して計算された結果のPRF出力が十分な数の後続ゼロビットを持つように十分なキーが見つかると、その結果がレスポンダに送信されます。
The reason for using several keys in the results, rather than just one key, is to reduce the variance in the time it takes the Initiator to solve the puzzle. We have chosen the number of keys to be four (4) as a compromise between the conflicting goals of reducing variance and reducing the work the Responder needs to perform to verify the puzzle solution.
結果で1つのキーではなく複数のキーを使用する理由は、イニシエーターがパズルを解くのにかかる時間のばらつきを減らすためです。分散を減らすという目標と、パズルのソリューションを検証するためにレスポンダが実行する必要がある作業を減らすという相反する目標の間の妥協点として、キーの数を4に選択しました。
When receiving a request with a solved puzzle, the Responder verifies two things:
パズルを解いてリクエストを受け取ると、レスポンダは2つのことを確認します。
o That the cookie is indeed valid.
o クッキーが本当に有効であること。
o That the results of PRF of the transmitted cookie calculated with the transmitted keys has a sufficient number of trailing zero bits.
o 送信されたキーを使用して計算された送信されたCookieのPRFの結果に、十分な数の後続ゼロビットがあること。
Example 1: Suppose the calculated cookie is 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 (20 octets), the algorithm is PRF-HMAC-SHA256, and the required number of zero bits is 18. After successively trying a bunch of keys, the Initiator finds the following four 3-octet keys that work:
例1：計算されたCookieが739ae7492d8a810cf5e8dc0f9626c9dda773c5a3（20オクテット）であり、アルゴリズムがPRF-HMAC-SHA256であり、必要なゼロビット数が18であるとします。イニシエーターは次の4つの3オクテットを見つけます。機能するキー：
+--------+----------------------------------+----------------+
| Key | Last 32 Hex PRF Digits | # of Zero Bits |
+--------+----------------------------------+----------------+
| 061840 | e4f957b859d7fb1343b7b94a816c0000 | 18 |
| 073324 | 0d4233d6278c96e3369227a075800000 | 23 |
| 0c8a2a | 952a35d39d5ba06709da43af40700000 | 20 |
| 0d94c8 | 5a0452b21571e401a3d00803679c0000 | 18 |
+--------+----------------------------------+----------------+
Table 1: Four Solutions for the 18-Bit Puzzle
表1：18ビットパズルの4つのソリューション
Example 2: Same cookie, but modify the required number of zero bits to 22. The first 4-octet keys that work to satisfy that requirement are 005d9e57, 010d8959, 0110778d, and 01187e37. Finding these requires 18,382,392 invocations of the PRF.
例2：同じCookieですが、必要なゼロビット数を22に変更します。この要件を満たすために機能する最初の4オクテットキーは、005d9e57、010d8959、0110778d、および01187e37です。これらを見つけるには、PRFを18,382,392回呼び出す必要があります。
+----------------+-------------------------------+
| # of Zero Bits | Time to Find 4 Keys (Seconds) |
+----------------+-------------------------------+
| 8 | 0.0025 |
| 10 | 0.0078 |
| 12 | 0.0530 |
| 14 | 0.2521 |
| 16 | 0.8504 |
| 17 | 1.5938 |
| 18 | 3.3842 |
| 19 | 3.8592 |
| 20 | 10.8876 |
+----------------+-------------------------------+
Table 2: The Time Needed to Solve a Puzzle of Various Difficulty for
the Cookie 39ae7492d8a810cf5e8dc0f9626c9dda773c5a3
The figures above were obtained on a 2.4 GHz single-core Intel i5 processor in a 2013 Apple MacBook Pro. Run times can be halved or quartered with multi-core code, but they would be longer on mobile phone processors, even if those are multi-core as well. With these figures, 18 bits is believed to be a reasonable choice for puzzle level difficulty for all Initiators, and 20 bits is acceptable for specific hosts/prefixes.
上記の数値は、2013年のApple MacBook Proの2.4 GHzシングルコアインテルi5プロセッサーで得られたものです。ランタイムはマルチコアコードを使用して半分または4分の1にすることができますが、携帯電話のプロセッサでは、マルチコアコードであっても長くなります。これらの数値では、18ビットはすべてのイニシエーターにとってパズルレベルの難易度の妥当な選択であると考えられ、20ビットは特定のホスト/プレフィックスで許容されます。
Using the puzzles mechanism in the IKE_SA_INIT exchange is described in Section 7.1.
IKE_SA_INIT交換でのパズルメカニズムの使用については、7.1節で説明しています。
When the Responder is under attack, it SHOULD prefer previously authenticated peers who present a Session Resumption ticket [RFC5723]. However, the Responder SHOULD NOT serve resumed Initiators exclusively because dropping all IKE_SA_INIT requests would lock out legitimate Initiators that have no resumption ticket. When under attack, the Responder SHOULD require Initiators presenting Session Resumption tickets to pass a return routability check by including the COOKIE notification in the IKE_SESSION_RESUME response message, as described in Section 4.3.2. of [RFC5723]. Note that the Responder SHOULD cache tickets for a short time to reject reused tickets (Section 4.3.1 of [RFC5723]); therefore, there should be no issue of half-open SAs resulting from replayed IKE_SESSION_RESUME messages.
レスポンダが攻撃を受けているとき、セッション再開チケット[RFC5723]を提示する以前に認証されたピアを優先する必要があります。ただし、すべてのIKE_SA_INIT要求をドロップすると再開チケットのない正当なイニシエーターがロックアウトされるため、レスポンダーは再開されたイニシエーターのみを提供するべきではありません（SHOULD NOT）。攻撃を受けた場合、レスポンダは、セクション4.3.2で説明されているように、IKE_SESSION_RESUME応答メッセージにCOOKIE通知を含めることにより、セッション再開チケットを提示するイニシエータが戻りルーティング可能性チェックに合格することを要求する必要があります（SHOULD）。 [RFC5723]の。 Responderは、再利用されたチケットを拒否するためにチケットを短時間キャッシュする必要があります（[RFC5723]のセクション4.3.1）。したがって、再生されたIKE_SESSION_RESUMEメッセージに起因するハーフオープンSAの問題はありません。
Several kinds of DoS attacks are possible on servers supported by IKE Session Resumption. See Section 9.3 of [RFC5723] for details.
IKEセッション再開によってサポートされるサーバーでは、いくつかの種類のDoS攻撃が可能です。詳細については、[RFC5723]のセクション9.3をご覧ください。
Once the IKE_SA_INIT exchange is finished, the Responder is waiting for the first message of the IKE_AUTH exchange from the Initiator. At this point, the Initiator is not yet authenticated, and this fact allows an attacker to perform an attack, described in Section 3. Instead of sending a properly formed and encrypted IKE_AUTH message, the attacker can just send arbitrary data, forcing the Responder to perform costly CPU operations to compute SK_* keys.
IKE_SA_INIT交換が完了すると、レスポンダはイニシエータからのIKE_AUTH交換の最初のメッセージを待ちます。この時点では、イニシエーターはまだ認証されていないため、攻撃者はセクション3で説明した攻撃を実行できます。攻撃者は、適切に形成され暗号化されたIKE_AUTHメッセージを送信する代わりに、任意のデータを送信してレスポンダに強制的に送信させることができます。 SK_ *キーを計算するためにコストのかかるCPU操作を実行します。
If the received IKE_AUTH message failed to decrypt correctly (or failed to pass the Integrity Check Value (ICV) check), then the Responder SHOULD still keep the computed SK_* keys, so that if it happened to be an attack, then an attacker cannot get an advantage of repeating the attack multiple times on a single IKE SA. The Responder can also use puzzles in the IKE_AUTH exchange as described in Section 7.2.
受信したIKE_AUTHメッセージが正しく復号化できなかった（または整合性チェック値（ICV）チェックに合格しなかった）場合でも、レスポンダーは計算されたSK_ *キーを保持する必要があるため、攻撃である場合、攻撃者は1つのIKE SAで攻撃を複数回繰り返す利点があります。セクション7.2で説明されているように、レスポンダはIKE_AUTH交換でパズルを使用することもできます。
In IKEv2, each side may use the "Hash and URL" Certificate Encoding to instruct the peer to retrieve certificates from the specified location (see Section 3.6 of [RFC7296] for details). Malicious Initiators can use this feature to mount a DoS attack on the Responder by providing a URL pointing to a large file possibly containing meaningless bits. While downloading the file, the Responder consumes CPU, memory, and network bandwidth.
IKEv2では、両側で「ハッシュとURL」の証明書エンコーディングを使用して、指定した場所から証明書を取得するようピアに指示できます（詳細については、[RFC7296]のセクション3.6を参照してください）。悪意のあるイニシエーターはこの機能を使用して、無意味なビットを含む可能性のある大きなファイルを指すURLを提供することにより、レスポンダーにDoS攻撃を仕掛けることができます。ファイルのダウンロード中、レスポンダはCPU、メモリ、およびネットワーク帯域幅を消費します。
To prevent this kind of attack, the Responder should not blindly download the whole file. Instead, it SHOULD first read the initial few bytes, decode the length of the ASN.1 structure from these bytes, and then download no more than the decoded number of bytes. Note that it is always possible to determine the length of ASN.1 structures used in IKEv2, if they are DER-encoded, by analyzing the first few bytes. However, since the content of the file being downloaded can be under the attacker's control, implementations should not blindly trust the decoded length and SHOULD check whether it makes sense before continuing to download the file. Implementations SHOULD also apply a configurable hard limit to the number of pulled bytes and SHOULD provide an ability for an administrator to either completely disable this feature or limit its use to a configurable list of trusted URLs.
この種の攻撃を防ぐために、レスポンダはファイル全体を盲目的にダウンロードしないでください。代わりに、最初の数バイトを読み取り、これらのバイトからASN.1構造の長さをデコードしてから、デコードしたバイト数以下をダウンロードする必要があります。最初の数バイトを分析することにより、DERvでエンコードされている場合、IKEv2で使用されるASN.1構造の長さを常に判別できることに注意してください。ただし、ダウンロードされるファイルのコンテンツは攻撃者の制御下にある可能性があるため、実装はデコードされた長さを盲目的に信頼してはならず、ファイルのダウンロードを続行する前にそれが意味があるかどうかを確認する必要があります。実装では、プルされるバイト数に構成可能なハード制限を適用する必要があり（SHOULD）、管理者がこの機能を完全に無効にするか、その使用を信頼できるURLの構成可能なリストに制限する機能を提供する必要があります。
IKE fragmentation described in [RFC7383] allows IKE peers to avoid IP fragmentation of large IKE messages. Attackers can mount several kinds of DoS attacks using IKE fragmentation. See Section 5 of [RFC7383] for details on how to mitigate these attacks.
[RFC7383]で説明されているIKEフラグメンテーションにより、IKEピアは大きなIKEメッセージのIPフラグメンテーションを回避できます。攻撃者は、IKEフラグメンテーションを使用して数種類のDoS攻撃を仕掛けることができます。これらの攻撃を緩和する方法の詳細については、[RFC7383]のセクション5を参照してください。
Once an IKE SA is created, there is usually only a limited amount of IKE messages exchanged. This IKE traffic consists of exchanges aimed to create additional Child SAs, IKE rekeys, IKE deletions, and IKE liveness tests. Some of these exchanges require relatively little resources (like a liveness check), while others may be resource consuming (like creating or rekeying a Child SA with DH exchange).
IKE SAが作成されると、通常、交換されるIKEメッセージの量は制限されます。このIKEトラフィックは、追加の子SA、IKEキー再生成、IKE削除、およびIKE活性テストの作成を目的とした交換で構成されています。これらの交換の一部は、比較的少ないリソース（活性チェックなど）を必要としますが、他のリソースは（DH交換で子SAを作成または再キーイングするなど）リソースを消費する場合があります。
Since any endpoint can initiate a new exchange, there is a possibility that a peer would initiate too many exchanges that could exhaust host resources. For example, the peer can perform endless continuous Child SA rekeying or create an overwhelming number of Child SAs with the same Traffic Selectors, etc. Such behavior can be caused by broken implementations, misconfiguration, or as an intentional attack. The latter becomes more of a real threat if the peer uses NULL Authentication, as described in [RFC7619]. In this case, the peer remains anonymous, allowing it to escape any responsibility for its behavior. See Section 3 of [RFC7619] for details on how to mitigate attacks when using NULL Authentication.
どのエンドポイントも新しい交換を開始できるため、ピアがホストリソースを使い果たす可能性のある交換を開始しすぎる可能性があります。たとえば、ピアは、エンドレスで継続的な子SAのキー再生成を実行したり、同じトラフィックセレクターなどで圧倒的な数の子SAを作成したりできます。このような動作は、実装の破損、設定の誤り、または意図的な攻撃が原因である可能性があります。 [RFC7619]で説明されているように、ピアがNULL認証を使用する場合、後者はより現実的な脅威になります。この場合、ピアは匿名のままで、動作の責任を逃れることができます。 NULL認証を使用する場合の攻撃を緩和する方法の詳細については、[RFC7619]のセクション3を参照してください。
The following recommendations apply especially for NULL-authenticated IKE sessions, but also apply to authenticated IKE sessions, with the difference that in the latter case, the identified peer can be locked out.
次の推奨事項は、特にNULL認証されたIKEセッションに適用されますが、認証されたIKEセッションにも適用されますが、後者の場合、識別されたピアがロックアウトされる可能性があります。
o If the IKEv2 window size is greater than one, peers are able to initiate multiple simultaneous exchanges that increase host resource consumption. Since there is no way in IKEv2 to decrease window size once it has been increased (see Section 2.3 of [RFC7296]), the window size cannot be dynamically adjusted depending on the load. It is NOT RECOMMENDED to allow an IKEv2 window size greater than one when NULL Authentication has been used.
o IKEv2ウィンドウサイズが1より大きい場合、ピアはホストリソースの消費を増やす複数の同時交換を開始できます。 IKEv2ではウィンドウサイズを増やした後でそれを減らす方法がないため（[RFC7296]のセクション2.3を参照）、負荷に応じてウィンドウサイズを動的に調整することはできません。 NULL認証が使用されている場合、1より大きいIKEv2ウィンドウサイズを許可することはお勧めしません。
o If a peer initiates an abusive amount of CREATE_CHILD_SA exchanges to rekey IKE SAs or Child SAs, the Responder SHOULD reply with TEMPORARY_FAILURE notifications indicating the peer must slow down their requests.
o ピアが大量のCREATE_CHILD_SA交換を開始してIKE SAまたは子SAのキーを再生成する場合、レスポンダーは、ピアが要求を遅くする必要があることを示すTEMPORARY_FAILURE通知で応答する必要があります（SHOULD）。
o If a peer creates many Child SAs with the same or overlapping Traffic Selectors, implementations MAY respond with the NO_ADDITIONAL_SAS notification.
o ピアが同じまたは重複するトラフィックセレクターで多数の子SAを作成する場合、実装はNO_ADDITIONAL_SAS通知で応答する場合があります。
o If a peer initiates many exchanges of any kind, the Responder MAY introduce an artificial delay before responding to each request message. This delay would decrease the rate the Responder needs to process requests from any particular peer and frees up resources on the Responder that can be used for answering legitimate clients. If the Responder receives retransmissions of the request message during the delay period, the retransmitted messages MUST be silently discarded. The delay must be short enough to avoid legitimate peers deleting the IKE SA due to a timeout. It is believed that a few seconds is enough. Note, however, that even a few seconds may be too long when settings rely on an immediate response to the request message, e.g., for the purposes of quick detection of a dead peer.
o ピアがあらゆる種類の多くの交換を開始する場合、レスポンダは各要求メッセージに応答する前に人為的な遅延を導入してもよい（MAY）。この遅延により、レスポンダーが特定のピアからの要求を処理するために必要な速度が低下し、正当なクライアントへの応答に使用できるレスポンダー上のリソースが解放されます。レスポンダが遅延期間中に要求メッセージの再送信を受信した場合、再送信されたメッセージは通知なく破棄されなければなりません（MUST）。遅延は、正当なピアがタイムアウトのためにIKE SAを削除するのを防ぐのに十分なほど短くなければなりません。数秒で十分と考えられています。ただし、設定が要求メッセージへの即時応答に依存している場合、たとえば、停止したピアを迅速に検出するために、数秒でも長すぎる可能性があることに注意してください。
o If these countermeasures are inefficient, implementations MAY delete the IKE SA with an offending peer by sending Delete Payload.
o これらの対策が非効率的である場合、実装はDelete Payloadを送信することにより、問題のあるピアを持つIKE SAを削除することができます（MAY）。
In IKE, a client can request various configuration attributes from the server. Most often, these attributes include internal IP addresses. Malicious clients can try to exhaust a server's IP address pool by continuously requesting a large number of internal addresses. Server implementations SHOULD limit the number of IP addresses allocated to any particular client. Note, this is not possible with clients using NULL Authentication, since their identity cannot be verified.
IKEでは、クライアントはサーバーにさまざまな構成属性を要求できます。ほとんどの場合、これらの属性には内部IPアドレスが含まれます。悪意のあるクライアントは、多数の内部アドレスを継続的に要求することにより、サーバーのIPアドレスプールを使い果たす可能性があります。サーバー実装は、特定のクライアントに割り当てられるIPアドレスの数を制限する必要があります（SHOULD）。 NULL認証を使用するクライアントでは、身元を確認できないため、これは不可能です。
This section outlines a plan for defending a Responder from a DDoS attack based on the techniques described earlier. The numbers given here are not normative, and their purpose is to illustrate the configurable parameters needed for surviving DDoS attacks.
このセクションでは、前述の手法に基づいてDDoS攻撃からレスポンダーを防御するための計画の概要を説明します。ここに示す数値は規範的ではなく、その目的は、DDoS攻撃を生き残るために必要な構成可能なパラメーターを説明することです。
Implementations are deployed in different environments, so it is RECOMMENDED that the parameters be settable. For example, most commercial products are required to undergo benchmarking where the IKE SA establishment rate is measured. Benchmarking is indistinguishable from a DoS attack, and the defenses described in this document may defeat the benchmark by causing exchanges to fail or to take a long time to complete. Parameters SHOULD be tunable to allow for benchmarking (if only by turning DDoS protection off).
実装はさまざまな環境にデプロイされるため、パラメーターを設定可能にすることをお勧めします。たとえば、ほとんどの市販製品は、IKE SA確立率が測定されるベンチマークを受ける必要があります。ベンチマークはDoS攻撃と区別がつかず、このドキュメントで説明されている防御策は、交換が失敗したり、完了までに長い時間がかかることにより、ベンチマークを打ち負かす可能性があります。パラメータは、ベンチマークを可能にするために調整可能である必要があります（DDoS保護をオフにすることによってのみ）。
Since all countermeasures may cause delays and additional work for the Initiators, they SHOULD NOT be deployed unless an attack is likely to be in progress. To minimize the burden imposed on Initiators, the Responder should monitor incoming IKE requests for two scenarios:
すべての対策はイニシエーターに遅延と追加の作業を引き起こす可能性があるため、攻撃が進行している可能性が高い場合を除いて、展開しないでください。イニシエーターに課される負荷を最小限に抑えるために、レスポンダーは2つのシナリオで着信IKE要求を監視する必要があります。
1. A general DDoS attack. Such an attack is indicated by a high number of concurrent half-open SAs, a high rate of failed IKE_AUTH exchanges, or a combination of both. For example, consider a Responder that has 10,000 distinct peers of which at peak, 7,500 concurrently have VPN tunnels. At the start of peak time, 600 peers might establish tunnels within any given minute, and tunnel establishment (both IKE_SA_INIT and IKE_AUTH) takes anywhere from 0.5 to 2 seconds. For this Responder, we expect there to be less than 20 concurrent half-open SAs, so having 100 concurrent half-open SAs can be interpreted as an indication of an attack. Similarly, IKE_AUTH request decryption failures should never happen. Supposing that the tunnels are established using Extensible Authentication Protocol (EAP) (see Section 2.16 of [RFC7296]), users may be expected to enter a wrong password about 20% of the time. So we'd expect 125 wrong password failures a minute. If we get IKE_AUTH decryption failures from multiple sources more than once per second, or EAP failures more than 300 times per minute, this can also be an indication of a DDoS attack.
1. 一般的なDDoS攻撃。このような攻撃は、多数の同時ハーフオープンSA、高率の失敗したIKE_AUTH交換、またはその両方の組み合わせによって示されます。たとえば、10,000の異なるピアがあり、ピーク時に7,500が同時にVPNトンネルを持つレスポンダを考えてみます。ピーク時間の開始時に、600のピアが指定された1分以内にトンネルを確立する可能性があり、トンネルの確立（IKE_SA_INITとIKE_AUTHの両方）には0.5〜2秒かかります。このレスポンダの場合、同時ハーフオープンSAは20未満になると予想されるため、同時オープンSAが100になると、攻撃の兆候と解釈できます。同様に、IKE_AUTH要求の復号化の失敗は発生しません。トンネルが拡張認証プロトコル（EAP）を使用して確立されているとすると（[RFC7296]のセクション2.16を参照）、ユーザーは約20％の時間、間違ったパスワードを入力することが期待される場合があります。したがって、1分間に125回の間違ったパスワードの失敗が予想されます。複数のソースから1秒間に1回以上IKE_AUTH復号化エラーが発生するか、1分あたり300回を超えるEAPエラーが発生する場合は、DDoS攻撃の兆候である可能性もあります。
2. An attack from a particular IP address or prefix. Such an attack is indicated by an inordinate amount of half-open SAs from a specific IP address or prefix, or an inordinate amount of IKE_AUTH failures. A DDoS attack may be viewed as multiple such attacks. If these are mitigated successfully, there will not be a need to enact countermeasures on all Initiators. For example, measures might be 5 concurrent half-open SAs, 1 decrypt failure, or 10 EAP failures within a minute.
2. 特定のIPアドレスまたはプレフィックスからの攻撃。このような攻撃は、特定のIPアドレスまたはプレフィックスからの異常に多くのハーフオープンSA、または異常な量のIKE_AUTHの失敗によって示されます。 DDoS攻撃は、そのような複数の攻撃と見なされる場合があります。これらが問題なく軽減された場合、すべてのイニシエーターに対策を実施する必要はありません。たとえば、1分間に5つの同時ハーフオープンSA、1つの復号化失敗、または10のEAP失敗が測定される場合があります。
Note that using countermeasures against an attack from a particular IP address may be enough to avoid the overload on the half-open SA database. In this case, the number of failed IKE_AUTH exchanges will never exceed the threshold of attack detection.
特定のIPアドレスからの攻撃に対する対策を使用すれば、ハーフオープンSAデータベースの過負荷を回避するのに十分であることに注意してください。この場合、失敗したIKE_AUTH交換の数が攻撃検出のしきい値を超えることはありません。
When there is no general DDoS attack, it is suggested that no cookie or puzzles be used. At this point, the only defensive measure is to monitor the number of half-open SAs, and set a soft limit per peer IP or prefix. The soft limit can be set to 3-5. If the puzzles are used, the puzzle difficulty SHOULD be set to such a level (number of zero bits) that all legitimate clients can handle it without degraded user experience.
一般的なDDoS攻撃がない場合は、Cookieやパズルを使用しないことをお勧めします。この時点での唯一の防御策は、ハーフオープンSAの数を監視し、ピアIPまたはプレフィックスごとにソフト制限を設定することです。ソフトリミットは3〜5に設定できます。パズルを使用する場合、パズルの難易度は、すべての正当なクライアントがユーザーエクスペリエンスを低下させることなく処理できるレベル（ゼロビットの数）に設定する必要があります（SHOULD）。
As soon as any kind of attack is detected, either a lot of initiations from multiple sources or a lot of initiations from a few sources, it is best to begin by requiring stateless cookies from all Initiators. This will mitigate attacks based on IP address spoofing and help avoid the need to impose a greater burden in the form of puzzles on the general population of Initiators. This makes the per-node or per-prefix soft limit more effective.
複数のソースからの多数の開始またはいくつかのソースからの多数の開始のいずれかの種類の攻撃が検出されるとすぐに、すべてのイニシエーターからのステートレスCookieを要求することから始めるのが最善です。これにより、IPアドレスのスプーフィングに基づく攻撃が軽減され、イニシエーターの一般的な集団にパズルという形で大きな負担をかける必要がなくなります。これにより、ノードごとまたはプレフィックスごとのソフト制限がより効果的になります。
When cookies are activated for all requests and the attacker is still managing to consume too many resources, the Responder MAY start to use puzzles for these requests or increase the difficulty of puzzles imposed on IKE_SA_INIT requests coming from suspicious nodes/ prefixes. This should still be doable by all legitimate peers, but the use of puzzles at a higher difficulty may degrade the user experience, for example, by taking up to 10 seconds to solve the puzzle.
すべてのリクエストでCookieがアクティブになり、攻撃者が依然として多くのリソースを消費している場合、レスポンダーはこれらのリクエストにパズルを使用し始めたり、疑わしいノード/プレフィックスからのIKE_SA_INITリクエストに課せられたパズルの難易度を高めたりする場合があります。これはまだすべての正当な仲間が実行できるはずですが、難易度の高いパズルを使用すると、たとえばパズルを解くのに最大10秒かかるなど、ユーザーエクスペリエンスが低下する可能性があります。
If the load on the Responder is still too great, and there are many nodes causing multiple half-open SAs or IKE_AUTH failures, the Responder MAY impose hard limits on those nodes.
それでもレスポンダの負荷が大きすぎて、多数のノードがハーフオープンSAまたはIKE_AUTHの失敗を引き起こしている場合、レスポンダはそれらのノードにハード制限を課してもよい（MAY）。
If it turns out that the attack is very widespread and the hard caps are not solving the issue, a puzzle MAY be imposed on all Initiators. Note that this is the last step, and the Responder should avoid this if possible.
攻撃が非常に広がっており、ハードキャップが問題を解決していないことが判明した場合、すべてのイニシエーターにパズルを課すことができます。これが最後のステップであり、レスポンダは可能であればこれを回避する必要があることに注意してください。
This section describes how the puzzle mechanism is used in IKEv2. It is organized as follows. Section 7.1 describes using puzzles in the IKE_SA_INIT exchange and Section 7.2 describes using puzzles in the IKE_AUTH exchange. Both sections are divided into subsections describing how puzzles should be presented, solved, and processed by the Initiator and the Responder.
このセクションでは、IKEv2でパズルメカニズムを使用する方法について説明します。以下のように構成されています。セクション7.1では、IKE_SA_INIT交換でのパズルの使用について説明し、セクション7.2では、IKE_AUTH交換でのパズルの使用について説明します。両方のセクションは、イニシエーターとレスポンダーがパズルを提示、解決、処理する方法を説明するサブセクションに分かれています。
The IKE Initiator indicates the desire to create a new IKE SA by sending an IKE_SA_INIT request message. The message may optionally contain a COOKIE notification if this is a repeated request performed after the Responder's demand to return a cookie.
IKEイニシエーターは、IKE_SA_INIT要求メッセージを送信して、新しいIKE SAを作成することを示します。 Cookieを返すようにレスポンダの要求の後に実行された繰り返し要求である場合、メッセージにはCOOKIE通知がオプションで含まれる場合があります。
HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] -->
Figure 1: Initial IKE_SA_INIT Request
図1：最初のIKE_SA_INIT要求
According to the plan, described in Section 6, the IKE Responder monitors incoming requests to detect whether it is under attack. If the Responder learns that a DoS or DDoS attack is likely to be in progress, then its actions depend on the volume of the attack. If the volume is moderate, then the Responder requests the Initiator to return a cookie. If the volume is high to such an extent that puzzles need to be used for defense, then the Responder requests the Initiator to solve a puzzle.
セクション6で説明した計画に従って、IKE Responderは着信要求を監視して、攻撃を受けているかどうかを検出します。 DoSまたはDDoS攻撃が進行中である可能性が高いことをレスポンダーが学習した場合、そのアクションは攻撃の量によって異なります。ボリュームが中程度の場合、レスポンダはイニシエータにCookieを返すように要求します。防御のためにパズルを使用する必要があるほどボリュームが大きい場合、レスポンダは開始者にパズルを解くように要求します。
The Responder MAY choose to process some fraction of IKE_SA_INIT requests without presenting a puzzle while being under attack to allow legacy clients, that don't support puzzles, to have a chance to be served. The decision whether to process any particular request must be probabilistic, with the probability depending on the Responder's load (i.e., on the volume of attack). The requests that don't contain the COOKIE notification MUST NOT participate in this lottery. In other words, the Responder must first perform a return routability check before allowing any legacy client to be served if it is under attack. See Section 7.1.4 for details.
レスポンダは、攻撃を受けている間、パズルを提示せずにIKE_SA_INITリクエストの一部を処理して、パズルをサポートしていないレガシークライアントにサービスを提供できるようにする場合があります。特定の要求を処理するかどうかの決定は確率的である必要があり、確率はレスポンダの負荷（つまり、攻撃の量）に依存します。 COOKIE通知を含まないリクエストは、この宝くじに参加してはなりません。つまり、レスポンダは、攻撃を受けている場合にレガシークライアントへのサービス提供を許可する前に、まず返送可能性チェックを実行する必要があります。詳細については、セクション7.1.4を参照してください。
If the Responder makes a decision to use puzzles, then it includes two notifications in its response message -- the COOKIE notification and the PUZZLE notification. Note that the PUZZLE notification MUST always be accompanied with the COOKIE notification, since the content of the COOKIE notification is used as an input data when solving the puzzle. The format of the PUZZLE notification is described in Section 8.1.
レスポンダがパズルを使用することを決定した場合、応答メッセージにはCOOKIE通知とPUZZLE通知の2つの通知が含まれます。 COOKIE通知の内容はパズルを解くときに入力データとして使用されるため、PUZZLE通知には常にCOOKIE通知を添付する必要があることに注意してください。 PUZZLE通知のフォーマットについては、セクション8.1で説明しています。
<-- HDR, N(COOKIE), N(PUZZLE), [V+][N+]
Figure 2: IKE_SA_INIT Response Containing Puzzle
ふぃぐれ ２： いけ＿さ＿いにＴ れｓぽんせ こんたいにんｇ ぷっ→え
The presence of these notifications in an IKE_SA_INIT response message indicates to the Initiator that it should solve the puzzle to have a better chance to be served.
IKE_SA_INIT応答メッセージにこれらの通知が含まれていると、イニシエーターがパズルを解いてサービスを受ける可能性が高まることを示します。
The PUZZLE notification contains the difficulty level of the puzzle -- the minimum number of trailing zero bits that the result of PRF must contain. In diverse environments, it is nearly impossible for the Responder to set any specific difficulty level that will result in roughly the same amount of work for all Initiators, because computation power of different Initiators may vary by an order of magnitude, or even more. The Responder may set the difficulty level to 0, meaning that the Initiator is requested to spend as much power to solve a puzzle as it can afford. In this case, no specific value of ZBC is required from the Initiator; however, the larger the ZBC that the Initiator is able to get, the better the chance is that it will be served by the Responder. In diverse environments, it is RECOMMENDED that the Initiator set the difficulty level to 0, unless the attack volume is very high.
PUZZLE通知には、パズルの難易度（PRFの結果に含まれる必要がある後続ゼロビットの最小数）が含まれています。さまざまな環境では、レスポンダが特定の難易度を設定して、すべてのイニシエータにほぼ同じ量の作業をもたらすことはほぼ不可能です。これは、異なるイニシエータの計算能力が1桁またはそれ以上異なる場合があるためです。レスポンダは難易度を0に設定できます。これは、イニシエータがパズルを解決するのに十分なパワーを費やすことを要求されることを意味します。この場合、イニシエーターからZBCの特定の値は必要ありません。ただし、イニシエーターが取得できるZBCが大きいほど、レスポンダーによって提供される可能性が高くなります。多様な環境では、攻撃量が非常に大きくない限り、イニシエーターが難易度を0に設定することをお勧めします。
If the Responder sets a non-zero difficulty level, then the level SHOULD be determined by analyzing the volume of the attack. The Responder MAY set different difficulty levels to different requests depending on the IP address the request has come from.
レスポンダがゼロ以外の難易度レベルを設定する場合、レベルは攻撃の量を分析することによって決定される必要があります。レスポンダは、リクエストの送信元のIPアドレスに応じて、リクエストごとに異なる難易度を設定できます（MAY）。
The PUZZLE notification also contains an identifier of the algorithm that is used by the Initiator to compute the puzzle.
PUZZLE通知には、開始者がパズルを計算するために使用するアルゴリズムの識別子も含まれています。
Cryptographic algorithm agility is considered an important feature for modern protocols [RFC7696]. Algorithm agility ensures that a protocol doesn't rely on a single built-in set of cryptographic algorithms but has a means to replace one set with another and negotiate new algorithms with the peer. IKEv2 fully supports cryptographic algorithm agility for its core operations.
暗号化アルゴリズムの俊敏性は、最新のプロトコル[RFC7696]の重要な機能と見なされています。アルゴリズムの俊敏性により、プロトコルは単一の組み込みの暗号化アルゴリズムのセットに依存せず、1つのセットを別のセットに置き換え、新しいアルゴリズムをピアとネゴシエートする手段が確保されます。 IKEv2は、コアオペレーションの暗号化アルゴリズムの俊敏性を完全にサポートしています。
To support crypto-agility in case of puzzles, the algorithm that is used to compute a puzzle needs to be negotiated during the IKE_SA_INIT exchange. The negotiation is performed as follows. The initial request message from the Initiator contains an SA payload containing a list of transforms of different types. In that manner, the Initiator asserts that it supports all transforms from this list and can use any of them in the IKE SA being established. The Responder parses the received SA payload and finds mutually supported transforms of type PRF. The Responder selects the preferred PRF from the list of mutually supported ones and includes it into the PUZZLE notification. There is no requirement that the PRF selected for puzzles be the same as the PRF that is negotiated later for use in core IKE SA crypto operations. If there are no mutually supported PRFs, then IKE SA negotiation will fail anyway and there is no reason to return a puzzle. In this case, the Responder returns a NO_PROPOSAL_CHOSEN notification. Note that PRF is a mandatory transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of [RFC7296]), and at least one transform of this type is always present in the SA payload in an IKE_SA_INIT request message.
パズルの場合に暗号アジリティをサポートするには、パズルの計算に使用されるアルゴリズムをIKE_SA_INIT交換中にネゴシエートする必要があります。交渉は次のように行われます。イニシエーターからの最初の要求メッセージには、さまざまなタイプの変換のリストを含むSAペイロードが含まれています。そのようにして、イニシエーターは、このリストからのすべての変換をサポートし、確立されているIKE SAでそれらのいずれかを使用できると断言します。レスポンダは受信したSAペイロードを解析し、相互にサポートされているPRFタイプの変換を見つけます。レスポンダは、相互にサポートされているPRFのリストから優先PRFを選択し、PUZZLE通知に含めます。パズル用に選択されたPRFが、コアIKE SA暗号化操作で使用するために後でネゴシエートされるPRFと同じである必要はありません。相互にサポートされているPRFがない場合、IKE SAネゴシエーションはいずれにしても失敗し、パズルを返す理由がありません。この場合、レスポンダはNO_PROPOSAL_CHOSEN通知を返します。 PRFはIKE SAの必須の変換タイプであり（[RFC7296]のセクション3.3.2および3.3.3を参照）、このタイプの少なくとも1つの変換がIKE_SA_INIT要求メッセージのSAペイロードに常に存在することに注意してください。
If the Responder supports puzzles, then a cookie should be computed in such a manner that the Responder is able to learn some important information from the sole cookie, when it is later returned back by the Initiator. In particular, the Responder SHOULD be able to learn the following information:
レスポンダがパズルをサポートしている場合、Cookieは、後でイニシエータによって返されたときに、レスポンダが唯一のCookieからいくつかの重要な情報を学習できるように計算する必要があります。特に、レスポンダは次の情報を学習できる必要があります（SHOULD）。
o Whether the puzzle was given to the Initiator or only the cookie was requested.
o パズルがイニシエーターに与えられたか、Cookieのみが要求されたか。
o The difficulty level of the puzzle given to the Initiator.
o イニシエーターに与えられたパズルの難易度。
o The number of consecutive puzzles given to the Initiator.
o イニシエーターに与えられた連続したパズルの数。
o The amount of time the Initiator spent to solve the puzzles. This can be calculated if the cookie is timestamped.
o イニシエーターがパズルを解くために費やした時間。これは、Cookieにタイムスタンプが付けられている場合に計算できます。
This information helps the Responder to make a decision whether to serve this request or demand more work from the Initiator.
この情報は、レスポンダーがこの要求を処理するか、イニシエーターにさらに作業を要求するかを決定するのに役立ちます。
One possible approach to get this information is to encode it in the cookie. The format of such encoding is an implementation detail of the Responder, as the cookie would remain an opaque block of data to the Initiator. If this information is encoded in the cookie, then the Responder MUST make it integrity protected, so that any intended or accidental alteration of this information in the returned cookie is detectable. So, the cookie would be generated as:
この情報を取得する1つの可能なアプローチは、それをCookieにエンコードすることです。 Cookieはイニシエーターへの不透明なデータブロックのままであるため、このようなエンコードの形式はレスポンダーの実装の詳細です。この情報がCookieにエンコードされている場合、レスポンダは完全性を保護する必要があります。これにより、返されたCookie内のこの情報の意図的または偶発的な変更が検出可能になります。したがって、Cookieは次のように生成されます。
Cookie = <VersionIDofSecret> | <AdditionalInfo> |
Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>)
Note that according to Section 2.6 of [RFC7296], the size of the cookie cannot exceed 64 bytes.
[RFC7296]のセクション2.6によると、Cookieのサイズは64バイトを超えることはできません。
Alternatively, the Responder may generate a cookie as suggested in Section 2.6 of [RFC7296], but associate the additional information, using local storage identified with the particular version of the secret. In this case, the Responder should have different secrets for every combination of difficulty level and number of consecutive puzzles, and should change the secrets periodically, keeping a few previous versions, to be able to calculate how long ago a cookie was generated.
または、[RFC7296]のセクション2.6で提案されているように、レスポンダはCookieを生成しますが、特定のバージョンのシークレットで識別されるローカルストレージを使用して、追加情報を関連付けます。この場合、レスポンダーは難易度と連続するパズルの数の組み合わせごとに異なるシークレットを持ち、以前のバージョンをいくつか維持しながらシークレットを定期的に変更して、Cookieが生成されてからどれくらい前に計算できるようにする必要があります。
The Responder may also combine these approaches. This document doesn't mandate how the Responder learns this information from a cookie.
レスポンダはこれらのアプローチを組み合わせることもできます。このドキュメントでは、レスポンダーがCookieからこの情報をどのように学習するかを規定していません。
When selecting cookie generation, algorithm implementations MUST ensure that an attacker gains no or insignificant benefit from reusing puzzle solutions in several requests. See Section 10 for details.
Cookieの生成を選択する場合、アルゴリズムの実装では、攻撃者が複数のリクエストでパズルソリューションを再利用してもまったくメリットがないか、わずかなメリットしか得られないようにする必要があります。詳細については、セクション10を参照してください。
If the Initiator receives a puzzle but it doesn't support puzzles, then it will ignore the PUZZLE notification as an unrecognized status notification (in accordance with Section 3.10.1 of [RFC7296]). The Initiator MAY ignore the PUZZLE notification if it is not willing to spend resources to solve the puzzle of the requested difficulty, even if it supports puzzles. In both cases, the Initiator acts as described in Section 2.6 of [RFC7296] -- it restarts the request and includes the received COOKIE notification in it. The Responder should be able to distinguish the situation when it just requested a cookie from the situation where the puzzle was given to the Initiator, but the Initiator for some reason ignored it.
イニシエーターがパズルを受信しても、パズルをサポートしていない場合、パズル通知は認識されないステータス通知として無視されます（[RFC7296]のセクション3.10.1に従って）。イニシエーターは、パズルをサポートしている場合でも、要求された難易度のパズルを解決するためにリソースを費やす気がない場合、パズル通知を無視する場合があります。どちらの場合も、イニシエーターは[RFC7296]のセクション2.6に記載されているように機能します。イニシエーターはリクエストを再開し、受信したCOOKIE通知を含めます。レスポンダーは、Cookieを要求したときの状況と、パズルがイニシエーターに渡された状況を区別できるはずですが、何らかの理由でイニシエーターはそれを無視しました。
If the received message contains a PUZZLE notification and doesn't contain a COOKIE notification, then this message is malformed because it requests to solve the puzzle but doesn't provide enough information to allow the puzzle to be solved. In this case, the Initiator MUST ignore the received message and continue to wait until either a valid PUZZLE notification is received or the retransmission timer fires. If it fails to receive a valid message after several retransmissions of IKE_SA_INIT requests, then this means that something is wrong and the IKE SA cannot be established.
受信したメッセージにPUZZLE通知が含まれ、COOKIE通知が含まれていない場合、パズルの解決を要求するが、パズルを解決するのに十分な情報が提供されないため、このメッセージは不正な形式です。この場合、イニシエーターは受信したメッセージを無視し、有効なPUZZLE通知が受信されるか、再送信タイマーが起動するまで待機し続けなければなりません（MUST）。 IKE_SA_INIT要求を数回再送信した後、有効なメッセージの受信に失敗した場合、これは何か問題があり、IKE SAを確立できないことを意味します。
If the Initiator supports puzzles and is ready to solve them, then it tries to solve the given puzzle. After the puzzle is solved, the Initiator restarts the request and returns back to the Responder the puzzle solution in a new payload called a Puzzle Solution (PS) payload (see Section 8.2) along with the received COOKIE notification.
イニシエーターがパズルをサポートし、それらを解決する準備ができている場合、指定されたパズルを解決しようとします。パズルが解決されると、イニシエーターは要求を再開し、受信したCOOKIE通知と共に、パズルソリューション（PS）ペイロード（セクション8.2を参照）と呼ばれる新しいペイロードのパズルソリューションをレスポンダに戻します。
HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] -->
Figure 3: IKE_SA_INIT Request Containing Puzzle Solution
ふぃぐれ ３： いけ＿さ＿いにＴ れくえｓｔ こんたいにんｇ ぷっ→え そぅちおん
General principles of constructing puzzles in IKEv2 are described in Section 4.4. They can be summarized as follows: given unpredictable string S and PRF, find N different keys Ki (where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at least the specified number of trailing zero bits. This specification requires that the puzzle solution contains 4 different keys (i.e., N=4).
IKEv2でパズルを構築する一般的な原則については、セクション4.4で説明しています。それらは次のように要約できます。予測不可能な文字列SとPRFが与えられた場合、そのPRFのN個の異なるキーKi（i = [1..N]）を見つけ、PRF（Ki、S）の結果が少なくとも指定された数になるようにします。後続ゼロビットの。この仕様では、パズルソリューションに4つの異なるキーが含まれている必要があります（つまり、N = 4）。
In the IKE_SA_INIT exchange, it is the cookie that plays the role of
unpredictable string S. In other words, in the IKE_SA_INIT, the task
for the IKE Initiator is to find the four different, equal-sized keys
Ki for the agreed upon PRF such that each result of PRF(Ki,cookie)
where i = [1..4] has a sufficient number of trailing zero bits. Only
the content of the COOKIE notification is used in puzzle calculation,
i.e., the header of the Notify payload is not included.
Note that puzzles in the IKE_AUTH exchange are computed differently than in the IKE_SA_INIT_EXCHANGE. See Section 7.2.3 for details.
IKE_AUTH交換のパズルは、IKE_SA_INIT_EXCHANGEとは異なる方法で計算されることに注意してください。詳細については、セクション7.2.3を参照してください。
The received request must at least contain a COOKIE notification. Otherwise, it is an initial request and in this case, it MUST be processed according to Section 7.1. First, the cookie MUST be checked for validity. If the cookie is invalid, then the request is treated as initial and is processed according to Section 7.1. It is RECOMMENDED that a new cookie is requested in this case.
受信したリクエストには、少なくともCOOKIE通知が含まれている必要があります。それ以外の場合、それは最初のリクエストであり、この場合、セクション7.1に従って処理する必要があります。まず、Cookieの有効性を確認する必要があります。 Cookieが無効な場合、リクエストは初期として扱われ、セクション7.1に従って処理されます。この場合、新しいCookieを要求することをお勧めします。
If the cookie is valid, then some important information is learned from it or from local state based on the identifier of the cookie's secret (see Section 7.1.1.3 for details). This information helps the Responder to sort out incoming requests, giving more priority to those that were created by spending more of the Initiator's resources.
Cookieが有効な場合、Cookieのシークレットの識別子に基づいて、Cookieまたはローカル状態からいくつかの重要な情報が学習されます（詳細は、セクション7.1.1.3を参照）。この情報は、レスポンダーが着信要求を整理するのに役立ち、イニシエーターのリソースをより多く費やすことによって作成された要求を優先します。
First, the Responder determines if it requested only a cookie or presented a puzzle to the Initiator. If no puzzle was given, this means that at the time the Responder requested a cookie, it didn't detect the DoS or DDoS attack, or the attack volume was low. In this case, the received request message must not contain the PS payload, and this payload MUST be ignored if the message contains a PS payload for any reason. Since no puzzle was given, the Responder marks the request with the lowest priority since the Initiator spent little resources creating it.
最初に、レスポンダはCookieのみをリクエストしたか、イニシエータにパズルを提示したかを判断します。パズルが与えられなかった場合、これは、レスポンダーがCookieを要求したときに、DoSまたはDDoS攻撃を検出しなかったか、攻撃量が少なかったことを意味します。この場合、受信したリクエストメッセージにPSペイロードを含めることはできません。何らかの理由でメッセージにPSペイロードが含まれている場合、このペイロードを無視する必要があります。パズルが与えられなかったので、イニシエーターがそれを作成するためにほとんどリソースを費やさなかったので、レスポンダーは最も低い優先度でリクエストをマークします。
If the Responder learns from the cookie that the puzzle was given to the Initiator, then it looks for the PS payload to determine whether its request to solve the puzzle was honored or not. If the incoming message doesn't contain a PS payload, this means that the Initiator either doesn't support puzzles or doesn't want to deal with them. In either case, the request is marked with the lowest priority since the Initiator spent little resources creating it.
レスポンダーは、パズルからイニシエーターに渡されたことをCookieから学習すると、PSペイロードを探して、パズルを解くための要求が受け入れられたかどうかを判断します。着信メッセージにPSペイロードが含まれていない場合、これは、イニシエーターがパズルをサポートしていないか、パズルを処理したくないことを意味します。どちらの場合も、イニシエーターが作成にほとんどリソースを費やさなかったため、リクエストは最低の優先度でマークされています。
If a PS payload is found in the message, then the Responder MUST verify the puzzle solution that it contains. The solution is interpreted as four different keys. The result of using each of them in the PRF (as described in Section 7.1.3) must contain at least the requested number of trailing zero bits. The Responder MUST check all of the four returned keys.
PSペイロードがメッセージで見つかった場合、レスポンダは、それが含むパズルソリューションを検証する必要があります。ソリューションは4つの異なるキーとして解釈されます。 PRFでそれらをそれぞれ使用した結果（セクション7.1.3で説明）には、少なくとも要求された数の後続ゼロビットが含まれている必要があります。レスポンダは返された4つのキーすべてをチェックする必要があります。
If any checked result contains fewer bits than were requested, this means that the Initiator spent less resources than expected by the Responder. This request is marked with the lowest priority.
チェックされた結果に含まれるビットが要求されたよりも少ない場合、これはイニシエーターが使用したリソースがレスポンダーの予想より少ないことを意味します。このリクエストは最低の優先度でマークされています。
If the Initiator provided the solution to the puzzle satisfying the requested difficulty level, or if the Responder didn't indicate any particular difficulty level (by setting the ZBC to 0) and the Initiator was free to select any difficulty level it can afford, then the priority of the request is calculated based on the following considerations:
イニシエーターが要求された難易度を満たすパズルの解決策を提供した場合、またはレスポンダーが特定の難易度（ZBCを0に設定することによって）を示さなかった場合、イニシエーターが提供できる難易度を自由に選択できます。リクエストの優先度は、以下の考慮事項に基づいて計算されます。
o The Responder MUST take the smallest number of trailing zero bits among the checked results and count it as the number of zero bits the Initiator solved for.
o レスポンダは、チェックされた結果の中で、トレーリングゼロビットの最小数を取り、イニシエーターが解決したゼロビットの数としてそれをカウントする必要があります。
o The higher number of zero bits the Initiator provides, the higher priority its request should receive.
o イニシエーターが提供するゼロビットの数が多いほど、要求が受け取る優先順位が高くなります。
o The more consecutive puzzles the Initiator solved, the higher priority it should receive.
o イニシエーターが解決したパズルが連続するほど、優先順位が高くなります。
o The more time the Initiator spent solving the puzzles, the higher priority it should receive.
o イニシエーターがパズルを解くのに費やした時間が長いほど、イニシエーターが受け取る優先順位は高くなります。
After the priority of the request is determined, the final decision whether to serve it or not is made.
要求の優先順位が決定された後、それを処理するかどうかの最終決定が行われます。
The Responder decides what to do with the request based on the request's priority and the Responder's current load. There are three possible actions:
レスポンダは、リクエストの優先度とレスポンダの現在の負荷に基づいて、リクエストの処理方法を決定します。 3つの可能なアクションがあります。
o Accept request.
o 要請を受け入れます。
o Reject request.
o リクエストを拒否します。
o Demand more work from the Initiator by giving it a new puzzle.
o イニシエーターに新しいパズルを与えることで、より多くの作業を要求します。
The Responder SHOULD accept an incoming request if its priority is high -- this means that the Initiator spent quite a lot of resources. The Responder MAY also accept some low-priority requests where the Initiators don't support puzzles. The percentage of accepted legacy requests depends on the Responder's current load.
優先度が高い場合、レスポンダは着信リクエストを受け入れる必要があります（SHOULD）。これは、イニシエータがかなりのリソースを費やしたことを意味します。レスポンダは、イニシエータがパズルをサポートしていない、いくつかの優先度の低いリクエストを受け入れることもできます（MAY）。受け入れられたレガシーリクエストの割合は、レスポンダの現在の負荷によって異なります。
If the Initiator solved the puzzle, but didn't spend much resources for it (the selected puzzle difficulty level appeared to be low and the Initiator solved it quickly), then the Responder SHOULD give it another puzzle. The more puzzles the Initiator solves the higher its chances are to be served.
イニシエーターがパズルを解決したが、多くのリソースを費やさなかった場合（選択したパズルの難易度は低く、イニシエーターはすぐに解決したように見えます）、レスポンダーは別のパズルを与える必要があります（SHOULD）。イニシエーターが解決するパズルが多いほど、提供される可能性が高くなります。
The details of how the Responder makes a decision for any particular request are implementation dependent. The Responder can collect all of the incoming requests for some short period of time, sort them out based on their priority, calculate the number of available memory slots for half-open IKE SAs, and then serve that number of requests from the head of the sorted list. The remainder of requests can be either discarded or responded to with new puzzle requests.
レスポンダが特定のリクエストに対して決定を行う方法の詳細は、実装に依存します。レスポンダは、すべての着信要求を短期間に収集し、優先順位に基づいてそれらを整理し、ハーフオープンIKE SAの使用可能なメモリスロットの数を計算し、その数の要求をサービスヘッドから提供できます。ソートされたリスト。残りのリクエストは破棄するか、新しいパズルリクエストで応答できます。
Alternatively, the Responder may decide whether to accept every incoming request with some kind of lottery, taking into account its priority and the available resources.
あるいは、レスポンダは、その優先度と使用可能なリソースを考慮して、何らかの種類の宝くじですべての着信要求を受け入れるかどうかを決定する場合があります。
Once the IKE_SA_INIT exchange is completed, the Responder has created a state and is waiting for the first message of the IKE_AUTH exchange from the Initiator. At this point, the Initiator has already passed the return routability check and has proved that it has performed some work to complete the IKE_SA_INIT exchange. However, the Initiator is not yet authenticated, and this allows a malicious Initiator to perform an attack, as described in Section 3. Unlike a DoS attack in the IKE_SA_INIT exchange, which is targeted on the Responder's memory resources, the goal of this attack is to exhaust a Responder's CPU power. The attack is performed by sending the first IKE_AUTH message containing arbitrary data. This costs nothing to the Initiator, but the Responder has to perform relatively costly operations when computing the DH shared secret and deriving SK_* keys to be able to verify authenticity of the message. If the Responder doesn't keep the computed keys after an unsuccessful verification of the IKE_AUTH message, then the attack can be repeated several times on the same IKE SA.
IKE_SA_INIT交換が完了すると、レスポンダは状態を作成し、イニシエータからのIKE_AUTH交換の最初のメッセージを待機します。この時点で、イニシエーターは既に返送可能性チェックに合格しており、IKE_SA_INIT交換を完了するためにいくつかの作業を実行したことを証明しています。ただし、イニシエーターはまだ認証されていないため、セクション3で説明されているように、悪意のあるイニシエーターが攻撃を実行できます。レスポンダーのメモリリソースを対象とするIKE_SA_INIT交換でのDoS攻撃とは異なり、この攻撃の目的はレスポンダのCPUパワーを使い果たす。攻撃は、任意のデータを含む最初のIKE_AUTHメッセージを送信することによって実行されます。これはイニシエーターには何の費用もかかりませんが、DH共有シークレットを計算し、SK_ *キーを導出してメッセージの信頼性を検証できるようにする場合、レスポンダーは比較的コストのかかる操作を実行する必要があります。 IKE_AUTHメッセージの検証に失敗した後、レスポンダが計算されたキーを保持しない場合、同じIKE SAで攻撃を数回繰り返すことができます。
The Responder can use puzzles to make this attack more costly for the Initiator. The idea is that the Responder includes a puzzle in the IKE_SA_INIT response message and the Initiator includes a puzzle solution in the first IKE_AUTH request message outside the Encrypted payload, so that the Responder is able to verify a puzzle solution before computing the DH shared secret.
レスポンダはパズルを使用して、この攻撃をイニシエータにとってよりコストのかかるものにすることができます。アイデアは、レスポンダーがIKE_SA_INIT応答メッセージにパズルを含み、イニシエーターが暗号化されたペイロードの外側の最初のIKE_AUTH要求メッセージにパズルソリューションを含めることにより、レスポンダーはDH共有シークレットを計算する前にパズルソリューションを検証できるというものです。
The Responder constantly monitors the amount of the half-open IKE SA states that receive IKE_AUTH messages that cannot be decrypted due to integrity check failures. If the percentage of such states is high and it takes an essential fraction of the Responder's computing power to calculate keys for them, then the Responder may assume that it is under attack and SHOULD use puzzles to make it harder for attackers.
レスポンダは、整合性チェックの失敗により復号化できないIKE_AUTHメッセージを受信するハーフオープンIKE SA状態の量を常に監視します。そのような状態のパーセンテージが高く、レスポンダのキーを計算するためにレスポンダの計算能力の本質的な部分を占める場合、レスポンダは攻撃を受けていると想定し、パズルを使用して攻撃者にとって困難にする必要があります。
The Responder requests the Initiator to solve a puzzle by including the PUZZLE notification in the IKE_SA_INIT response message. The Responder MUST NOT use puzzles in the IKE_AUTH exchange unless a puzzle has been previously presented and solved in the preceding IKE_SA_INIT exchange.
レスポンダは、IKE_SA_INIT応答メッセージにPUZZLE通知を含めることにより、パズルを解くようイニシエータに要求します。レスポンダーは、前のIKE_SA_INIT交換でパズルが以前に提示および解決されていない限り、IKE_AUTH交換でパズルを使用してはなりません（MUST NOT）。
<-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+]
Figure 4: IKE_SA_INIT Response Containing IKE_AUTH Puzzle
ふぃぐれ ４： いけ＿さ＿いにＴ れｓぽんせ こんたいにんｇ いけ＿あうＴＨ ぷっ→え
The difficulty level of the puzzle in the IKE_AUTH exchange should be chosen so that the Initiator would spend more time to solve the puzzle than the Responder to compute the DH shared secret and the keys needed to decrypt and verify the IKE_AUTH request message. On the other hand, the difficulty level should not be too high, otherwise legitimate clients will experience an additional delay while establishing the IKE SA.
IKE_AUTH交換でのパズルの難易度は、イニシエーターがDH共有シークレットとIKE_AUTH要求メッセージを復号化および検証するために必要なキーを計算するためにレスポンダーよりもパズルを解くのに多くの時間を費やすように選択する必要があります。一方、難易度は高すぎないようにしてください。そうしないと、正当なクライアントがIKE SAの確立中に追加の遅延が発生します。
Note that since puzzles in the IKE_AUTH exchange are only allowed to be used if they were used in the preceding IKE_SA_INIT exchange, the Responder would be able to roughly estimate the computational power of the Initiator and select the difficulty level accordingly. Unlike puzzles in the IKE_SA_INIT, the requested difficulty level for IKE_AUTH puzzles MUST NOT be 0. In other words, the Responder must always set a specific difficulty level and must not let the Initiator choose it on its own.
IKE_AUTH交換のパズルは、前のIKE_SA_INIT交換で使用された場合にのみ使用できるため、レスポンダはイニシエータの計算能力を大まかに推定し、それに応じて難易度を選択できることに注意してください。 IKE_SA_INITのパズルとは異なり、IKE_AUTHパズルの要求された難易度は0であってはなりません。つまり、レスポンダーは常に特定の難易度を設定し、イニシエーターが自分で選択するようにしてはなりません。
The algorithm for the puzzle is selected as described in Section 7.1.1.2. There is no requirement that the algorithm for the puzzle in the IKE_SA INIT exchange be the same as the algorithm for the puzzle in the IKE_AUTH exchange; however, it is expected that in most cases they will be the same.
パズルのアルゴリズムは、セクション7.1.1.2で説明されているように選択されます。 IKE_SA INIT交換のパズルのアルゴリズムがIKE_AUTH交換のパズルのアルゴリズムと同じである必要はありません。ただし、ほとんどの場合、それらは同じになると予想されます。
If the IKE_SA_INIT regular response message (i.e., the message containing SA, KE, NONCE payloads) contains the PUZZLE notification and the Initiator supports puzzles, it MUST solve the puzzle. Note that puzzle construction in the IKE_AUTH exchange differs from the puzzle construction in the IKE_SA_INIT exchange and is described in Section 7.2.3. Once the puzzle is solved, the Initiator sends the IKE_AUTH request message containing the PS payload.
IKE_SA_INIT通常の応答メッセージ（つまり、SA、KE、NONCEペイロードを含むメッセージ）にPUZZLE通知が含まれていて、イニシエーターがパズルをサポートしている場合は、パズルを解決する必要があります。 IKE_AUTH交換でのパズルの構築は、IKE_SA_INIT交換でのパズルの構築とは異なり、セクション7.2.3で説明されています。パズルが解決されると、イニシエーターはPSペイロードを含むIKE_AUTH要求メッセージを送信します。
HDR, PS, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SA, TSi, TSr} -->
Figure 5: IKE_AUTH Request Containing IKE_AUTH Puzzle Solution
図5：IKE_AUTHパズルソリューションを含むIKE_AUTHリクエスト
The PS payload MUST be placed outside the Encrypted payload, so that the Responder is able to verify the puzzle before calculating the DH shared secret and the SK_* keys.
PSペイロードは暗号化されたペイロードの外側に配置する必要があるため、レスポンダーはDH共有シークレットとSK_ *キーを計算する前にパズルを検証できます。
If IKE fragmentation [RFC7383] is used in the IKE_AUTH exchange, then the PS payload MUST be present only in the first IKE Fragment message, in accordance with Section 2.5.3 of [RFC7383]. Note that calculation of the puzzle in the IKE_AUTH exchange doesn't depend on the content of the IKE_AUTH message (see Section 7.2.3). Thus, the Initiator has to solve the puzzle only once, and the solution is valid for both unfragmented and fragmented IKE messages.
IKEフラグメンテーション[RFC7383]がIKE_AUTH交換で使用される場合、PSペイロードは、[RFC7383]のセクション2.5.3に従って、最初のIKEフラグメントメッセージにのみ存在する必要があります。 IKE_AUTH交換でのパズルの計算は、IKE_AUTHメッセージの内容に依存しないことに注意してください（セクション7.2.3を参照）。したがって、イニシエーターは一度だけパズルを解く必要があり、ソリューションはフラグメント化されていないIKEメッセージとフラグメント化されたIKEメッセージの両方に有効です。
A puzzle in the IKE_AUTH exchange is computed differently than in the IKE_SA_INIT exchange (see Section 7.1.3). The general principle is the same; the difference is in the construction of the string S. Unlike the IKE_SA_INIT exchange, where S is the cookie, in the IKE_AUTH exchange, S is a concatenation of Nr and SPIr. In other words, the task for the IKE Initiator is to find the four different keys Ki for the agreed upon PRF such that each result of PRF(Ki,Nr | SPIr) where i=[1..4] has a sufficient number of trailing zero bits. Nr is a nonce used by the Responder in the IKE_SA_INIT exchange, stripped of any headers. SPIr is the IKE Responder's SPI from the IKE header of the SA being established.
IKE_AUTH交換のパズルは、IKE_SA_INIT交換（セクション7.1.3を参照）とは異なる方法で計算されます。一般的な原理は同じです。違いは文字列Sの構築にあります。IKEがCookieであるIKE_SA_INIT交換とは異なり、IKE_AUTH交換では、SはNrとSPIrの連結です。言い換えると、IKEイニシエーターのタスクは、PRF（Ki、Nr | SPIr）の各結果がi = [1..4]で十分な数になるように、合意されたPRFの4つの異なるキーKiを見つけることです。後続ゼロビット。 Nrは、IKE_SA_INIT交換でレスポンダによって使用されるナンスであり、ヘッダーはすべて削除されています。 SPIrは、確立中のSAのIKEヘッダーからのIKEレスポンダーのSPIです。
If the Responder requested the Initiator to solve a puzzle in the IKE_AUTH exchange, then it MUST silently discard all the IKE_AUTH request messages without the PS payload.
レスポンダがイニシエータにIKE_AUTH交換のパズルを解くように要求した場合、PSペイロードのないすべてのIKE_AUTHリクエストメッセージをサイレントに破棄する必要があります。
Once the message containing a solution to the puzzle is received, the Responder MUST verify the solution before performing computationally intensive operations, i.e., computing the DH shared secret and the SK_* keys. The Responder MUST verify all four of the returned keys.
パズルの解を含むメッセージが受信されると、レスポンダーは、計算を多用する操作、つまり、DH共有シークレットとSK_ *キーを計算する前に、解を検証する必要があります。レスポンダは、返された4つのキーすべてを検証する必要があります。
The Responder MUST silently discard the received message if any checked verification result is not correct (contains insufficient number of trailing zero bits). If the Responder successfully verifies the puzzle and calculates the SK_* key, but the message authenticity check fails, then it SHOULD save the calculated keys in the IKE SA state while waiting for the retransmissions from the Initiator. In this case, the Responder may skip verification of the puzzle solution and ignore the PS payload in the retransmitted messages.
チェックされた検証結果が正しくない場合（後続のゼロビットの数が不十分な場合）、レスポンダは受信したメッセージを黙って破棄する必要があります。レスポンダがパズルの検証とSK_ *キーの計算に成功したが、メッセージの真正性チェックに失敗した場合、イニシエータからの再送信を待つ間、計算されたキーをIKE SA状態で保存する必要があります。この場合、レスポンダはパズルソリューションの検証をスキップして、再送信されたメッセージのPSペイロードを無視することがあります。
If the Initiator uses IKE fragmentation, then it sends all fragments of a message simultaneously. Due to packets loss and/or reordering, it is possible that the Responder receives subsequent fragments before receiving the first one that contains the PS payload. In this case, the Responder MAY choose to keep the received fragments until the first fragment containing the solution to the puzzle is received. In this case, the Responder SHOULD NOT try to verify authenticity of the kept fragments until the first fragment with the PS payload is received, and the solution to the puzzle is verified. After successful verification of the puzzle, the Responder can then calculate the SK_* key and verify authenticity of the collected fragments.
イニシエーターがIKEフラグメンテーションを使用する場合、メッセージのすべてのフラグメントを同時に送信します。パケットの損失や並べ替えが原因で、PSペイロードを含む最初のフラグメントを受信する前に、レスポンダが後続のフラグメントを受信する可能性があります。この場合、レスポンダーは、パズルの解を含む最初のフラグメントが受信されるまで、受信したフラグメントを保持することを選択できます（MAY）。この場合、レスポンダーは、PSペイロードを含む最初のフラグメントが受信され、パズルの解が検証されるまで、保持されているフラグメントの信頼性を検証しようとすべきではありません（SHOULD NOT）。パズルの検証が成功した後、レスポンダはSK_ *キーを計算し、収集されたフラグメントの信頼性を検証できます。
The PUZZLE notification is used by the IKE Responder to inform the Initiator about the need to solve the puzzle. It contains the difficulty level of the puzzle and the PRF the Initiator should use.
PUZZLE通知は、IKEレスポンダがパズルを解決する必要があることを開始者に通知するために使用されます。パズルの難易度と開始者が使用するPRFが含まれています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRF | Difficulty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) -- MUST be 0.
o プロトコルID（1オクテット）-0でなければなりません。
o SPI Size (1 octet) -- MUST be 0, meaning no SPI is present.
o SPIサイズ（1オクテット）-0でなければなりません（SPIが存在しないことを意味します）。
o Notify Message Type (2 octets) -- MUST be 16434, the value assigned for the PUZZLE notification.
o 通知メッセージタイプ（2オクテット）-16434でなければなりません（PUZZLE通知に割り当てられた値）。
o PRF (2 octets) -- Transform ID of the PRF algorithm that MUST be used to solve the puzzle. Readers should refer to the "Transform Type 2 - Pseudorandom Function Transform IDs" subregistry on [IKEV2-IANA] for the list of possible values.
o PRF（2オクテット）-パズルを解くために使用しなければならないPRFアルゴリズムの変換ID。読者は、可能な値のリストについて、[IKEV2-IANA]の「Transform Type 2-Pseudorandom Function Transform IDs」サブレジストリを参照する必要があります。
o Difficulty (1 octet) -- Difficulty level of the puzzle. Specifies the minimum number of trailing zero bits (ZBC) that each of the results of PRF must contain. Value 0 means that the Responder doesn't request any specific difficulty level, and the Initiator is free to select an appropriate difficulty level on its own (see Section 7.1.1.1 for details).
o 難易度（1オクテット）-パズルの難易度。 PRFの各結果に含まれる必要がある後続ゼロビット（ZBC）の最小数を指定します。値0は、レスポンダーが特定の難易度を要求せず、イニシエーターが適切な難易度を自由に選択できることを意味します（詳細については、セクション7.1.1.1を参照）。
This notification contains no data.
この通知にはデータが含まれていません。
The solution to the puzzle is returned back to the Responder in a dedicated payload, called the PS payload.
パズルの解は、PSペイロードと呼ばれる専用のペイロードでレスポンダーに返されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Puzzle Solution Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Puzzle Solution Data (variable length) -- Contains the solution to the puzzle -- four different keys for the selected PRF. This field MUST NOT be empty. All of the keys MUST have the same size; therefore, the size of this field is always a multiple of 4 bytes. If the selected PRF accepts only fixed-size keys, then the size of each key MUST be of that fixed size. If the agreed upon PRF accepts keys of any size, then the size of each key MUST be between 1 octet and the preferred key length of the PRF (inclusive). It is expected that in most cases, the keys will be 4 (or even less) octets in length; however, it depends on puzzle difficulty and on the Initiator's strategy to find solutions, and thus the size is not mandated by this specification. The Responder determines the size of each key by dividing the size of the Puzzle Solution Data by 4 (the number of keys). Note that the size of Puzzle Solution Data is the size of the Payload (as indicated in the Payload Length field) minus 4 -- the size of the Payload header.
o パズルソリューションデータ（可変長）-パズルのソリューションが含まれています-選択したPRFの4つの異なるキー。このフィールドを空にすることはできません。すべてのキーは同じサイズでなければなりません。したがって、このフィールドのサイズは常に4バイトの倍数になります。選択したPRFが固定サイズの鍵のみを受け入れる場合、各鍵のサイズはその固定サイズでなければなりません。合意されたPRFが任意のサイズのキーを受け入れる場合、各キーのサイズは1オクテットからPRFの優先キー長（両端を含む）の間でなければなりません。ほとんどの場合、キーの長さは4オクテット（またはそれ以下）になると予想されます。ただし、パズルの難しさと解決策を見つけるためのイニシエーターの戦略に依存するため、サイズはこの仕様では必須ではありません。レスポンダは、パズルソリューションデータのサイズを4（キーの数）で割ることにより、各キーのサイズを決定します。パズルソリューションデータのサイズは、ペイロードのサイズ（ペイロードの長さフィールドに示されている）から4-ペイロードヘッダーのサイズを引いたものであることに注意してください。
The payload type for the PS payload is 54.
PSペイロードのペイロードタイプは54です。
The puzzle difficulty level should be set by balancing the requirement to minimize the latency for legitimate Initiators with making things difficult for attackers. A good rule of thumb is taking about 1 second to solve the puzzle. At the time this document was written, a typical Initiator or botnet member can perform slightly less than a million hashes per second per core, so setting the number of zero bits to 20 is a good compromise. It should be noted that mobile Initiators, especially phones, are considerably weaker than that. Implementations should allow administrators to set the difficulty level and/or be able to set the difficulty level dynamically in response to load.
パズルの難易度は、正当なイニシエーターのレイテンシを最小限に抑えるための要件と攻撃者にとって困難なものとをバランスさせることによって設定する必要があります。経験則では、パズルを解くのに約1秒かかります。このドキュメントが作成された時点では、一般的なイニシエーターまたはボットネットメンバーはコアあたり1秒あたり100万ハッシュより少し少ない速度で実行できるため、ゼロビットの数を20に設定することは適切な妥協案です。モバイルイニシエーター、特に電話は、それよりもかなり弱いことに注意してください。実装では、管理者が難易度を設定したり、負荷に応じて難易度を動的に設定したりできるようにする必要があります。
Initiators SHOULD set a maximum difficulty level beyond which they won't try to solve the puzzle and log or display a failure message to the administrator or user.
イニシエーターは、難易度の最大値を設定する必要があります。これを超えると、パズルを解いてログに記録したり、管理者またはユーザーにエラーメッセージを表示したりすることはありません。
Until the widespread adoption of puzzles happens, most Initiators will ignore them, as will all attackers. For puzzles to become a really powerful defense measure against DDoS attacks, they must be supported by the majority of legitimate clients.
パズルが広く採用されるまで、ほとんどのイニシエーターは、すべての攻撃者がそうであるように、それらを無視します。パズルがDDoS攻撃に対する本当に強力な防御策になるには、正当なクライアントの大多数がパズルをサポートする必要があります。
Care must be taken when selecting parameters for the puzzles, in particular the puzzle difficulty. If the puzzles are too easy for the majority of attackers, then the puzzle mechanism wouldn't be able to prevent DoS or DDoS attacks and would only impose an additional burden on legitimate Initiators. On the other hand, if the puzzles are too hard for the majority of Initiators, then many legitimate users would experience unacceptable delays in IKE SA setup (and unacceptable power consumption on mobile devices) that might cause them to cancel the connection attempt. In this case, the resources of the Responder are preserved; however, the DoS attack can be considered successful. Thus, a sensible balance should be kept by the Responder while choosing the puzzle difficulty -- to defend itself and to not over-defend itself. It is RECOMMENDED that the puzzle difficulty be chosen, so that the Responder's load remains close to the maximum it can tolerate. It is also RECOMMENDED to dynamically adjust the puzzle difficulty in accordance to the current Responder's load.
パズルのパラメーター、特にパズルの難易度を選択するときは注意が必要です。パズルが大多数の攻撃者にとって簡単すぎる場合、パズルのメカニズムはDoSまたはDDoS攻撃を防ぐことができず、正当なイニシエーターに追加の負担をかけるだけです。一方、大多数のイニシエーターにとってパズルが難しすぎる場合、正当なユーザーの多くは、IKE SAのセットアップで許容できないほどの遅延（およびモバイルデバイスでの許容できない電力消費）を経験し、接続試行をキャンセルする可能性があります。この場合、レスポンダのリソースは保持されます。ただし、DoS攻撃は成功したと見なすことができます。したがって、パズルの難易度を選択する間、レスポンダーは賢明なバランスを維持する必要があります-自分自身を防御し、自分自身を過度に防御しないようにします。パズルの難易度を選択することをお勧めします。これにより、レスポンダの負荷が許容できる最大値に近くなります。また、現在のレスポンダの負荷に応じてパズルの難易度を動的に調整することをお勧めします。
If the cookie is generated as suggested in Section 2.6 of [RFC7296], then an attacker can use the same SPIi and the same Ni for several requests from the same IPi. This will result in generating the same cookies for these requests until the Responder changes the value of its cookie generation secret. Since the cookies are used as an input data for puzzles in the IKE_SA_INIT exchange, generating the same cookies allows the attacker to reuse puzzle solutions, thus bypassing the proof-of-work requirement. Note that the attacker can get only limited benefit from this situation -- once the half-open SA is created by the Responder, all the subsequent initial requests with the same IPi and SPIi will be treated as retransmissions and discarded by the Responder. However, once this half-open SA is expired and deleted, the attacker can create a new one for free if the Responder hasn't changed its cookie generation secret yet.
[RFC7296]のセクション2.6で提案されているようにCookieが生成された場合、攻撃者は同じIPiからの複数のリクエストに対して同じSPIiと同じNiを使用できます。これにより、レスポンダがCookie生成シークレットの値を変更するまで、これらのリクエストに対して同じCookieが生成されます。 CookieはIKE_SA_INIT交換でパズルの入力データとして使用されるため、同じCookieを生成すると、攻撃者はパズルソリューションを再利用でき、作業証明の要件を回避できます。攻撃者はこの状況から限られた利益しか得られないことに注意してください。レスポンダーによってハーフオープンSAが作成されると、同じIPiとSPIiを持つ後続のすべての初期リクエストは再送信として扱われ、レスポンダーによって破棄されます。ただし、このハーフオープンSAの有効期限が切れて削除されると、レスポンダがCookie生成シークレットをまだ変更していない場合、攻撃者は新しいSAを無料で作成できます。
The Responder can use various countermeasures to completely eliminate or mitigate this scenario. First, the Responder can change its cookie generation secret frequently especially if under attack, as recommended in Section 2.6 of [RFC7296]. For example, if the Responder keeps two values of the secret (current and previous) and the secret lifetime is no more than a half of the current half-open SA retention time (see Section 4.1), then the attacker cannot get benefit from reusing a puzzle solution. However, short cookie generation secret lifetime could have a negative consequence on weak legitimate Initiators, since it could take too long for them to solve puzzles, and their solutions would be discarded if the cookie generation secret has been already changed few times.
レスポンダは、さまざまな対策を使用して、このシナリオを完全に排除または軽減できます。まず、[RFC7296]のセクション2.6で推奨されているように、特に攻撃を受けている場合、レスポンダはCookie生成シークレットを頻繁に変更できます。たとえば、レスポンダが2つのシークレットの値（現在と以前）を保持しており、シークレットの有効期間が現在のハーフオープンSA保持時間の半分以下である場合（セクション4.1を参照）、攻撃者は再利用から利益を得ることができません。パズルソリューション。ただし、Cookie生成のシークレットの有効期間が短いと、弱い正当なイニシエーターに悪影響を与える可能性があります。パズルを解くのに時間がかかりすぎ、Cookie生成のシークレットがすでに何度か変更されている場合、ソリューションは破棄されます。
Another approach for the Responder is to modify the cookie generation algorithm in such a way that the generated cookies are always different or are repeated only within a short time period. If the Responder includes a timestamp in <AdditionalInfo> as suggested in Section 7.1.1.3, then the cookies will repeat only within a short time interval equal to timestamp resolution. Another approach for the Responder is to maintain a global counter that is incremented every time a cookie is generated and include this counter in <AdditionalInfo>. This will make every cookie unique.
Responderの別のアプローチは、生成されたCookieが常に異なるように、または短期間にのみ繰り返されるように、Cookie生成アルゴリズムを変更することです。セクション7.1.1.3で提案されているように、レスポンダの<AdditionalInfo>にタイムスタンプが含まれている場合、Cookieはタイムスタンプの解決に等しい短い時間間隔内でのみ繰り返されます。 Responderの別のアプローチは、Cookieが生成されるたびに増分されるグローバルカウンターを維持し、このカウンターを<AdditionalInfo>に含めることです。これにより、すべてのCookieが一意になります。
Implementations MUST use one of the above (or some other) countermeasures to completely eliminate or make insignificant the possible benefit an attacker can get from reusing puzzle solutions. Note that this issue doesn't exist in IKE_AUTH puzzles (Section 7.2) since the puzzles in IKE_AUTH are always unique if the Responder generates SPIr and Nr randomly in accordance with [RFC7296].
実装では、上記の（またはその他の）対策のいずれかを使用して、パズルソリューションを再利用することで攻撃者が得る可能性のある利益を完全に排除または取るに足らないものにする必要があります。 [RFC7296]に従ってレスポンダがランダムにSPIrとNrを生成する場合、IKE_AUTHのパズルは常に一意であるため、この問題はIKE_AUTHパズル（セクション7.2）には存在しないことに注意してください。
Solving puzzles requires a lot of CPU usage that increases power consumption. This additional power consumption can negatively affect battery-powered Initiators, e.g., mobile phones or some Internet of Things (IoT) devices. If puzzles are too hard, then the required additional power consumption may appear to be unacceptable for some Initiators. The Responder SHOULD take this possibility into consideration while choosing the puzzle difficulty and while selecting which percentage of Initiators are allowed to reject solving puzzles. See Section 7.1.4 for details.
パズルを解くには、消費電力を増加させる多くのCPU使用率が必要です。この追加の電力消費は、バッテリー駆動のイニシエーター、例えば携帯電話やモノのインターネット（IoT）デバイスに悪影響を与える可能性があります。パズルが難しすぎる場合、必要な追加の電力消費が一部のイニシエーターにとって許容できないように見えることがあります。レスポンダーは、パズルの難易度を選択する際、およびパズルの解答を拒否できるイニシエーターの割合を選択する際に、この可能性を考慮に入れるべきです（SHOULD）。詳細については、セクション7.1.4を参照してください。
If the Initiator uses NULL Authentication [RFC7619], then its identity is never verified. This condition may be used by attackers to perform a DoS attack after the IKE SA is established. Responders that allow unauthenticated Initiators to connect must be prepared to deal with various kinds of DoS attacks even after the IKE SA is created. See Section 5 for details.
イニシエーターがNULL認証[RFC7619]を使用する場合、そのIDは検証されません。この状態は、IKE SAの確立後に攻撃者がDoS攻撃を実行するために使用される可能性があります。認証されていないイニシエーターに接続を許可するレスポンダーは、IKE SAが作成された後でも、さまざまな種類のDoS攻撃に対応できるように準備する必要があります。詳細については、セクション5を参照してください。
To prevent amplification attacks, implementations must strictly follow the retransmission rules described in Section 2.1 of [RFC7296].
増幅攻撃を防ぐために、実装は[RFC7296]のセクション2.1で説明されている再送信ルールに厳密に従う必要があります。
This document defines a new payload in the "IKEv2 Payload Types" registry:
このドキュメントでは、「IKEv2 Payload Types」レジストリで新しいペイロードを定義しています。
54 Puzzle Solution PS
54パズルソリューションPS
This document also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry:
このドキュメントでは、「IKEv2通知メッセージタイプ-ステータスタイプ」レジストリで新しい通知メッセージタイプも定義しています。
16434 PUZZLE
16434パズル
[IKEV2-IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org/assignments/ikev2-parameters>.
[IKEV2-IANA] IANA、「Internet Key Exchange Version 2（IKEv2）Parameters」、<http://www.iana.org/assignments/ikev2-parameters>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, <http://www.rfc-editor.org/info/rfc5723>.
[RFC5723] Sheffer、Y。およびH. Tschofenig、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）セッションの再開」、RFC 5723、DOI 10.17487 / RFC5723、2010年1月、<http://www.rfc-editor.org/ info / rfc5723>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, 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、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, <http://www.rfc-editor.org/info/rfc7383>.
[RFC7383] Smyslov、V。、「Internet Key Exchange Protocol Version 2（IKEv2）Message Fragmentation」、RFC 7383、DOI 10.17487 / RFC7383、2014年11月、<http://www.rfc-editor.org/info/rfc7383> 。
[BITCOINS] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System", October 2008, <https://bitcoin.org/bitcoin.pdf>.
[BITCOINS] Nakamoto、S。、「Bitcoin：A Peer-to-Peer Electronic Cash System」、2008年10月、<https://bitcoin.org/bitcoin.pdf>。
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, <http://www.rfc-editor.org/info/rfc7619>.
[RFC7619] Smyslov、V。およびP. Wouters、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）のNULL認証方式」、RFC 7619、DOI 10.17487 / RFC7619、2015年8月、<http：//www.rfc- editor.org/info/rfc7619>。
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <http://www.rfc-editor.org/info/rfc7696>.
[RFC7696] Housley、R。、「暗号化アルゴリズムの敏捷性と実装必須アルゴリズムの選択に関するガイドライン」、BCP 201、RFC 7696、DOI 10.17487 / RFC7696、2015年11月、<http://www.rfc-editor.org / info / rfc7696>。
Acknowledgements
謝辞
The authors thank Tero Kivinen, Yaron Sheffer, and Scott Fluhrer for their contributions to the design of the protocol. In particular, Tero Kivinen suggested the kind of puzzle where the task is to find a solution with a requested number of zero trailing bits. Yaron Sheffer and Scott Fluhrer suggested a way to make puzzle difficulty less erratic by solving several weaker puzzles. The authors also thank David Waltermire and Paul Wouters for their careful reviews of the document, Graham Bartlett for pointing out the possibility of an attack related to "Hash & URL", Stephen Farrell for catching the repeated cookie issue, and all others who commented on the document.
著者は、プロトコルの設計に貢献してくれたTero Kivinen、Yaron Sheffer、およびScott Fluhrerに感謝します。特に、Tero Kivinenは、要求されたゼロの後続ビットを持つソリューションを見つけることが課題であるようなパズルを提案しました。 Yaron ShefferとScott Fluhrerは、いくつかの弱いパズルを解くことにより、パズルの難易度をより不安定にしない方法を提案しました。著者はまた、文書の注意深いレビューを提供してくれたDavid WaltermireとPaul Wouters、「ハッシュとURL」に関連する攻撃の可能性を指摘してくれたGraham Bartlett、繰り返し発生するCookieの問題をキャッチしてくれたStephen Farrell、およびコメントした他のすべてに感謝します。ドキュメント。
Authors' Addresses
著者のアドレス
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 6789735 Israel
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st。テルアビブ6789735イスラエル
Email: ynir.ietf@gmail.com
Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation
Valery Smyslov ELVIS-PLUS PO Box 81モスクワ（ゼレノグラード）124460ロシア連邦
Phone: +7 495 276 0211
Email: svan@elvis.ru