要約

  • draft-liu-sidrops-rpki-rtr-over-quic-04は導入部で「0-RTT」recoveryを利点に挙げるが、接続規則はclient、server、TLS設定にEarly Dataの禁止を要求する。
  • QUIC streamを四つに分けても、completeなRPKI cache viewは自動的に生まれない。Protocol Version、Session ID、Serial Number、参加stream集合、最後のEnd of Dataが揃って初めてcommitを説明できる。

revision 04は2026年9月7日付のindividual Internet-Draftで、headerのintended statusはStandards Trackである。しかしWG adopted document、IETF consensus、RFCではない。DatatrackerにもRFC stream、responsible AD、telechatはない。WG draftの8210bisがbase protocolを定義していても、個人提案のQUIC mappingまで採択済みになるわけではない。

導入部はQUICの二つの能力を結びつける。TLS 1.3を組み込んだ迅速なconnection establishmentと、独立streamによる並列配送である。以前接続したserverなら、clientは最初のpacketへRTR session requestを載せて「0-RTT」recoveryを実現し、RPKI verification databaseとの空白期間をほぼ瞬時に閉じられると述べる。

同じ文書のSection 3.1は逆の命令を書く。RTRoQUIC implementationはEarly Dataを使ってはならない。ClientHelloにearly_dataを含めてはならず、serverは提示された場合にrejectし、TLS 1.3 stackは0-RTTをdisableしなければならない。この組合せはrevision 03から入り、04にも残った。

session resumptionと0-RTTは同義ではない。RFC 9001は0-RTT disabledでもresumptionを利用できるとする。resumptionがhandshakeの作業を減らしても、application dataは安全境界を待つ場合がある。0-RTTは過去のconnection stateを使い、handshake complete前にapplication dataを送る機能だ。導入部のfirst-packet requestは後者であり、規範が禁止した部分である。

禁止理由はreplay riskとforward secrecyの差だ。Routing decisionへ渡るRPKI dataにそのriskを許さない判断は理解できる。それでも、禁止した機能を復旧時間の根拠にはできない。評価対象は許可された1-RTT/resumptionと、cache transactionが終わるまでの全時間である。

複数streamにも別のcommit問題がある。単純なmappingでは全RTR PDUが一つのbidirectional streamを通る。optional designはSerial Notify、Serial Query、Reset Query、Cache Reset、Error ReportをControl Channelへ置き、Cache Response、payload、End of DataをData Channelへ分ける。

payloadはIPv4 Prefix、IPv6 Prefix、Router Key、ASPAの四種類に分配できる。あるstreamのlossが別streamのdeliveryを止めないのはQUICの利点だ。ただし、IPv4、IPv6、Router Keyが終わり、ASPAが遅れているとき、viewはまだcompleteではない。

revision 04は各Data ChannelへCache ResponseとEnd of Dataを送るよう求める。最初に届いたCache Responseをvalidとし、最後に届いたEnd of Dataをvalidとする。従ってtransactionには「期待されるstream一覧」が必要になる。一覧がなければ、receiverは今見たEnd of Dataが最後かどうか判断できない。

QUICのorderはstream内に限られる。connection全体のtotal orderではない。最初のEnd of Dataでcommitすればpartial snapshotになる可能性がある。最後を待つ設計なら、streamの生成、queryへのbinding、reset、close、error、期待数をinteroperableに定義しなければならない。

8210bisではSerial Numberが一つのcacheのlogical versionを示し、Session IDがsequence spaceを示す。Protocol Versionも含めて初めて対応関係が決まる。Cacheはvalidated update完了前に新dataを送れない。通常のexchangeではEnd of Dataを受けたrouterが「このcacheのcurrent dataを全て受けた」と判断し、そのserialへ進む。

このatomicな意味を四streamへ分割したからといって弱めてよいわけではない。Router Key PDUが正しく到着しても、同じversionのASPAとprefix withdrawalが揃った証明にはならない。TLS authenticationもcache epochの正しさやsnapshot completenessまでは保証しない。

識別子のscopeは狭い。Serial Numberはcache間、protocol version間で比較できず、resetを越えて維持する必要もない。Base draftはSession IDの誤ったreuseにより、後続deltaがstale stateと衝突しない場合、routerがout of syncのままになる可能性を警告する。Encrypted transportはこのlogical collisionを修復しない。

preferred cacheが複数なら、一つのsession完了はglobal view完了でもない。8210bisではVRPは最初のpreferred cacheが提供した時点で効き、最後のcacheがwithdrawするまで残る。Operatorはcacheごとのreceiptと、union結果のreceiptを分けなければならない。

下流も別のauthorityを持つ。PDU receipt、local install、BGP reevaluation、best-path selection、RIB、FIB、packet outcomeは同じ事実ではない。QUICが一つのintervalを短縮しても、後続decisionの証明にはならない。

UDP blocking時のTCP fallbackもdraftに含まれる。MonitoringはQUIC failure、TCP start、authentication、Cache Response、last End of Data、installを分離すべきだ。「RTR connected」だけではstale-view intervalを測れない。

Running-Code Primacyなら、独立実装が同じRTR versionを選び、期待したendpointを認証し、0-RTTを拒否し、Data Channel集合に合意し、一streamのlossを越え、真のlast End of Dataで一つのversionをcommitできるかを問う。図の並列矢印では足りない。

stream数、certificate policy、cache preference、retry、fallbackはlocal choiceでよい。しかしtransaction receiptは共通でなければならない。Protocol Version、cache、Session ID、Serial Number、query、stream set、completionを一つにbindingする仕様が必要だ。

Leadershipが承認すべきなのはQUICという名前ではない。許可されたprotocolで測った短縮、partial viewを防ぐcommit、tested TCP fallback、cache diversity、rollback、そしてrouting effectまで追える証拠である。

情報源