要約
- L2Fは
MID=0でトンネルを確立し、非ゼロのMIDで個別のクライアント接続を受理する。前者のOPENは後者を証明しない。 - CLID、MID、Challenge、KeyはNASとHome Gateway間のプロトコル文脈を識別・保護するが、人の権限やアプリケーション主体を確定しない。
- データトラフィックにはL2F自身の信頼性保証がないため、正常な制御面から全フレーム到達や利用可能なサービスを推論できない。
消えるフレームと残る制御状態
RFC 2341の仮想ダイヤルアップでは、利用者はPSTNまたはISDNを通じてISPのNetwork Access Server(NAS)へ物理的に接続する。しかしPPPまたはSLIPの終端は、離れたHome Gatewayに置かれる。L2Fは両者の間でリンク層フレームをカプセル化し、アクセス地点とプロトコル終端を切り離す。
この構成には複数の成立条件がある。呼がNASに届くこと、PPPのLCPが進むこと、NASが見かけ上の利用者情報から宛先Home Gatewayを選ぶこと、L2Fトンネルが成立すること、個別クライアントが受理されること、追加認証とNCPが終わること、フレームが実際に届くこと、そしてアプリケーションが結果を返すことだ。いずれか一つだけでは全体を代表できない。
トンネルの交渉はMID=0で行われる。両端はL2F_CONFとL2F_OPENを交換し、Name、Challenge、Assigned_CLIDを共有する。その結果、トンネルはクライアントを確立できる状態になる。RFCの記述は、トンネルが利用可能になったことと、クライアントが成立したことを明確に分けている。
クライアント接続は非ゼロのMIDを使う。NASは認証方式やCHAP、PAP、LCPから得た情報を含み得る別のL2F_OPENを送り、Home GatewayがL2F_OPENを返して初めて、そのクライアント接続が受理されたことになる。PPPまたはSLIPフレームの転送はその後だ。一つのトンネル内で、各MIDは独立したOPEN/CLOSEの生存期間を持つ。
識別子が証明するのは参照先である
CLIDは、下位媒体だけでは区別しにくい複数のトンネルを分離する。MIDは、そのトンネルの中から一つのクライアント接続を選ぶ。MID=0はトンネル制御専用で、非ゼロ値はクライアント状態に使われる。閉じたMIDを再利用するときは、新規接続として初期化しなければならない。
これは状態表を正しく参照する仕組みであり、人物証明ではない。CLIDから、端末を操作した人の法的身元は分からない。MIDから、その人の現在の権限や、後段のアプリケーションが認識した主体は分からない。経路選択用のハンドルを資格情報へ昇格させると、実際には存在しない証拠を作ることになる。
RFC 2341自身が、ISP側で得るものを利用者の「apparent identity」と表現している。ISPはそこからHome Gatewayを探し、最終的な受理・拒否はHome Gatewayが決める。受理後にも、L2Fの範囲外でPPPまたはSLIPの追加認証を実施できる。RFC 1994のCHAPも独自のChallenge/Response境界を持つ。名前の取得、資格情報の転送、秘密の検証、ネットワーク利用の許可、アプリへのログインは別の出来事だ。
データに対する沈黙は仕様の一部
L2Fの制御メッセージは再送の対象になる。一方、RFC 2341はデータトラフィックにフロー制御や信頼性のある配送を提供しないと明記し、再送を内包されるプロトコルへ委ねる。通常のデータではL2FのSeqフィールドも一般に使われない。
したがって、OPEN、ECHO応答、正しいKey、増加するカウンターのどれも、個々のフレームの到着証明にはならない。それぞれ、対端が応答したこと、ある文脈が有効だったこと、ある境界でトラフィックを観測したことは示せる。しかしエンドツーエンドの受領記録には不足する。
PPPの場合、L2Fは物理フレーミング、透過処理、FCSを取り除いたリンク層フレームを運ぶ。PPP Echo、NCPネゴシエーション、TERMREQも、L2Fから見ればトンネルされるHDLC-like frameだ。L2F自身はPPPのTERMREQを検出せず、PPP endpointの結果がL2F_CLOSEへの遷移を起こす必要がある。
さらにPPPにはLCPによる確立、任意の認証、NCPによるネットワーク層設定がある。その上でアプリケーションが独自のセッションを開始する。下位層の成功は上位層の成功条件を満たすことがあっても、上位層の結果を観測したことにはならない。
Keyが守る範囲を広げない
トンネル確立時には共有秘密とChallenge/Response計算が使われる。以降のパケットには認証応答から縮約した32ビットKeyを載せることができ、未知のCLID、誤ったKey、無効なパケットは破棄される。これは、設定済みNAS–Home Gateway関係の中で一部のspoofingに対抗する仕組みだ。
しかしpayloadの機密性、最終利用者の認可、アプリケーション認証、処理結果までは保証しない。後のRFC 3193はL2TPについて、トンネル認証、パケットごとの完全性、replay防止、機密性、エンドツーエンド安全性を分けた。その区別をL2Fの能力として遡及させることはできないが、トンネル相手の確認と業務結果の安全な完了を分ける根拠にはなる。
Historicという分類の読み方
RFC 2341は現在Historicである。Status of MemoはInternet標準を規定しないと述べ、IETF DatatrackerはLegacy stream、IETF endorsementなし、標準化手続き上のformal standingなしと記す。これは技術記録を無価値にしない。一方、RFCの存在から導入規模、相互運用、現在の利用、製品成功を推測することもできない。
残すべき実務は、境界ごとの記録だ。物理呼、LCP、Gateway選択、CLID単位のトンネル、MID単位のクライアント、追加認証、両端のフレーム、NCP、アプリセッション、利用者が見た結果を分離する。NASとHome Gatewayのカウンターを別々に残し、CLOSEも両端で追う。仕様名ではなく、実際に観測した出来事が証拠になる。
出典
- https://www.rfc-editor.org/info/rfc2341/
- https://www.rfc-editor.org/rfc/rfc2341.html
- https://datatracker.ietf.org/doc/rfc2341/
- https://datatracker.ietf.org/doc/rfc2341/history/
- https://errata.rfc-editor.org/search/?rfc_number=2341
- https://www.rfc-editor.org/rfc/rfc1661.html
- https://www.rfc-editor.org/rfc/rfc1662.html
- https://www.rfc-editor.org/rfc/rfc1994.html
- https://www.rfc-editor.org/rfc/rfc2661.html
- https://www.rfc-editor.org/rfc/rfc2868.html
- https://www.rfc-editor.org/rfc/rfc3193.html
- https://www.rfc-editor.org/rfc/rfc3931.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/on-data-sovereignty-technical-vs-practical-realities/
- https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

