要約

  • RFC 7999のBLACKHOLE communityは、印を付けたprefix宛てのトラフィックを捨ててほしいという助言である。受信者は、当該sessionで事前合意があり、隣接ネットワークにcovering prefixの広告権限があり、明示的なローカルポリシーがある場合に限って実行する。
  • 宛先型RTBHは、より具体的な経路をdiscard/nullへ解決する。攻撃トラフィックを制約回線の手前で止める代わりに、同じ宛先への正当な通信も同時に失う。
  • 証明には、生のUPDATE、prefix権限、incident承認、ROV、import policy、伝播抑止、RIB、FIB、drop counter、packet、withdrawal、復旧を一続きにする必要がある。Established sessionは、そのどの結果も保証しない。

回線を救うために一つの宛先を切る

合成事例を考える。transit顧客の203.0.113.19に大規模な攻撃が集中し、顧客側のfilterへ届く前にaccess circuitが飽和した。顧客は上流へ203.0.113.19/32を広告し、BLACKHOLEを付ける。そのBGP sessionでは事前にサービス利用が合意され、上流は顧客が203.0.113.0/24を広告できることを確認している。

上流は/32を受理し、ネットワーク内に閉じ込め、各ingressでdiscardへ解決する。攻撃パケットは顧客回線を通らなくなる。正当なパケットも通らない。/24内のほかのアドレスは利用可能なままである。これは対象サービスの救済ではなく、一つを犠牲にして周囲の容量を守る処置だ。

その後、自動処理が誤って203.0.113.91/32を送ったとする。これは同じ/24にある正常なサービスだ。peerもcovering prefixもcommunityも正しい。sessionも落ちない。確認がそこまでなら、形式上正しい要求が誤ったincident intentを実行し、健康なサービスが消える。

この出来事自体は実事故の主張ではない。しかし、実装上の境界は現実である。address space内の広告権限は、「この瞬間にこのhostを切断する」という判断の正しさまで証明しない。

共通なのは言葉であり、命令権ではない

IANAはBLACKHOLEを0xFFFF029Aとして登録し、運用上は65535:666と表される。RFC 7999はこれをwell-knownでadvisory、transitiveなBGP communityとし、宛先型blackholingの共通信号にした。事業者ごとに異なるtrigger値を覚える負担を減らす効果がある。

だが、受理して尊重するか、無視するかは各operatorが決める。二者間関係では、広告前に双方が利用へ合意しなければならない。明示設定がなければ、装置は値を見ただけでトラフィックを捨てるべきではない。

標準化は送信者を受信ネットワークの管理者にしない。送信者は助言を付ける。受信者がsession、prefix、local policyを照合し、実行可能な権限があるか決める。サービスを提供しないネットワークは無視できる。collectorは属性を保存してもpacketを一つも転送しない。値を認識できるrouterにも、discard policyがない場合がある。

Heng LuのMinimum Initial Specificationで見ると、共通層は数値と意味だけで足りる。顧客資格、商用条件、地域、装置範囲、期限は参加者側に残る。Localized Future Decisionによって、同じ信号を採用しないネットワークも無効にはならない。Voluntary Adoptionによって、文書ではなく設定、実装、FIB、利用実績が現実を作る。

経路が勝つことと、通信が届くことを分ける

通常の運用会話では、「経路を受け入れた」を「到達できる」と短縮しがちである。宛先型RTBHは、その省略を意図的に壊す。

RFC 5635は、参加routerにnull/discard interfaceへ向く経路を用意し、対象のBGP routeをそのnext hopへ解決する方式を説明する。より具体的なprefixが選ばれることで、packetは顧客回線を消費する前にingressで落ちる。

したがって、経路は正しく受信され、best pathになり、Loc-RIBへ入っていてもよい。そのforwarding結果は非配送である。Loc-RIBだけでは通常のreachabilityを証明せず、blackhole実行の証明にも足りない。各ingress classのFIB entry、next-hop resolution、dispositionを見る必要がある。

宛先型RTBHは攻撃と正当な通信を区別しない。対象を完全にofflineにする代わりに、ほかの宛先や基盤へのcollateral damageを抑える。報告は「保護された共有容量」と「犠牲になったサービス可用性」を別々に示すべきだ。link utilizationの低下は、packetが来なくなった証拠であり、サービス継続の証拠ではない。

RFCが置く二つの錠と、運用が補う三つ目

二者間でBLACKHOLEを実行する条件は二つある。

第一に、広告されたprefixは、隣接ネットワークが広告を許可された同一またはより短いprefixに覆われなければならない。顧客に無関係なInternet宛先を上流のnullへ落とす権限を与えてはならない。

