要約

  • GTSMでは保護対象のBGP通信をTTLまたはHop Limit 255で送出し、承認済みのネットワーク距離に収まる受信値だけを先へ進める。
  • 高い受信値は近さの証拠であって、相手の本人性やTCP/BGP内容の正当性ではない。オンリンク攻撃、経路上攻撃、トンネル、断片には別の防御が要る。
  • 実証は双方向で行う。送信時の255、到着値、しきい値、最初の破棄カウンタ、TCP/BGP状態、経路結果を一つの時系列に結ぶ。

運用者はまずhops 2をhops 3へ変えたくなる。それで可用性は戻るかもしれない。しかし変更後は、正規パケットだけでなく、もう一段遠い場所からの偽装パケットも距離検査を満たし得る。hop countは到達性の調整値であると同時に、信頼半径の上限でもある。

255から引き算して分かること

IPv4のTTLとIPv6のHop Limitは8ビットで、255が最大値である。通常の転送ではルータを通るたびに減る。GTSMはこの上限を送信値に固定し、受信側で残量を見る。

直結なら255、多段なら経路で消費した分だけ小さくなる。Ciscoの参照資料は受信下限を「255から設定hop countを引いた値」と説明する。FRRoutingはneighbor PEER ttl-security hops NUMBERを提供する。ただしhopの数え方やebgp-multihopとの関係は実装事項であり、CLIの見た目を他社装置へ移植してはならない。対象機種で送受信パケットを捕捉し、実際の境界を確かめる必要がある。

253以上を認める関係で252が来れば、そのパケットは予定した距離契約に反する。253が来ても、相手の名前や組織を証明したことにはならない。遠隔の攻撃者は255を超える初期値を作れないが、正規peerと同じリンク上の攻撃者は同じ高い値を付けられる。GTSMが強いのは遠さに対してであり、近くの偽装に対してではない。

Trustedは内容への信任ではない

RFC 5082は、登録済みGTSMセッションに属し受信値が範囲内のパケットをTrusted、範囲外をDangerous、セッションに対応づけられず判断できないものをUnknownとする。

ここでTrustedという語を拡張解釈してはいけない。侵害された正規peerからの不正UPDATEは距離検査を通る。逆に、正しいpeerのパケットでも保守経路が伸びればDangerousになり得る。分類しているのは発言の真偽ではなく、到来距離の整合性である。

さらに重要なのは処理位置だ。RFC 5082はCPUやラインカード帯域など、制御プレーンの希少資源を守る目的を持つ。BGPデーモンで破棄する時点では、すでにCPUキューやTCP処理を消費している可能性がある。転送プレーンやラインレートに近い場所でDangerousを分離できるほど、DoS防御としての実効性が高い。

従って証跡は一つのカウンタでは足りない。ハードウェア、制御プレーンポリサー、カーネル、TCPソケット、BGPプロセスの順に可視性を並べ、どこから見えなくなったかを特定する。BGPログだけでは「早期に希少資源を守った」とは言えない。

設定、設計、経路、実行を分ける

RFC 5082は既存プロトコル向けの汎用自動ネゴシエーションを定義していない。両端で手動設定し、255で送り、相手の距離に合う受信境界を置く。

そのため台帳には四つの事実が要る。承認したトポロジー、設定値、観測した実経路、装置が実際に適用したしきい値である。導入時には一致していても、ECMP、障害迂回、loopback移行、装置交換、IPv6化、セキュリティサービス挿入で乖離する。

設定表示は意図の証拠にすぎない。BGPがEstablishedであることもGTSM有効の証明ではない。両端で機能が無効でもセッションは成立する。境界を証明するには、正規パケットの通過に加え、しきい値より一つ低い試験パケットが予想した早い段階で落ちることを確認する。

multihopは信頼の直径を作る

直結peerでは、正規パケットが255で到着し、普通のルータを一台挟むだけで値が下がる。RFC 5082が最も明確な適用範囲を限定トポロジー、とりわけ直接接続に置く理由である。

