[要約] 要約： RFC 2809は、L2TP強制トンネリングをRADIUSを介して実装するためのガイドラインです。目的： このRFCの目的は、L2TPを使用してネットワーク上のトラフィックを安全にトンネリングするためのRADIUSプロトコルの使用方法を提供することです。
Network Working Group B. Aboba
Request for Comments: 2809 Microsoft
Category: Informational G. Zorn
Cisco
April 2000
Implementation of L2TP Compulsory Tunneling via RADIUS
半径を介したL2TP強制トンネルの実装
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（c）インターネット協会（2000）。無断転載を禁じます。
Abstract
概要
This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP protocol. This provisioning can be accomplished via the integration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate documents.
このドキュメントでは、L2TPプロトコルを使用して、ダイヤルアップネットワークでの強制トンネルのプロビジョニングに生じる実装の問題について説明します。このプロビジョニングは、半径とトンネリングプロトコルの統合を介して実現できます。他のトンネリングプロトコルで発生した実装の問題は、ドキュメントを分離するために残されています。
Voluntary Tunneling In voluntary tunneling, a tunnel is created by the user, typically via use of a tunneling client.
自発的なトンネリング自発的トンネリングでは、通常、トンネルクライアントの使用を介してトンネルがユーザーによって作成されます。
Compulsory Tunneling In compulsory tunneling, a tunnel is created without any action from the user and without allowing the user any choice.
強制トンネリング強制トンネリングでは、ユーザーからのアクションなしで、ユーザーに選択肢を許可することなくトンネルが作成されます。
Tunnel Network Server This is a server which terminates a tunnel. In L2TP terminology, this is known as the L2TP Network Server (LNS).
トンネルネットワークサーバーこれは、トンネルを終了するサーバーです。L2TP用語では、これはL2TPネットワークサーバー（LNS）として知られています。
Network Access Server The Network Access Server (NAS) is the device that clients contact in order to get access to the network. In L2TP terminology, a NAS performing compulsory tunneling is referred to as the L2TP Access Concentrator (LAC).
ネットワークアクセスサーバーネットワークアクセスサーバー（NAS）は、ネットワークにアクセスするためにクライアントが接触するデバイスです。L2TP用語では、強制トンネリングを実行するNASがL2TPアクセス濃縮器（LAC）と呼ばれます。
RADIUS authentication server This is a server which provides for authentication/authorization via the protocol described in [1].
RADIUS認証サーバーこれは、[1]で説明されているプロトコルを介して認証/承認を提供するサーバーです。
RADIUS proxy In order to provide for the routing of RADIUS authentication requests, a RADIUS proxy can be employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the RADIUS server, the proxy appears to act as a RADIUS client. Can be used to locate the tunnel endpoint when realm-based tunneling is used.
RADIUSプロキシRADIUS認証要求のルーティングを提供するために、RADIUSプロキシを使用できます。NASにとって、RADIUSプロキシはRADIUSサーバーとして機能するように見え、RADIUSサーバーには、プロキシはRADIUSクライアントとして機能するように見えます。レルムベースのトンネリングが使用されるときに、トンネルエンドポイントを見つけるために使用できます。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [4].
このドキュメントでは、キーワードは「可能性があります」、「必要はない」、「オプション」、「推奨」、「は」、「必要はありません」、および「必要はありません」は、[4]で説明されているように解釈されるべきではありません。
Many applications of tunneling protocols involve dial-up network access. Some, such as the provisioning of secure access to corporate intranets via the Internet, are characterized by voluntary tunneling: the tunnel is created at the request of the user for a specific purpose. Other applications involve compulsory tunneling: the tunnel is created without any action from the user and without allowing the user any choice.
トンネルプロトコルの多くのアプリケーションには、ダイヤルアップネットワークアクセスが含まれます。インターネットを介した企業イントラネットへの安全なアクセスのプロビジョニングなどの一部は、自発的なトンネリングによって特徴付けられます。トンネルは、特定の目的のためにユーザーの要求に応じて作成されます。他のアプリケーションには、強制トンネリングが含まれます。トンネルは、ユーザーからのアクションなしで、ユーザーに選択肢を許可することなく作成されます。
Examples of applications that might be implemented using compulsory tunnels are Internet software upgrade servers, software registration servers and banking services. These are all services which, without compulsory tunneling, would probably be provided using dedicated networks or at least dedicated network access servers (NAS), since they are characterized by the need to limit user access to specific hosts.
強制トンネルを使用して実装される可能性のあるアプリケーションの例は、インターネットソフトウェアアップグレードサーバー、ソフトウェア登録サーバー、銀行サービスです。これらはすべて、強制的なトンネリングなしで、特定のホストへのユーザーアクセスを制限する必要があることを特徴とするため、専用ネットワークまたは少なくとも専用ネットワークアクセスサーバー（NAS）を使用しておそらく提供されるサービスです。
Given the existence of widespread support for compulsory tunneling, however, these types of services could be accessed via any Internet service provider (ISP). The most popular means of authorizing dial-up network users today is through the RADIUS protocol. The use of RADIUS allows the dial-up users' authorization and authentication data to be maintained in a central location, rather than on each NAS. It makes sense to use RADIUS to centrally administer compulsory tunneling, since RADIUS is widely deployed and was designed to carry this type of information. New RADIUS attributes are needed to carry the tunneling information from the RADIUS server to the NAS. Those attributes are defined in [3].
ただし、強制トンネリングに対する広範なサポートの存在を考えると、これらのタイプのサービスには、インターネットサービスプロバイダー（ISP）を介してアクセスできます。今日のダイヤルアップネットワークユーザーを承認する最も一般的な手段は、RADIUSプロトコルを使用することです。RADIUSを使用すると、ダイヤルアップユーザーの承認データと認証データを、各NASではなく、中央の場所に維持できます。半径を使用して義務的なトンネリングを中央に投与することは理にかなっています。これは、半径が広く展開され、このタイプの情報を運ぶように設計されているためです。RADIUSサーバーからNASにトンネリング情報を運ぶには、新しいRADIUS属性が必要です。これらの属性は[3]で定義されています。
Current proposals for routing of tunnel requests include static tunneling, where all users are automatically tunneled to a given endpoint, and realm-based tunneling, where the tunnel endpoint is determined from the realm portion of the userID. User-based tunneling as provided by integration of RADIUS and tunnel protocols offers significant advantages over both of these approaches.
トンネルリクエストのルーティングに関する現在の提案には、すべてのユーザーが自動的に特定のエンドポイントにトンネリングされる静的トンネルと、ユーザーIDのレルム部分からトンネルエンドポイントが決定されるレルムベースのトンネルが含まれます。RADIUSとトンネルプロトコルの統合によって提供されるユーザーベースのトンネルは、これらのアプローチの両方よりも大きな利点を提供します。
Static tunneling requires dedication of a NAS device to the purpose. In the case of an ISP, this is undesirable because it requires them to dedicate a NAS to tunneling service for a given customer, rather than allowing them to use existing NASes deployed in the field. As a result static tunneling is likely to be costly for deployment of a global service.
静的トンネリングには、目的に対するNASデバイスの献身が必要です。ISPの場合、これは、フィールドに展開されている既存のnaseを使用できるようにするのではなく、特定の顧客のためにNASをトンネルサービスに捧げる必要があるため、望ましくありません。その結果、静的トンネルは、グローバルサービスの展開に費用がかかる可能性があります。
Realm-based tunneling assumes that all users within a given realm wish to be treated the same way. This limits flexibility in account management. For example, BIGCO may desire to provide Janet with an account that allows access to both the Internet and the intranet, with Janet's intranet access provided by a tunnel server located in the engineering department. However BIGCO may desire to provide Fred with an account that provides only access to the intranet, with Fred's intranet access provided by a tunnel network server located in the sales department. Such a situation cannot be accommodated with realm-based tunneling, but can be accommodated via user-based tunneling as enabled by the attributes defined in [3].
レルムベースのトンネリングは、特定のレルム内のすべてのユーザーが同じ方法で扱われることを望んでいると仮定しています。これにより、アカウント管理の柔軟性が制限されます。たとえば、Bigcoは、インターネットとイントラネットの両方へのアクセスを可能にするアカウントをジャネットに提供したい場合があります。ジャネットのイントラネットアクセスは、エンジニアリング部門にあるトンネルサーバーから提供されます。ただし、Bigcoは、Fredのイントラネットへのアクセスのみを提供するアカウントをFredに提供したい場合があり、Fredのイントラネットアクセスが販売部門にあるトンネルネットワークサーバーによって提供されます。このような状況は、レルムベースのトンネルに対応することはできませんが、[3]で定義されている属性によって有効にされたユーザーベースのトンネリングを介して対応できます。
RADIUS-based compulsory tunneling can support both single authentication, where the user is authenticated at the NAS or tunnel server, or dual authentication, where the user is authenticated at both the NAS and the tunnel server. When single authentication is supported, a variety of modes are possible, including telephone-number based authentication. When dual-authentication is used, a number of modes are available, including dual CHAP authentications;
RADIUSベースの強制トンネリングは、ユーザーがNASまたはトンネルサーバーで認証されている単一認証、またはユーザーがNASとトンネルサーバーの両方で認証されるデュアル認証の両方をサポートできます。単一の認証がサポートされている場合、電話番号ベースの認証など、さまざまなモードが可能です。二重認証を使用する場合、デュアルチャップ認証など、多くのモードが利用可能です。
CHAP/EAP authentication; CHAP/PAP(token) authentication; and EAP/EAP authentication, using the same EAP type for both authentications. EAP is described in [5].
chap/eap認証;chap/pap（token）認証;両方の認証に同じEAPタイプを使用して、EAP/EAP認証。EAPは[5]で説明されています。
The alternatives are described in more detail below.
代替案については、以下で詳しく説明します。
Single authentication alternatives include:
単一認証の代替品は次のとおりです。
NAS authentication NAS authentication with RADIUS reply forwarding Tunnel server authentication
RADIUSによるNAS認証NAS認証応答転送トンネルサーバー認証
With this approach, authentication and authorization (including tunneling information) occurs once, at the NAS. The advantages of this approach are that it disallows network access for unauthorized NAS users, and permits accounting to done at the NAS. Disadvantages are that it requires that the tunnel server trust the NAS, since no user authentication occurs at the tunnel server. Due to the lack of user authentication, accounting cannot take place at the tunnel server with strong assurance that the correct party is being billed.
このアプローチにより、NASでは、認証と認証（トンネリング情報を含む）が1回発生します。このアプローチの利点は、不正なNASユーザーのネットワークアクセスを許可し、NASで行う会計を許可することです。欠点とは、トンネルサーバーでユーザー認証が発生しないため、トンネルサーバーがNASを信頼する必要があることです。ユーザー認証が不足しているため、正しい当事者が請求されていることを強く保証して、トンネルサーバーで会計が行われることはありません。
NAS-only authentication is most typically employed along with LCP forwarding and tunnel authentication, both of which are supported in L2TP, described in [2]. Thus, the tunnel server can be set up to accept all calls occurring within authenticated tunnels, without requiring PPP authentication. However, this approach is not compatible with roaming, since the tunnel server will typically only be set up to accept tunnels from a restricted set of NASes. A typical initiation sequence looks like this:
NASのみの認証は、[2]で説明されているL2TPでサポートされているLCP転送およびトンネル認証とともに、最も通常採用されています。したがって、PPP認証を必要とせずに、認証されたトンネル内で発生するすべての呼び出しを受け入れるようにトンネルサーバーを設定できます。ただし、トンネルサーバーは通常、制限付きのnaseセットからトンネルを受け入れるようにのみ設定されるため、このアプローチはローミングと互換性がありません。典型的な開始シーケンスは次のようになります：
Client and NAS: Call Connected Client and NAS: PPP LCP negotiation Client and NAS: PPP authentication NAS to RADIUS Server: RADIUS Access-request RADIUS server to NAS: RADIUS Access-Accept/Access-Reject NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP forwarding Tunnel Server to NAS: L2TP Incoming-Call-Reply NAS to Tunnel Server: L2TP Incoming-Call-Connected Client and Tunnel Server: NCP negotiation The process begins with an incoming call to the NAS, and the PPP LCP negotiation between the client and the NAS. In order to authenticate the client, the NAS will send a RADIUS Access-Request to the RADIUS server and will receive a RADIUS Access-Accept including tunnel attributes, or an Access-Reject.
クライアントおよびNAS：コレクションコネクテッドクライアントとNAS：PPP LCPネゴシエーションクライアントとNAS：PPP認証NASからラジアスサーバー：RADIUSアクセスRequest RADIUS SERVER TO NAS：RADIUS ACCESS-ACCEPT/ACSECT-REJECT NASからTunnel Server：L2TP Incoming-Call-LCP転送トンネルサーバーW/LCPをNASに転送するリクエスト：L2TPエクシームコールリプリーNASからトンネルサーバーへ：L2TP着信コール接続クライアントとトンネルサーバー：NCP交渉は、NASとPPP LCPへの通話から始まります。クライアントとNASの間の交渉。クライアントを認証するために、NASはRADIUS Access-RequestをRADIUSサーバーに送信し、Tunnel属性、またはアクセスrejectを含むRADIUSアクセスacceptを受け取ります。
In the case where an L2TP tunnel is indicated, the NAS will now bring up a control connection if none existed before, and the NAS and tunnel server will bring up the call. At this point, data will begin to flow through the tunnel. The NAS will typically employ LCP forwarding, although it is also possible for the tunnel server to renegotiate LCP. If LCP renegotiation is to be permitted, the NAS SHOULD NOT send an LCP CONFACK completing LCP negotiation. Rather than sending an LCP CONFACK, the NAS will instead send an LCP Configure-Request packet, described in [6]. The Client MAY then renegotiate LCP, and from that point forward, all PPP packets originated from the client will be encapsulated and sent to the tunnel server.
L2TPトンネルが示されている場合、NASは以前に存在しなかった場合、NASとトンネルサーバーがコールを引き上げます。この時点で、データはトンネルを流れ始めます。NASは通常、LCP転送を採用しますが、トンネルサーバーがLCPを再交渉することも可能です。LCPの再交渉が許可される場合、NASはLCPの交渉を完了するLCP雑誌を送るべきではありません。NASは、LCPの混乱を送信するのではなく、[6]に記載されているLCP Configure-Requestパケットを送信します。クライアントはLCPを再交渉する場合があり、その時点から、クライアントから発信されたすべてのPPPパケットがカプセル化され、トンネルサーバーに送信されます。
Since address assignment will occur at the tunnel server, the client and NAS MUST NOT begin NCP negotiation. Instead, NCP negotiation will occur between the client and the tunnel server.
アドレスの割り当てはトンネルサーバーで発生するため、クライアントとNASはNCP交渉を開始してはなりません。代わりに、クライアントサーバーとトンネルサーバーの間でNCPの交渉が発生します。
With this approach, authentication and authorization occurs once at the NAS and the RADIUS reply is forwarded to the tunnel server. This approach disallows network access for unauthorized NAS users; does not require trust between the NAS and tunnel server; and allows for accounting to be done at both ends of the tunnel. However, it also requires that both ends share the same secret with the RADIUS server, since that is the only way that the tunnel server can check the RADIUS Access-Reply.
このアプローチにより、NASで認証と承認が一度発生し、RADIUS応答がトンネルサーバーに転送されます。このアプローチは、許可されていないNASユーザーのネットワークアクセスを許可しません。NASとトンネルサーバーの間の信頼は必要ありません。トンネルの両端で会計を行うことができます。ただし、トンネルサーバーがRADIUSアクセス応答を確認できる唯一の方法であるため、両端はRADIUSサーバーと同じ秘密を共有する必要があります。
In this approach, the tunnel server will share secrets with all the NASes and associated RADIUS servers, and there is no provision for LCP renegotiation by the tunnel server. Also, the tunnel server will need to know how to handle and verify RADIUS Access-Accept messages.
このアプローチでは、トンネルサーバーはすべてのNASEと関連RADIUSサーバーと秘密を共有し、トンネルサーバーによるLCP再交渉の規定はありません。また、トンネルサーバーは、RADIUS Access-Acceptメッセージを処理および検証する方法を知る必要があります。
While this scheme can be workable if the reply comes directly from a RADIUS server, it would become unmanageable if a RADIUS proxy is involved, since the reply would be authenticated using the secret shared by the client and proxy, rather than the RADIUS server. As a result, this scheme is impractical.
このスキームは、RADIUSサーバーから直接返信する場合に実行可能になりますが、RADIUSサーバーではなくクライアントとプロキシが共有する秘密を使用して応答が認証されるため、RADIUSプロキシが関与すると管理できなくなります。その結果、このスキームは非現実的です。
In this scheme, authentication and authorization occurs once at the tunnel server. This requires that the NAS determine that the user needs to be tunneled (through RADIUS or NAS configuration). Where RADIUS is used, the determination can be made using one of the following methods:
このスキームでは、トンネルサーバーで認証と承認が一度発生します。これには、NASがユーザーが（半径またはNAS構成を介して）トンネリングする必要があると判断する必要があります。半径を使用する場合、次の方法のいずれかを使用して決定を行うことができます。
Telephone-number based authentication UserID
電話番号ベースの認証ユーザーID
Using the Calling-Station-Id and Called-Station-Id RADIUS attributes, authorization and subsequent tunnel attributes can be based on the phone number originating the call, or the number being called. This allows the RADIUS server to authorize users based on the calling phone number or to provide tunnel attributes based on the Calling-Station-Id or Called-Station-Id. Similarly, in L2TP the tunnel server MAY choose to reject or accept the call based on the Dialed Number and Dialing Number included in the L2TP Incoming-Call-Request packet sent by the NAS. Accounting can also take place based on the Calling-Station-Id and Called-Station-Id.
呼び出しステーションIDおよび呼び出したステーション-ID RADIUS属性を使用すると、認証とその後のトンネル属性は、呼び出しの発信電話番号、または呼び出された番号に基づいています。これにより、RADIUSサーバーは、呼び出し電話番号に基づいてユーザーを承認したり、呼び出しとステーションIDまたは呼び出したステーションIDに基づいてトンネル属性を提供したりできます。同様に、L2TPでは、トンネルサーバーは、NASが送信したL2TPのcoming-Call-Requestパケットに含まれるダイヤル番号とダイヤル番号に基づいて、コールを拒否または受け入れることを選択できます。会計は、呼び出されたステーション-IDおよびCalking-Station-IDに基づいて行うこともできます。
RADIUS as defined in [1] requires that an Access-Request packet contain a User-Name attribute as well as either a CHAP-Password or User-Password attribute, which must be non-empty. To satisfy this requirement the Called-Station-Id or Calling-Station-Id MAY be furnished in the User-Name attribute and a dummy value MAY be used in the User-Password or CHAP-Password attribute.
[1]で定義されているRADIUSでは、アクセスリクエストパケットには、ユーザー名属性と、空でない必要があるチャップパスワードまたはユーザーパスワード属性のいずれかが含まれる必要があります。この要件を満たすために、呼び出されたステーションIDまたは呼び出しステーション-IDをユーザー名属性に提供する場合があり、ユーザーパスワードまたはチャプターワード属性でダミー値を使用できます。
In the case of telephone-number based authentication, a typical initiation sequence looks like this:
電話番号ベースの認証の場合、典型的な開始シーケンスは次のようになります。
Client and NS: Call Connected NAS to RADIUS Server: RADIUS Access-request RADIUS server to NAS: RADIUS Access-Accept/Access-Reject NAS to Tunnel Server: L2TP Incoming-Call-Request Tunnel Server to NAS: L2TP Incoming-Call-Reply NAS to Tunnel Server: L2TP Incoming-Call-Connected Client and Tunnel Server: PPP LCP negotiation Client and Tunnel Server: PPP authentication Tunnel Server to RADIUS Server: RADIUS Access-request (optional) RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject Client and Tunnel Server: NCP negotiation The process begins with an incoming call to the NAS. If configured for telephone-number based authentication, the NAS sends a RADIUS Access-Request containing the Calling-Station-Id and the Called-Station-Id attributes. The RADIUS server will then respond with a RADIUS Access-Accept or Access-Reject.
クライアントとNS：接続されたNASをRADIUSサーバーに呼び出します：RADIUS ACCESS-REQUEST RADIUS SERVER TO NAS：RADIUS ACCESS-ACCEPT/ACCESS-REJECT NASからTunnel Server：L2TP Ecoming-Call-Request Tunnel Server to NAS：L2TP ecoming-Call-ReplyNASからトンネルサーバーへ：L2TP着信接続クライアントとトンネルサーバー：PPP LCPネゴシエーションクライアントとトンネルサーバー：PPP認証トンネルサーバーからラジウスサーバー：RADIUSアクセスリクエスト（オプション）RADIUSサーバーからトンネルサーバー：RADIUS ACCESS-ACCEPT/Access-Reject Client and Tunnel Server：NCPネゴシエーションプロセスは、NASへの着信コールから始まります。電話番号ベースの認証用に構成されている場合、NASは、呼び出しステーション-IDおよび呼び出したステーション-ID属性を含むRADIUSアクセスリケストを送信します。RADIUSサーバーは、RADIUS Access-AcceptまたはAccess-rejectで応答します。
The NAS MUST NOT begin PPP authentication before bringing up the tunnel. If timing permits, the NAS MAY bring up the tunnel prior to beginning LCP negotiation with the peer. If this is done, then LCP will not need to be renegotiated between the peer and tunnel server, nor will LCP forwarding need to be employed.
NASは、トンネルを育てる前にPPP認証を開始してはなりません。タイミングが許可されている場合、NASは、ピアとのLCP交渉を開始する前にトンネルを育てることができます。これが行われた場合、LCPはピアサーバーとトンネルサーバーの間で再交渉する必要はなく、LCP転送を使用する必要もありません。
If the initial telephone-number based authentication is unsuccessful, the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS MUST send an LCP-Terminate and disconnect the user.
最初の電話番号ベースの認証が失敗した場合、RADIUSサーバーはRADIUS Access-rejectを送信します。この場合、NASはLCPターミネートを送信してユーザーを切断する必要があります。
In the case where tunnel attributes are included in the RADIUS Access-Accept, and an L2TP tunnel is indicated, the NAS will now bring up a control connection if none existed before. This is accomplished by sending an L2TP Start-Control-Connection-Request message to the tunnel server. The tunnel server will then reply with an L2TP Start-Control-Connection-Reply. If this message indicates an error, or if the control connection is terminated at any future time, then the NAS MUST send an LCP-Terminate and disconnect the user.
トンネルの属性がRADIUSアクセスacceptに含まれ、L2TPトンネルが示されている場合、NASは以前に存在しなかった場合、制御接続を引き起こします。これは、L2TP Start-Control-Connection-Requestメッセージをトンネルサーバーに送信することで実現されます。トンネルサーバーは、L2TP Start-Control-Connection-Replyで返信します。このメッセージがエラーを示している場合、または将来の制御接続が終了した場合、NASはLCP末端を送信してユーザーを切断する必要があります。
The NAS will then send an L2TP Incoming-Call-Request message to the tunnel server. Among other things, this message will contain the Call Serial Number, which along with the NAS-IP-Address and Tunnel-Server-Endpoint is used to uniquely identify the call. The tunnel server will reply with an L2TP Incoming-Call-Reply message. If this message indicates an error, then the NAS MUST send an LCP-Terminate and disconnect the user. If no error is indicated, the NAS then replies with an L2TP Incoming-Call-Connected message.
NASは、Tunnel ServerにL2TPの着信要求メッセージを送信します。とりわけ、このメッセージにはコールシリアル番号が含まれます。これには、NAS-IPアドレスおよびトンネルサーバーエンドポイントとともに、コールを一意に識別するために使用されます。トンネルサーバーは、L2TPのrecing-call-Replyメッセージで返信します。このメッセージがエラーを示した場合、NASはLCPターミネートを送信してユーザーを切断する必要があります。エラーが示されていない場合、NASはL2TP受信コール接続メッセージで応答します。
At this point, data can begin to flow through the tunnel. If LCP negotiation had been begun between the NAS and the client, then LCP forwarding may be employed, or the client and tunnel server will now renegotiate LCP and begin PPP authentication. Otherwise, the client and tunnel server will negotiate LCP for the first time, and then move on to PPP authentication.
この時点で、データはトンネルを流れ始める可能性があります。NASとクライアントの間でLCP交渉が開始された場合、LCP転送が採用されるか、クライアントとトンネルサーバーがLCPを再交渉し、PPP認証を開始することがあります。それ以外の場合、クライアントとトンネルサーバーは初めてLCPをネゴシエートし、PPP認証に進みます。
If a renegotiation is required, at the time that the renegotiation begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP negotiation, and the client and NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP CONFACK, the NAS will instead send an LCP Configure-Request Packet, described in [6]. The Client MAY then renegotiate LCP, and from that point forward, all PPP packets originated from the client will be encapsulated and sent to the tunnel server. When LCP re-negotiation has been concluded, the NCP phase will begin, and the tunnel server will assign an address to the client.
再交渉が必要な場合は、再交渉が始まる時点で、NASはLCPの総混乱をLCP交渉を完了するべきではなく、クライアントとNASはNCPの交渉を始めてはなりません。NASは、LCPの混乱を送信するのではなく、[6]に記載されているLCP Configure-Requestパケットを送信します。クライアントはLCPを再交渉する場合があり、その時点から、クライアントから発信されたすべてのPPPパケットがカプセル化され、トンネルサーバーに送信されます。LCPの再交渉が終了すると、NCPフェーズが開始され、トンネルサーバーがクライアントにアドレスを割り当てます。
If L2TP is being used as the tunnel protocol, and LCP renegotiation is required, the NAS MAY in its initial setup notification include a copy of the LCP CONFACKs sent in each direction which completed LCP negotiation. The tunnel server MAY then use this information to avoid an additional LCP negotiation. With L2TP, the initial setup notification can also include the authentication information required to allow the tunnel server to authenticate the user and decide to accept or decline the connection. However, in telephone-number based authentication, PPP authentication MUST NOT occur prior to the NAS bringing up the tunnel. As a result, L2TP authentication forwarding MUST NOT be employed.
L2TPがトンネルプロトコルとして使用されており、LCP再交渉が必要な場合、NASには、最初のセットアップ通知には、LCP交渉を完了した各方向に送信されたLCP混乱のコピーが含まれる場合があります。トンネルサーバーは、この情報を使用して、追加のLCP交渉を避けることができます。L2TPを使用すると、最初のセットアップ通知には、トンネルサーバーがユーザーを認証し、接続を受け入れるか拒否することを決定するために必要な認証情報を含めることもできます。ただし、電話番号ベースの認証では、NASがトンネルを育てる前にPPP認証が発生しないでください。その結果、L2TP認証転送を使用してはなりません。
In performing the PPP authentication, the tunnel server can access its own user database, or alternatively can send a RADIUS Access-Request. The latter approach is useful in cases where authentication forwarding is enabled, such as with roaming or shared use networks. In this case, the RADIUS and tunnel servers are under the same administration and are typically located close together, possibly on the same LAN. Therefore having the tunnel server act as a RADIUS client provides for unified user administration. Note that the tunnel server's RADIUS Access-Request is typically sent directly to the local RADIUS server rather than being forwarded via a proxy.
PPP認証を実行する際、Tunnel Serverは独自のユーザーデータベースにアクセスしたり、RADIUS Access-Requestを送信したりできます。後者のアプローチは、ローミングや共有使用ネットワークなど、認証転送が有効になっている場合に役立ちます。この場合、半径とトンネルサーバーは同じ管理下にあり、通常は同じLAN上に近くに位置しています。したがって、トンネルサーバーをRADIUSクライアントとして機能させると、統一されたユーザー管理が提供されます。トンネルサーバーのRADIUS Access-Requestは、通常、プロキシを介して転送されるのではなく、ローカルRADIUSサーバーに直接送信されることに注意してください。
The interactions involved in initiation of a compulsory tunnel with telephone-number based authentication are summarized below. In order to simplify the diagram that follows, we have left out the client. However, it is understood that the client participates via PPP negotiation, authentication and subsequent data interchange with the Tunnel Server.
強制トンネルの開始に伴う相互作用と電話番号ベースの認証を以下にまとめます。次の図を簡素化するために、クライアントを除外しました。ただし、クライアントは、PPPの交渉、認証、およびその後のデータがトンネルサーバーと交換することで参加することが理解されています。
INITIATION SEQUENCE
開始シーケンス
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call connected
Send RADIUS
Access-Request
with Called-Station-Id,
and/or Calling-Station-Id
LCP starts
IF authentication
succeeds
Send ACK
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send Incoming-Call-Request message to Tunnel Server Send Incoming-Call-Reply to NAS Send Incoming-Call-Connected message to Tunnel Server
トンネルサーバーに着信コールリクエストメッセージを送信
Send data through the tunnel Re-negotiate LCP, authenticate user, bring up IPCP, start accounting
トンネルを介してデータを送信し、LCPを再交渉し、ユーザーを認証し、IPCPを育て、会計を開始します
Since authentication will occur only at the tunnel-server, tunnel initiation must occur prior to user authentication at the NAS. As a result, this scheme typically uses either the domain portion of the userID or attribute-specific processing on the RADIUS server. Since the user identity is never verified by the NAS, either the tunnel server owner must be willing to be billed for all incoming calls, or other information such as the Calling-Station-Id must be used to verify the user's identity for accounting purposes.
認証はトンネルサーバーでのみ発生するため、NASでのユーザー認証の前にトンネルの開始が発生する必要があります。その結果、このスキームは通常、userIDのドメイン部分またはRADIUSサーバーで属性固有の処理のいずれかを使用します。ユーザーのIDはNASによって検証されないため、トンネルサーバーの所有者は、すべての着信コールに対して請求されることをいとわない必要があります。または、会計上の目的でユーザーのIDを検証するために、呼び出しステーションIDなどのその他の情報を使用する必要があります。
In attribute-specific processing RADIUS may be employed and an attribute is used to signal tunnel initiation. For example, tunnel attributes can be sent back if the User-Password attribute contains a dummy value (such as "tunnel" or "L2TP"). Alternatively, a userID beginning with a special character ('*') could be used to indicate the need to initiate a tunnel. When attribute-specific processing is used, the tunnel server may need to renegotiate LCP.
属性固有の処理半径では、属性を使用してトンネルの開始を信号します。たとえば、ユーザーパスワード属性にダミー値（「トンネル」や「L2TP」など）が含まれている場合、トンネル属性を返送できます。あるいは、特別な文字（ '*'）で始まるユーザーIDを使用して、トンネルを開始する必要性を示すことができます。属性固有の処理を使用する場合、トンネルサーバーはLCPを再交渉する必要がある場合があります。
Another solution involves using the domain portion of the userID; all users in domain X would be tunneled to address Y. This proposal supports compulsory tunneling, but does not provide for user-based tunneling.
別のソリューションには、userIDのドメイン部分を使用することが含まれます。ドメインXのすべてのユーザーは、Yに対処するためにトンネリングされます。この提案は、強制トンネリングをサポートしていますが、ユーザーベースのトンネリングを提供していません。
In order for the NAS to start accounting on the connection, it would need to use the identity claimed by the user in authenticating to the tunnel server, since it did not verify the identity via RADIUS. However, in order for that to be of any use in accounting, the tunnel endpoint needs to have an account relationship with the NAS owner. Thus even if a user has an account with the NAS owner, they cannot use this account for tunneling unless the tunnel endpoint also has a business relationship with the NAS owner. Thus this approach is incompatible with roaming.
NASが接続の会計を開始するためには、RADIUSを介してIDを確認しなかったため、Tunnel Serverに認証されているユーザーが請求するIDを使用する必要があります。ただし、それが会計で使用されるためには、トンネルエンドポイントはNASの所有者とアカウント関係を持つ必要があります。したがって、ユーザーがNASの所有者とアカウントを持っていても、トンネルのエンドポイントにもNASの所有者とビジネス関係がある場合を除き、このアカウントをトンネリングに使用することはできません。したがって、このアプローチはローミングと互換性がありません。
A typical initiation sequence involving use of the domain portion of the userID looks like this:
useridのドメイン部分の使用を含む典型的な開始シーケンスは、次のようになります。
Client and NAS: Call Connected Client and NAS: PPP LCP negotiation Client and NAS: Authentication NAS to Tunnel Server: L2TP Incoming-Call-Request Tunnel Server to NAS: L2TP Incoming-Call-Reply NAS to Tunnel Server: L2TP Incoming-Call-Connected Client and Tunnel Server: PPP LCP re-negotiation Client and Tunnel Server: PPP authentication Tunnel Server to RADIUS Server: RADIUS Access-request (optional) RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject Client and Tunnel Server: NCP negotiation The process begins with an incoming call to the NAS, and the PPP LCP negotiation between the Client and NAS. The authentication process will then begin and based on the domain portion of the userID, the NAS will now bring up a control connection if none existed before, and the NAS and tunnel server will bring up the call. At this point, data MAY begin to flow through the tunnel. The client and tunnel server MAY now renegotiate LCP and will complete PPP authentication.
クライアントとNAS：コレクションコネクテッドクライアントとNAS：PPP LCPネゴシエーションクライアントとNAS：認証NASからトンネルサーバーへ：L2TP comping-call-requestトンネルサーバーからNAS：L2TP ecoming-call-reply to tunnel Server：l2tp exoming-call-接続されたクライアントとトンネルサーバー：PPP LCP再negotiationクライアントとトンネルサーバー：PPP認証トンネルサーバーからラジウスサーバー：RADIUS ACCESS-REQUEST（オプション）RADIUSサーバーからトンネルサーバー：RADIUS ACCESS-ACCEPT/ACSECT-REJECTクライアントとトンネルサーバー：NCP交渉このプロセスは、NASへの着信コールと、クライアントとNASの間のPPP LCP交渉から始まります。その後、認証プロセスが開始され、UserIDのドメイン部分に基づいて、NASは以前に存在しなかった場合に制御接続を引き上げ、NASとトンネルサーバーは呼び出しを引き上げます。この時点で、データがトンネルを流れ始める可能性があります。クライアントとトンネルサーバーは、LCPを再交渉し、PPP認証を完了するようになります。
At the time that the renegotiation begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP negotiation, and the client and NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP CONFACK, the NAS will instead send an LCP Configure-Request packet, described in [6]. The Client MAY then renegotiate LCP, and from that point forward, all PPP packets originated from the client will be encapsulated and sent to the tunnel server. In single authentication compulsory tunneling, L2TP authentication forwarding MUST NOT be employed. When LCP re-negotiation has been concluded, the NCP phase will begin, and the tunnel server will assign an address to the client.
再交渉が開始されたとき、NASはLCPの交渉を完了するLCP雑誌を送信するべきではなく、クライアントとNASはNCPの交渉を開始してはなりません。NASは、LCPの混乱を送信するのではなく、[6]に記載されているLCP Configure-Requestパケットを送信します。クライアントはLCPを再交渉する場合があり、その時点から、クライアントから発信されたすべてのPPPパケットがカプセル化され、トンネルサーバーに送信されます。単一認証強制トンネリングでは、L2TP認証転送を使用してはなりません。LCPの再交渉が終了すると、NCPフェーズが開始され、トンネルサーバーがクライアントにアドレスを割り当てます。
In performing the PPP authentication, the tunnel server can access its own user database, or it MAY send a RADIUS Access-Request. After the tunnel has been brought up, the NAS and tunnel server can start accounting.
PPP認証を実行する際に、Tunnel Serverは独自のユーザーデータベースにアクセスするか、RADIUS Access-Requestを送信する場合があります。トンネルが育てられた後、NASとトンネルサーバーは会計を開始できます。
The interactions are summarized below.
相互作用を以下にまとめます。
INITIATION SEQUENCE
開始シーケンス
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
Authentication
phase starts
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
ENDIF
IF no control
connection exists
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send Incoming-Call-Request message to Tunnel Server Send Incoming-Call-Reply to NAS Send Incoming-Call-Connected message to Tunnel Server
トンネルサーバーに着信コールリクエストメッセージを送信
Send data through the tunnel Re-negotiate LCP, authenticate user, bring up IPCP, start accounting
トンネルを介してデータを送信し、LCPを再交渉し、ユーザーを認証し、IPCPを育て、会計を開始します
In this scheme, authentication occurs both at the NAS and the tunnel server. This requires the dial-up client to handle dual authentication, with attendant LCP re-negotiations. In order to allow the NAS and tunnel network server to authenticate against the same database, this requires RADIUS client capability on the tunnel network server, and possibly a RADIUS proxy on the NAS end.
このスキームでは、NASとトンネルサーバーの両方で認証が発生します。これには、ダイヤルアップクライアントがデュアル認証を処理する必要があります。NASおよびトンネルネットワークサーバーが同じデータベースに対して認証できるようにするために、これにはトンネルネットワークサーバーのRADIUSクライアント機能が必要であり、場合によってはNASエンドのRADIUSプロキシが必要です。
Advantages of dual authentication include support for authentication and accounting at both ends of the tunnel; use of a single userID/password pair via implementation of RADIUS on the tunnel network server; no requirement for telephone-number based authentication, or attribute-specific processing on the RADIUS server.
二重認証の利点には、トンネルの両端での認証と会計のサポートが含まれます。トンネルネットワークサーバー上のRADIUSの実装による単一のユーザーID/パスワードペアの使用。RADIUSサーバーでの電話番号ベースの認証、または属性固有の処理の要件はありません。
Dual authentication allows for accounting records to be generated on both the NAS and tunnel server ends, making auditing possible. Also the tunnel endpoint does not need to have an account relationship with the NAS owner, making this approach compatible with roaming.
デュアル認証により、NASサーバーとトンネルサーバーの両方で会計記録を生成し、監査を可能にします。また、トンネルのエンドポイントは、NASの所有者とアカウント関係を持つ必要はなく、このアプローチをローミングと互換性のあるものにします。
A disadvantage of dual authentication is that unless LCP forwarding is used, LCP will need to be renegotiated; some clients do not support it at all, and others only support only a subset of the dual authentication combinations. Feasible combinations include PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP, CHAP/EAP, EAP/CHAP, and EAP/EAP. EAP is described in [5].
二重認証の欠点は、LCP転送を使用しない限り、LCPを再交渉する必要があることです。一部のクライアントはそれをまったくサポートしておらず、他のクライアントはデュアル認証の組み合わせのサブセットのみをサポートするだけです。実行可能な組み合わせには、PAP/PAP（トークン）、PAP/CHAP、PAP/EAP、CHAP/PAP（トークン）、CHAP/CHAP、CHAP/EAP、EAP/CHAP、およびEAP/EAPが含まれます。EAPは[5]で説明されています。
In the case of a dual authentication, a typical initiation sequence looks like this:
二重認証の場合、典型的な開始シーケンスは次のようになります。
Client and NAS: PPP LCP negotiation Client and NAS: PPP authentication NAS to RADIUS Server: RADIUS Access-request RADIUS server to NAS: RADIUS Access-Accept/Access-Reject NAS to Tunnel Server: L2TP Incoming-Call-Request Tunnel Server to NAS: L2TP Incoming-Call-Reply NAS to Tunnel Server: L2TP Incoming-Call-Connected Client and Tunnel Server: PPP LCP re-negotiation (optional) Client and Tunnel Server: PPP authentication Tunnel Server to RADIUS Server: RADIUS Access-request (optional) RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject Client and Tunnel Server: NCP negotiation
クライアントとNAS：PPP LCPネゴシエーションクライアントとNAS：PPP認証RADIUSサーバーへのNAS：RADIUS ACCESS-REQUEST RADIUS SERVER TO NAS：RADIUS ACCESS-ACCEPT/ACSICE-REJECT NAS TONNEL SERVE：L2TP ecoming-call-Reply nas to Tunnel Server：L2TP受信コール接続クライアントとトンネルサーバー：PPP LCP再negotiation（オプション）クライアントおよびトンネルサーバー：PPP認証トンネルサーバーからRADIUS ACCESS-REQUEST（オプション））RADIUSサーバーからトンネルサーバー：RADIUS ACCESS-ACCEPT/ACCESS-REJECTクライアントとトンネルサーバー：NCP交渉
The process begins with an incoming call to the NAS. The client and NAS then begin LCP negotiation. Subsequently the PPP authentication phase starts, and the NAS sends a RADIUS Access-Request message to the RADIUS server. If the authentication is successful, the RADIUS server responds with a RADIUS Access-Accept containing tunnel attributes.
このプロセスは、NASへの着信コールから始まります。その後、クライアントとNASはLCPの交渉を開始します。その後、PPP認証フェーズが開始され、NASはRADIUS Access-RequestメッセージをRADIUSサーバーに送信します。認証が成功した場合、RADIUSサーバーは、トンネル属性を含むRADIUS Access-Acceptを含む応答します。
In the case where an L2TP tunnel is indicated, the NAS will now bring up a control connection if none existed before, and the NAS and tunnel server will bring up the call. At this point, data MAY begin to flow through the tunnel. The client and tunnel server MAY now renegotiate LCP and go through another round of PPP authentication. At the time that this renegotiation begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP negotiation, and the client and NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP CONFACK, the NAS will instead send an LCP Configure-Request packet, described in [6]. The Client MAY then renegotiate LCP, and from that point forward, all PPP packets originated from the client will be encapsulated and sent to the tunnel server. When LCP re-negotiation has been concluded, the NCP phase will begin, and the tunnel server will assign an address to the client.
L2TPトンネルが示されている場合、NASは以前に存在しなかった場合、NASとトンネルサーバーがコールを引き上げます。この時点で、データがトンネルを流れ始める可能性があります。クライアントとトンネルサーバーは、LCPを再交渉し、PPP認証の別のラウンドを通過できるようになりました。この再交渉が開始されたとき、NASはLCPの交渉を完了するLCP雑誌を送信すべきではなく、クライアントとNASはNCPの交渉を開始してはなりません。NASは、LCPの混乱を送信するのではなく、[6]に記載されているLCP Configure-Requestパケットを送信します。クライアントはLCPを再交渉する場合があり、その時点から、クライアントから発信されたすべてのPPPパケットがカプセル化され、トンネルサーバーに送信されます。LCPの再交渉が終了すると、NCPフェーズが開始され、トンネルサーバーがクライアントにアドレスを割り当てます。
If L2TP is being used as the tunnel protocol, the NAS MAY in its initial setup notification include a copy of the LCP CONFACKs sent in each direction which completed LCP negotiation. The tunnel server MAY then use this information to avoid an additional LCP negotiation. With L2TP, the initial setup notification can also include the authentication information required to allow the tunnel server to authenticate the user and decide to accept or decline the connection. However, this facility creates a vulnerability to replay attacks, and can create problems in the case where the NAS and tunnel server authenticate against different RADIUS servers. As a result, where user-based tunneling via RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be employed.
L2TPがトンネルプロトコルとして使用されている場合、NASは最初のセットアップ通知に、LCP交渉を完了した各方向に送信されたLCP混乱のコピーが含まれる場合があります。トンネルサーバーは、この情報を使用して、追加のLCP交渉を避けることができます。L2TPを使用すると、最初のセットアップ通知には、トンネルサーバーがユーザーを認証し、接続を受け入れるか拒否することを決定するために必要な認証情報を含めることもできます。ただし、この施設は、攻撃を再生する脆弱性を生み出し、NASとトンネルサーバーが異なるRADIUSサーバーに対して認証される場合に問題を引き起こす可能性があります。その結果、RADIUS経由のユーザーベースのトンネルが実装されている場合、L2TP認証転送は採用されてはなりません。
In performing the PPP authentication, the tunnel server can access its own user database, or it MAY send a RADIUS Access-Request. After the tunnel has been brought up, the NAS and tunnel server can start accounting.
PPP認証を実行する際に、Tunnel Serverは独自のユーザーデータベースにアクセスするか、RADIUS Access-Requestを送信する場合があります。トンネルが育てられた後、NASとトンネルサーバーは会計を開始できます。
The interactions involved in initiation of a compulsory tunnel with dual authentication are summarized below.
デュアル認証を使用した強制トンネルの開始に伴う相互作用を以下にまとめます。
INITIATION SEQUENCE
開始シーケンス
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
PPP authentication
phase starts
Send RADIUS
Access-Request
with userID and
authentication data
IF authentication
succeeds
Send ACK
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send Incoming-Call-Request message to Tunnel Server Send Incoming-Call-Reply to NAS Send Incoming-Call-Connected message to Tunnel Server
トンネルサーバーに着信コールリクエストメッセージを送信
Send data through the tunnel Re-negotiate LCP, authenticate user, bring up IPCP, start accounting ENDIF
トンネルを介してデータを送信し、LCPを再交渉し、ユーザーを認証し、IPCPを育て、アカウンティングENDIFを開始します
The tear down of a compulsory tunnel involves an interaction between the client, NAS and Tunnel Server. This interaction is virtually identical regardless of whether telephone-number based authentication, single authentication, or dual authentication is being used. In any of the cases, the following events occur:
強制トンネルの解体には、クライアント、NAS、トンネルサーバー間の相互作用が含まれます。この相互作用は、電話番号ベースの認証、単一認証、またはデュアル認証が使用されているかどうかに関係なく、実質的に同一です。いずれの場合でも、次のイベントが発生します。
Tunnel Server to NAS: L2TP Call-Clear-Request (optional) NAS to Tunnel Server: L2TP Call-Disconnect-Notify
トンネルサーバーからNASへ：L2TP Call-Clear-Request（オプション）NASからトンネルサーバー：L2TP Call-Disconnect-Notify
Tunnel termination can occur due to a client request (PPP termination), a tunnel server request (Call-Clear-Request), or a line problem (call disconnect).
クライアントリクエスト（PPP終了）、トンネルサーバー要求（コールクレアリクエスト）、または行の問題（コール切断）により、トンネル終了が発生する可能性があります。
In the case of a client-requested termination, the tunnel server MUST terminate the PPP session. The tunnel server MUST subsequently send a Call-Clear-Request to the NAS. The NAS MUST then send a Call-Disconnect-Notify message to the tunnel server, and will disconnect the call.
クライアントが要求した終了の場合、トンネルサーバーはPPPセッションを終了する必要があります。トンネルサーバーは、その後、NASにコールクリアレクエストを送信する必要があります。NASは、Call-Disconnect-NotifyメッセージをTunnel Serverに送信する必要があり、呼び出しを切断する必要があります。
The NAS MUST also respond with a Call-Disconnect-Notify message and disconnection if it receives a Call-Clear-Request from the tunnel server without a client-requested termination.
また、NASは、クライアントが要求されていない終了なしにトンネルサーバーからコールクリアレクエストを受信した場合、コールディスコンコネクトノティイのメッセージと切断で応答する必要があります。
In the case of a line problem or user hangup, the NAS MUST send a Call-Disconnect-Notify to the tunnel server. Both sides will then tear down the call.
ラインの問題またはユーザーのハングアップの場合、NASはトンネルサーバーにcall-disconnect-notifyを送信する必要があります。その後、双方がコールを取り壊します。
The interactions involved in termination of a compulsory tunnel are summarized below. In order to simplify the diagram that follows, we have left out the client. However, it is understood that the client MAY participate via PPP termination and disconnection.
強制トンネルの終了に伴う相互作用を以下にまとめます。次の図を簡素化するために、クライアントを除外しました。ただし、クライアントはPPP終了と切断を介して参加できることが理解されています。
TERMINATION SEQUENCE
終了シーケンス
NAS Tunnel Server RADIUS Server
--- ------------- -------------
IF user disconnected
send
Call-Disconnect-Notify
message to tunnel server
Tear down the call
stop accounting
ELSE IF client requests
termination
send
Call-Clear-Request
to the NAS
Send
Call-Disconnect-Notify
message to tunnel server
Disconnect the user
Tear down the call
stop accounting
ENDIF
In the case that the NAS and the tunnel server are using distinct RADIUS servers, some interesting cases can arise in the provisioning of compulsory tunnels.
NASとトンネルサーバーが異なるRADIUSサーバーを使用している場合、強制トンネルのプロビジョニングでいくつかの興味深いケースが発生する可能性があります。
If distinct RADIUS servers are being used, it is likely that distinct userID/password pairs will be required to complete the RADIUS and tunnel authentications. One pair will be used in the initial PPP authentication with the NAS, and the second pair will be used for authentication at the tunnel server.
個別の半径サーバーが使用されている場合、RADIUSとトンネル認証を完了するには、個別のユーザーID/パスワードペアが必要になる可能性があります。1つのペアは、NASとの最初のPPP認証で使用され、2番目のペアはトンネルサーバーでの認証に使用されます。
This has implications if the NAS attempts to forward authentication information to the tunnel server in the initial setup notification. Since the userID/password pair used for tunnel authentication is different from that used to authenticate against the NAS, forwarding authentication information in this manner will cause the tunnel authentication to fail. As a result, where user-based tunneling via RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be employed.
これは、NASが最初のセットアップ通知でトンネルサーバーに認証情報を転送しようとする場合に意味があります。トンネル認証に使用されるユーザーID/パスワードペアは、NASに対する認証に使用されるものとは異なるため、この方法で認証情報を転送すると、トンネル認証が失敗します。その結果、RADIUS経由のユーザーベースのトンネルが実装されている場合、L2TP認証転送は採用されてはなりません。
In order to provide maximum ease of use in the case where the userID/password pairs are identical, tunnel clients typically attempt authentication with the same userID/password pair as was used in the initial PPP negotiation. Only after this fails do they prompt the user for the second pair. Rather than putting up an error message indicating an authentication failure, it is preferable to present a dialog requesting the tunnel userID/password combination.
ユーザーID/パスワードのペアが同一の場合に最大限の使いやすさを提供するために、トンネルクライアントは通常、最初のPPPネゴシエーションで使用されたのと同じユーザーID/パスワードペアで認証を試みます。これが失敗した後にのみ、2番目のペアのユーザーに促します。認証障害を示すエラーメッセージを表示するよりも、トンネルユーザーID/パスワードの組み合わせを要求するダイアログを提示することが望ましいです。
A similar issue arises when extended authentication methods are being used, as is enabled by EAP, described in [5]. In particular, when one-time passwords or cryptographic calculators are being used, different passwords will be used for the first and second authentications. Thus the user will need to be prompted to enter the second password.
[5]で説明されているEAPによって有効になっているように、拡張認証方法が使用されている場合、同様の問題が発生します。特に、1回限りのパスワードまたは暗号化計算機が使用されている場合、1回目と2回目の認証には異なるパスワードが使用されます。したがって、ユーザーは2番目のパスワードを入力するように求められる必要があります。
It is possible for the two RADIUS servers to return different Port-Limit attributes. For example, it is conceivable that the NAS RADIUS server will only grant use of a single channel, while the tunnel RADIUS server will grant more than one channel. In this case, the correct behavior is for the tunnel client to open a connection to another NAS in order to bring up a multilink bundle on the tunnel server. The client MUST NOT indicate to the NAS that this additional link is being brought up as part of a multilink bundle; this will only be indicated in the subsequent negotiation with the tunnel server.
2つのRADIUSサーバーが異なるポートリミット属性を返すことができます。たとえば、NAS Radiusサーバーは単一のチャネルの使用のみを許可し、トンネルRadiusサーバーは複数のチャネルを付与すると考えられます。この場合、正しい動作は、トンネルクライアントがトンネルサーバーにマルチリンクバンドルを表示するために別のNASへの接続を開くことです。クライアントは、この追加リンクがマルチリンクバンドルの一部として育てられていることをNASに示してはなりません。これは、トンネルサーバーとのその後の交渉でのみ示されます。
It is also conceivable that the NAS RADIUS server will allow the client to bring up multiple channels, but that the tunnel RADIUS server will allow fewer channels than the NAS RADIUS server. In this case, the client should terminate use of the excess channels.
また、NAS Radiusサーバーがクライアントが複数のチャネルを持ち出すことを可能にするが、Tunnel RadiusサーバーはNAS Radiusサーバーよりも少ないチャネルを許可すると考えられます。この場合、クライアントは過剰なチャネルの使用を終了する必要があります。
In the provisioning of roaming and shared use networks, one of the requirements is to be able to route the authentication request to the user's home RADIUS server. This authentication routing is accomplished based on the userID submitted by the user to the NAS in the initial PPP authentication. The userID is subsequently relayed by the NAS to the RADIUS server in the User-Name attribute, as part of the RADIUS Access-Request.
ローミングと共有使用ネットワークのプロビジョニングでは、要件の1つは、認証要求をユーザーのHome Radiusサーバーにルーティングできるようにすることです。この認証ルーティングは、最初のPPP認証でユーザーがNASに提出したユーザーIDに基づいて実現されます。その後、UserIDは、RADIUS Access-Requestの一部として、NASによってUser-Name属性のRADIUSサーバーに中継されます。
Similarly, [2] refers to use of the userID in determining the tunnel endpoint, although it does not provide guidelines for how RADIUS or tunnel routing is to be accomplished. Thus the possibility of conflicting interpretations exists.
同様に、[2]は、トンネルエンドポイントの決定においてユーザーIDの使用を指しますが、半径またはトンネルルーティングの達成方法に関するガイドラインは提供していません。したがって、矛盾する解釈の可能性が存在します。
The use of RADIUS in provisioning of compulsory tunneling relieves the userID from having to do double duty. Rather than being used both for routing of the RADIUS authentication/authorization request as well for determination of the tunnel endpoint, the userID is now used solely for routing of RADIUS authentication/authorization requests. Tunnel attributes returned in the RADIUS Access-Response are then used to determine the tunnel endpoint.
強制トンネリングのプロビジョニングにおける半径の使用は、ユーザーIDが二重の義務を果たさなければならないことから解放されます。RADIUS認証/認証要求のルーティングの両方を使用するのではなく、トンネルエンドポイントの決定にも同様に、UserIDはRADIUS認証/認証要求のルーティングのみに使用されます。次に、RADIUSアクセス応答で返されるトンネル属性を使用して、トンネルエンドポイントを決定します。
Since the framework described in this document allows both ISPs and tunnel users to authenticate users as well as to account for resources consumed by them, and provides for maintenance of two distinct userID/password pairs, this scheme provides a high degree of flexibility. Where RADIUS proxies and tunneling are employed, it is possible to allow the user to authenticate with a single userID/password pair at both the NAS and the tunnel endpoint. This is accomplished by routing the NAS RADIUS Access-Request to the same RADIUS server used by the tunnel server.
このドキュメントで説明されているフレームワークでは、ISPとトンネルユーザーの両方がユーザーを認証するだけでなく、ユーザーが消費するリソースを考慮し、2つの異なるユーザーID/パスワードペアのメンテナンスを提供できるため、このスキームは高度な柔軟性を提供します。RADIUSプロキシとトンネリングが採用されている場合、NASとトンネルエンドポイントの両方で、ユーザーが単一のユーザーID/パスワードペアで認証できるようにすることができます。これは、NAS RADIUS Access-Requestをトンネルサーバーで使用する同じRADIUSサーバーにルーティングすることで実現されます。
[1] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[1] Rigney C.、Rubens A.、Simpson W.およびS. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and Palter, B., "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[2] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。and Palter、B。、「L2TP ""、RFC 2661、1999年8月。
[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", Work in Progress.
[3] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。and Goyret、I。、「トンネルプロトコルサポートの半径属性」、進行中の作業。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Blunk, L. anf J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[5] Blunk、L。およびJ. Vollbrecht、「PPP拡張可能な認証プロトコル（EAP）」、RFC 2284、1998年3月。
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[6] シンプソン、W。、編集者、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
In PPP-based tunneling, PPP security is negotiated between the client and the tunnel server, and covers the entire length of the path. This is because the client does not have a way to know that they are being tunneled. Thus, any security the NAS may negotiate with the tunnel server will occur in addition to that negotiated between the client and NAS.
PPPベースのトンネルでは、PPPセキュリティがクライアントサーバーとトンネルサーバーの間でネゴシエートされ、パスの全長をカバーします。これは、クライアントがトンネルに登録されていることを知る方法がないためです。したがって、NASがクライアントとNASの間で交渉したものに加えて、トンネルサーバーと交渉する可能性のあるセキュリティが発生します。
In L2TP compulsory tunneling, this means that PPP encryption and compression will be negotiated between the client and the tunnel server. In addition, the NAS may bring up an IPSEC security association between itself and the tunnel server. This adds protection against a number of possible attacks.
L2TP強制トンネリングでは、これはPPP暗号化と圧縮がクライアントとトンネルサーバーの間でネゴシエートされることを意味します。さらに、NASは、それ自体とトンネルサーバーとの間にIPSECセキュリティ関連を提出する場合があります。これにより、多くの可能な攻撃に対する保護が追加されます。
Where RADIUS proxies are deployed, the Access-Reply sent by the RADIUS server may be processed by one or more proxies prior to being received by the NAS. In order to ensure that tunnel attributes arrive without modification, intermediate RADIUS proxies forwarding the Access-Reply MUST NOT modify tunnel attributes. If the RADIUS proxy does not support tunnel attributes, then it MUST send an Access-Reject to the NAS. This is necessary to ensure that the user is only granted access if the services requested by the RADIUS server can be provided.
RADIUSプロキシが展開される場合、RADIUSサーバーから送信されるアクセス応答は、NASが受信する前に1つ以上のプロキシによって処理される場合があります。トンネルの属性が変更なしで到着するようにするために、中間半径プロキシはアクセス対応を転送してはならないトンネル属性を変更してはなりません。RADIUSプロキシがトンネル属性をサポートしていない場合、NASにアクセス拒否を送信する必要があります。これは、RADIUSサーバーから要求されたサービスを提供できる場合にのみ、ユーザーがアクセスを許可されることを確認するために必要です。
Since RADIUS tunnel attributes are used for compulsory tunneling, address assignment is handled by the tunnel server rather than the NAS. As a result, if tunnel attributes are present, the NAS MUST ignore any address assignment attributes sent by the RADIUS server. In addition, the NAS and client MUST NOT begin NCP negotiation, since this could create a time window in which the client will be capable of sending packets to the transport network, which is not permitted in compulsory tunneling.
Radiusトンネル属性は強制トンネリングに使用されるため、アドレスの割り当てはNASではなくトンネルサーバーによって処理されます。その結果、トンネル属性が存在する場合、NASはRADIUSサーバーによって送信されたアドレス割り当て属性を無視する必要があります。さらに、NASとクライアントはNCPの交渉を開始してはなりません。これにより、クライアントがパケットをトランスポートネットワークに送信できる時間ウィンドウが作成される可能性があるため、強制トンネルでは許可されていません。
Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions of this problem space, and to Allan Rubens of Tut Systems and Bertrand Buclin of AT&T Labs Europe for their comments on this document.
この問題スペースについて多くの有用な議論をしてくれたMicrosoftのGurdeep Singh Pall、およびTUT SystemsのAllan RubensとAT＆T Labs EuropeのBertrand Buclinに感謝します。
Most of the work on this document was performed while Glen Zorn was employed by the Microsoft Corporation.
このドキュメントの作業のほとんどは、グレンゾーンがMicrosoft Corporationに採用されている間に実行されました。
The RADIUS Working Group can be contacted via the current chair:
RADIUSワーキンググループは、現在の椅子から連絡できます。
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
カール・リグニー・リビングストン・エンタープライズ4464ウィロー・ロード・プレザントン、カリフォルニア94588
Phone: +1 510-426-0770
EMail: cdr@livingston.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: +1 425-936-6605
EMail: bernarda@microsoft.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 USA
Glen Zorn Cisco Systems、Inc。500 108th Avenue N.E.、Suite 500 Bellevue、WA 98004 USA
Phone: +1 425 438 8218
FAX: +1 425 438 1848
EMail: gwz@cisco.com
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実践するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待します。情報をIETFエグゼクティブディレクターに宛ててください。
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。