要約

  • RFC 3424によれば、NATに唯一の「外側」はなく、反射アドレスは一つのobserverが一つのaddress realmで一時点に見たmappingにすぎない。
  • 暫定的なtraversalには、限定された問題、exit strategy、脆弱性、長期解の要件、配備実績という五つの説明責任が必要である。

同じ端末が二つの外部アドレスを持った。リフレクターAに問い合わせると一方が返り、最終相手Bへ送ると別の変換境界に阻まれた。どちらかが嘘をついたわけではない。二つの観測を一つの普遍的な属性として扱った設計が間違っていた。

2002年11月のIAB Informational文書であるRFC 3424は、UNilateral Self-Address Fixing、すなわちNATを越えて端末が自分の見え方を推定・修正する手法を検討した。これはInternet Standardを定める文書ではない。むしろ、heuristicを一般解として恒久化することへの建築上の警告である。

観測には必ず視点がある

変換状態はNAT装置の内部にある。端末が別のrealmにいる協力サービスへpacketを送り、見えたsource tupleを返してもらえば、一つの観測は得られる。しかし、そのサービスは中間装置の規則、寿命、次の宛先に使うmappingを知っているわけではない。

最終targetが別の境界やpolicy pathの向こうにいれば、違うtupleを見る可能性がある。したがってserver-reflexive addressから証明できるのは、「そのobserverがその時にそう見た」という範囲までだ。target-relative reachability、将来の安定性、firewallの許可、transport確立、application受理は別々である。

リフレクターの応答を認証しても、発言者のprovenanceが強くなるだけで、発言の射程は広がらない。署名付きの局所観測も普遍的identityではない。

「public address」という便利な呼称は、視点を消す。RFC 3424の重要な一文は、NATにunique outsideはないという指摘だ。外側を一つと仮定しないことが、障害解析と責任分界の出発点になる。

過去のmappingを未来予測に使う

NATはbindingを回収したり変更したりする。connectionless transportでは変化時点を端末が予測できないこともある。そのため暫定策はkeepalive、再照会、clientとservice双方の推定stateを必要とする。

ここで反射は測定から予測へ変わる。過去に使えたmappingが次回も使える、同じtargetにも通る、経路変更後も保持される、と仮定する。リフレクターはNATと統合されていないため、その予測を保証できない。

keepaliveが成功したことは、maintenance packetがそのpathで結果を得たというreceiptでしかない。policyが長期許可したことも、applicationが有用な処理を受け入れたことも示さない。

そして新しいserviceは新しいfailure domainになる。名前解決、route、capacity、abuse対策、state同期が通信条件へ加わる。本来のendpoint二者だけなら共有しなかった障害と運用費用を、すべてのsessionが引き受ける。

抜け道とpolicy判断を混ぜない

明示的なmiddlebox communicationがなければ、UNSAF方式は着信が装置のpolicy supervisionの下で通過したかを確認できない。mapping discoveryとauthorizationを同一視すると、観測された副作用が正式な許可を代行する。

これはtraversalを全面否定する議論ではない。証拠の境界を守る議論である。一度packetが通った、bindingが開いた、connectivity checkが成功した、transportが確立した、applicationが認証した。これらは順番に強くなるが、互いの代用品ではない。

中間装置の安全機能を迂回し得る方式には、そのpolicyとの関係が必要だ。同時に、operatorが不可視の挙動へ依存を強いるなら、application側は拒否理由も改善経路も得られない。暗黙の制御は両者から検証可能性を奪う。

五つの質問が暫定性を検査する

第一に、対象問題を厳密かつ狭く定義する。一般的なNAT traversalを約束すれば、対象外条件が消え、短期策は終点を失う。

第二に、exitまたはtransitionを記述する。適切な技術が普及するほど使用量が自然に減る構造が望ましい。owner、数値条件、移行順序、撤去試験がなければexit planとは呼べない。

第三に、brittlenessを示す。追加依存、layer coupling、debugging cost、移行中の不整合、service停止時の影響をhappy pathと同じ重さで扱う。

第四に、長期解が満たすべきrequirementsを抽出し、その実現へつなげる。暫定運用が利用者だけを増やし、代替技術の知識を増やさないなら、それはbridgeではなくlock-inである。

第五に、実際のNAT挙動と運用経験を論じる。running codeは主張を制約する。ただし、一つの成功例をすべての装置へ一般化してはならない。

五問の本質は、開始許可だけでなく終了権限も設計することにある。

STUNは「解」から「道具」へ狭くなった

RFC 3489の初期STUNは、より広いtraversalの姿を描いた。これをobsoleteしたRFC 5389は、名称をSession Traversal Utilities for NATへ変更し、STUN単独をcomplete solutionとする主張を退けた。各usageが周辺mechanismとsecurity treatmentを説明する。RFC 8489もその道具を更新したが、反射addressをglobal identityにはしなかった。

ICEは複数のhost、server-reflexive、relayed candidatesを交換し、candidate pairを実際にcheckする。selected pairは当該ICE sessionで検査されたconnectivityの証拠である。将来の別session、別path、application outcomeまで保証しない。

PCPはmappingを明示的に制御するprotocolを提供し、推測より読みやすいcontrol surfaceを作る。それでも、mapping grantとremote acceptanceは異なる。中間装置のreceiptはendpointのreceiptにならない。

後続仕様の教訓は万能策の発見ではない。utility、candidate、check、selected pair、granted mappingという限定語で、各証拠が語れる範囲を小さくしたことだ。

緑の一灯を十二のreceiptへ分解する

記録はlocal interfaceとtransport tupleから始まる。reflectorのidentity、route、address realm、反射mapping、timestamp、lifetime assumptionを保存する。明示的ruleまたはmapping grantがある場合は、それも独立した記録にする。

次にtarget identityとtargetが実際に見たtuple、candidate-pair check、transport establishment、authenticated application exchange、user-visible outcomeを分ける。後段の成功で前段の仮定を遡って正当化しない。

retry、expiry、network change、changed-path behaviorも必要だ。さらにexception owner、scope、retirement triggerを結び、最後に利用が本当に減った、または終了したことを証明する。

最後のreceiptがなければ、「temporary」は技術的性質ではなく、最初の会議で使われた形容詞にすぎない。

証拠の限界

RFC 3424は現在のNAT普及状況を測った資料ではなく、特定vendor、operator、application、incidentの挙動を証明しない。IPv6、STUN、TURN、ICE、PCPのどれかをuniversal exitと認定してもいない。reflected addressはendpoint identityではなく、connectivity checkはapplication authorizationではなく、keepaliveはstable policyではない。

Heng Luのminimum initial specification、localized future decision、voluntary adoption、running-code primacyは、ここでは開示された分析視角である。小さなutilityは将来のlocal choiceを残すべきで、配備結果は主張を狭めるために使うべきだ。一回の成功を恒久権限へ変えてはならない。

情報源