WLC の msglog で以下のメッセージが継続的に記録され、特定のクライアントが継続的に通信出来ない場合があります。
#LWAPP-3-REPLAY_ERR: spam_lrad.c:xxxxx The system has received replay error on slot [slot ID], WLAN ID [WLAN ID], count xxx from AP [AP's MAC Address]
これは APの show logging で記録される以下に対応するものです。
%DOT11-4-CCMP_REPLAY: Client [Client MAC Address] had [Error Frame Count] AES-CCMP TSC replays
AP がクライアントから受信したデータフレームの CCMP ヘッダに含まれる PN (Packet Number) が受信済みフレームの値より小さい場合、リプレイ攻撃が疑われるためにフレームは破棄されますが、実際にはクライアントの無線ドライバの不具合などで発生する事例が多く見受けられます。
このドキュメントでは無線キャプチャにより CCMP Replay Error の原因調査例を記述します。
Packet Number とは ?
Packet Number は AES-CCMP データフレームの CCMP ヘッダに含まれるフレームで Sequence Number とは異なる値です。
Wireshark では CCMP Parameters 内の CCMP Ext. Initialization Vector フィールドで確認できます。
CCMP ヘッダの構成は以下のようになっており、1, 2, 5, 6, 7, 8オクテット目の合計 6バイトで PN を表します。
上記 Wireshark の例ではフレーム番号 #6001 の Sequence Number = 3301 で、PN = 0x000000001CEF であることが分かります。
PN はデバイスが AES-CCMP 暗号フレームを作成する度に 1つずつインクリメントされ、CCMP ヘッダに記録されるとともに Nonce の要素として暗号化処理にも使用されます。
クライアントが PN を通信中にリセット後、継続的にエラーが記録される例
AP の show logging で特定のクライアントについて CCMP Replay Error メッセージ
%DOT11-4-CCMP_REPLAY: Client xxxx.xxxx.xxxx had xxx AES-CCMP TSC replays
が継続的に記録される場合、無線キャプチャを取得して Wireshark で
wlan.sa == xx:xx:xx:xx:xx:xx && wlan.ccmp.extiv
によるフィルタを行って、当該クライアントから送信される CCMP ヘッダを持つデータフレームを抽出します。
debug client とキャプチャを同時に取得すると、CCMP Replay Error が発生したタイミングで以下のような状況が確認できました。
#5989 は PN = 0x000000001CEE のデータフレームです。(SN = 3300)
#5993 は PN = 000000001CF1 で #5989 の PN より大きな値のため受信可能です。PN = 0x1CEF および 0x1CF0 のフレームが抜けていることが分かります。
#5996 は APからのフレームです。
#5997 の PN は 0x000000001CF2 で #5993 の次の値になっています。(SN = 17)
frame #6001 は PN = 0x000000001CEF で、直前のフレーム #5997の PN=0x1CF2 より小さな値、#5989 と #5993 の間で抜けていた PN になっています。SN は #5989 の続きの 3001 になっています。
frame #6003 は PN = 0x000000001CF0 で #6001 の続きの値、かつ、#5989 と #5993 の間で抜けていた PN になっています。
frame #6011 は PN = 0x000000000002 で、これまでの PN=0x1C.. ではなく初期化されているような状況になっています。
frame #6013 は PN = 0x000000000003 で、#6011 の次の値になっています。
クライアントが #5989 と #5993 の間で欠落していた PN を持つフレームが後から #6001, #6003 で送信するという、通常は発生しない out-of-order 事象と PN のリセットと思われる事象が連続して発生し、それ以降、この無線クライアントについて継続的に CCMP Replay Error が記録される状況でした。
一方、debug client を確認すると、当該時刻に session-timeouによる EAP再認証が発生していたことが分かり、#6011で PN のリセットは暗号鍵の更新に伴う期待される挙動であることが判断できます。
*Dot1x_NW_MsgTask_6: xxxx 21:18:00.858: xx:xx:xx:xx:xx:xx Sending EAP-Success to mobile xx:xx:xx:xx:xx:xx (EAP Id x)
*Dot1x_NW_MsgTask_6: xxxx 21:18:01.978: xx:xx:xx:xx:xx:xx Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile xx:xx:xx:xx:xx:xx
EAP認証を用いる環境では、再認証処理に関するフレームも暗号化され、キャプチャでは EAPパケットおよび 4 way handshake フレームは、(無線クライアントと有線上の端末間の通信ではなく) 無線クライアントと AP の間のデータフレームとして記録されます。キャプチャでは、以下の Wireshark フィルタで抽出できます。
wlan.fc.type_subtype == 0x0028 && ((wlan.sa==[クライアントMAC] && wlan.da==[BSSID]) || (wlan.sa==[BSSID] && wlan.sa==[クライアント MAC]))
このフィルタにより、#5996, #5997 は debug client に記録された 4 way handshakeの message 3 および message 4 であることが判明したことから、out-of-order となっている #6001, #6003 が 4 way handshake 完了後に送信され、AP側で新しいセッションの PNが 0x1CEF で初期化されたことで、#6011 以降のフレームが CCMP Replay Error となることが分かりました。
クライアントが 4 way handshake 完了後に out-of-order となる PN を持つフレームを送信する原因としては、4 way handshakeに関するフレームを通常のデータフレームより優先的に送信して #6001, #6003 が送信キュー内に滞留されたことが推測できます。
4 way handshake が完了して鍵更新が行われた際は、以前のセッションで付与された PN を持つフレームが送信キューにある場合はフラッシュする必要があり、クライアントのドライバで必要な処理を行っているか調査する必要があります。
このように、CCMP Replay Error が発生した場合の原因調査には、無線キャプチャが必須となり、それが認証のタイミングで発生しているのでれば debug client の同時取得も必要です。
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
