要約

  • LACNICは7月20日、FORT 1.7.0がASPAオブジェクトを検証し、その情報をルーターに共有すると説明した。同時に、ASPAは正式な標準として未発行であり、機能は実験的だとも明記した。
  • 対応する1.7.0.experimentalでは--server.max-rtr-versionの初期値が0である。タグ付き文書ではASPAを運ぶのはRTRv2とされ、別系統の--output.aspaも初期状態では無効だ。
  • 実装、設定、実際の交渉版、受理オブジェクト、経路判定、ルーティング方針を分けた記録がなければ、「対応」という語だけでは運用効果を説明できない。

このリリースの境界を示す数字は、1.7.0よりも0である。

LACNICのブログは、一部のRPKIリポジトリに存在するASPAをFORTが検証し、ルーターの判断に使える情報として共有すると紹介した。4日前の実リリースは1.7.0.experimentalという名称で、ASPAとRTRv2を実装する一方、サーバーが交渉するRTRの上限を0にしている。

ブログは可能性を、リリースノートは選択前の挙動を述べている。どちらも正しく、どちらも個別ネットワークの設定を証明しない。

実験状態を隠したという根拠もない。LACNICはASPAが未標準化で変更され得ると記した。プロジェクトは、FORTが現時点でRouter Keyを生成せずRTRv1の追加機能を使えないこと、RTRv2仕様が更新中であることを理由に挙げる。問うべきは慎重さの是非ではなく、配布物から実際のルート処理までを追跡できるかである。

三つの設定は同じスイッチではない

リリースに固定された使用ガイドには、別々の制御がある。

設定 初期値 対象
--aspa.max-providers 4,000 一検証周期に一つの顧客ASNが宣言できるプロバイダーASNの上限
--output.aspa NULL（無効） 有効なASPAをJSONへ出力するか
--server.max-rtr-version 0 ルータークライアントと交渉できるRPKI-to-Routerの最大版

入力上限、ファイル出力、ライブプロトコルは異なる面である。一つを設定しても、残りは開かない。

同文書によれば、RTRv0はプレフィックスVRPを配り、RTRv1はRouter Keyを加え、RTRv2でASPAが加わる。したがって初期設定のFORTはASPAを内部検証でき、別途ファイル名を指定すればJSONにも出せるが、v0で成立したルーターセッションはv2のASPA PDUを受け取れない。

これは全ルーターがASPAを受け取っていないという意味ではない。運用者は上限を2に変更できる。確認できるのは配布時の境界だけだ。

プロトコル交渉も保存すべき状態である

現行のRTRv2第27版では、ルーターが自ら実装する最高版で問い合わせる。キャッシュが対応すれば同版で開き、必要なら互換性のある低い版へ落ちる。低い版で合意したセッションでは、高い版の機能は使えない。

そのため設定値2は準備を示すだけである。クライアントがv2を要求し、交渉がv2で終わり、関連ASPAが届き、経路状態が計算され、ローカル方針が動いて初めて連鎖が完成する。

実行バイナリ、オブジェクト検証、ファイル出力、サーバー上限、クライアント対応、ASPA被覆、状態計算、方針のどこでも止まり得る。すべてを「ASPAが動いた／動かない」の二値にすると、修復場所を見失う。

署名済みオブジェクトは経路命令ではない

ASPAプロファイル第29版は、顧客ASNの保持者がプロバイダーASNを承認する署名オブジェクトを定義する。Relying Partyによるオブジェクト検証は有用な承認情報を作るが、特定のAS_PATHをまだ評価していない。

検証手順第28版は、その後の結果をValid、Unknown、Invalidに分ける。Invalidを選択対象外とし、UnknownをValidと同じ優先度にすることを推奨する一方、具体的な緩和方針は運用者の裁量とする。

有効オブジェクト数はバリデータ層、v2セッションは転送層、三状態は計算層を示す。RIB、FIB、方針記録があって初めて適用を示せる。ASPAを受信したことは、ルートを拒否したことではない。

v0を無策と表現するのも誤りだ。オリジン検証は続き、ファイル出力は実験にも使える。確かな表現は、FORTが実験的能力を提供し、ルーターへの配送と緩和を明示的な選択に残した、である。

草案番号もソフトウェアの身元である

タグ付きガイドは実装対象をRTRv2第25版とする。調査時点の現行版は第27版、ASPAプロファイルは第29版、経路検証は第28版だった。

この差だけで非互換とは言えない。編集修正か動作変更かは比較と試験が必要である。ただし実験実装を再現するには、単なる「RTRv2対応」では足りず、草案版、commit、パッケージ、試験相手が必要だと分かる。

RFC 8210は公開済みのversion 1仕様であり、ASPA PDUはまだInternet-Draftであるversion 2側にある。初期値0には合理性があり、その後の移行には履歴が要る。

ダウンロード件数は代替証拠にならない。取得、導入、起動、v2交渉、方針適用はすべて別である。

公開能力カードとローカル有効化証票

能力カードにはtagとcommit、パッケージ名とハッシュ、実装した各草案版、初期値と範囲、既知の差分、試験済みクライアント、置換とrollbackを記す。私的ネットワークの遠隔測定は不要である。

有効化証票は、導入ハッシュ、起動時刻、設定指紋、RTR上限、交渉版ごとの安全なクライアント集計、検証周期、理由別の受理・拒否ASPA数、出力状態とハッシュ、検証モード、経路状態、緩和方針、例外、rollbackを保存する。

ルーター名やトポロジーは公開しなくてよい。対外的には版別集計で足り、詳細は監査や障害調査のためにネットワーク内で保持できる。

両者はパッケージハッシュ、実装草案版、設定指紋で結ぶ。結合できなければ、公開資料は可能性だけ、運用資料は無名のプロセスだけを語る。

結論の限界

資料は導入数、設定変更数、v2セッション数、関連オブジェクト数、拒否ルート数を示さない。LACNICの説明が虚偽だとも、v2を初期値にすべきだとも、第25版と第27版が非互換だとも証明しない。

ASPAはBGP全体を保証しない。プロバイダー承認とリーク検知に使えるが、転送面を検証せず、Unknownをなくさず、ローカル方針を代替しない。

分かるのは、1.7.0.experimentalがASPAとRTRv2を実装し、ルーター上限を0、ファイル出力を無効として出荷し、最終緩和を運用者に残したことである。「ASPA対応か」ではなく、「どのbuild、どの草案、どの交渉、どの状態、どの方針か」と問うべきだ。

情報源