要約

  • リクエストの送信元などの文脈に依存するポータルは、端末が別の接続経路を使うと、同じURIでも必要な識別情報を得られないことがある。
  • 識別子の一意性は、あるポータルにある時点で接続する機器の範囲で成立する。アドレスや接続先の機器が変われば、古い対応関係を更新または無効化する必要がある。
  • 複数のアドレスをまとめるか、内部の安定した識別値を残すかは、サービス上の選択でもある。継続性を得るための対応表は、長期的な追跡を可能にする情報にもなる。

同じ画面を別の回線から開く

仮に、ある利用者が訪問先のネットワークに接続し、案内されたポータルのリンクを端末に残したとする。その後、別のネットワークインターフェースを使って同じリンクを開く。端末もリンクも変わっていない。だが、リクエストを受け取る側から見ると、送信元や名前解決の条件は以前とは異なるかもしれない。

画面が表示されることと、その画面が意図した接続の状態を扱っていることは別である。支払いの画面であれば、いま使っている回線のための操作なのか、先ほど接続したネットワークのための操作なのかも区別する必要がある。

これは特定の事業者や端末で観測した障害ではなく、設計上の関係を考えるための仮定である。問題は通信ができるかだけではない。通信できたとき、サーバーがどの機器とどの接続について答えているのか、という点にある。

RFC 8952 は、この問題をキャプティブポータルの機器識別として扱う。2020年11月に公開された情報提供を目的とするアーキテクチャ文書であり、インターネット標準化過程の仕様ではない。その第3節は、各構成要素が利用者の機器を識別するだけでなく、相互にやり取りするときにも同じ機器を指している必要があると説明する。

識別子は、そのために使う材料である。番号を一つ選んだだけでは、経路や時点が変わっても同じ対応関係が保たれるとは限らない。

URIの外側に置いた前提

APIがリクエストの文脈から端末を識別するなら、複数の端末に共通のURIを使うことができる。送信元アドレスなどが、URIに含まれていない区別を補っているからだ。

この方式は、想定した経路では役に立つ。しかし、複数のネットワークインターフェースを持つ端末が別の経路を使えば、文脈は変わる。問い合わせ元によって異なる答えを返すDNSの構成も、APIの宛先や、その宛先が得られる情報に影響しうる。

RFC 8952は二つを区別している。APIへのアクセス自体は文脈に依存してよい。一方、APIが提供するURIは機器ごとに一意で、正しく機能するために文脈へ依存しないことが望ましい。すべてのAPI接続が文脈から独立しなければならない、と読み替えてはいけない。

また、URIに認証されていない機器識別子をそのまま含めれば解決するわけでもない。文書は、そのような方法がなりすましや再送による不正利用の危険を生むと指摘する。対象を指し示せることと、適切な権限で操作できることは、異なる設計上の責任である。

あるURIが別の回線からも使える場合でも、機能の一部を元のキャプティブネットワーク内に限ることはありうる。RFC 8952は、支払いが現在の接続のためではないという注意を表示する例に触れる。リンクの到達性だけでなく、利用者がどのサービスに対して操作しているかを明確にする必要がある。

状態を返す側と、パケットを通す側

ポータルの構成要素にはそれぞれ別の役割がある。設定情報を配るサービスは、端末がどこへ問い合わせるべきかを知らせる。状態APIは接続の制限状態を返す。利用者向けのポータルは必要な手続きを扱い、通信を制御する装置はデータパケットを通すかどうか判断する。

これらが同じ設備上に存在しても、機器の対応関係が自動的に正しくなるわけではない。逆に、分散しているから必ず誤るわけでもない。大切なのは、各機能が識別に使う情報を取得でき、その意味を共有していることである。

2020年9月に標準化過程の仕様として公開された RFC 8908 は、APIが必要な機器情報をほかの方法では得られない場合、設定時にクライアントごとに異なるURIを提供することを推奨している。そのURIは同じ端末でもセッションごとに変わりうる。ネットワークへ参加するたびに、発見や設定の手続きを利用し、以前のURIが変わらないとは想定しないことも推奨する。

この推奨は、サービスの状態と接続の実態を結ぶためのものである。URIを永久の機器番号にする要求でも、自然人の身元を確認する仕組みでもない。

TLSによる保護も必要だ。RFC 8908でサーバーを検証する対象は、ネットワークの設定機構が渡したホスト名である。検証に成功しても、設定機構そのものの安全性や、そのネットワークを利用者が信頼すべきかどうかまで確認したことにはならない。証明書を検証できない場合、この仕様が定めるAPIとのやり取りを続けてはならない。

安全な通信路は、必要な条件を守る。しかし、サーバー内部でリクエストを誤った端末に対応付けたなら、その誤りまでは訂正してくれない。

一意である期間は終わる

RFC 8952が求める識別子の一意性には、空間と時間の範囲がある。同じポータルと、その時点でやり取りしている機器の間で区別できればよい。値を後で別の機器に割り当てることも、独立したポータルが同じ値を使うことも認められている。

これは、短期のネットワーク利用に永久の世界共通番号を必要としないための実用的な考え方である。ローカルな値を再利用できることは、設計の自由度になる。

