要約

  • RFC 8092のLarge Communityは32ビット値を三つ持ち、四オクテットASNと二つのローカル値を無理なく表現する。しかし左端のASNは署名ではなく、値の追加者も途中の完全性も証明しない。
  • 操作権限が生じるのは、受信側ポリシーが隣接者、関係、関数、パラメータを具体的な変更へ結び付けるときである。受信UPDATEからRIB、FIB、実パケットまでのreadbackが必要だ。
  • 自AS名前空間の不正利用を除去しつつ、他AS向けの有用な文脈は残す。情報と命令、malformedとunauthorized、集合と優先順位を分け、移行時には正負双方のcanaryを使う。

正しい構文で越えた境界

仮想のマルチホーム顧客AS 4200004100が、二つのトランジットとIXPのroute serverへ接続しているとする。一方のプロバイダーは、地域別にLOCAL_PREFを下げる関数と、特定のpeer classへの広告を止める関数を公開している。顧客は混雑回避のため、試験用プレフィックスにその二値を付けた。

受信者Aは、送信セッションが契約済み顧客であること、各関数がその顧客に許可されていること、地域と相手区分が許容範囲内であることを確認する。Adj-RIB-Inには受信値が残り、policy traceに認可とmatchが記録される。Loc-RIBの選択、隣接者ごとのAdj-RIB-Out、FIB next-hop、パケット計測が同じ結果を指す。

受信者Bでは移行が途中で止まっていた。エッジは属性をparseできるものの、古いインポート規則群が共通ポリシーより前で全Large Communitiesを削除する。セッションはEstablishedのまま、経路数も通常、到達性も残る。要求だけが意思決定層へ届かない。

受信者Cは逆に、値を強く信じすぎる。自ASをGlobal Administratorに持つtupleを見つけると、どのpeer-groupから来たかを確認せず関数を実行する。peerや顧客の下流が同じ値を作れば、内部制御へ入力できる。壊れたpacket formatではない。認可のないprincipalに正しい文法を与えた結果である。

この差を「Large Communities対応済み」という一語では表せない。表現可能性、著者、許可、ローカル解釈、実行、サービス結果は別々の現実層であり、それぞれに証拠が要る。

96ビットが解いた問題

RFC 1997のCommunityは四オクテットである。運用上は上位16ビットをASN、下位16ビットをローカル値として読む慣行が広まった。しかし四オクテットASNは、その上位欄に入らない。

Extended Communityは型を持つ八オクテットの仕組みを提供した。RFC 5668には四オクテットAS固有形式があるが、Global Administratorが四オクテットを使うため、Local Administratorは二オクテットに限られる。二つの完全なローカル値を並べたい用途には足りない。

RFC 8092はGlobal Administrator、Local Data Part 1、Local Data Part 2を各四オクテットとした。IANAのpath attribute type codeは32である。RFC 8195は運用上の読み方としてASN:Function:Parameterを示す。

世界共通の関数表は定めない。あるネットワークは受信地点を、別のネットワークは関係区分や選択的広告を表す。この小さな初期仕様は、自発的な採用と現場の実装から協調を育てられる。一方で、意味を強制する中央権威もない。値を命令にするのは、常に受信者のrunning codeである。

左のASNは所有域であって印鑑ではない

Global AdministratorにASNを使う場合、そのASNの保有者が後二欄の意味を定める。これは名前の衝突を避ける規律であり、個々の値へ付く電子署名ではない。

64497:9:3を見ても、AS 64497が付けたとは断定できない。originが付けたかもしれず、中間ASや直近の隣接者が追加したかもしれない。RFC 8092は中間ASによる追加、削除、変更を認め、完全性保護がないことを明記する。

予約番号の扱いも認証ではない。0、65535、4294967295をGlobal Administratorへ使うことは推奨されないが、その出現だけで属性がmalformedになるわけではない。長さとencodingを検査するparser、意味を引くdictionary、送信者の権利を判定するauthorizationは独立させるべきだ。

一hopのセッション保護は目の前のpeerの識別に役立つ。それ以前に誰がtransitive valueを書いたかまでは保証しない。RPKI origin validationも、利用可能なROAに照らしてorigin ASとprefixの組を検証するだけで、communityの作者や他AS内部のLOCAL_PREF操作権を証明しない。

観測値と制御入力は同じ器に入る

RFC 8195はinformational communityとaction communityを区別する。前者は受信地点、隣接関係、対象範囲などを説明する。後者は広告範囲、LOCAL_PREF、next-hop、AS_PATH prependなどの変更を求める。

ワイヤ上の形は同じである。どちらかを決めるのは運用者の辞書とpolicyだ。辞書が非公開、古い、または装置ごとに違えば、一台では診断用情報、別の一台では実行可能な命令になり得る。

そこで情報用とaction用の範囲を分ける。各actionにはowner、許可されたsender class、parameter domain、衝突時の優先、AFI/SAFI、有効期限、rollbackを付ける。「地域3」がどのedge群を指すか、「prepend 5」が上限内か、「announce-none」と例外が同時に来たとき何を優先するかを曖昧にしない。

