要約

  • RFC 1997では、communityを理解する受信者はNO_EXPORT経路をconfederation境界の外へ広告してはならない。ただし送信者やprefixの正当性を認証する値ではない。
  • 値は本地ポリシーが変更できるoptional transitive属性に入る。RFC 8642は、似たcommunity書換え命令が実装ごとにwell-known値を消したり残したりした事実を記録した。
  • 信頼には、送信、受信、変換、各出口広告までの経路証拠が必要であり、prefixと関係性のfilterも別に維持しなければならない。

ある網がprivate interconnectionにmore-specific prefixを出し、隣接網の内部だけで使わせたいとする。送信側はNO_EXPORTを付ける。ここで確認できるのは自分の出口で依頼を添えたことだけだ。境界が実在するかは隣接網の処理に残されている。

RFC 1997のCOMMUNITIESは、共通の性質を持つdestinationをまとめ、policy管理を簡潔にするために作られた。属性はoptional、transitiveで、四octetの値から成る。属性がtransitiveであることと、NO_EXPORT経路を外へ出してよいことは別である。

規則は明確だ。NO_EXPORTを含む経路はBGP confederationの境界外へ広告できない。独立したASはこの規則では自分自身を一つのconfederationとして扱う。NO_ADVERTISEなら他のどのBGP peerにも送れない。NO_EXPORT_SUBCONFEDは同じconfederation内の別member ASも外部peerとして扱う。

IANAが値を登録し、RFCが意味を定める。この共通語彙によって、送信者は相手のvendor syntaxを知らなくても範囲を伝えられる。一方、RFC 1997は受信者が本地ポリシーによってcommunityを追加・変更できることも認める。これは遠隔命令ではなく、自治した実行者への入力である。

RFC 8642は、その入力がどこで失われるかを示した。set communityのように見える命令でも、全communityを置換する実装、一部のwell-known値を残す実装、既存値を消さない実装があった。同じ設計書から異なる経路が出てしまう。

したがってconfigurationだけでは証拠にならない。商用tagを足すroute-mapがNO_EXPORTまで消すことがある。IPv4とIPv6が別policy chainを通ることもある。保存された設定とrunning processが一致しない場合もある。判定対象は結果として広告された経路である。

RFC 8642は新しい実装が差異を増やすことを禁じるが、既存fleetを遡って統一しない。upgradeでは制御したprefixを使い、前後の属性を比較する必要がある。

RFC 7454は、受信communityの信頼境界を示す。隣接者に利用権がない自網namespaceの値は除去し、それ以外は一般に残し、とりわけ理由なくNO_EXPORTを消さない。全てを信じれば外部からprivate actionを呼び出され、全てを消せば正当なscopeまで壊れる。

NO_EXPORTには署名も履歴もない。誰が最初に付けたか、originがprefixを広告してよいか、契約がその範囲を認めたかを証明しない。RPKI origin validationとcommunity scopeは別の問いである。

RFC 7908のroute leakは、期待された範囲を越えた伝播であり、多くはprovider、customer、peer間に分散したpolicyで定義される。NO_EXPORTが一つもない漏えいもある。prefix filter、customer cone、neighbor classごとのexport policyは不可欠だ。

RFC 9234は別の設計を加える。両端がOPENでBGP Roleを確認し、Only to Customer属性で関係性に沿った伝播状態を持たせる。片側が付けただけのmarkと異なり、関係の整合性をprotocol内で確かめられる。

それでも権限は分散する。strict modeはrole不一致でsessionを拒否できるが、software update後の停止リスクもある。途中のASがOTCを意図的に除去することもできる。機械可読性は高まるが、中央執行や暗号学的保証にはならない。

証拠は送信側のAdj-RIB-Outから始まる。正確なNLRI、address family、peer、policy前後の属性を残す。受信側ではraw received routeとimport後の状態を分ける。最後に、境界を越え得る全出口の広告を確認する。

一つのpublic collectorで見えないことは世界全体の非広告を証明しない。collectorが見ているsessionは限定される。canary prefixをNO_EXPORTあり・なしで広告し、既知のpeerと複数の観測点で、許可範囲内の到達性、範囲外の不在、withdraw後の消去を確かめる。

automationは設定文字列ではなく経路結果を比較すべきだ。保護されたcommunityが書換えで消えるrelease、関係matrixとAdj-RIB-Outが食い違う状態、期限切れexceptionを止める。事故時には、実際にUPDATEを出す網がprefix filterや選択的withdrawという本地の停止手段を持つ。

Heng Luのminimum initial specificationは、この役割分担を説明する。共通層は小さな語彙と明確な初期境界を与え、将来の例外やrisk判断は損失を負う側に残す。running-code primacyの下では、RFCとcommitは意図であり、実際のUPDATEがsystemである。

NO_EXPORTは弱いから失敗なのではない。routerの支配権を渡さずにscopeを伝えられることが価値である。ただし名前だけでは経路は止まらない。各自治点が選び、実装し、証明して初めて境界になる。

Sources