要約

  • 経路集約は複数の詳細経路から一つの短いプレフィックスを新たに生成する。RFC 9774の現在の原則ではAS_SETを使わず、ATOMIC_AGGREGATEがAS_PATHの欠落を示し、AGGREGATORが最後に集約したspeakerを示す。
  • 集約経路の存在、正しいROA、稼働中のBGPセッションは、覆われた全宛先への到達性を証明しない。寄与経路が失われれば、外部広告が安定したまま、パケットをローカルで破棄することが正しい結果になり得る。
  • 圧縮を認める条件は、意図したorigin AS、寄与ASごとのフィルタ、圧縮前の経路記録、RIB/FIBとパケットの検証、そして集約契約全体を戻せるrollbackである。

午前2時13分、AS 64505は四本の顧客 /24 を 203.0.112.0/22 に集約した。更新量を抑え、上流に一つの安定した経路を見せるためだ。/22 には64505を許可するROAがあり、UPDATEにはATOMIC_AGGREGATEとAGGREGATORが付いた。

午前3時07分、メンテナンス中の顧客から受けていた 203.0.114.0/24 が消えた。残り三本があるため装置は /22 を維持した。公開collectorにwithdrawalはなく、RPKI-ROVはValid、上流セッションはEstablished、FIBにも集約経路が残る。通常のダッシュボードなら正常と判定する。

しかし消えた /24 宛てのprobeは、64505に到着後、より長い一致を見つけられず、集約用のdiscard routeで終わる。この破棄はループ防止として正しい。別の短い経路で外へ出し、同じ集約に戻すことを防ぐからだ。ただし正しく破棄されたことは、サービスが提供されたことを意味しない。

この事例は仮想だが、仕組みは標準そのものである。ATOMIC_AGGREGATEは配達保証ではない。公開されたAS_PATHが、集約を構成した実経路の全てを表せないと知らせる属性である。

集約は表示の省略ではなく、新しい経路の生成である

BGPは複数のmore-specificを一つのless-specific NLRIへまとめる。新しい経路は独自の属性、生成条件、export policy、転送結果を持つ。元の経路が一つ消えても残り得るため、単なる画面上の略記ではない。

RFC 4271の当初の手順は、寄与する全AS_PATHに共通する最長の先頭シーケンスを残し、残りのAS番号を順序なしのAS_SETへ入れた。これで関与したASの一部は残るが、通過順序は失われる。右端のorigin ASも一意に決めにくく、起源や順序を扱うセキュリティ技術に向かない。

RFC 6472は2011年にAS_SETとAS_CONFED_SETを使わないよう勧告した。2025年5月のRFC 9774はそれを廃止して標準要件へ進めた。移行期などにoperatorが明示的な例外を設定しない限り、speakerはsetを含むUPDATEを広告してはならず、受信時にはtreat-as-withdrawとする。

集約そのものを捨てたのではない。曖昧な集合の代わりに、オリジンを意図的に固定し、失った情報の存在を明示する方式へ責任を移したのである。

空の属性が語る「分からないこと」

ATOMIC_AGGREGATEは属性コード6、well-known discretionaryで、値の長さはゼロである。省かれたAS番号、寄与経路、時刻、署名は一切入らない。意味はプロトコル上の約束だけにある。

AS_SETを落とした結果として元経路のAS番号が除外されたなら、集約にはこの属性を付けるべきである。受信者は転送時に消すべきではなく、そのNLRIを細分化して再広告してはならない。そして実際のパケット経路には、表示されたAS_PATHにないASが含まれ得ると理解しなければならない。

これは安全認証ではなく、知識の限界である。何かを省いたことは伝えるが、何を省いたかは伝えない。プレフィックスを許可せず、集約者を認証せず、到達性も証明しない。寄与経路の一つが既にATOMIC_AGGREGATEを持つなら、新しい集約も継承する。二度目の要約で最初の欠落を消してはならない。

外部との共通情報を薄くすることには価値がある。しかし薄い情報は、削った現実を支配する根拠にはならない。短い経路は、強い証拠ではなく、少ない証拠なのである。

AGGREGATORは最後の行為者であり、履歴台帳ではない

AGGREGATORはコード7のoptional transitive属性である。集約を作ったspeakerは、自身のAS番号とIPアドレス、通常はBGP Identifierを入れられる。RFC 9774のconsistent brief aggregationでは、ATOMIC_AGGREGATEとともに含める。

二つの属性の役割は異なる。前者は経路情報の欠落、後者は現在の集約を最後に形成したASとspeakerを表す。寄与者、policy version、承認者、以前の集約履歴までは記録しない。寄与経路が持っていたAGGREGATORを、そのまま新経路へ複製することもRFC 4271は認めていない。

