要約

  • RFC 8955はtraffic条件とactionをBGPで配る一方、default validationでは最長一致するunicast routeのoriginatorとFlowSpecのoriginatorを結び、unicast routeが変わるたびに再検証を求める。
  • Susan HaresはRFC 8955の共著者で、IPv6版RFC 8956のeditorの一人である。domain内controller向けに検証を緩和したRFC 9117は別の著者陣によるもので、inter-domainの一般的なfilter権限を認めてはいない。

一つのupdateがpacketの扱いを変える

DDoSへの対応では、数十台のrouterへ個別にcommandを入れる時間がない。FlowSpecは、destinationやsource prefix、protocol、port、ICMP、TCP flag、packet length、DSCP、fragment条件を組み合わせたruleをBGPで配る。extended communityにより、byteまたはpacket単位のrate、sampling、terminal、route targetへのredirect、traffic markingを指定できる。rateが0ならdiscardになる。

この速さは防御に役立つが、誤りも同じ速さで広がる。普通のrouteは主にnext hopを変える。FlowSpecは一致したpacketの運命を直接変える。BGP messageとして正しくdecodeできることと、そのspeakerがactionを要求する資格を持つことは別である。

IETF DatatrackerのSusan Hares公式プロフィールは、彼女の長い標準化活動を記録する。本稿で扱う根拠はその中の限定された文書系列だ。2020年12月のRFC 8955はStandards Trackで、Christoph Loibl、Susan Hares、Robert Raszuk、Danny McPherson、Martin Bacherを著者とし、RFC 5575とRFC 7674をobsoleteにした。IPv6拡張のRFC 8956では、Loibl、Raszuk、Haresがeditorを務めた。

これは個人発明の物語ではない。RFCは共著、working group review、実装と運用の積み重ねである。確認できるのは、HaresがFlowSpec改訂の文書作業に参加した事実であって、技術やdeploymentを一人で所有したという事実ではない。

Ruleの順番と、ruleの資格

複数のFlowSpec ruleが同じpacketに一致する場合、RFC 8955は比較順を定義する。actionが付いていないmatchのdefaultはacceptである。異なる実装が同じrule setから同じ優先順を作るために、deterministic orderは欠かせない。しかし順番が一致しても、許可のないruleは許可されない。

default validationは既存のunicast routingを権限の根拠に使う。destination prefixを含むFlowSpec ruleについて、最長一致するunicast routeを探し、両者のoriginatorが一致するかを確かめる。別のneighboring ASからmore-specific routeが来ていれば、元のruleは無効になり得る。EBGPでは、FlowSpecとunicastのAS pathで左端のASも比較する。

これは署名による本人確認でも、善意の証明でもない。scopeを限定する考え方である。destinationへの直近のnext ASは、受け取ったtrafficを自網内で捨てる立場にある。そのASがupstreamへ早い地点でのrate-limitやdiscardを頼めれば、攻撃trafficがlink capacityを埋める前に止められる。つまりstandingは、BGPを話せることではなく、現在のdestination pathから生じる。

経路が変わればstandingも変わる。RFC 8955は、対応するunicast routeの変更時にFlowSpec validationをやり直すよう求める。best pathのoriginが変わった、別のpeerからmore-specificが現れた、といった状態変化は、すでにinstall済みのruleにも影響する。受信時だけ検査するautomationは、一時的な資格を永続的な権限に変えてしまう。

Controllerはforwarding pathにいない

local domain内のcentral controllerは別の形を持つ。operatorが正当に管理するcontrollerでも、対象prefixへのbest forwarding pathには現れないことがある。RFC 8955のstrictなorigin testだけを適用すると、routerではないからこそ設置されたcontrollerがrejectされる。

2021年8月のRFC 9117は、この問題に合わせてvalidationを更新した。著者はJeffrey Uttaro、Jorge Alcaide、Clarence Filsfils、David Smith、Pradosh Mohapatraであり、Susan Haresではない。この後続RFCを取り上げる理由は、Haresが共著したRFC 8955の境界が後にどう調整されたかを示すためである。

例外は同一local domain内に限定される。operatorは自ら管理するroute controllerを明示的にtrustし、そのsessionについてorigin validationを緩和できる。route serverが通常のtransit routerと異なるAS_PATHを扱う点も修正された。一方、remote domainのcontrollerに普遍的なfilter権限を与える内容ではない。domainを越えるruleは、受信側が別のriskを明示的に引き受けない限り、強いvalidationの対象であり続ける。

「自社controllerに自社設備をprogramさせる」ことはlocal governanceで決められる。「neighborに自網のpacket treatmentを変えさせる」ことはinter-domain coordinationである。両者を同じtrust checkboxで処理すべきではない。

Control planeのvalidは結果のvalidではない

RFC 8955は、validationを緩めると不要なfiltering、remarking、redirectが起こり得ると警告する。rate以外のactionはforwardingやVPN context、queueに影響する。故障または侵害されたcontrollerは大量updateを送り、platform capacityを消費し、意図より広いmatchをinstallできる。

受信policyでは、peerごとに許すaction、prefix、port、rate、redirect先、rule数を制限できる。route server経由ならAS_PATHの意味を別途検証する必要がある。さらに、BGP tableへのacceptとforwarding hardwareへのinstallは同じではない。install成功も、対象serviceだけに作用した証明ではない。

RFCの発行はproduction evidenceでもない。全vendorで同じcomponentが使えること、operatorがfeatureをenableしたこと、DDoS mitigationが成功したことは、標準文書からは分からない。標準は意味をそろえる。稼働結果はrouterとtrafficから得る。

共有するのは小さな文法でよい

Lu HengのMinimum Initial Specification, Localized Future Decision, and Voluntary Adoptionを分析枠にすると、FlowSpecの役割分担が見えやすい。共有するのはmatch component、action encoding、order、unicast routeに基づくdefault validationである。どのpeerを信頼するか、何を許すか、controllerの例外、capacity、log、withdrawalは受信domainが決める。

共通syntaxを共通の命令権と誤解すれば危険になる。各社がsyntaxを勝手に解釈すればinteroperabilityが消える。小さく共通化した意味と、localに説明責任を持つ決定面の組合せが必要だ。

Running-Code Primacyの観点では、control-planeにrouteがあるだけでは不十分である。validation state、rule order、hardware install、match counter、実際のaction、service impact、withdrawal、recoveryを確認する。unicast route変更時に権限が再計算されたかも試す。この二つの後年の論考はSofia Renの分析枠であり、HaresやRFC著者の見解として扱わない。

信頼できるFlowSpec運用は、ruleごとに三つの答えを残す。誰が出したか。現在のどのrouting factが資格を与えたか。どのlocal policyがactionを許したか。強いruleほど、その答えは狭く、更新可能で、取り消せなければならない。

出典