multihopにも防御価値はある。三hopまで許すなら、それより遠い攻撃元を排除できる。ただし直径内にいる攻撃者は同じ条件を満たせる。RFC 7454もmultihopで効果が弱まる点を指摘している。

余白には根拠が必要だ。平常二hopなのに五hopを許すなら、障害時経路のためなのか、過去のテンプレートなのかを区別する。前者は可用性に対する明示的な投資、後者は所有者のいない境界拡張である。

方向も分ける。AからBは二hop、BからAは三hopという構成は珍しくない。SYNだけ通ってSYN-ACKが落ちることもある。ECMPの一部だけが長い場合、ハッシュによって断続障害になる。IPv4の値からIPv6を推測せず、方向・アドレスファミリ・経路・セッションepochごとに分布を持つべきだ。

トンネルは距離を持ち上げる

トンネルでは外側が何十hop進んでも、内側TTLが保たれる場合がある。終端近くで復元された内側パケットは、実際の注入地点よりも近く見える。MPLSのuniform、pipe、short-pipeでも振る舞いが異なる。

RFC 5082はトンネル終端の信頼、完全性、送信元検証を前提として扱う。記録すべきは「トンネルは一hop」ではない。入口で誰が注入できるか、内外TTLをどう扱うか、どこで復号・終端するか、出口でsource validationを行うかである。

DDoSスクラビングや仮想ファイアウォールを挿入してもpeerアドレスは変わらないことがある。しかし距離証拠の意味は変わる。GTSMの算術を変える中間装置は、BGP設定に現れなくても信頼境界に含まれる。

断片も例外である。非先頭fragmentにはTCPヘッダがなく、GTSMセッションへ早期に関連づけにくい。再構成を待てばメモリとCPUを使う。RFC 5082が断片化回避を勧めるのはこのためであり、MTU、ICMP、fragment rate limitを別途検証する必要がある。

距離検査の次に残る検査

GTSMは「距離が妥当か」を見る。ingress filteringは「このインターフェースからこの送信元が来てよいか」を見る。TCP-AOは鍵の文脈に基づいてセグメントの真正性と完全性を守る。control-plane policyは資源量を制限し、BGP policyは経路の許可を決める。

同一リンクの攻撃者はGTSMを通ってもsource validationで落ちるべきだ。on-path攻撃者は距離を維持できるため暗号認証が要る。正しく認証されたpeerが侵害されれば、不正prefixはローカルimport policyで止めるしかない。Unknown trafficには別のpolicingが必要になる。

どの層も代替ではない。TTL 255をauthenticationと呼ぶのは過大評価であり、authenticationでないから無価値だとするのは過小評価である。GTSMの役割は、近くから来たはずの制御通信について、遠隔偽装の候補を早く安価に落とすことにある。

失敗を予測できるcanary

変更前に双方向の実パケットを取り、送信255、受信値の分布、適用カウンタを確認する。平常経路だけでなく、保守経路と現実的な障害経路をモデル化する。

新しい正規到着値が252なら、旧境界を保つため経路を直すのか、252を含む新直径を承認するのかを先に決める。一時的な拡張には期限とrollbackを付ける。

隔離したpeerで、しきい値より上、ちょうど、ひとつ下の三点を送る。最初の二つは次の層へ進み、最後は予測した早期カウンタだけを増やすべきである。その後、同一リンクからのsource spoof、誤ったTCP key、認証済みpeerからの不許可経路を別々に試す。各テストが別の層で失敗すれば、制御の分離を証明できる。

切り替え後はGTSM drop、TCP retransmission、authentication failure、BGP FSM、受信経路を同じ時系列で見る。経路がないだけではTTL起因と断定できない。ACL、鍵、NOTIFICATION、import policyも同じ外形を作る。

rollbackは旧経路または両端の明示的なしきい値へ戻す。片側だけ無効化し、もう片側を最大まで開く方法は、セッションを直しても安全性を説明不能にする。

252のパケットは「偽物」ではなく、253という契約に合わなかった。GTSMを正しく使うとは、この差を守ることだ。近接性は次の検査へ進む資格しか与えず、本人性、完全性、経路権限までは与えない。