Magic Transit と anycast の IPsec トンネルを使う場合は、アンチリプレイ保護を無効にすることを推奨します。Cloudflare では、この設定はデフォルトで無効です。ただし、無効化に対応していない機器（Cisco Meraki、Velocloud、AWS VPN Gateway など）向けに、API または Cloudflare ダッシュボードから有効にできます。
リプレイ保護の設定方法は トンネルを追加する を参照してください。このページでは、リプレイ攻撃の内容、IPsec のアンチリプレイを無効にする理由、関連する注意点を説明します。
リプレイ攻撃は、攻撃者が パケット ↗ を傍受して記録し、後から同じパケットを対象ネットワークへ再送して、自分に有利な結果を得ようとする攻撃です。
設計の甘い IoT（Internet of Things）のガレージドアオープナーを考えます。操作プロトコルは単純です。UDP（User Datagram Protocol）パケットのデータ部に、ガレージドアのパスワードと open または shut が入っています。データ部はガレージドアの鍵で暗号化され、所有者のスマートフォンがガレージドアの開閉のために送信します。
暗号化キーとパスワードを推測して開閉するのは、攻撃者にとって難しいでしょう。記録したパケットの暗号化内容は見えません。ただし、ガレージが視界に入る位置にいれば、どのパケットが開扉に対応するかを推測できる場合があります。攻撃者は開扉したいときに、記録した open パケットを送ります。そのパケットにはパスワードが含まれ、正しい鍵で暗号化済みなので、ドアは開きます。
このリプレイ攻撃を防ぐには、ガレージドアへ送る各コマンドにパケット番号を付けます。1 通目は packet 1、2 通目は packet 2 のようにし、ガレージドアは毎回、次の番号のパケットだけを受け付けます。たとえば packet 1 を受け取ったあと、受け付けるのは packet 2 だけです。攻撃者が packet 1 を再送しても、ガレージドアはそのリクエストを無視します。
IPsec のアンチリプレイ保護は、上の例の防止方法に近い動きをします。送信側は各 IPsec パケットにシーケンス番号を付けます。受信側は、すでに見たシーケンス番号を追跡し、これまでに見た最大値の周辺の小さなウィンドウ内のパケットだけを受け付けます。ウィンドウは通常 64〜1024 パケットです。インターネットではパケットの順序入れ替わりや損失が起きるため、IPsec は厳密な連番ではなくウィンドウを使います。許容するシーケンス番号の範囲を持つことで、こうした問題を吸収します。
標準の IPsec アンチリプレイ保護は、送信者と受信者がそれぞれ 1 台であることを前提にします。送信者はシーケンス番号をメモリに保持し、パケットごとに増やします。受信者は、すでに処理したシーケンス番号を追跡します。
Cloudflare の anycast アーキテクチャは、このモデルに合いません。Magic Transit は anycast を使うため、どのパケットも、数百のデータセンターにある数千台のサーバーのいずれかで処理できます。この分散処理が Magic Transit の性能と耐障害性につながります。その一方で、シーケンス番号の状態を完全に把握する単一のサーバーはありません。
Magic Transit の IPsec トンネルでリプレイ保護を有効にすると、Cloudflare は 1 本のトンネルのパケットを、シーケンス番号を管理する 1 台のサーバーへルーティングします。このモードではリプレイ保護は正しく動きます。ただし、Cloudflare のグローバルなサーバー群へトラフィックを分散する利点は失われます。また、適用方向は一方向（Cloudflare から顧客ネットワーク）だけです。Cloudflare は、顧客ネットワークからのパケットを単一サーバーへはルーティングせず、その方向ではリプレイ保護を適用しません。
IPsec のアンチリプレイ保護は、トランスポートモード（ホスト間、あるいはアプリ間の IPsec）では非常に重要です。トランスポートモードでは、攻撃者は暗号化されたプロトコルを比較的容易に特定でき、そのプロトコルがリプレイ攻撃の対象なら、どのパケットを再送するかを見極めやすいです。一方、Magic Transit はトンネルモードを使います。トンネルモードでは、リプレイ攻撃を成功させるのは本質的にかなり難しくなります。
トンネルモードでリプレイ攻撃が難しい理由はいくつかあります。
- IPsec は内側のパケット全体を暗号化します。そのため、攻撃者はキャプチャしたユーザーパケットについてほとんど分からず、リプレイ攻撃のための相関も難しくなります。分かるのは、パケットを暗号化した外側のサイトネットワーク、受信する外側のサイトネットワーク、おおよそのパケットサイズ程度です。特定の内側ユーザーパケットフローを識別して相関し、再送するには足りません。
- リプレイ攻撃は、同じ暗号化キーを使っているときだけ成立します。リキー後、ルーターは古い再送パケットを破棄します。
- ほとんどのプロトコルは、パケット単位のリプレイに脆弱ではありません。インターネットではパケットが重複しうるため、TCP や UDP 上の多くのプロトコルは、すでにシーケンス番号などで、回線上の重複パケットを処理します。その場合、リプレイトラフィックは単なる重複パケットとして見え、終端ホストが正しく処理します。
- アンチリプレイ保護は、より上位の OSI（Open Systems Interconnection）層でも利用できます。今日の多くのアプリケーションは、SSL/TLS（Secure Sockets Layer / Transport Layer Security）、SSH（Secure Shell）、SFTP（SSH File Transfer Protocol）などの安全な通信プロトコルでアプリケーションデータを運びます。これらのプロトコル（ネットワーク層より上位の OSI 層）は、ネイティブにアンチリプレイ保護を備えています。
- 攻撃面が小さいため、パケット傍受の確率も下がります。IPsec トンネルは、ユーザーサイトのルーターと Cloudflare のグローバルネットワークのあいだのサイト間 VPN で、専用の ISP（Internet Service Provider）接続を通ることが多く、通常は非常に安全です。さらに、Cloudflare の IPsec 実装の anycast 特性により、IPsec トンネルは顧客のエッジルーターに最も近い 300 以上の Cloudflare データセンターのいずれかで終端します。暗号化パケットが通る物理距離と経路も短くなります。
アンチリプレイ保護に関連するトンネルの不安定さやパケットドロップが起きている場合は、トンネルヘルスのトラブルシューティング を参照してください。