Cloudflare WAN と anycast IPsec トンネルを使う場合は、アンチリプレイ保護を無効にすることを推奨します。Cloudflare はこの設定をデフォルトで無効にしています。ただし、無効化に対応していないデバイス（Cisco Meraki、Velocloud、AWS VPN Gateway など）向けに、API または Cloudflare ダッシュボードから有効にできます。
リプレイ保護の設定方法は トンネルを追加する を参照してください。このページでは、リプレイ攻撃、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 アンチリプレイ保護は、送信側 1 台と受信側 1 台を前提にします。送信側はメモリ上のシーケンス番号を保持し、パケットごとに増やします。受信側は処理済みのシーケンス番号を追跡します。
Cloudflare の anycast アーキテクチャはこのモデルに合いません。Cloudflare WAN は anycast を使うため、どのパケットも数百のデータセンターにある数千台のサーバーのいずれかで処理されます。この分散処理が Cloudflare WAN の性能と耐障害性の根拠です。一方で、シーケンス番号の状態を完全に把握している単一サーバーはありません。
Cloudflare WAN の IPsec トンネルでリプレイ保護を有効にすると、Cloudflare は 1 本のトンネルのパケットを、シーケンス番号を追跡する 1 台のサーバーへルーティングします。このモードではリプレイ保護は正しく動きますが、Cloudflare のグローバルサーバーへトラフィックを分散する利点は失われます。適用方向も一方向（Cloudflare から顧客ネットワーク）だけです。顧客ネットワークからのパケットは単一サーバーへ寄せず、その方向ではリプレイ保護を適用しません。
IPsec アンチリプレイ保護は、トランスポートモード（ホスト間、あるいはアプリ間の IPsec）では非常に重要です。トランスポートモードでは、攻撃者は暗号化したプロトコルを比較的容易に特定でき、そのプロトコルがリプレイ攻撃の対象なら、どのパケットを再送するかも特定しやすいです。一方 Cloudflare WAN はトンネルモードを使い、リプレイ攻撃を成功させるのは本質的に難しくなります。
トンネルモードでリプレイ攻撃が難しい理由は次のとおりです。
- IPsec は内側のパケット全体を暗号化します。攻撃者はキャプチャしたユーザーパケットについてほとんど分からず、リプレイ攻撃のための関連付けも困難です。分かるのは、暗号化した外側のサイトネットワーク、受信する外側のサイトネットワーク、パケットのおおよそのサイズ程度です。特定の内側ユーザーフローを識別して関連付け、再送するには足りません。
- リプレイ攻撃は、同じ暗号化キーを使う場合にだけ成立します。再鍵（rekey）のあと、ルーターは古い再送パケットを破棄します。
- ほとんどのプロトコルは、パケット単位のリプレイに弱いわけではありません。インターネットではパケットが重複することがあるため、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）接続を通します。さらに anycast のため、IPsec トンネルは顧客のエッジルーターに最も近い 300 か所以上の Cloudflare データセンターのいずれかで終端し、暗号化パケットが通る物理距離と範囲を最小化します。
アンチリプレイ保護に関連してトンネルが不安定になったり、パケットドロップが起きたりする場合は、トンネルヘルスのトラブルシューティング を参照してください。