RFC 3102：gatewayがpublic addressを貸したとき

要約

RFC 3102では、private realmのhostがpublic address一個、または共有address上のport群を借りられた。ただしresource pool、bind、lease、policyはgatewayが保持した。
parameterがhostに見えるようになっても、経路は自明にならない。hostはlocal destinationとpublic tunnelを選別する必要があり、realmをまたぐmulti-party applicationには一般解がなかった。

書き換えを隠す代わりに、貸与を見せる

従来型NATは、境界で取引を完結させた。hostはprivate source addressでpacketを作り、translatorが外向きにaddressやportを書き換え、戻りでは対応を逆にたどる。hostを変更しなくてよい反面、payload内にaddressを含むprotocolやheaderの不変性を前提にするsecurity mechanismでは、透明性が崩れた。

2001年10月のRFC 3102–3105は、別の配置を試した。RSIP hostはまず異なるaddress realmの間にあるgatewayへresourceを求める。gatewayはpublic realmのparameterを一時的に貸し、hostはそれを自分のstackへ組み込む。内側packetは借りたpublic sourceで作られ、tunnelでgatewayへ届く。gatewayは外側を外し、内側sourceを書き換えずに送る。

RSA-IPはlease中、一つのpublic address全体を一hostへ割り当てる。RSAP-IPは一つのaddressを複数hostで共有し、それぞれに重複しないportを与える。前者は一時的な完全住所、後者は共同住所の限られた入口に近い。

どちらでもhostはpublic parameterを知る。しかしaddressの恒久的な権利がhostへ移るわけではない。private addressはgatewayまでの足場として残り、gatewayはpoolと承認権を保持する。見える場所が変わったのであって、統制点が消えたのではない。

一つの「割当て」は複数の事実に分かれた

RFC 3103は、この構想をmessageとstateにした。hostはregisterしてclient IDを受け取る。assignment responseにはaddress、必要ならport、bind ID、lease time、tunnel type、flow policyが含まれる。hostは延長、照会、外部からのlisten、解放、登録解除を要求できた。

それぞれの記録が示す範囲は狭い。registerはgatewayがclient sessionを認識したことを示す。assignmentは条件付きでresourceが許可されたことを示す。bindはprivate側のhostとpublic parameterを結ぶ。leaseは時間を区切る。policyは利用できるremote endpointを制限する。

しかしassignment responseだけではroute installationを証明しない。bindはtunnel稼働の証明ではない。hostから出たpacketはgatewayが受理した証明ではない。外へ出たpacketもreplyが正しいhostへ戻った証明ではない。RSIPはstate machineを観測可能にしたが、完成したpathはrunning packetでしか確認できない。

hostは希望するaddressやportを提示できても、gatewayは使用中、枯渇、policy違反を理由に拒否できる。未割当てのaddress、tuple、remote destination、tunnelを使うpacketはdropされる。packetのsourceを書くのはhostでも、その利用が生きたgrantに属するか判断するのはgatewayだった。

「近い相手」をhostが判定しなければならない

public parameterを知るhostは、送信先ごとに問いを抱える。private networkへ直接出すのか、RSIP interfaceとtunnelを通すのか。単一subnetならmaskで足りるかもしれない。複雑なnetworkではgatewayがprivate networkとmaskの一覧を持ち、hostのqueryへ答える案が示された。

だがrouteがRSIP sessionより速く変われば、答えは古くなる。hostはdestinationごとに問い合わせる必要さえある。RFC 3102は、堅牢な一般解を作ることが難しく、問題の深刻さも分かっていないと率直に書いた。

multi-party applicationでは矛盾が露出した。ある参加者がIP addressをglobal endpoint identifierとして別の参加者へ渡しても、相手がどのrealmから見るかは分からない。private addressは外部から届かず、public addressを常に使えばlocal同士の通信までgatewayへ迂回しうる。文書はこの一般問題に既知の解がないとした。

これは単なる実装漏れではない。一つのaddressがtopology、reachability hint、identityの三役を期待されたことが原因だった。RSIPは借用を明示できても、全員に同じlocalityを与えることはできない。

leaseの終了と安全な再利用は別時刻だった

leaseはhostの権限を有限にし、希少なaddressやportをpoolへ戻せる。hostは延長またはfreeを要求し、gatewayはexpireまたはdeallocateできる。しかし行政的な時計がtransport stateを同時に消すわけではない。