第二に、受信側がその特定sessionでBLACKHOLEを尊重すると合意していなければならない。address spaceへの権限だけで、すべてのpeeringが廃棄サービスになるわけではない。

しかし、正しい/24内の誤った/32は両方を通る。侵害されたrouterも正しいpeerを使える。古い要求が攻撃終了後に再送されることもある。BGP UPDATEには、誰が、どのserviceを、どのincidentのために、いつまで止めると承認したかを普遍的に検証できる票はない。

三つ目の錠は運用系で実装する。requester identity、incident ID、exact prefix、service、理由、scope、承認時刻、expiry、withdrawal ownerを残し、処理したpeer、AFI/SAFI、policy versionと結び付ける。

prefix filterは「この顧客はこの空間内を広告できるか」を答える。incident ledgerは「権限者が今この宛先の犠牲を意図したか」を答える。前者なしの人手承認は入力ミスに弱い。後者なしのfilterは、自動化へaddress block全体の常設停止権を渡す。

/32の精度は、通常の境界を越える

RFC 7999はcollateral damageを小さくするため、可能な限りspecificなprefixを推奨する。典型的にはIPv4 /32、IPv6 /128である。

一方、通常のInternet routingではIPv4 /24、IPv6 /48より長い経路がfilterされることが多い。inter-domain RTBHは意図的な例外を開く。指定顧客のhost routeをローカルな廃棄用に受け入れながら、それを通常のglobal reachabilityとして外へ出さない。

例外は、顧客が制御するcovering prefix、address family別の許容長、承認sessionとcommunity、実行region、local actionによって囲う必要がある。

specificであることは、対象が正しいことを保証しない。一つの/32がDNS、認証、制御endpointなら影響は大きい。/24全体のblackholeが必要な攻撃もあるが、同時に多数のaddressを犠牲にする。prefix lengthは単なるsyntaxではなくblast radiusである。

通常のmaximum-prefix limitだけでも不十分だ。一つの誤blackhole routeが数千の通常経路より重大な損失を生む。active件数、protected endpoint、最大継続時間、実行地域も意味的に制限する必要がある。

破壊的なmore-specificを権限域に閉じ込める

RFC 7999はNO_ADVERTISE、NO_EXPORTまたは同等のcommunityを追加するよう勧める。RFC 1997では、NO_ADVERTISEは他の全peerへの広告を止め、NO_EXPORTはASまたはconfederation境界の外への広告を止める。内部配布の可否が異なる。

上流はすべてのingressへ経路を配る場合も、攻撃が入るregionだけで廃棄する場合もある。制約は実際のexecution graphに合わなければならない。必要な内部配布まで止めれば防御は効かず、外部境界が緩ければmore-specificが漏れる。

漏えいは二重の危険を持つ。遠端がBLACKHOLEを無視しても、longest-prefix matchでtrafficを引き寄せる可能性がある。尊重すれば、廃棄するnetworkが増える。RFC 5635がegress prefix filterを重視する理由である。

FRRoutingの現行文書は、BLACKHOLE受信時にNO_ADVERTISEを自動追加すると説明する。これはFRRのrunning behaviorであり、全vendor・全versionの約束ではない。別実装はroute-mapを必要とし、community全体を置換するpolicyが保護値を消すこともある。

確認すべきものは、各neighbor classに対するpolicy適用後のAdj-RIB-Outである。設定は意図であり、出力routeが実際の送信準備状態を示す。

認証されたsessionでも、廃棄意図は認証されない

BLACKHOLEはclassic COMMUNITIES attributeで運ばれる。RFC 1997はlocal policyによる変更を認める。RFC 7999は、途中のspeakerがcommunityを追加、削除、変更しても検出できない場合があり、BGPsecもこの問題を解決しないと警告する。不正な追加は到達性へのDoSになり得る。

session保護はpeerなりすましを抑えるが、選ばれたhostがincidentの正しい対象であることまでは証明しない。RPKI origin validationも別の関係を見る。covering VRP、origin AS、最大prefix lengthからValid、Invalid、NotFoundを決めるが、communityや廃棄要求を署名しない。

host routeはここで衝突する。ROAが/24のoriginを許可してもmaxLengthを/32まで広げていなければ、正当なblackhole /32がInvalidになり得る。RFC 7999はROVが正当な要求を誤って止めないよう求める。しかし、BLACKHOLE付きrouteを一律ROV免除すれば、変更可能な属性がbypassになる。すべてのROAを/32や/128まで拡張することも、Validになり得るmore-specific集合を広げる。

