要約

  • RFC 5291ではBGP receiverが型付きOutbound Route Filterをpeerへ送り、peerがlocal outbound policyに追加して、後で捨てられるUPDATEを生成・送信しないようにできる。
  • ADD、REMOVE、REMOVE-ALLが変更するのはpeer提供かつsession限定の状態である。PERMITとDENYは希望を表すが、senderのlocal filterは消せず、peerは希望を採用しないこともできる。
  • IMMEDIATEは変更と再広告を可視化し、DEFERはcommitまで保存するだけである。証拠はsource、wire encoding、received ORF、local export、Adj-RIB-Out、UPDATE、receiver RIBをつなぎ、sessionごとに再構築する。

顧客routerだけを見れば、作業は成功に見える。受信経路が数十万から数百へ減り、memoryとCPUが下がった。変更記録には「providerが要求通りnarrow feedを送信」と書かれる。

普通のinbound filterでも同じ表示になる。providerが全tableを送り続けても、顧客のRIBは小さい。そこで証明されたのはlocal rejectionであって、remote側で仕事が消えたことではない。ORFは無駄をsender側で止める仕組みだが、結果の証明には両側が必要になる。

経路と要求は逆方向に流れる

通常のBGPでは、senderがLoc-RIBとlocal outbound policyからpeer別Adj-RIB-Outを作る。receiverは受信後にinbound policyを適用する。互いの自律性は境界で接する。

ORFは限定された逆向きsignalを追加する。receiverがfilter entryを送り、senderはそのreceiver向けoutbound filterへ加えられる。routeはproviderからcustomerへ進み、routeを減らす希望はcustomerからproviderへ戻る。

RFC 5291が定めるのは置換ではなく合成である。received ORFはlocally configured outbound filterに追加される。customerは「少なく」を求められるが、providerのsecurity rule、commercial boundary、confidentiality ruleを消せない。REMOVE-ALLが消すのは指定されたreceived ORFの全entryであり、全export policyではない。

ORF entryはpeerがhonorするかどうかを決められるlocal preferenceでもある。capability negotiationは協調surfaceを開くが、remote executionの権利を与えない。receiverは独立したinbound protectionを残し、実際のfeedを確認する。

Capabilityはfamily、type、directionの交差である

Capability code 3はOPENでAFI/SAFI、ORF type、Send/Receive directionを伝える。単純な「ORF対応」bitではない。

有効なのは双方の正確なintersectionだけだ。customerがIPv4 unicastのAddress Prefix ORFをsendしたくても、providerが同typeをIPv6でしかreceiveしないなら、IPv4関係は成立しない。sendできることはreceiveできることを意味せず、一つのfamilyは別familyを証明しない。

intersectionは初期feedにも影響する。対象familyで交差がある場合、RFC 5291はsenderがqualifying Route Refreshを受けるまでrouteを広告しないことを勧める。plain refresh、またはentry付きIMMEDIATEがその開始点になり、receiverは大きな初期tableの前に希望を置ける。

交差がなければ通常BGPが動く。Established sessionでもIPv4は待機し、IPv6は直ちに広告することがある。緑色のsession statusはtype、direction、first commitを示さない。

証拠はsession epochごとの実際のOPENを保存する。configurationはintent、negotiated intersectionはrunning interfaceである。

local prefix-listとpeerの状態は別物である

ORF entryはAFI/SAFI、type、action、match、type固有valueからなる。ADDはinstall、REMOVEは指定entryの削除、REMOVE-ALLはORFを空にする。PERMITは一致UPDATEを通す希望、DENYは通さない希望である。

RFC 5292のAddress Prefix ORFはSequence、Prefix、Length、Minlen、Maxlenを持つ。exact prefixとmore-specificのlength rangeを表現し、Sequenceが評価順を決める。

編集ファイル、local compiled entries、Route Refreshのbytes、peerがdecodeしたreceived ORFは四つのidentityである。generatorがsequenceを逆転し、denyを落とし、AFIを誤り、旧versionを送る可能性がある。source hashだけでは終端を証明できない。

canaryはexact permit、範囲内more-specific、Maxlenを一bit越えたroute、explicit deny、さらにORFがpermitしてもlocal exportがblockするrouteを含める。

複数の非空ORF typeがある場合、routeはすべてを通る。PERMITとDENYの合成はDENYになる。一種類だけの画面はeffective feedを過大表示し得る。

