要約

  • SAND Internet-Draft第04版はBundleをBPSecで保護する一方、送信ノードが下位ネットワーク、termination point、BP宛先に応じて広告する型とinstanceを選ぶことを認め、隣接者ごとに非重複の集合が見える「split brain」を明記する。
  • 認証済み広告は利用許可ではない。受信側は発見データを個別に認可・cullでき、SYMMETRICやRouter Advertisementからアプリケーション成功やroute authorityを推論できない。
  • 比較可能性を支えるのは、一つの信頼フラグではなく、Source、Security Source、Previous Node、宛先、受信文脈、filter epoch、Reference Time、supersessionと受信側判断を結ぶ広告投影receiptである。

発見プロトコルには、見えるものを増やすほど良いという期待がある。しかしSAND第04版の設計を読むと、発見の品質は「すべてを全員に配ること」ではない。適切な相手に、適切な下位網を通して、適切な範囲だけを提示し、その由来を検証できることにある。

ここで扱うSANDは、Bundle Protocol Version 7の参加ノードが、近隣、資格情報、underlayer network、convergence layer、資源予測、局所topology、routing willingness、endpointを広告・発見するためのInternet-Draftである。中央台帳の同期方式ではない。草案はむしろ、送信と受信の双方に局所policyを残す。

したがって、二つの観測結果が違うという事実だけでは異常を意味しない。異常かどうかを決めるには、両方がどの文脈から作られたかを残さなければならない。

SourceとPrevious Nodeを一つに畳まない

SAND BundleはSource EIDを持ち、SAND Group EIDまたは別のSAND Singleton EIDへ送られる。1-hop用のmessage setではHop Limit 1を使う。だが、bundleが転送される場合、原作者と今回の送信者が同じとは限らない。SANDは1-hop neighborをより遠いnodeとは違って扱うため、previous hopの肯定的識別を要求する。

優先順位は、利用可能ならconvergence layerが認証したidentity、次に認証済みPrevious Node extension block、最初のhopならPrimary blockの認証済みSource Node IDである。転送nodeがsourceでない場合、その区別が残る。

全SAND Bundleはpayloadを対象にするBlock Integrity Blockを含む。payload BIBのSecurity Sourceはbundle Source EIDと同じnodeを識別しなければならないが、security policyによりEID表現は異なり得る。Previous Node blockにも別のBIBが必要で、そのSecurity Sourceはprevious nodeを識別する。

この配置が証明するのは、誰がbundleを作ったか、どのnodeが直前hopだったか、どのprincipalが特定blockを保護したかである。三つは関連するが同義ではない。監視基盤が取り込み時に一個のnode欄へ正規化すれば、検証成功の裏で帰責情報が失われる。

BPSecは内容の完全性と主体へのbindingを強くする。しかし署名者が知る全情報を列挙したこと、別の宛先にも同じ集合を送ったこと、受信者がその内容を利用すべきことまでは証明しない。

Solicitationは開示命令ではない

Data Solicitationは相手が特定種類の情報を欲していることを知らせる。それでも草案は、送信nodeのlocal policyを上書きしてはならないとする。どのmessage typeを広告するか、各型のどのinstanceを含めるかはadvertiser側のoperational decisionである。

フィルタ理由は多様だ。発見を無効にしたtermination pointを除く、変化しないcredentialを毎回送らない、IP-only環境に非IP parameterを出さない、といった運用上の選択がある。group destinationには接続開始に必要な最小情報だけを出し、保護されたsingleton destinationにはより詳しいCL instanceやcredentialを出すというsecurity設計もある。

第04版のContext-Specific Advertisement Filteringは、ULN、termination point、BP destinationまたはsourceに応じた選択を認める。private PKIX CAのcertificateをそのtrust rootが意味を持つULNに限定できる。IPv6-only termination pointではIPv6関連CLだけを示せる。複数filterを組み合わせれば、二つのneighborが同一nodeについて異なる、場合によっては全く重ならないdata setを見る。

草案自身がこれを“split brain”の一種と呼ぶ。その表現を読んで、即座に障害を連想してはいけない。ここではまず、文脈依存の投影が生む構造的結果である。片方に見えないcredentialが他方に存在することは、単独では改ざんでも情報欠落でもない。

zero-configuration group messagingのpayloadは、追加のconfidentialityがなければ観測され得る。Hop Limit 1は盗聴不能を意味しない。そのためDNS名、IP address、CL instance、neighbor、certificateをtermination pointごとに非対称に隠すことは、情報漏洩を抑える正常な判断になり得る。

発見側も第二の地図を作る

transport条件を満たして受信したSAND messageでも、discovering nodeは利用を義務付けられない。構造を実装して解釈できることと、そのdataをlocal information baseに採用することは別である。

利用認可はmessage type、bundle source/destination、CL受信parameter、以前に発見または交渉した情報に依存できる。受信nodeはirrelevantな項目をcullしてもよい。非IP parameterを理解できないIP-only nodeは、それをlocal representationから落とすかもしれない。現時点で到達経路のないaddressも除外され得る。

ただし、現在のroute check失敗は将来も到達不能という意味ではない。cullingは受信nodeの現在判断であり、広告nodeの永続的事実を否定するものではない。central inventoryがculling後のrowだけを収集すれば、送信側非開示、受信側非認可、実装未対応、現在到達不能を一つの「不在」にしてしまう。

