IPSecアンチリプレイチェック障害のトラブルシューティング
はじめに
このドキュメントでは、インターネットプロトコルセキュリティ(IPSec)アンチリプレイチェックの障害に関連する問題について説明し、考えられる解決策を示します。
バックグラウンド情報
リプレイアタックの概要
リプレイアタックはネットワーク攻撃の一種で、有効なデータ伝送が悪意をもって、または不正に記録され、後で繰り返されます。これは、有効なユーザになりすまして正当な接続を中断または悪影響を及ぼすために、正当な通信を記録し、それを繰り返す第三者によってセキュリティを弱体化させる試みです。
IPSecリプレイチェック保護
IPsecにより各暗号化パケットに単調増加するシーケンス番号を割り当て、攻撃者に対するアンチリプレイ保護を提供する。受信側のIPsecエンドポイントは、これらの番号と受け入れ可能なシーケンス番号のスライディングウィンドウを使用して、すでに処理したパケットを追跡します。Cisco IOS®実装のデフォルトのアンチリプレイウィンドウサイズは、次の図に示すように64パケットです。
IPSecトンネルエンドポイントでアンチリプレイ保護が有効になっている場合、着信IPSecトラフィックは次のように処理されます。
- シーケンス番号がウィンドウ内にあり、以前に受信されていない場合、パケットの整合性がチェックされます。パケットが整合性検証チェックに合格すると、そのパケットは受け入れられ、ルータはこのシーケンス番号が受信されたことを示すマークを付けます。たとえば、上記の図では、Encapsulating Security Payload(ESP)シーケンス番号が162のパケットがリプレイウィンドウ内にあります。
- シーケンス番号がウィンドウ内にあるものの、以前に受信された場合、パケットはドロップされます。この重複パケットは廃棄され、ドロップはリプレイドロップカウンタに記録されます。
- シーケンス番号がウィンドウ内で最も大きいシーケンス番号よりも大きい場合、パケットの整合性がチェックされます。パケットが整合性検証チェックに合格すると、スライディングウィンドウが右に移動します。たとえば、シーケンス番号が189の有効なパケットを受信した場合、ウィンドウの新しい右エッジは189に設定され、左エッジは125（189 - 64 [ウィンドウサイズ]）になります。
- シーケンス番号が左端より小さい場合、パケットはドロップされ、リプレイカウンタに記録されます。これは不正なパケットと見なされます。
リプレイチェックが失敗し、パケットがドロップされた場合、ルータは次のようなsyslogメッセージを生成します。
%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle n, src_addr x.x.x.x, dest_addr y.y.y.y, SPI 0xzzzzzzzz
IPSecリプレイドロップを引き起こす可能性のある問題
すでに説明したように、リプレイチェックの目的は、正当なパケットの悪意のある繰り返しを防止することです。リプレイ・チェックの失敗の原因となる一般的な条件には、次のものがあります。
- このエラーは、配信中にトンネルエンドポイント間のネットワークパスでパケットが並べ替えられることによって発生する可能性があります。これは、ピア間に複数のネットワークパスがある場合に発生する可能性があります。
- このエラーは、Cisco IOS内のパケット処理パスが異なるために発生する可能性があります。たとえば、フラグメント化されたIPsecパケットでは、復号化の前にIPの再構成が必要となる場合、処理されるまでにリプレイウィンドウの範囲外となる程度に十分遅延が発生する可能性があります。
- エラーは、送信側のIPsecエンドポイントまたはネットワークパス内で有効になっているQuality of Service(QoS)が原因で発生する可能性があります。Cisco IOSの実装では、出力方向のQoSの前にIPsec暗号化が行われます。低遅延キューイング(LLQ)などの特定のQoS機能により、IPSecパケット配信が順不同になり、リプレイチェックの失敗が原因で受信側エンドポイントによってドロップされる可能性があります。
- ネットワーク設定や運用上の問題により、パケットがネットワークを通過する際にパケットが重複する可能性があります。
- 攻撃者（中間者）は、ESPトラフィックを遅延、ドロップ、および複製する可能性があります。
IPSec リプレイ ドロップのトラブルシューティング
IPSecリプレイドロップのトラブルシューティングで重要となるのは、リプレイが原因でドロップされたパケットを識別し、パケットキャプチャを使用してこれらのパケットが実際にリプレイされたパケットであるか、リプレイウィンドウ外の受信側ルータに到着したパケットであるかを判別することです。ドロップされたパケットをスニファトレースでキャプチャされた内容と正しく照合するには、まず、ドロップされたパケットが属するピアとIPSecフロー、およびパケットのESPシーケンス番号を特定します。
Cisco IOS XEデータパスパケットトレース機能の使用
Cisco IOS® XEソフトウェアを実行するルータプラットフォームでは、リプレイドロップが発生したときに、ピアに関する情報とIPsec Security Parameter Index（SPI；セキュリティパラメータインデックス）がsyslogメッセージに出力されます。これは、ドロップされたパケットが属するピアと特定のトンネルを識別するために役立ちます。ただし、ESPシーケンス番号はこの出力には表示されません。ESP シーケンス番号は、特定の IPSec フローの中の IPSec パケットを一意に識別するのに使用されます。このシーケンス番号がないと、どのパケットがドロップされたかをパケット キャプチャで識別することが難しくなります。
Cisco IOS® XEデータパスのパケットトレース機能は、リプレイドロップが発生した場合に次のsyslogメッセージを表示して使用できます。
%IOSXE-3-PLATFORM: F0: cpp_cp: QFP:0.0 Thread:060 TS:00000001132883828011
%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 3, src_addr 10.2.0.200, dest_addr 10.1.0.100, SPI 0x4c1d1e90
ドロップされたパケットの ESP シーケンス番号を特定するには、パケット トレース機能で次の手順を実行します。
ステップ 1：ピアデバイスからのトラフィックと照合するために、プラットフォーム条件付きデバッグフィルタを設定します。
debug platform condition ipv4 10.2.0.200/32 ingress
debug platform condition start
ステップ 2パケット ヘッダー情報をコピーするため、次のように、copy オプションを付加した状態でパケット トレースを有効にします。
debug platform packet-trace packet 64
debug platform packet-trace copy packet input l3 size 100
ステップ 3リプレイ エラーが検出されたら、パケット トレース バッファを使用して、リプレイを原因としてドロップされたパケットを識別します。ESP シーケンス番号は、コピーされたパケットの中に表示されます。
Router#show platform packet-trace summary
Pkt Input Output State Reason
0 Gi4/0/0 Tu1 CONS Packet Consumed
1 Gi4/0/0 Tu1 CONS Packet Consumed
2 Gi4/0/0 Tu1 CONS Packet Consumed
3 Gi4/0/0 Tu1 CONS Packet Consumed
4 Gi4/0/0 Tu1 CONS Packet Consumed
5 Gi4/0/0 Tu1 CONS Packet Consumed
6 Gi4/0/0 Tu1 DROP 053 (IpsecInput)
7 Gi4/0/0 Tu1 DROP 053 (IpsecInput)
8 Gi4/0/0 Tu1 CONS Packet Consumed
9 Gi4/0/0 Tu1 CONS Packet Consumed
10 Gi4/0/0 Tu1 CONS Packet Consumed
11 Gi4/0/0 Tu1 CONS Packet Consumed
12 Gi4/0/0 Tu1 CONS Packet Consumed
13 Gi4/0/0 Tu1 CONS Packet Consumed
上記の出力から、パケット番号 6 と 7 がドロップされていることがわかります。これで、次の詳細な調査が可能になります。
Router#show platform packet-trace packet 6
Packet: 6 CBUG ID: 6
Summary
Input : GigabitEthernet4/0/0
Output : Tunnel1
State : DROP 053 (IpsecInput)
Timestamp : 3233497953773
Path Trace
Feature: IPV4
Source : 10.2.0.200
Destination : 10.1.0.100
Protocol : 50 (ESP)
Feature: IPSec
Action : DECRYPT
SA Handle : 3
SPI : 0x4c1d1e90
Peer Addr : 10.2.0.200
Local Addr: 10.1.0.100
Feature: IPSec
Action : DROP
Sub-code : 019 - CD_IN_ANTI_REPLAY_FAIL
Packet Copy In
45000428 00110000 fc329575 0a0200c8 0a010064 4c1d1e90 00000006 790aa252
e9951cd9 57024433 d97c7cb8 58e0c869 2101f1ef 148c2a12 f309171d 1b7a4771
d8868af7 7bae9967 7d880197 46c6a079 d0143e43 c9024c61 0045280a d57b2f5e
23f06bc3 ab6b6b81 c1b17936 98939509 7aec966e 4dd848d2 60517162 9308ba5d
上記の出力で太字で強調されているように、ESPシーケンス番号のオフセットは、IPヘッダーの先頭から24バイト（またはIPパケットペイロードデータの4バイト）です。この例では、ドロップされたパケットの ESP シーケンス番号は 0x6 です。
パケットキャプチャの収集
リプレイチェックの失敗が原因でドロップされたパケットのパケット情報の識別に加えて、対象のIPSecフローのパケットキャプチャは同時に収集される必要があります。これは、同じIPSecフロー内のESPシーケンス番号パターンの調査に役立ち、リプレイドロップの理由の特定に役立ちます。Cisco IOS XEルータでEmbedded Packet Capture(EPC)を使用する方法の詳細については、「Cisco IOSおよびCisco IOS XEの組み込みパケットキャプチャの設定例」を参照してください。
Wiresharkシーケンス番号分析の使用
WANインターフェイス上の暗号化(ESP)パケットのパケットキャプチャが収集されたら、Wiresharkを使用して、シーケンス番号異常に対してESPシーケンス番号分析を実行できます。まず、図に示すように、Preferences > Protocols > ESPでSequence Number Checkが有効になっていることを確認します。
次に、次のように、Analyze > Expertの情報でESPシーケンス番号の問題を確認します。
誤ったシーケンス番号が設定されているパケットのいずれかをクリックすると、次のような詳細情報が表示されます。
ソリューション
ピアが特定され、リプレイドロップのパケットキャプチャが収集されると、次の3つのシナリオでリプレイの失敗が説明される可能性があります。
- 遅延した有効なパケットである場合：
パケット キャプチャは、パケットが実際に有効であるか、また、問題は（ネットワーク遅延または伝送パスの問題による）軽微なものであるか詳細なトラブルシューティングが必要であるか、確認するのに役立ちます。たとえば、キャプチャでは、シーケンス番号がXのパケットが誤った順序で到着しており、リプレイウィンドウサイズが64に設定されているとします。シーケンス番号(X + 64)を持つ有効なパケットがパケットXの前に到着すると、ウィンドウが右にシフトされ、リプレイ障害のためにパケットXがドロップされます。
このようなシナリオでは、リプレイウィンドウのサイズを増やすか、リプレイチェックを無効にして、このような遅延を許容できるものと見なし、正当なパケットが廃棄されないようにすることができます。デフォルトでは、リプレイウィンドウのサイズはかなり小さくなっています（ウィンドウサイズは64）。 サイズを大きくしても、攻撃のリスクが大幅に高まることはありません。IPSecアンチリプレイウィンドウの設定方法については、『IPSecアンチリプレイウィンドウの設定方法：拡張と無効化』を参照してください。 - 送信側エンドポイントのQoS設定が原因である場合：
IPSecの後にパケットの並べ替えがIPSec送信デバイスのQoS設定によって発生する場合、潜在的な緩和策は、Cisco IOS XEプラットフォームで利用可能なIPSec SAごとの複数シーケンス番号スペースを使用することです。
- 以前に受信した重複パケットである場合：
この場合、同じIPSecフロー内で同じESPシーケンス番号を持つ2つ以上のパケットがパケットキャプチャで観察される可能性があります。この場合、IPsecリプレイ保護が意図したとおりに機能し、ネットワークでのリプレイ攻撃を防止するため、パケットのドロップが予想されます。syslogは単なる情報です。この状態が続く場合は、潜在的なセキュリティの脅威として調査する必要があります。
追加情報
Cisco IOS Classicを使用するレガシールータでのリプレイエラーのトラブルシューティング
Cisco IOSを使用するレガシーISR G2シリーズルータでのIPsecリプレイドロップは、次に示すようにCisco IOS XEを使用するルータとは異なります。
%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=529, sequence number=13
メッセージ出力は、ピアのIPアドレスまたはSPI情報を提供しません。このプラットフォームでトラブルシューティングを行うには、エラーメッセージで「conn-id」を使用します。リプレイはSAごとの（セキュリティアソシエーション）チェック（as opposed to aピアごととは異なる）であるため、エラーメッセージで「conn-id」を特定し、show crypto ipsec saの出力でそれを探します。 syslogメッセージは、パケットキャプチャでドロップされたパケットを一意に識別するのに役立つESPシーケンス番号も提供します。
これを以下に示します。
%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=529, sequence number=13
Router#show crypto ipsec sa | in peer|conn id
current_peer 10.2.0.200 port 500
conn id: 529, flow_id: SW:529, sibling_flags 80000046, crypto map: Tunnel0-head-0
conn id: 530, flow_id: SW:530, sibling_flags 80000046, crypto map: Tunnel0-head-0
Router#
Router#show crypto ipsec sa peer 10.2.0.200 detail
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 10.1.0.100
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 10.2.0.200 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 27, #pkts encrypt: 27, #pkts digest: 27
#pkts decaps: 27, #pkts decrypt: 27, #pkts verify: 27
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 0, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 21
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 10.1.0.100, remote crypto endpt.: 10.2.0.200
path mtu 2000, ip mtu 2000, ip mtu idb Serial2/0
current outbound spi: 0x8B087377(2332586871)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0xE7EDE943(3891128643)
transform: esp-gcm ,
in use settings ={Tunnel, }
conn id: 529, flow_id: SW:529, sibling_flags 80000046, crypto map:
Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4509600/3223)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
<SNIP>
この出力からわかるように、リプレイドロップは、0xE7EDE943のインバウンドESP SA SPIを持つ10.2.0.200ピアアドレスによるものです。また、ログメッセージ自体から、ドロップされたパケットのESPシーケンス番号が13であることもわかります。ピアアドレス、SPI番号、およびESPシーケンス番号の組み合わせを使用して、パケットキャプチャでドロップされたパケットを一意に識別できます。
以前のCisco IOS XEソフトウェアとの連携
以前のCisco IOS XEリリースを実行しているルータでは、次に示すように、syslogに報告される「REPLAY_ERROR」によって、リプレイされたパケットがドロップされたピア情報を含む実際のIPsecフローを出力できません。
%IOSXE-3-PLATFORM: F0: cpp_cp: QFP:00 Thread: 095 TS:00000000240306197890
%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 3
正しいIPsecピアとフロー情報を特定するには、syslogメッセージに出力されたデータプレーン(DP)ハンドルをこのコマンドで入力パラメータSA Handleとして使用し、Quantum Flow Processor(QFP)のIPsecフロー情報を取得します。
Router#show platform hardware qfp active feature ipsec sa 3
QFP ipsec sa Information
QFP sa id: 3
pal sa id: 2
QFP spd id: 1
QFP sp id: 2
QFP spi: 0x4c1d1e90(1276976784)
crypto ctx: 0x000000002e03bfff
flags: 0xc000800
: src:IKE valid:Yes soft-life-expired:No hard-life-expired:No
: replay-check:Yes proto:0 mode:0 direction:0
: qos_preclassify:No qos_group:No
: frag_type:BEFORE_ENCRYPT df_bit_type:COPY
: sar_enable:No getvpn_mode:SNDRCV_SA
: doing_translation:No assigned_outside_rport:No
: inline_tagging_enabled:No
qos_group: 0x0
mtu: 0x0=0
sar_delta: 0
sar_window: 0x0
sibling_sa: 0x0
sp_ptr: 0x8c392000
sbs_ptr: 0x8bfbf810
local endpoint: 10.1.0.100
remote endpoint: 10.2.0.200
cgid.cid.fid.rid: 0.0.0.0
ivrf: 0
fvrf: 0
trans udp sport: 0
trans udp dport: 0
first intf name: Tunnel1
<SNIP>
Embedded Event Manager(EEM)スクリプトを使用して、データ収集を自動化することもできます。
event manager applet Replay-Error
event syslog pattern "%IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error"
action 1.0 regexp "([0-9]+)$" "$_syslog_msg" dph
action 2.0 cli command "enable"
action 3.0 cli command "show platform hardware qfp active feature ipsec sa $dph |
append bootflash:replay-error.txt"
この例では、収集された出力はブートフラッシュにリダイレクトされます。この出力を確認するには、more bootflash:replay-error.txtコマンドを使用します。
関連情報
- 音声ビデオ対応 IPSec VPN（V3PN）ソリューション参照ネットワーク設計
- IPSecアンチリプレイウィンドウの設定方法：拡張と無効化」を参照してください。
- テクニカル サポートとドキュメント – Cisco Systems
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
7.0 |
14-Sep-2026
|
再認定 |
6.0 |
21-Nov-2025
|
機械翻訳、ブランディング、書式設定、および一部のリンクの修正。 |
5.0 |
04-Sep-2024
|
SEO、機械翻訳、リファレンス、およびフォーマットが更新されました。 |
2.0 |
13-Feb-2022
|
追加情報 |
1.0 |
15-Dec-2013
|
初版 |
フィードバック