Network Working Group B. Aboba
Request for Comments: 2809 Microsoft
Category: Informational G. Zorn
Cisco
April 2000
Implementation of L2TP Compulsory Tunneling via RADIUS
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プロトコルを使用してダイヤルアップネットワークに強制的トンネリングのプロビジョニングに生じる実装上の問題について説明します。このプロビジョニングは、RADIUSおよびトンネリングプロトコルの統合を介して達成することができます。他のトンネリングプロトコルに遭遇した実装上の問題は、別の文書に残されています。
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].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[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が広く展開されており、この種の情報を運ぶために設計されていたので、それは、中央で強制的トンネリングを管理するためにRADIUSを使用する意味があります。新しい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デバイスの献身が必要です。それはむしろ、彼らはフィールドで展開、既存のNASを使用することを可能にするよりも、特定の顧客に対するサービスをトンネリングするためにNASを捧げるためにそれらを必要とするため、ISPの場合、これは望ましくありません。その結果、静的なトンネリングは、グローバルなサービスを展開するためのコストがかかる可能性があります。
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は、営業部門にあるトンネルネットワーク・サーバによって提供さフレッドのイントラネットにアクセスして、イントラネットへのアクセスのみを提供したアカウントでフレッドを提供することを望むかもしれません。そのような状況は、領域ベースのトンネリングで収容することができないが、[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認証を含む、利用可能です。
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（トークン）認証。そして、両方の認証のために同じ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認証を必要とせずに、認証されたトンネル内で発生するすべてのコールを受け入れるように設定することができます。トンネルサーバは、典型的には、唯一のNASの制限されたセットからトンネルを受け入れるように設定されるので、このアプローチは、ローミングと互換性がありません。典型的な開始配列は次のようになります。
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
クライアントとNAS：RADIUSサーバへのPPP認証NAS：PPP LCPネゴシエーションクライアントとNAS：接続クライアントとNASを呼び出しNASへのRADIUSアクセス要求のRADIUSサーバ：RADIUSアクセス - 受け入れ/トンネルサーバにNASをアクセス拒否：L2TP着信L2TP着信-返信NASトンネルサーバへ：L2TP着信接続クライアントとトンネルサーバー：NCPのネゴシエーションNASへ/ LCP転送トンネルサーバワット-request
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は、RADIUSサーバにRADIUSアクセス要求を送信すると、RADIUSトンネル属性、またはアクセス拒否を含め、接続許可を受け取ることになります。
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とトンネルサーバーがコールをもたらします。この時点で、データがトンネルを通って流れ始めます。トンネルサーバは、LCPを再交渉することも可能であるが、NASは、典型的には、LCP転送を採用します。 LCPの再ネゴシエーションを許可する場合、NASは、LCPネゴシエーションを完了LCPのCONFACKを送るべきではありません。むしろLCP CONFACKを送信するよりも、NASは、代わりに[6]に記載のLCP設定要求パケットを送信します。カプセル化され、トンネルサーバーに送信されます次に、クライアントは、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に1回発生し、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.
このアプローチでは、トンネルサーバは、すべてのNASと関連したRADIUSサーバと秘密を共有し、トンネルサーバにより、LCP再ネゴシエーションのための規定はありません。また、トンネルサーバは、RADIUSアクセス受諾メッセージを処理し、検証する方法を知っておく必要があります。
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:
この方式では、認証と認可がトンネルサーバに1回発生します。これは、NASは、ユーザが（RADIUSまたはNAS構成を通して）トンネリングされる必要があることを決定することを必要とします。 RADIUSを使用する場合、決意は、次のいずれかの方法を用いて作製することができます。
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着信-Requestパケットに含まダイヤル番号に基づいてコールを拒否するか、受け入れることを選ぶかもしれません。会計も呼び出し-駅-IDと呼ばれ-駅-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.
で定義されているRADIUSは、[1]のAccess-Requestパケットは、ユーザー名が非空である必要がありますCHAP-パスワードまたはユーザー・パスワード属性、どちらかだけでなく、属性を含んでいることが必要です。この要件を満たすために呼び出さ-駅-IDまたは呼び出し-駅-IDは、User-Name属性で装飾することができ、ダミーの値は、ユーザーのパスワードやCHAP-Password属性に使用されるかもしれません。
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
クライアントとNS：サーバーをRADIUSに接続されているNASを呼び出す：NASへのRADIUSアクセス要求のRADIUSサーバ：RADIUSアクセス - 受け入れ/トンネルサーバにNASをアクセス拒否：L2TP着信リクエストのトンネルサーバーNASへ：L2TP着信-返信トンネルサーバーへのNAS：L2TP着信接続クライアントとトンネルサーバー：PPP LCPネゴシエーションクライアントとトンネルサーバー：PPP認証トンネルサーバーRADIUSサーバへ：RADIUSアクセス要求（オプション）RADIUSサーバトンネルサーバーへ：RADIUS /アクセスは、受け入れNCP交渉：クライアントとトンネルサーバーへのアクセス拒否
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.
プロセスは、NASへの着信コールで始まります。電話番号ベースの認証用に設定した場合、NASは、通話-駅-IDを含むRADIUSアクセス要求を送信し、呼び出され-駅-ID属性。 RADIUSサーバは、RADIUSアクセス - 受け入れまたはアクセス拒否で応答します。
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アクセス拒否送信します。この場合、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アクセス - 受け入れ、およびL2TPトンネルが示されているに含まれている場合に、NASは、現在の制御接続をもたらします。これは、トンネルサーバにL2TPスタートコントロール接続要求メッセージを送信することによって達成されます。トンネルサーバは、L2TPスタートコントロール接続返信で返信させていただきます。このメッセージはエラーを示し、または制御接続は、任意の将来の時間で終了した場合、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は、トンネルサーバにL2TP着信-Requestメッセージを送信します。とりわけ、このメッセージが一緒にNAS-IP-Addressとトンネル - サーバー - エンドポイントを一意にコールを識別するために使用されるコールのシリアル番号を、含まれています。トンネルサーバは、L2TP着信応答メッセージで応答します。このメッセージがエラーを示す場合、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.
この時点で、データがトンネルを通って流れ始めることができます。 LCPネゴシエーションがNASとクライアントの間で始まっていた場合には、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 CONFACKを送ってはいけません、そして、クライアントとNASは、NCPのネゴシエーションを開始してはなりません。むしろLCP CONFACKを送信するよりも、NASは、代わりに[6]に記載のLCP設定要求パケットを送信します。カプセル化され、トンネルサーバーに送信されます次に、クライアントは、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 MAYは、LCPネゴシエーションを完了し、各方向で送信されるLCPのCONFACKsのコピーを含みます。トンネルサーバは、追加のLCPのネゴシエーションを避けるために、この情報を使用することができます。 L2TPを使用すると、初期設定の通知は、トンネルサーバがユーザを認証し、接続を受け入れるか拒否するかを決定できるようにするために必要な認証情報を含めることができます。しかし、電話番号に基づく認証では、PPP認証前トンネルをもたらすNASに発生してはいけません。その結果、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認証を行う際に、トンネルサーバは、自身のユーザデータベースにアクセスすることができ、または代替的にRADIUSアクセス要求を送信することができます。後者のアプローチは、ローミングまたは共用ネットワークと同様に認証転送が有効になっている場合に有用です。この場合、RADIUSトンネルサーバーは、同じ管理下にあり、典型的には、おそらく同じLAN上に、互いに近接して配置されています。 RADIUSクライアントは、統一されたユーザ管理を提供するように、したがって、トンネルサーバー作用を有します。トンネルサーバのRADIUSアクセス - 要求は、典型的には、むしろ、プロキシを介して転送されるよりも、ローカル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
着信-返信NASには、トンネルサーバへの着信接続メッセージを送るSendトンネルサーバーへの着信-Requestメッセージを送信
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でのユーザ認証の前に行われなければなりません。結果として、このスキームは、典型的には、RADIUSサーバ上のユーザIDや属性特定処理のドメイン部分のいずれかを使用します。ユーザーのアイデンティティがNASによって検証されることはありませんので、所有者は、このような呼び出し-駅-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.
属性特定処理にRADIUSを使用することができる属性は、トンネルの開始を通知するために使用されます。ユーザーパスワード属性が（例えば「トンネル」または「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.
別の解決策は、ユーザーIDのドメイン部分を使用することを含みます。ドメイン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経由で身元を確認していなかったことから、トンネルサーバへの認証にユーザーによって要求されたアイデンティティを使用する必要があります。しかし、それは会計のいずれかの使用であるためには、トンネルエンドポイントは、NASの所有者のアカウントの関係を持っている必要があります。トンネルのエンドポイントにもNASの所有者とのビジネス関係を持っていない限り、このようにユーザーがNASの所有者のアカウントを持っている場合でも、彼らはトンネリングのため、このアカウントを使用することはできません。したがって、このアプローチは、ローミングと互換性がありません。
A typical initiation sequence involving use of the domain portion of the userID looks like this:
ユーザーIDのドメイン部分の使用を伴う典型的な開始配列は次のようになります。
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
クライアントとNAS：トンネルサーバへの認証NAS：PPP LCPネゴシエーションクライアントとNAS：接続されたクライアントとNASを呼び出しL2TP着信リクエストのトンネルサーバーNASへ：L2TP着信-返信NASトンネルサーバへ：L2TP着信-Call- RADIUSサーバへのPPP認証トンネルサーバー：PPP LCP再ネゴシエーションクライアントとトンネルサーバー：クライアントとトンネルサーバーを接続したRADIUSアクセス要求（オプション）RADIUSサーバトンネルサーバへ：RADIUSアクセス - 受け入れ/アクセス拒否クライアントとトンネルサーバー： NCPのネゴシエーション
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ネゴシエーションを開始します。認証プロセスは、開始され、どれも前に存在しなかった場合は、ユーザーIDのドメイン部分に基づいて、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のCONFACK、およびクライアントに送信してはいけませんし、NASは、NCPのネゴシエーションを開始してはなりません。むしろLCP CONFACKを送信するよりも、NASは、代わりに[6]に記載のLCP設定要求パケットを送信します。カプセル化され、トンネルサーバーに送信されます次に、クライアントは、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認証を行うには、トンネルサーバは、独自のユーザーデータベースにアクセスすることができ、またはそれは、RADIUSアクセス要求を送信することができます。トンネルが育ててきた後、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
着信-返信NASには、トンネルサーバへの着信接続メッセージを送るSendトンネルサーバーへの着信-Requestメッセージを送信
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とトンネルサーバの両方で起こります。これは、付随するLCPの再交渉で、二重の認証を処理するために、ダイヤルアップクライアントが必要です。 NASやトンネルネットワーク・サーバが同じデータベースに対して認証できるようにするために、これはトンネルネットワークサーバ、およびおそらくNAS側のRADIUSプロキシの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
RADIUSサーバへのPPP認証NAS：クライアントとNAS：PPP LCPネゴシエーションクライアントとNAS NASへのRADIUSアクセス要求のRADIUSサーバ：RADIUSアクセス - 受け入れ/トンネルサーバにNASをアクセス拒否：L2TP着信リクエストのトンネルサーバーNASへ：トンネルサーバーへのL2TP着信-返信NAS：L2TP着信接続クライアントとトンネルサーバー：PPP LCPは再交渉（オプション）クライアントとトンネルサーバー：PPP認証トンネルサーバーRADIUSサーバへ：RADIUSアクセス要求（オプショントンネルサーバーへの）RADIUSサーバ：RADIUSアクセス - 受け入れ/アクセス拒否クライアントとトンネルサーバー：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サーバにRADIUS Access-Requestメッセージを送信します。認証に成功すると、RADIUSサーバは、RADIUSアクセス - 受け入れトンネル属性を含むで応答します。
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 CONFACK完了LCPネゴシエーションを送ってはいけません、そして、クライアントとNASは、NCPのネゴシエーションを開始してはなりません。むしろLCP CONFACKを送信するよりも、NASは、代わりに[6]に記載のLCP設定要求パケットを送信します。カプセル化され、トンネルサーバーに送信されます次に、クライアントは、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 MAYは、LCPネゴシエーションを完了し、各方向で送信されるLCPのCONFACKsのコピーを含みます。トンネルサーバは、追加の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認証を行うには、トンネルサーバは、独自のユーザーデータベースにアクセスすることができ、またはそれは、RADIUSアクセス要求を送信することができます。トンネルが育ててきた後、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
着信-返信NASには、トンネルサーバへの着信接続メッセージを送るSendトンネルサーバーへの着信-Requestメッセージを送信
Send data through the tunnel Re-negotiate LCP, authenticate user, bring up IPCP, start accounting ENDIF
会計ENDIFを開始し、ユーザーを認証し、LCPを再交渉するトンネルを介してデータを送信するIPCPを持ち出します
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
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は、トンネルサーバへのコールを切断-通知メッセージを送らなければなりませんし、コールを切断します。
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はまた、クライアントが要求終了せずにトンネルサーバからコール・クリア-Requestを受信した場合、メッセージと切断をコール外し-通知で応じなければなりません。
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は、トンネルサーバにコール切断は、通知送らなければなりません。双方は、その呼を切断します。
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 /パスワードのペアは、RADIUSトンネル認証を完了するために必要とされる可能性があります。一組は、NASとの初期PPP認証に使用され、第二の対は、トンネルサーバーでの認証のために使用されます。
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 /パスワードのペアを用いて認証を試みます。これは、彼らが第二の対のためにユーザを促し行う失敗した後にのみ。むしろ、認証失敗を示すエラーメッセージを置くよりも、トンネルのユーザー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によってイネーブルされるように、使用されている場合、同様の問題が生じます。特に、ワンタイムパスワードや暗号計算が使用されている場合、異なるパスワードが第一および第二の認証のために使用されるであろう。したがって、ユーザは、第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サーバが異なるポート制限の属性を返すことが可能です。例えば、トンネルRADIUSサーバが複数のチャネルを付与する一方NAS 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サーバは、クライアントが複数のチャンネルを立ち上げることを可能にすることも考えられるが、トンネル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.
ローミングと共用ネットワークのプロビジョニングでは、必要条件の一つは、ルートにユーザのホームRADIUSサーバに認証要求できるようにすることです。この認証ルーティングは、初期PPP認証でNASにユーザーが提出したユーザIDに基づいて行われます。ユーザーIDは、その後、RADIUSアクセス要求の一部として、User-Name属性でRADIUSサーバにNASによって中継されます。
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]、それはRADIUSまたはトンネルルーティングを達成する方法についての指針を提供していないが、トンネルエンドポイントを決定する際にユーザ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.
強制的トンネリングのプロビジョニングでRADIUSを使用することは、二重の義務を行う必要性からユーザーIDを解放します。トンネルエンドポイントの決意のためにもRADIUS認証/許可要求のルーティングのための両方に使用されるのではなく、ユーザーIDについてのみ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 /パスワードのペアを使用して認証できるようにすることが可能です。これは、トンネルサーバによって使用される同一のRADIUSサーバへのNAS 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.、ルーベンスA.、シンプソンW.及びS. Willens、RFC 2138、1997年4月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[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.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、G.およびPalter、B.、 "レイヤ2トンネリングプロトコル "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]ゾルン、G.、Leifer、D.、ルーベンス、A.、シュライバー、J.、ホールドレッジ、M.及びGoyretを、I.、進行中の作業 "RADIUSは、トンネルプロトコルサポートのための属性"。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Blunk, L. anf J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[5]ブルンク、L. J. ANF 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サーバによって送信されたAccess-返信前NASによって受信される1つのまたは複数のプロキシによって処理されてもよいです。属性は変更せずに到着するトンネルを確実にするために、アクセス・リプライを転送する中間RADIUSプロキシは、トンネル属性を変更してはいけません。 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.
この問題空間の多くの有用な議論のための、およびツタンカーメンシステムのアランルーベンスとAT＆T LabsのヨーロッパのベルトランBuclinに、この文書に彼らのコメントのためのMicrosoftのガーディープ・シンポールに感謝します。
Most of the work on this document was performed while Glen Zorn was employed by the Microsoft Corporation.
グレンツォルンは、Microsoft社が採用している間に、このドキュメントの作業のほとんどを行いました。
The RADIUS Working Group can be contacted via the current chair:
RADIUSワーキンググループは、現在のいすを介して接触させることができます。
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
カールRigneyリビングストン企業4464ウィロー・ロードプレザントン、カリフォルニア94588
Phone: +1 510-426-0770 EMail: cdr@livingston.com
電話：+1 510-426-0770電子メール：cdr@livingston.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
Phone: +1 425-936-6605 EMail: bernarda@microsoft.com
電話：+1 425-936-6605電子メール：bernarda@microsoft.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 USA
グレンツォルンシスコシステムズ社500第108アベニューN.E.、スイート500ワシントン州ベルビュー98004 USA
Phone: +1 425 438 8218 FAX: +1 425 438 1848 EMail: gwz@cisco.com
電話：+1 425 438 8218 FAX：+1 425 438 1848 Eメール：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.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。