IKEレスポンダがCookieシークレットを「頻繁に」変更する必要があるのはなぜですか？
IKEv2には COOKIEモード の概念があり、存在しないIPアドレスからの開始要求のフラッドによる状態の枯渇を防止しようとします。
IKEに対する2つの予想される攻撃は、状態とCPUの枯渇です。この場合、偽造されたIPアドレスからのセッション開始要求でターゲットがフラッディングされます。これらの攻撃は、レスポンダーが最小限のCPUを使用し、イニシエーターがパケットの送信元であるアドレスでパケットを受信できることがわかるまで、SA）に状態をコミットしない場合、効果が低下する可能性があります。
開始者は応答者に要求を送信します。レスポンダーは、イニシエーターが持っていないシークレットとリクエストの詳細を使用してCookieを作成し、イニシエーターに送り返します。次に、イニシエーターは要求を繰り返しますが、今回はCookieを添付して、要求の送信元IPアドレスに送信されたパケットを受信できることを証明します。
RFCは、Cookieの構築方法を推奨しています。
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
ここで、Ni、IPi、およびSPIiは、IPアドレスからの要求を一意に定義する秘密でない値です。
RFCはさらにこう言っています
特に攻撃を受けている場合、レスポンダは
<secret>の値を頻繁に変更する必要があります。
なぜRFCはこの推奨を行うのですか？
Strongswanはこれを シークレットの使用回数を10000に制限する で実装します。 Windows 150秒の分解能で時間値を埋め込みます （28項を参照）をCookieに埋め込みます。
シークレットがnever変更されていない場合、攻撃者が特定のソースIPとリクエストパラメータに対する応答を確認すると、リクエストでレスポンダをスパムできます正しいクッキーと一緒に。ですから、ある段階でそれを変更する正当な理由は確かにあります。
しかし、（優れたハッシュ関数を想定すると）Cookieは秘密に関する有用な情報をフラッディング攻撃者に漏らしません。したがって、シークレットを頻繁に、たとえば毎日最大で変更することなく、このスキームは指定された目標（攻撃者の制御外のIPアドレスからの要求のフラッドによる状態の枯渇）に対する保護を提供するようです。攻撃者は、レスポンダがそのリクエストの状態を維持する前に、リクエストを送信したい各IPアドレスからのリクエストに対するレスポンダからのレスポンスを観察する必要があります。
では、なぜ「頻繁に」なのでしょうか。
（正当な答えは「なぜそうでないのか？」かもしれません-私はそれに他に何かがあるのかと思っています。）
「秘密」が何週間も変わらないとしましょう。攻撃者として、IPスプーフィングなしで数週間にわたって多くの接続を確立することができました。このようにして、（有効なcookie値）を数百万収集します。それぞれ、特定のソースIPアドレスと関連するパラメータ（Ni、 RFCのIPiとSPTiの値）。これは準備ステップです。
次に、実際に攻撃が発生したときに、必要なIPスプーフィングを使用して5分以内にそれらすべてをまとめて再生します。値は一致し、サーバーは何百万ものクライアントにリソースを割り当てます。これはサーバーをかなり効果的に溺死させます。
構造上、この攻撃は、サーバーが生成できる有効なCookie（「攻撃時にサーバーによって受け入れられる」という意味で「有効」）の数に制限されます。シークレットを変更すると、古いCookieは無効になります。シークレットを頻繁に変更することにより、現在有効なCookie値のセットの最大サイズが低く抑えられ、上記の攻撃が回避されます。
もちろん、もちろん、攻撃の場合に「もっと頻繁に」シークレットを変更する必要があると主張するのは、IT精神の精神を煽る単なるシャーマニスティックなダンスです。同様に、「秘密が追加されたデータをハッシュする」という自家製の構造が「良い方法」と記述されているのを見ると、私はうずくまってうなり、血の涙を流します。 [〜＃〜] hmac [〜＃〜] について聞いたことはありませんか？ あなたは、HMACについて聞いたことがない人からの暗号化のアドバイスに従いたいですか？