要約

  • KeyIDは送信中のsegmentを認証したMaster Key Tupleを示す。RNextKeyIDは送信者が将来の受信に使いたいMKTを示すだけで、秘密の配送、受領確認、相手の送信鍵切替を証明しない。
  • 状態は方向別である。各endpointに現在の送信鍵と希望する受信鍵があり、一つのsessionには四つの実質状態がある。「active key」一欄に統合すると、完了判定に必要な差が消える。
  • 旧MKTを廃止できるのは、新しいKeyIDと正常なMACを両方向で観測し、BGPの安定、再接続、旧鍵依存ゼロ、完全なrollbackを確認した後だけである。

障害の原因は秘密そのものの違いとは限らない。両チームが安全な帯域外経路で同じbyte列を受け取っていても、ローカルな命名がずれる。Aは新MKTにSendID 42、RecvID 42を付ける。Bは自分の規則でSendID 43、RecvID 43を付ける。change ticketでは双方とも「鍵42」と呼ぶが、TCP-AOが参照するのは会議の名称ではなく、各方向の実効IDである。

Aは新MKTを受信側の第一候補にする。Aから出るsegmentのMACはまだKeyID=17で作られる一方、RNextKeyID=42が載る。Bは旧MKTでそのsegmentを正常に検証し、そのsocket pairに対してSendID 42の送信MKTが手元にあるか調べる。該当する準備済みMKTがなければ、RFC 5925上は切替を行わない。この失敗はB→A方向に関するもので、Bは17で送信し続ける。後にBがRNextKeyID=43を通知しても、A→Bを切り替えるにはA側にSendID 43の準備済み送信MKTが必要である。

この無動作は不具合ではない。遠隔の一byteが、未配備または未承認の鍵をローカル装置に強制するのを防ぐ。しかしdashboardが「エラーなし」を「切替済み」と解釈すると、安全機構が障害の前触れに変わる。

二つのIDは別々の方向を語る

TCP-AOはTCP option Kind 29であり、Length、KeyID、RNextKeyID、MACを含む。小さなoptionが担うのは、既にendpointへ届いた鍵文脈の調整である。秘密配送protocolではない。

KeyIDは現在の送信segmentを説明する。送信時にはcurrent MKTのSendIDが入る。受信側はsource/destination addressとportの組にそのbyteを加え、RecvIDが一致するMKTを探してMACを検証する。一方向のSendIDは、反対側にあるその方向用RecvIDと対応しなければならない。

RNextKeyIDは逆方向の将来を示す。送信者は、今後受け取るsegmentの検証に使いたいMKTのRecvIDを載せる。それを受けたpeerは、要求された値に合う送信MKTをローカルで持っている場合にだけcurrent_keyを変更できる。

ID自体に暗号学的性質はない。0から255までの任意のlabelで、乱数でもversion番号でもなく、予約値もない。方向ごとに違ってよい。同じ42であっても、秘密、algorithm、MAC長、lifetime、socket scopeが同じとは限らない。

したがってRNextKeyID=42は、「あなたが対応する送信MKTを既に持つなら、私はRecvID 42で受けたい」という条件付きの意思表示である。鍵の配送証明でも、相手の切替完了通知でもない。

labelの背後にあるMKTが本体である

Master Key Tupleは秘密だけで構成されない。RFC 5925は、local/remote IP addressとTCP portからなるconnection identifier、SendID、RecvID、master key、key derivation algorithm、MAC algorithm、ほかのTCP optionをMACに含めるかどうかをMKTに持たせる。実装や管理系は有効期間も付加できる。

受信segmentはsocket pairとKeyIDによって正確に一つのMKTへ一致しなければならない。同じ秘密でも、別VRF、別address family、別peer range、別方向、別RecvIDに置かれていれば、実行時には同じ能力ではない。

option inclusionも相互運用条件である。TCP-AO自身のfieldは、計算時にMAC部分をzeroにして常に保護される。その他のTCP optionを含めるかはMKTによる。両端で方針、algorithm、MAC長が違えば、同じmaster keyでも検証は失敗する。

そのためinventoryには、住所とport、routing instance、SendID、RecvID、algorithm、MAC長、option方針、有効期間、current/rnext role、TCP connection epochが必要である。「42を投入済み」という一文では削除を承認できない。

master keyとtraffic keyは同じではない

TCP-AOはMKTとconnection contextからtraffic keyを導出する。入力には両端のaddress、port、接続後は双方向のInitial Sequence Numberが入る。送受信方向とSYN/接続後trafficも区別される。

同じmaster keyでも、peer、方向、connection epochが変われば別のtraffic keyになる。addressとportが再利用されても、新しいISNを持つ再接続は新しい認証文脈である。長時間生きた既存sessionの成功は、次のSYNが成功する証拠にならない。

Sequence Number Extensionは32-bit TCP sequenceのwrapを越える高位状態を提供し、長い接続のreplay耐性を支える。各方向に独立したSNEがあり、接続時にzeroから始まる。MAC failureを調べる際は、packetだけでなくそのepochが必要である。

秘密のfingerprint一致は重要だが、それだけでは足りない。ID、socket scope、方向、algorithm、option policy、MAC length、接続状態のどこかがずれていれば、同じ秘密は同じ運用結果を生まない。

一つのsessionに二つの切替がある

各endpointは、送信用のcurrent_keyを最大一つ、受信用に希望するrnext_keyを最大一つ持つ。AとBを合わせると四つのpointerになる。鍵切替は左右対称の一回操作ではない。

最初は配備である。旧MKTを有効なまま、新MKTをAとBの受信に使える状態へ置く。確認対象は保存されたconfigurationではなく、実行中socketに見えるMKTである。