さらに、context-specific authorizationには、messageを元のenveloping Bundleと、受信に使ったlocal CL instanceへ結び直せる必要がある。BPAとapplicationのinterfaceがその情報を渡さなければ、設定にpolicyが書かれていても実行時には判定できない。仕様上可能であることと、running codeが証拠を受け取れることは別だ。

最新に見えるbundleが最新とは限らない

SAND messageは同じ型について差分だけを運ぶのではなく、advertising nodeのfull setを運ぶ。重複受信しても同じ結果になりやすい反面、古いfull setをcurrent stateへ戻さない仕組みが不可欠になる。

受信nodeはsourceとmessage typeごとにReference Timeを記録し、なければCreation Timestampを使う。同一または古い時刻のmessageは完全処理前に無視する。順序はDTN Time、その次にSequence Numberで決まる。superseded messageを無視しても処理失敗ではない。

従って、二つのbundleがともに正しく署名されていても、state変更資格は片方にしかない。replayはresourceを浪費できるが、規則どおりなら新しいstateを上書きできない。一方、状態変化時だけ送る方式では、新しいbundleのlossによって古い視点が残り得る。Validity Duration、Repetition Interval、periodic timer、change-triggered送信のどれを使うかで、沈黙の意味は変わる。

運用画面には「最後に受信した時刻」だけでなく、messageのReference Time、validity、supersession結果が必要である。collector到着時刻をprotocolの鮮度と混同してはならない。

SYMMETRICはサービスの両方向成功ではない

Local Topology Advertisementは1-hop neighborのReachabilityとしてHEARD、SYMMETRIC、LOSTを使う。HEARDはpeerからmessageを受け取ったが、peerの広告するlocal topologyに自nodeがまだ現れない状態。SYMMETRICはpeerが自nodeを広告しており、少なくとも両方向で一回ずつmessageが受信された状態。LOSTは実装定義timeout内に受信がなかった状態である。

これらはapplication delivery、持続的capacity、双方向の同品質を保証しない。相互neighbor間のrouting metricsにも同期はなく、同じ項目でも値の一致は期待されない。調整方法は実装事項である。Termination Point Indexのようにadvertiserのlocal namespaceでしか意味を持たない値もある。

Router Advertisementでは0から6のwillingnessやAttached Networks patternを提示できる。*:**でgateway的範囲を表すこともできるが、草案はstub networkだけがその広告を見るべきだと注意する。そして、広告をinformation baseに記録すること、routing用に認可すること、実際にrouteを使うことを分離する。

適切なrouting authorizationがなければroute leakingとhijackingの脅威が残る。草案はBP routingを認可するRPKI相当が現在ないとも述べる。認証済みRouter Advertisementは帰責可能なclaimであって、route installation命令ではない。

比較の前に広告投影receiptを作る

必要なのは広告投影receiptである。これはDaniel Kadeによる運用提案であり、第04版が定義する新しいwire objectではない。

receiptはprotected bundleのhashとidentity、Source EID、BIB Security Source、Previous Node、destination、Hop Limit、Creation Timestamp、受信時刻を保存する。どのidentity validation pathが使われたかも残す。次に、送受信したULN、termination point、CL instanceを結ぶ。

message typeごとにinstance集合、Reference Time、Validity Duration、Repetition Interval、supersession verdictを記録する。可能ならadvertiser filter/configuration epochを特定する。受信側ではauthorizationとcullingの結果・理由を保存し、post-policy information-base projectionにhashを付ける。

route install/useは別receiptにする。forwarding観測とapplication outcomeも後続の証拠にする。巨大な一つのログを作ることが目的ではない。authenticatedという一bitが、開示、採用、route authority、deliveryを勝手に兼任することを防ぐためである。

二つのreceiptがあれば、差異をintentional scope、policy epoch差、stale、superseded、receiver culling、unsupported parameter、delivery loss、misconfiguration、unexplained divergenceへ分類できる。receiptがなければ、スクリーンショット同士の議論しか残らない。

草案の状態を過大評価しない

Datatracker上、第04版は2026年9月8日公開、2027年3月12日失効予定のactive DTN Working Group Internet-Draftである。headerはStandards Trackと記すが、証拠凍結時のDatatracker intended RFC status欄は未設定だった。RFC、最終IANA allocation、deployment証明ではない。

Implementation Statusはexample proof-of-conceptに触れる。同じsectionは、contributorから提供された情報を検証しておらず、実装catalogでもIETF endorsementでもないと明記する。本稿はadoption、interoperability、特定製品、実事件、route leak、outageを主張しない。

RFC 9171はBPv7、RFC 9172はBPSec、RFC 8949とRFC 8610はCBOR/CDDLを支える。RFC 6130はMANETのneighborhood discoveryを比較対象にする。RFC 4593、RFC 7908、RFC 6480はrouting threat、route leak、RPKIの境界を示す。どれもcontext-specific SAND viewをglobal truthへ変換しない。

この仕組みから導ける結論は限定的である。認証は、誰がある文脈で何を述べたかを証明できる。完全性、route authority、application resultは別の証拠を必要とする。