2022年の個人Internet-Draftは、通常のorigin authorizationとdiscard authorizationを分離するRPKI DOAを提案した。草案は失効し、IETFの正式な地位を持たない。問題の存在を示す比較材料であり、現在の標準防御として扱えない。

現時点では、peer identity、exact prefix filter、説明可能なROV rule、community match、incident approval、local scope、FIB observationを組み合わせるしかない。一つの認証結果がほかを代替することはない。

宛先RTBH、送信元RTBH、FlowSpec、scrubbingを混同しない

宛先型RTBHはdestinationで落とし、対象への全trafficを失う。送信元型RTBHはdiscard routeとuRPFを組み合わせ、packet sourceのlookupを選定ingressで失敗させる。RFC 5635は宛先用communityを再利用しないよう求め、source triggerは通常、外部peerではなくローカルattack-management systemから入れるよう注意する。

FlowSpecはflowのmatchとactionを別のNLRIで配る。RFC 7999はBLACKHOLEをFlowSpec NLRIに使わないと明記する。sinkholeは観測のためにtrafficを転送先変更し、scrubbingは正当trafficの温存を目指す。宛先blackholeは分析も選別もせず捨てる。

機構を正しく記録しなければ、「攻撃を軽減した」が「被害サービスを維持した」にすり替わる。

UPDATEからpacketの不在までを証明する

事前contractにはcustomer、exact session、AFI/SAFI、covering prefix、許容長、community、protected exclusion、region、ROV policy、max lifetime、withdrawal ownerを持たせる。

各triggerで保存する証拠は次の通りである。

  1. raw UPDATE、timestamp、peer、AS_PATH、origin、next hop、全community；
  2. prefix authorizationの正確なmatchと生成元；
  3. ROV stateとspecificity例外のrule；
  4. matchしたimport term、追加したcontainment、next-hop変更；
  5. Adj-RIB-In、Loc-RIB selection、選定理由；
  6. 各ingress classのFIBとdiscard resolution；
  7. device、interface、意味、baselineを伴うdrop counter；
  8. discard境界の前後でのpacket observation；
  9. 経路を受け取ってはならないneighborごとのAdj-RIB-Out；
  10. withdrawal、policy再評価、FIB削除、通常経路の再選定、service probe。

UPDATEは入力、policy logは判断、RIBは選択、FIBは実行命令、packetは結果を証明する。outbound viewは封じ込め、復旧probeは権限の終了を証明する。

単一の「blackhole active」表示では、未選択route、discardへ解決できないnext hop、一部ingressだけのFIB、withdrawal後も残るstale stateを区別できない。RFC 7999はBLACKHOLE UPDATEの長期保存を勧めるが、監査にはpolicy、FIB、counter、incident recordも必要だ。

犠牲と同じ厳密さで復旧をcanaryする

安全に測定できるcanary prefixを用意し、customer session、address family、route server、region、platform、software releaseごとに通す。

許可canaryが受理され、無関係prefix、誤session、過大scopeが拒否されることを確認する。必要なcontainmentが出力に現れ、全対象FIBがdiscardし、想定counterだけが増え、withdrawal後に通常routeとpacket deliveryが戻るところまで一試験に含める。

live incidentがない、protected endpointである、ROVを説明できない、containmentが消える、未承認regionへ届く、外部eBGP outputに出る、expiryやwithdrawal ownerがない場合はpauseする。

誤service loss、scope拡大、route leak、release間のFIB不一致、prefix外のpacket loss、証拠から動作を再構成できない場合はrollbackする。withdrawalを送るだけでは完了しない。全FIBからdiscardが消え、通常routeが戻り、probeが成功し、回線が再び制御不能に飽和していないことを確かめる。

情報の層を混ぜない

Heng Luのreality layerで整理すると、UPDATE内の65535:666はsymbolである。import ruleは委任された決定、FIB entryは実行可能な力、消えたpacketは結果である。最初の文字列から最後の結果を推定すれば、権限と証明が崩れる。

Running-Code Primacyは「routerが動いたから正しい」とは言わない。正当性の主張を実際の動作で検証する。正しいcounterpartyが正しいprefixを要求し、受信者が限定policyを適用し、指定deviceだけが捨て、禁止境界へ漏れず、withdrawalが配送を戻したことまで示す。

中央のblackhole authorityは要らない。必要なのは最小の共通信号、ローカルに検証できる権限、限定された実行、持ち運べる証拠、そして明確な拒否経路である。

Sources