暗号学的な認証でもない。collectorに表示されたASとアドレスだけでは、アドレス空間の管理権、正しいpolicy、元証拠の保存を証明できない。4-octet ASN対応では、対応speaker間のAGGREGATORが8 octetになり、旧speakerをまたぐ場合はAS_TRANSとAS4_AGGREGATORを使う。保存されるのは番号であって、正当性ではない。

RFC 7606は不正なATOMIC_AGGREGATEやAGGREGATORをattribute discardで処理する。セッション全体を落とさない点は可用性に優れるが、警告や帰属だけが失われた経路が残り得る。エラーの記録をセッション状態から独立させる必要がある。

オリジンを寄与経路の偶然に任せない

AS_SETを捨て、共通の先頭列だけを残す方式はbrief aggregationと呼ばれる。寄与経路の集合が変われば、共通列も変わる。互いに異なる二経路では空だった列が、一方の消失後には残った経路そのものになり、見かけのorigin ASまで変化し得る。

これは隣接の生死に、対外責任を決めさせる設計である。RPKI-ROVの面でも、発生し得る全オリジンにROAを用意するという不安定な運用になる。

RFC 9774のconsistent brief aggregationは、意図したorigin ASの最も右側の出現位置でAS_PATHを切る。集約AS自身を選んでもよい。集約プレフィックスには、そのASを許可するROAが必要になる。64505が責任を負うのは、最後に残ったからではなく、operatorがそう決めたからだ。

origin ASとBGPのORIGIN属性も別物である。前者はAS_PATH右端から推定される。後者はIGP、EGP、INCOMPLETEのどの方法で情報がBGPへ入ったかを示し、集約時には最も不利な値が残る。同じ「オリジン」という表示に混ぜれば、異なる整合性を一つに見せてしまう。

ROAのValidも限定的だ。アドレス空間保持者がASに特定プレフィックスのoriginateを許可したことを示すだけで、省略AS_PATH、AGGREGATORのアドレス、NEXT_HOP、FIB、discard、パケット配送は検証しない。

AS_SETを外すと、ループ対策は設定へ移る

AS_SETには寄与ASの番号が残り、集約がそのASへ戻れば通常のループ検出で拒否できた。setを禁止すると、その自動的な記憶もAS_PATHから消える。

RFC 9774は集約を寄与ASへ広告すべきではないとする。各寄与者には、当該寄与者から学んだものを除き、他の適切なmore-specificを広告する。これはneighborごと、方向ごとのpolicyである。寄与者台帳が古ければ、短縮後のAS_PATHには誤りを補う情報がない。

データプレーンにも防壁が要る。RFC 4632は、集約には一致するが到達可能なmore-specificには一致しないパケットを、生成routerが破棄するよう求める。通常はnull/discard routeで実装する。これがなければdefaultなどで外へ出たパケットが再び集約へ戻り、ループを形成し得る。

discardは安全性の証拠であって、可用性の証拠ではない。そこへ落ちたパケットはループが止まったことと、対象宛先が利用不能なことを同時に示す。集約の存在だけを健康度にすれば、この二つを誤って一つにしてしまう。

圧縮前の証拠を別の場所に残す

公開collectorは最終的な /22、見えるorigin AS、到達した属性を観測できる。policy前に拒否された経路や無音になった寄与者は見えず、ゼロ長属性から省略ASを復元することもできない。

各集約のローカル台帳には、対象プレフィックス、必須・任意の寄与者、生成条件、pre-policyとacceptedのAS_PATH、計算した共通列、選択origin、ROA結果、policy version、実行speakerを記録する。その後のLoc-RIB、policy前後のAdj-RIB-Out、各属性、NEXT_HOP、ORIGIN、more-specific suppressionも保存する。

最後はforwardingで検証する。RIBとhardware FIBのdiscardを確認し、全アクティブ寄与プレフィックスから一つずつ、意図的な空白からも一つ宛先を選ぶ。前者は配送、後者はローカル破棄が期待値であり、異なるラベルを付ける。

監視状態も四つに分けるべきだ。寄与者あり、寄与者なしだが契約通り集約あり、集約なし、集約ありだがdiscardなし。最後の状態は公開面が正常に見える分だけ危険である。

集約契約全体をcanaryにする

集約変更は一行の設定変更ではない。NLRI、寄与条件、オリジン、ROA、欠落警告、行為者、export filter、more-specific suppression、discardを同時に変える。

canaryでは正と負の両方を試す。稼働中 /24 の宛先へ届くことを確認する。試験用寄与者を制御してwithdrawした後、その範囲の宛先が集約AS内でdiscardされ、neighborへ出ないことを確認する。同時に外部AS_PATH、ATOMIC_AGGREGATE、AGGREGATOR、ROV、more-specific広告を採取する。

rollbackはimport、suppression、aggregate generation、origin、ROA、outbound filter、null routeを一体で戻す。コマンドだけ戻して具体経路を回復しない作業は、元のサービス状態への復帰ではない。