DEFERは書き込み、IMMEDIATEは可視化である

ORF mutationはRoute Refreshを使うがtransaction choiceを持つ。IMMEDIATEはentryを処理し、新stateに基づいて影響routeを再広告する。senderはaffected routeを再広告し、unaffected routeも送ってよい。

DEFERは変更を保存するが、feedをすぐ変えない。後続plain Route RefreshまたはIMMEDIATE付きORFでcommitされる。local policyも変わり全再広告が必要なら、DEFERの後にplain refreshを送る。

この分離により複数entryを一貫したversionとして準備できる。同時に、両装置がnew stateを表示してもold Adj-RIB-Outがまだ有効という罠を生む。

各DEFERにはtransaction ID、expected hash、owner、commit、deadline、rollbackを持たせる。期限を過ぎたpending stateは成功ではない。

plain Route RefreshはORFをclearしない。既存received ORFを適用して再広告する。Enhanced Route Refresh markerもORF mutation recordの代わりにはならない。

要求を削除してもlocal refusalは消えない

peer-provided DENYを消せばfeedが広がる場合があり、last entryを消せばORF自体がなくなる。しかし最大範囲はsenderのlocal outbound policyとhonor判断で制限される。

rollbackは非対称である。customerは旧entryを戻し、ORFを空にし、capabilityをやめられる。どの操作もprovider ruleを弱めてはならない。customer ORFを唯一のsecurity barrierにする設計は、preferenceをauthorizationと取り違えている。

receiverもinbound filterを維持する。peerはpreferenceを無視し、stateを失い、異なるtypeを再交渉するかもしれない。resource optimizationはadmission controlではない。

unknown valueは以前のORF全体を消し得る

未交渉AFI/SAFIやtypeはignoreされ、存在しないentryのREMOVEもignoreされる。

しかし選択されたORF内にunrecognized field valueがあると、RFC 5291は以前受け取った指定ORF全体をremoveする。半分しか理解できないfilterを残さない設計だが、feedはlocal boundaryまで拡大し得る。

このfailure pathをisolated peerで試す。message、entry、whole ORFのどれが消えるか予測し、Adj-RIB-Outで確認する。parser logだけではroute effectを証明しない。

mutation frequency、entry count、scopeにもlimitが要る。compromised receiverは再計算と再広告を連発でき、compromised senderはhonorしたふりができる。無制限automationはresource attack surfaceになる。

sessionが自然な有効期限になる

ORFは交換されたBGP sessionの間だけ生きる。session終了とともにpeer-provided stateは消える。reset前screenshotは次epochを証明しない。

次のsessionはcapabilityを再交渉し、必要ならfirst qualifying refreshを待つ。race、initial request欠落、intersection変更はlocal fileが不変でもfeedを変える。

session epochにOPEN、first ORF/plain refresh、received entries、activation、first Adj-RIB-Outを結び付ける。期待request前にrouteが出れば異常である。

resetはstateを消すが全sessionへ影響する。通常rollbackはobserved reverse mutationであり、reconnectは再構築を完全に予測できる場合だけ使う。

両側canaryが削減を証明する

low-impact peerと一familyでbaselineを取る。outbound candidates、wire UPDATE、remote input、local rejectsを測る。

negotiation後、initial feed前にnarrow permit/denyのIMMEDIATEを送る。senderはdecoded entriesとlocal export intersectionを確認する。Adj-RIB-Out、wire、receiverが「除外UPDATEは送信すらされなかった」ことを示す。

version 2はDEFERを使う。stored stateだけ変わりfeedは変わらないことを確認し、plain refreshでcommitしてexact deltaを比べる。REMOVE、nonexistent REMOVE、REMOVE-ALL、last-entry removalも別々に試す。

最後にsessionをresetし、old state消失とcapability/first refreshによる再構築を証明する。すべてのAFI/SAFIで繰り返す。

acceptanceは「ORF enabled」ではない。どのworkを削減し、どのlocal ruleがdisclosureを拒否し、どのexact requestが変化を起こし、receiverが何を見たかというledgerである。

ORFが与えるのは、隣接に少なく話してほしいと頼む小さな権利だ。もっと公開させる権利でも、相手のruleを消す権利でもない。境界を残すから、協調は検証可能になる。