【RFC5925】BGP MD5認証の代替案 TCP-AO(TCP Authentication Option)

BGPのpeer認証は一般的にRFC 2385(Protection of BGP Sessions via the TCP MD5 Signature Option)で提案されているMD5を利用しているのが一般的ですが、この案を廃止し、代替案としてTCP-AO(TCP Authentication Option)が提案されています。

https://conference.apnic.net/50/assets/files/APCS790/The-TCP-Authentication-Option.pdf

TCP-AO(TCP Authentication-Option)とは

TCP-AO(TCP Authentication-Option)とは、RFC5925,RFC5926で提案されている
トランスポート層の認証を行うためのTCP option(Kind 29)です。

RFC7454(BGP Operations and Security)では、MD5よりTCP-AOを優先すると良いと提案されています。

本記事は、NANOG80(It is Time to Replace MD5)、APRICOT51、APNIC50を元に調べた情報のメモ書きです。
詳細は、NANOG80のスライド及びRFC5925、RFC5926をご参照ください。

RFC 5925 - The TCP Authentication Option

設定に関しては、Ciscoのマニュアルが分かりやすかった。

www.cisco.com

TCP-AOのメリット

TCP-AOを利用することで、既存のMD5に比べて主に以下の利点があります。
1. BGPやLDPなどの長時間持続しているTCPコネクションに対する攻撃への対策強化
2. 既存TCPコネクションを持続したまま、共有鍵の変更が可能
3. 複数の認証アルゴリズムのサポート

■BGP認証なしの場合

以下の攻撃を受け、TCPのセッションがresetされたり、
乗っ取りなどが発生する可能性がある。

-Blind insertion attack
–Reply attack

■Blind insertion attackの手法

- ルータAは、ルータBとのBGPセッションを維持
- ルータC(攻撃者)は、ルータBに毎秒数個の偽装パケットを送信
- ソースIPアドレスをルータA(スプーフィング)
- TCP/179 RSTパケット, ランダムなシーケンス番号
- ルータBは、シーケンス番号が無効のため、パケット破棄
- いずれルータC(攻撃者)は有効なシーケンス番号のパケットを送信
- BGPセッションがリセットされる

■BGP MD5認証[rfc 2385]

- 送信ノードと受信ノードに事前共有鍵を設定
- 送信ノードの手順
1. 各TCPセグメントのメッセージ認証コード(MAC)を計算する
2. MACの計算にMD5を利用
3. TCPセグメントと事前共有鍵を使ってMACを計算する
4. 各TCPセグメントにMD5署名オプションを含める
5. MD5 signature optionにMACを含める
- 受信ノードの手順
1. 受信したTCPセグメントごとにMACを算出
2. 計算したMACと受信したMACが一致しない場合はパケット破棄

■MD5の問題点

- 共有鍵の変更時、TCPコネクションをリセットする必要がある(共有鍵はそのまま)
- 認証アルゴリズムの俊敏性が求められる
- MD5は衝突の弱点あり

■認証に関する新しい要望

- TCPセッションをリセットすることなく事前共有鍵を変更可能
- 複数の認証アルゴリズム

■TCP-AOのコンセプト

- MKT (Master Key Tuple)
- 各ノードに1つ以上のMKTが設定される
- トラフィックキーの生成に使用
- トラフィックキー
- 各TCPセグメントのMACを生成するために使用
- TCP認証オプション
- TCPセグメントを認証するために使用
- MAC、KeyID、RNextKeyID を含む
- KeyIDは，MACの生成に使用されたMKTとトラフィック・キーを識別
- RNextKeyは、受信ノードが次のセグメントのMACを生成する際に使用するMKTおよびトラフィックキーを特定

■MKT

- TCPコネクションの識別子
- 送信元アドレス、送信先アドレス、送信元ポート、送信先ポート
- ワイルドカード可
- TCPオプションフラグ（MACでカバーされるTCPオプションを決定)
- 識別子
- 送信用、送信：送信セグメントのKeyIDの生成に使用
- 受信時、受信：インバウンドセグメントのKeyIDを解決するために使用
- 認証アルゴリズム
- マスターキー
- 鍵導出アルゴリズム

- 各ノードは1つ以上のMKTで構成されています。
- 各ノードはそれぞれのMKTから4つのトラフィックキーを得る
>Send_SYN_traffic_key,Receive_SYN_traffic_key,Send_other_traffic_key,Receive_other_traffic_key
- 各ノードは、どのMKTがアクティブであるかを独自に判断
- 方法はRFC5925の範囲外
- 多くの実装では、各MKTの開始時刻と終了時刻を指定しています

■認証

- 送信ノードの手順
- 各TCPセグメントのメッセージ認証コード(MAC)を計算する
- 適切な認証アルゴリズムを使用
- TCP セグメントとアクティブなトラフィックキーを使って MAC を計算
- 各セグメントに TCP-AO を含める
- TCP-AO の署名オプションには、MAC、KeyID、および RNextKeyID が含まる
- 受信ノードの手順
- 受信したTCPセグメントごとにMACを算出
- 受信した KeyID に関連するアルゴリズムとトラフィックキーを使用
- 計算したMACと受信したMACが一致しない場合はパケット破棄

■シーケンス番号のロールオーバ

TCPは、32bitsのシーケンス番号を使い回す(ロールオーバー)。
回避策として、シーケンス番号に加え疑似ヘッダの32bitsを拡張し、64ビットのシーケンス番号スペース(SNE)を利用することでリプライ攻撃を阻止。

■MD5とTCP-AOのオプションミスマッチ

TCP-AOとMD5の同時利用は、RFCで禁止(MUST NOT)されていますが、Cisco社の場合、

対向機器でTCP-AOオプションを未サポート時に接続できるオプションが存在します。(動作未確認)

"accept-ao-mismatch-connections"
TCP-AOオプションなしでピアから接続を受信したときに、接続を非TCP-AO接続として受け入れるオプション。

■NAPTなどを利用するミドルボックス(FWなど)を中継する場合の問題点

- IPアドレスまたはポートを変更しないミドルボックスはサポートする。
- TCP MSSやWindow Scaleなどを変更するミドルボックスではMACの計算で失敗する場合がある。

Ciscoには「"include-tcp-options":MACの計算にTCP-AO以外のTCPヘッダを見ない」があるため、
ミドルボックス対策の設定なのではないかと思う(用途不明)

■実装状況

- ノキア SR OS 16.0.R15, 19.10.R7, 20.5.R1 (Juniper社との相互運用性テスト済み)
- シスコ IOS XR 6.6.3および7.0.1以降は安定している
- ジュニパーネットワークス：20.3R1
- Huawei社：2021年第2四半期を目標とする
- Arista："スケジュールについてはノーコメント"、"我々はそれに取り組んでいる"