要約

  • RFC 3193 は L2TP の制御・データ双方を ESP で守るよう求めたが、保護が正しいトンネルに届くには、交渉中に変わるアドレスとポートを L2TP から IPsec のフィルターへ反映する必要があった。
  • IKE の鍵がパケットごとに確認するのは IKE が認証した主体であり、PPP が開始時に認証した利用者ではない。複数利用者の端末では、別途トラフィック分離がなければ人の同一性を証明できなかった。

最初に守るべきものは、完成したトンネルのデータではなく、トンネルを作ろうとする最初の SCCRQ だった。

L2TP は PPP フレームを運び、トンネル認証や PPP 認証、暗号、圧縮を利用できた。しかし開始時の認証だけでは、その後の制御パケットとデータパケットに完全性やリプレイ防止を与えない。PPP 暗号は L2TP 制御チャネルを守らず、鍵管理も L2TP 自身にはなかった。

そこで RFC 3193 は、制御とデータの両方に IPsec ESP を実装し、トランスポートモードとリプレイ防止を支えるよう要求した。トンネルモードは任意で、空暗号を含む当時の必須スイートを実装しても、どれを使うかは運用者が決める。実装可能性と実際の保護内容は別の証拠である。

難題はセレクターにあった。IKE Phase 2 は、アドレス、プロトコル、ポートで守るトラフィックを合意する。ところが L2TP は動的な送信元ポートを許し、応答側も SCCRP で別ポートを選べた。元仕様は別 IP アドレスへの移動さえ許していた。アプリケーションが最終ソケットを決める前に、IPsec は保護範囲を必要としていた。

RFC 3193 は、最初から全 UDP を広く許すのではなく、L2TP が判明した事実を IPsec フィルターデータベースへ注入する構造を採った。初期フィルターは SCCRQ より先に存在しなければならない。対応する SA がなければ SCCRQ の送信をきっかけに IKE が作成し、失敗すればパケットを落とす。開始メッセージだけを平文で通す余地を残さなかった。

送信元の動的ポートが確定すれば L2TP が値を渡し、Quick Mode 完了後に IKE が具体的なフィルターを SA に結び付ける。確立途中には応答側のポート変更を受ける幅が必要でも、確立後には残余 SA とフィルターを消せる。発見のための一時的な広さは、恒久的な権限ではない。

応答側が IP アドレスを変える場合、別アドレスから突然 SCCRP を返して連続性を主張することはできなかった。元の保護経路で StopCCN を送り、一般エラーと「Try Another」に新アドレスを載せる。開始側は形式を検査し、新しいフィルターを用意し、Phase 1 と Phase 2 を改めて成立させてから SCCRQ を送り直す。業務上は同じ接続目的でも、暗号状態は作り直す。

ポート変更では、応答側が SCCRP 前に選択し、L2TP が新フィルターを注入し、応答側から新しい Phase 2 を始める。最終規則は実際に選ばれたソケットを表す。UDP 1701 は初期の待合場所になり得るだけで、トンネルの資格証明ではなかった。

受信側でも二つの確認が残る。L2TP はまず、IPsec が復号または認証したパケットであり、平文で紛れ込んだものではないと確かめる。次に、IP アドレスと UDP ポートが、その L2TP トンネルを作ったソケット情報に一致するか調べる。信頼されたピアが別トンネルへパケットを差し込む可能性は、SA の真正性だけでは排除できない。

終了も一つの状態ではなかった。PPP の LCP 終了、L2TP 制御接続、IKE Phase 1、Phase 2 SA、インストール済みフィルターは関連するが別物である。L2TP トンネルを削除した後は対応 SA を削除し、IKE が削除通知を受けた時は L2TP に知らせる。必要な確認後にトンネル状態とフィルターを外す。

従って「VPN 切断」という一行だけでは不十分だ。トンネルが消えて SA が残ったのか、SA が消えてアプリケーションだけが接続中と思っているのか、初期の広いフィルターが残ったのかを区別できない。RFC 3193 は原子的な一レコードを仮定せず、複数状態の整合を求めた。

ヘッダーの物理的な負担も上位へ伝える必要があった。PPP が 1500 バイトを前提にしていても、L2TP と IPsec のヘッダーが加わる。規格は LCP 交渉前に、その分を差し引いた MTU を PPP へ示す案を述べた。後に IPsec が小さいパス MTU を知れば SA に保存し、L2TP へ通知する。下位層の観測は、明示的な連絡なしには上位層の事実にならない。

状態付き圧縮にも同じ問題があった。L2TP は接続指向でも、IP 上でパケット順序を必須にしない。一つの損失が履歴をずらし、後続パケットまで壊し得るため、無状態方式が望まれた。「トンネル」は信頼できる順序付きストリームを意味しない。

そして最も大きな境界が、誰を認証したかである。

PPP は開始時に利用者を認証しても、その人物を各パケットで再確認しない。IKE はしばしば機械を認証し、その鍵で IPsec が全パケットの完全性とリプレイ状態を確認する。継続的な証明は強いが、継続しているのは IKE の主張である。

共有端末なら差は決定的になる。PPP がある社員を認証し、IKE 証明書が端末全体に属する場合、ESP が示すのは端末鍵の保持者から来たことだ。OS が利用者ごとにトラフィックを隔離しなければ、別利用者も開いたトンネルを使える。パケット認証は PPP の利用者名を自動継承しない。

IKE で利用者認証を行っても、クライアントはその利用者のトラフィックだけをトンネルへ入れる必要がある。証明書、IKE 成功、端末内での隔離実行は三つの事実だった。

証明書は発行の権限を持ち込む。LNS は複数 CA を信頼でき、失効確認の扱いも CA ごとに違い得る。機械証明書の価値は、偽装した申請者がどれほど入手しにくいかに左右される。スマートカードは利用者鍵を守っても、承認済み端末だけを許す機械ポリシーとは衝突し得る。鍵の格納媒体だけでは権限の意味は決まらない。

グループ事前共有鍵は、さらに主体を曖昧にした。遠隔接続では動的アドレスが普通で、Main Mode は ID を受け取る前に鍵を必要とし得る。全員で同じ秘密を使えば選択問題は消えるが、知っている全員が同じ資格を持つ。その秘密は特定のクライアントや LNS を識別せず、所持者は LNS を装って古い PPP パスワード方式を攻撃できる。RFC 3193 は LNS 認証にグループ鍵を使わないよう勧告した。

Aggressive Mode は ID を早く送り鍵を選べる代わりに、ID を露出する。証明書は拡張しやすい代わりに、発行と失効の制度を要する。一つの「認証済み」という表示では、この取引条件が消える。

強制トンネルでは、クライアントが PPP を LAC に渡し、LAC–LNS 間の IPsec を知らない場合がある。LNS は SA の性質を読めても、クライアントは自分から LAC までの保護をそこから推論できない。知識が非対称だった。

自発トンネルではクライアント自身が L2TP を始め、LNS までの SA を観測できる。PPP 暗号や圧縮の重複を減らしやすくなるが、LNS 以後の区間は別である。RFC 3193 は冒頭で、エンドツーエンド安全を標準化する文書ではないと明言した。

この限定こそ歴史的な成果だった。L2TP が知るソケットを IPsec に渡し、IPsec が知る保護結果を L2TP が確認し、それぞれが知らない利用者や最終結果を主張しない。安全なトンネルは一枚の証明書ではなく、限界を保った複数の証拠の連携だった。