TCPはclose後も古いtupleをTIME_WAITに保持する。返却直後に同じaddress-portを別hostへ貸せば、遅延packetや古いconnectionの衝突回避状態が新しいgrantと重なる。lease expiryとsafe reuseは同一イベントではなかった。

failureでも記憶が割れる。host reboot後、gatewayにはhostが忘れたbindが残りうる。gateway reboot後、hostはserverが失ったassignmentをまだ有効だと思いうる。RFC 3103は再登録とerror exchangeで関係を作り直すが、片側のmemoryだけを真実にはできない。

運用証跡にはlease開始、extension、freeまたはexpiry、双方のreboot、再調整後に初めてacceptされたpacketを別々に残す必要がある。同じnumberでも、権限のgenerationが同じとは限らない。

共有locatorはidentityを一つにできなかった

RSA-IPとdynamic DNSの関係はDHCPに近い。一hostがlease中のaddress全体を使うからである。RSAP-IPでは複数FQDNが同じpublic addressを指し、portごとに別hostがserviceを運営できる。public peerが「一address上のapplicationは一logical hostに属する」と考えると誤る。RFC 3102はRSAP-IPとdynamic DNSの統合に慎重さを求めた。

RFC 3104はIPsecでこの分離をさらに明確にした。複数RSIP clientが一つのpublic addressを共有し、RSIPを知らないpeerへIKE/IPsecを開始できる。peerが見るsource addressは実際のpeer identityではないため、IKE client identifierが主体を示さなければならない。

戻りのIKE trafficはdestination port、initiator cookie、destination addressでdemultiplexできる。AH/ESPはprotocol、SPI、destination addressを使う。SPIはclient側とgateway側の両方でuniqueでなければならない。addressは到達入口ではあっても、暗号上のprincipalではなかった。

この拡張も万能ではない。主にclient initiationを扱い、IPsec implementationの協力が必要で、bump-in-the-stackがそのまま動くとは想定されなかった。packet headerの透明性とapplicationの透明性は別だった。

見つけたgatewayに使う権利があるとは限らない

RFC 3105はSLPでservice:rsip URL、capability、lifetime、任意のloadをadvertiseした。scopeはclient群を特定serverへ導き、clientはconnection数が少ないと申告するserverを選べた。

しかしSLP scopeはaccess controlではない。advertisementはserviceの自己申告であり、clientの資格証明ではない。loadは選択中に古くなり、実際に最小のserverを保証しない。発見の後にもregister、assignment、route installation、packet observationが必要だった。

したがってcontrol surfaceは分けて読める。administratorはdiscoveryを方向付ける。gatewayはgrantとpolicyを決める。hostはlocalityとpacket constructionを担う。remote peerはidentityやsessionを受け入れるか決める。最終結果は双方向trafficだけが示す。

Experimentalな設計が残した正直な地図

RFC 3102–3105はすべてExperimentalで、Internet Standardではない。IESG noteは完全実装に大きなhost/gateway変更が必要で、portの浮動がapplicationを壊し、運用が複雑になりうると警告した。RFC 3102自身もaddress shortageの長期解ではないとした。選んだ資料は広範なdeploymentもNATの置換も証明しない。

それでも歴史的価値は大きい。RSIPは、透明なtranslatorの内部に隠れていたaddress sharingを、register、allocation、bind、lease、policy、discovery、recovery、localityという別々の状態へ分解した。public parameterをhostへ持ち込むほど、共有はstate distributionの問題だと明確になった。

借りたpublic addressはpacketがどのrealmに現れようとするかを示せる。恒久所有、単一identity、正しいpath、IPsec認証、deliveryまでは示さない。gatewayがaddressを貸し、整合するcontrol recordとrunning state、往復packetがその貸与をserviceにした。

ゲートウェイがアドレスを貸し、ローカリティがプロトコルになった――RFC 3102

なぜ重要か

要約

書き換えを隠す代わりに、貸与を見せる

一つの「割当て」は複数の事実に分かれた

「近い相手」をhostが判定しなければならない

leaseの終了と安全な再利用は別時刻だった

共有locatorはidentityを一つにできなかった

見つけたgatewayに使う権利があるとは限らない

Experimentalな設計が残した正直な地図

出典

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説