RFC 7296、セクション 2.4、パラグラフ 3 を引用:
IKE はネットワークからの DoS 攻撃にもかかわらず動作するように設計されているため、エンドポイントは、ルーティング情報 (たとえば、ICMP メッセージ) または暗号保護なしで到着する IKE メッセージ (たとえば、通知メッセージ)に基づいて、他のエンドポイントが失敗したと結論付けてはなりません。不明な SPI について不平を言う) . エンドポイントは、他のエンドポイントが失敗したと判断する必要がありますが、これは、タイムアウト期間にわたって繰り返し試行された場合、または暗号で保護された INITIAL_CONTACT 通知が別の IKE SA で同じ認証済み ID に対して受信された場合に限られます。エンドポイントは、ルーティング情報に基づいて他のエンドポイントが失敗したことを疑い、他のエンドポイントが稼働しているかどうかを確認する要求を開始する必要があります。反対側が生きているかどうかを確認するために、IKE は (すべての IKE 要求と同様に) 確認応答を必要とする空の INFORMATIONAL 要求を指定します(IKE SA のコンテキスト内では、「空の」メッセージは IKE ヘッダーとそれに続く暗号化されたメッセージで構成されることに注意してください)。ペイロードを含まないペイロード)。暗号で保護された (新鮮な、つまり再送されていない) メッセージが最近相手側から受信された場合、保護されていない Notify メッセージは無視される場合があります。実装は、保護されていないメッセージに基づいてアクションを実行する速度を制限する必要があります。
(明確にするために)関連する攻撃者のタイプを考慮する必要があると思います。
1/ 任意のパケットをドロップできる攻撃者 (つまり、アクティブな MitM)
- これは、パケットをドロップするだけで DOS を実行できます。私の知る限り、彼がそうすることを妨げるものは何もありません。コミュニケーションを断ち切るのに洗練は必要ありません。
2/ 攻撃者がパケットをドロップできない
3/ 攻撃者が一部のパケットをドロップできる
- それは競争であり、結果はピアの構成と、攻撃者がドロップできるパケットの割合によって異なります。
編集>
問題の「ケース 2 の攻撃者」のシナリオは、次のように理解できます。
攻撃者の保護されていない INVALID_IKE_SPI 通知 (ピア_2 のアドレスから攻撃者によってなりすまし) を受信することにより、ピア_1 は (せいぜい) ピア_2 が失敗したと疑うことしかできません (暗号保護なしの IKE メッセージに基づいて、他のエンドポイントが失敗したと結論付けてはならないため) 。
空の情報要求を peer_2 (暗号で保護されている) に送信することにより、活性チェックを発行することを決定する場合があります (以下の注を参照)。
「ケース 2 攻撃者」はこの要求を改ざんできないため、peer_2 に到達する必要があります (指定されているように、実装固有の再送信が含まれる場合があります) 。
peer_2 (生きているため) は確認応答を返します (これは暗号で保護されています)。
「ケース 2 攻撃者」はこの応答を改ざんできないため、peer_1 に到達する必要があります。
この応答 ( peer_2 からの暗号で保護された新しいメッセージ) を受信すると、peer_1 は、peer_2 が有効であることを認識し、SA を維持します (何も起こらなかったため)。
注: 「実装は、保護されていないメッセージに基づいてアクションを実行する速度を制限する必要があります」という部分は、peer_1 が受信した保護されていない通知メッセージごとにこの活性チェックを実行してはならず、実装固有の速度制限メカニズムを配置する必要があることを意味します (おそらくトラフィックの増幅を防ぎます)。
免責事項: 私は仮想通貨の専門家ではないので、私の考えを検証してください。