RFC 8195が勧める意味の公開は、相互運用の前提になる。ただし公開ページはspecification layerにすぎない。実機にロードされた版、受信経路、matchした節、変化した属性と転送結果がexecution layerである。

自分の命令をscrubし、他者の文脈を残す

RFC 7454は、自ネットワーク番号を使う受信communityを原則scrubし、その関係に許可したものだけを通すよう勧める。同時に、顧客がさらに先のネットワークへ送るための値まで一律削除しないよう求める。

Large Communitiesでは少なくとも四分類が必要だ。隣接者が明示的に呼べる自namespaceのaction、自ASが付けるか契約上受けるinformational value、意味を解釈せず透過させるforeign value、そして不正・廃止・関係不適合・危険な組合せである。

全保存はprovider-owned actionの合成を許す。全削除はdownstream coordinationを壊す。ローカルmark追加時にset全体を置換すれば、以前の証拠まで消える。additive処理は履歴を保ちやすいが、旧版の削除と競合解決を用意しなければ値が堆積する。

Route serverは例外が契約化された場である。RFC 7948の環境では、clientが相手clientごとの広告を制御することがある。RFC 8195もannounce-to-all、announce-to-none、個別例外を例示する。ここでは外部入力によるexport controlがサービスそのものだ。それでもclient sessionを識別し、許可関数を結び、衝突を解き、受信者ごとのAdj-RIB-Outを証明しなければならない。この設計を通常のtransitへ持ち込めば、権限境界が変わる。

集合に語順はない

RFC 8092におけるLarge Communities属性は順序のないsetである。encoding上の先頭を「最優先」と読むpolicyは、プロトコルにない意味を実装偶然へ与えている。

重複値は送るべきでなく、受信時には静かに除去される。同じ値が二つあっても二者の承認にはならない。contains、match-any、match-every、complete-set equalityも分ける必要がある。Cisco IOS XRはmatch、additive setting、delete、attribute filteringを文書化し、FRRoutingはexact setやJSONによるreadbackを備える。可視化手段があることと、安全な規則が選ばれていることは別だ。

Aggregationでは、aggregateがcontributorの値のunionを持つ。情報は残るが、全構成prefixが同意した意味にはならない。別々のmore-specificが異なるactionを持てば、aggregateは双方を継承し得る。action classごとに集約越しの継承可否を定め、contributor evidenceを残す必要がある。

malformedを権限違反の代名詞にしない

Large Communities attribute valueの長さは、ゼロでない十二オクテットの倍数でなければならない。違反時はRFC 8092がRFC 7606のtreat-as-withdrawを適用する。

セッション全体をresetしない点は堅牢だが、監視上は見落としやすい。peerはEstablished、KEEPALIVEも継続、無関係なrouteも残る一方、対象NLRIだけがAdj-RIB-Inから消える。attribute error、route delta、サービス影響を同じ時系列へ載せるべきだ。

正しく十二オクテットであるが、許可のないsenderから来た値は別の失敗である。ローカルactionだけstripしてrouteを残す、契約によりrejectする、reviewへ隔離する、といった明示的な認可結果が要る。すべてを「形式不正」と呼べば、parser、dictionary、principal boundaryのどこが破れたか分からない。

移行対象は分散プログラムである

従来CommunityからLarge Communityへの移行では、producer、edge import、route reflector、route server、collector、顧客文書、incident toolingが同じpolicy epochへ移る必要がある。

dual signallingは旧装置との共存を助けるが、両方のruleが動けばactionを二重実行する。旧辞書と新辞書がずれれば逆の結果も生む。collectorが新値を保存していても、それはtransportの証拠であってdecision policyの採用証明ではない。

Canaryには安全で測定可能なprefixを使う。受信したlegacy/large set、scrub後のnormalization、ruleとversion、変化したattribute、各Adj-RIB-Out、selected route、FIB next-hop、packet behaviorを保存する。許可済みsenderだけでなく、未許可senderが動かないことも確認する。malformed lengthはlabで試す。サービスがaggregateを作るならunionも対象にする。

Rollbackは設定行だけでなくroute stateを戻す。rule削除後も、以前のLOCAL_PREFで選ばれたpathがpolicy re-evaluationまで残る場合がある。Route refreshには範囲と時機、hard resetには大きなconvergence costがある。RFC 4264のBGP wedgieのような安定した誤状態では、単独装置の復元だけでは意図したtraffic patternへ戻らず、協調変更が必要になる。

証拠台帳を層ごとにつなぐ

各routeについて、peer、関係class、prefix、AFI/SAFI、session epoch、raw received set、parse結果、normalized set、削除値、ローカル追加値、dictionary version、authorization、matched clause、生成属性を記録する。さらにLoc-RIB selection reason、隣接class別Adj-RIB-Out、FIB next-hop、packet probeを結ぶ。

これにより「運ばれたか」「well-formedか」「送信者に権利があったか」「当時ここで何を意味したか」「実行されたか」「データ面が変わったか」「先へ意味が残ったか」を混同せず答えられる。

Public collectorは最後の問いの一地点しか観測しない。途中の改変、最初のwriter、他AS内部だけのactionは見えない。値の欠如もscrub、best-path、aggregation、export viewの違いで起こる。便利な観測点を、持っていない認証権限へ昇格させてはならない。

Sources