要約
- RFC 3519 は Mobile IPv4 データを UDP に包み、NAT 通過後に home agent が見た外側送信元アドレスとポートを実効 care-of ロケータにした。
- 認証は登録内の care-of を守ったが、NAT が書き換える外側 tuple は守らない。短い lifetime、keepalive、IPsec は影響を抑えてもロケータを認証しない。
Mobile IPv4 はルーティング可能な care-of address を前提とした。NAPT は共通公開アドレスの内側を TCP/UDP ポートで区別した。IP-in-IP にはポートがないため、UDP の登録だけが通り、データトンネルが失敗し得た。
RFC 3519 は Tunnel Request、Reply、Data を追加した。承認後は IP、GRE、minimal encapsulation を UDP に入れ、home agent の 434 番と登録時の送信元ポートを使った。NAT は必要な識別子を得た。
肯定 Reply が証明するのは、その binding で UDP tunnelling を使う合意である。mapping の所有者や存続時間、次の配送は証明しない。Home agent は外側 source と内部 care-of を比較し、相違を NAT の兆候とした。そして観測した source を実効アドレスにした。
Mobile-Home または Foreign-Home Authentication は登録フィールドを保護する。NAT が変更できる外側 IP と UDP ポートはその外にある。それでも戻り経路は外側値で決まった。
経路上の攻撃者は Registration Request のヘッダーを変更し、別の宛先へ binding を作れた。一度変えれば、再登録または期限切れまで追加操作なしで転送が続く。
Foreign Agent 経由の co-located care-of では、home agent は最初の keepalive まで half-bound で待ち、mobile node のポートを学んだ。交換を見た者は偽 keepalive を先に送れる。同じ source IP を要求しても、同一アドレスの別ポートへの変更は認証されない。
UDP 内の ICMP Echo Request/Reply は mapping 消失も検出した。応答がなければ再登録し、同じネットワークで間隔を短くできる。既定は 110 秒、下限は十秒だった。
Home agent は情報不足のため動的に間隔を変えてはならなかった。故障信号に近い mobile node が適応する。Binding の有効性、mapping の生存、データ到着は別の時間軸だった。
短い lifetime は転送先変更の継続時間を制限するが、ヘッダー変更を防がない。IPsec は奪われたデータの機密性を守る一方、RFC 自身が転送先変更を防がないとした。
UNSAF の検討は、より強い仕組みに各変換の発見、NAT の権限検証、署名登録へのアドレス格納が必要だとした。RFC 3519 は既存 NAT との互換性を選び、その欠落を証明済みとは扱わなかった。
IANA の番号は実装間の共通言語であり、生きた mapping の証明ではない。歴史的教訓は、認証された要求と未認証の経路観測が一つの受理状態を作り得ることにある。
Force フラグも証拠を置き換えなかった。経路が登録シグナリングだけを通し、一般データを遮る場合、mobile node は NAT 検出結果にかかわらず UDP tunnelling を要求できた。対応しない home agent は拡張を読み飛ばし、通常の登録だけを受理する可能性がある。その場合、肯定的な Registration Reply が返っても UDP Tunnel Reply がなければ、mobile node は UDP tunnelling を使ってはならない。登録受理とトンネル受理は別の受領証だった。
Mapping が消えた後の挙動も同じ区別を示す。新しい外向きパケットは NAT に別の mapping を作らせ得るが、home agent は新しい Registration Request を受けるまで古いポートへ送り続ける。Keepalive は消失の兆候を与え、再登録は home agent の状態を更新する。どちらも過去の tuple が誰に属していたかを遡って証明しない。
さらに、重複する private address space では移動後も IP アドレス、netmask、gateway の見かけが同じ場合がある。RFC 3519 は gateway の link-layer address 変化を追加の移動兆候として挙げた。ここでも一つのアドレス値だけで接続点の同一性を決めず、観測層を分ける必要があった。
情報源
- https://www.rfc-editor.org/rfc/rfc3519.html
- https://www.rfc-editor.org/rfc/rfc3519.txt
- https://www.rfc-editor.org/info/rfc3519
- https://datatracker.ietf.org/doc/rfc3519/
- https://datatracker.ietf.org/doc/rfc3519/history/
- https://www.rfc-editor.org/errata_search.php?rfc=3519
- https://www.rfc-editor.org/rfc/rfc3344.html
- https://www.rfc-editor.org/rfc/rfc2003.html
- https://www.rfc-editor.org/rfc/rfc2004.html
- https://www.rfc-editor.org/rfc/rfc2784.html
- https://www.rfc-editor.org/rfc/rfc3024.html
- https://www.rfc-editor.org/rfc/rfc2663.html
- https://www.rfc-editor.org/rfc/rfc3022.html
- https://www.rfc-editor.org/rfc/rfc3424.html
- https://www.iana.org/assignments/mobileip-numbers/mobileip-numbers.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