次にAが受信希望を宣言する。BがRNextKeyIDをローカルDBで解決できれば、送信current_keyを変更する。Bから出た最初の新KeyID segmentをAが正常に検証して初めて、B→Aの切替が証明される。

逆方向は独立して行う。Bが受信希望を宣言し、Aが自分の状態をもとに送信を変える。途中ではBだけが新鍵、Aは旧鍵という状態も正しい。UIはそれを隠してはならない。

最後に明示したoverlapを保持し、再送、設定反映、観測遅延、再接続、rollbackを覆った後、旧MKTの依存ゼロを証明する。一個の「current key」表示はこの順序を表現できない。

切り替えないことがローカル権限を守る

旧鍵で正しく認証されたsegmentが、未知のRNextKeyIDを通知することはあり得る。対応するMKTがなければ変更しない。この規則により、peerは希望を示せても、こちらの鍵tableを作ったり、有効期限を変更したりできない。

共通仕様は最小限の交換形式を定める。各参加者は自ら検証できる状態をもとに変更を採用し、宣言ではなく実際の稼働状態と通信が採用を現実にする。

監視は結果を追う必要がある。RNextを受けた後、peerの送信KeyIDは本当に変わったか。新MKTのgood MAC counterは増えたか。key-not-found、bad MAC、wrong length、RNext request eventは出ていないか。BGPがEstablishedのままでも、17を使っているなら42の準備は証明されていない。

鍵管理はwire optionの外にある

RFC 5925は、帯域外protocolまたはmanual mechanismがMKTを供給すると仮定する。vault、API、暗号化channel、承認主体、監査記録を定義せず、旧MKTの削除も調整しない。

RFC 6518は鍵のlifecycleを広く捉える。有限の寿命は漏えい時の影響を抑えるが、頻繁な手作業は新たな露出と人為ミスを増やす。routing transportはadjacencyを落とさず変更できるべきで、key managementはfreshnessを運用可能にしなければならない。RFC 7211は、送信前に受信可能にすること、key tableの整合性、期限通知、時刻同期を重視する。

変更記録には、誰が生成し、plaintextがどこに存在し得たか、各endpointへどう届き、どのlocal IDを割り当て、受信/送信validityがいつ始まり、旧鍵がいつ終わり、誰が戻せるかを含める。

実務上必要なのは、運用者が有効なMKT、証拠、秘密、復旧手順を自ら保持し、両端を見られないベンダー画面に依存せずBGPを回復できることである。

旧鍵の削除が不可逆の境界になる

新MKTの追加は選択肢を増やす。旧MKTの削除は復帰経路を消す。旧鍵が残る間は遅れている方向やrollbackを支えられるが、削除後の不一致は直接TCP availabilityへ表れる。

永久保存も安全ではない。漏えいした鍵はreceiverが受け入れる限り有効であり、無期限overlapは旧鍵へのsilent regressionも許す。必要なのは、証拠で期間を区切る廃止である。

設定反映、TCP再送、telemetry lag、再接続、rollbackを覆う期間を決める。その間、各方向で最後の旧KeyIDと最初の新KeyIDを記録し、新MKTのgood MAC、bad/unknownの不増、BGPの安定、route baselineを確認する。既存socketと新しいSYNでは鍵選択pathが異なり得るため、controlled reconnectは必須である。

Linux kernel文書はgood/bad、key-not-found、AO-required counter、MKT inspection、trace eventを提供する。またreplacement current/rnextを指定しながら強制削除するinterfaceも説明するが、peerが旧鍵を要求し続ける場合は接続を壊し得ると警告する。緊急手段は双方向証明の代わりではない。

rollbackはsocket scope、SendID、RecvID、algorithm、MAC length、option policy、lifetime、secret provenanceを復元する。「17を戻す」だけでは、どの17かを決められない。

正しいMACはrouteを認可しない

valid MACが示すのは、segmentが期待した鍵文脈に合うことだけである。UPDATE内prefixの権利、AS_PATHの正当性、遠隔routerの健全性は証明しない。正規keyを持つpeerも誤経路を送れる。

RFC 4272は外部からのsession攻撃と、真正peerによるbogus routing informationを区別する。RFC 7454もTCP protection、GTSM、control-plane filtering、prefix filter、max-prefix、AS path policyを別の層として扱う。

診断でも分ける。bad MACはBGP parsing前に落ちる。認証済みでも不許可のrouteはimport policyで拒否される。max-prefixは正常認証されたsessionを意図的に閉じることがある。一つの「peer security」statusでは、どのauthorityが働いたか分からない。

canaryは四つの境界を証明する

まずrouting instance、両端address/port、BGP peer、TCP epoch、route baselineを固定する。双方の該当MKTを読み、SendID、RecvID、algorithm、length、option policy、validity、roleを記録する。secretは保護したfingerprintまたはcontrolled verificationで比較し、ticketへ貼らない。

第一に双方で新MKTの受信準備を証明する。第二にAが希望を通知し、Bが送る最初の新KeyIDと、Aが受け入れた最初のMACを捕捉する。第三に逆方向を独立に繰り返す。

両方向が新epochへ入ったら、KEEPALIVEと限定的なroute refreshまたはUPDATEを実行し、Adj-RIB、選択route、retransmissionを比較する。overlap後に再接続し、旧KeyIDがzeroであることを示してから、canary peerで旧MKTを削除し同じ検証を行う。

TCP-AOの強さは、権威を狭く保つ点にある。独立運用される二つのsystemがlocal labelを調整し、wireに秘密配送の権限を持たせない。新しい鍵epochが現実になるのは、双方が解決し、両方向が生成・検証し、BGPが再接続に耐え、旧依存がzeroになり、rollbackが残る時だけである。それまでは、42は提案にすぎない。