ただし、値の再利用と古いセッションの継承は別の行為だ。ある機器が離れた後、そのアドレスを別の機器に割り当てたとする。アドレスの割り当てとしては正しくても、API側に古い対応表が残っていれば、新しい機器について古い状態を返してしまう可能性がある。

第3.4.2節は、IPアドレスと機器の対応が変わった場合、構成要素が対応を削除または更新することを要求する。同時に同じアドレスを持つ機器がいないという確認だけでは、この更新を済ませた証拠にならない。

物理インターフェースを使う場合にも、接続された機器が変わったら、APIと通信制御装置の双方が関連する状態を無効化しなければならない。差し込み口が同じだからといって、差し込み口の向こうに同じ対象がいるとは限らない。

運用上の焦点は、値を記憶していることではなく、その値が何を指すかを更新できることにある。旧状態の解除を単なる記録整理とみなすと、サービスの対象を交代させる重要な処理が見えなくなる。

どこから見るかで、区別できる範囲が変わる

物理的な接続箇所は、一つのインターフェースにつながる機器が一つなら識別に使える。複数の機器が同じ箇所を共有するなら、その属性だけでは区別できない。通信制御装置が接続箇所を直接知るか、トンネルなどで識別情報を受け取る必要があり、APIにも同様の条件がある。

IPアドレスにも観測位置の条件がある。NATを越えた側からは、複数の機器が同じアドレスに見えることがある。RFC 8952は、構成要素がポートの対応を知っていれば機器を区別できる場合があるとする。共有された外部アドレスだけで個々の端末を特定できる、という意味ではない。

RFC 8908も、クライアントのIPアドレスを識別に使うシステムでは、APIと通信制御装置に同じアドレスが見える必要があると述べる。APIを遠隔の環境へ移す計画は、この条件を変えることがある。応答形式が同一でも、利用できる識別情報まで同一とは限らない。

アーキテクチャは、識別子を選ぶ際に一意性、なりすましにくさ、APIからの可視性、通信制御装置からの可視性を併せて評価するよう推奨する。各性質の良さを一つの数値に変換する評価式は定めていない。

機器識別を個人の身元の証明として扱わないことも重要だ。通信規則を適用するために十分な対応表が、ある人の行動を特定するためにも十分だとは限らない。用途を変えるなら、その分だけ別の根拠が必要になる。

一台に複数のアドレスがあるとき

IPv4とIPv6を使う端末や、同じリンクで複数のIPv6アドレスを持つ端末を、サービス上どうまとめるかも選択である。RFC 8952は、アドレスごとに別の機器として扱う方式と、一つの加入者の見え方にまとめる方式の両方を認める。

端末の筐体が一つという事実だけでは、選択は決まらない。まとめるなら、APIが延長したセッションと、通信制御装置が適用する条件が同じ範囲を指す必要がある。分けるなら、利用者に約束したサービスがその区別と矛盾しないようにする必要がある。

片方だけがまとめて扱うと、状態の説明とパケットの扱いが経路ごとに食い違う可能性がある。これは異なる選択を混在させた場合の分析であり、複数アドレスを持つすべての端末で障害が発生するという主張ではない。

文書はIPv6のサブネットによる識別の可能性にも触れるが、どの /64 も常に一人の加入者に対応するとは述べない。また、MACアドレスも候補に含めるものの、その利用法を一般的な解決策として展開してはいない。ここからアドレスのプライバシー機能を無効化する結論は出ない。

外側の番号を変えても、内側の関係は残る

サービスを途切れさせないために、変わる識別子を内部の安定した値へ対応付ける設計が考えられる。それは、複数のアドレスに現れるセッションを理解し、予定された変化の後もサービスを維持するために役立つ。

同時に、その安定した対応は機微な情報になる。RFC 8952のプライバシーに関する節は、変更可能な匿名識別子が長期追跡の抑制に役立つ一方、内部で長期的な値に結び付けるなら、その値を保護する必要があると説明する。

通信の暗号化は、経路上で対応情報が読まれる危険を抑える。だが、内部で誰が履歴を検索できるか、どの目的で保持するか、いつ関連付けを終えるかまでは決めない。外から見える番号の変更と、内部の識別関係の終了を混同してはならない。

調査に必要な情報を一切残さないことだけが答えでもない。ある交代を説明するための限定された記録と、あらゆる用途に備えた無期限の対応表は、別の選択である。前者の必要性が、そのまま後者の正当化になるわけではない。

Lu Hengによる代理問題の論考 は、判断する側と結果を負担する側の関係を問う。この視点を本件に使うなら、対応の統合、解除、保管を誰が決めるかを明らかにすることである。登録機関に関する同論考の批判を、ポータル事業者への事実認定として持ち込むことではない。

BTWの役割についての論考 が重視するのも、特定の主体を推すのではなく、現実の仕組みを記述する姿勢だ。継続した識別には価値がある。その識別を必要以上に続けることには、別の負担がある。

同じURIを開いたという事実から、同じサービス対象を扱っていると結論するには、その間の対応関係が必要になる。ポータルが維持すべきなのは永久の番号ではない。どの変化を越えて誰を同じとみなし、いつその判断を終えるのかについての、構成要素間の明確な合意である。

出典