RFC2809 日本語訳
2809 Implementation of L2TP Compulsory Tunneling via RADIUS. B. Aboba,G. Zorn. April 2000. (Format: TXT=47259 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba
Request for Comments: 2809 Microsoft
Category: Informational G. Zorn
Cisco
April 2000
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 2809年のマイクロソフトカテゴリ: 情報のG.ゾルンコクチマス2000年4月
Implementation of L2TP Compulsory Tunneling via RADIUS
RADIUSを通したL2TPコンパルソリーTunnelingの実装
Status of this Memo
この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.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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の統合で達成されて、プロトコルにトンネルを堀ることであることができます。 他のトンネリングプロトコルで遭遇する導入問題がドキュメントを切り離すのが残されます。
1. Terminology
1. 用語
Voluntary Tunneling
In voluntary tunneling, a tunnel is created by the user,
typically via use of a tunneling client.
自発的のTunneling In自発的のトンネリング、トンネルはそうです。通常トンネリングクライアントの使用でユーザによって作成されます。
Compulsory Tunneling
In compulsory tunneling, a tunnel is created without any
action from the user and without allowing the user any
choice.
強制的なTunneling In強制的なトンネリング、トンネルはユーザからのどんな動作なしでもどんな選択もユーザに許すことなしで作成されます。
Tunnel Network Server
This is a server which terminates a tunnel. In L2TP
terminology, this is known as the L2TP Network Server
(LNS).
トンネルNetwork Server Thisはトンネルを終えるサーバです。 L2TP用語で、これはL2TP Network Server(LNS)として知られています。
Aboba & Zorn Informational [Page 1] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[1ページ]RFC2809L2TPコンパルソリーTunneling
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).
ネットワークAccess Server Network Access Server(NAS)はクライアントがネットワークに近づく手段を得るために連絡するデバイスです。 L2TP用語で、強制的なトンネリングを実行するNASはL2TP Access Concentrator(LAC)と呼ばれます。
RADIUS authentication server
This is a server which provides for
authentication/authorization via the protocol described in
[1].
RADIUS認証サーバThisは[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プロキシIn注文を使うことができます。 NASにおいて、RADIUSプロキシは、RADIUSサーバとして機能するように見えます、そして、プロキシはRADIUSクライアントとして機能するようにRADIUSサーバに、見えます。 分野ベースのトンネリングが使用されているとき、トンネル終点の場所を見つけるのに使用できます。
2. Requirements language
2. 要件言語
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [4].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[4]で説明されるように解釈されることになっていてください、」であるべきです
3. Introduction
3. 序論
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
しかしながら、強制的なトンネリングの広範囲のサポートの存在を考えて、どんなインターネット接続サービス業者(ISP)でもこれらのタイプのサービスにアクセスできるでしょう。 RADIUSプロトコルを通して今日ダイヤルをネットワーク利用者に認可する最もポピュラーな手段があります。 RADIUSの使用はダイアルアップユーザーの承認と認証を許します。
Aboba & Zorn Informational [Page 2] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[2ページ]RFC2809L2TPコンパルソリーTunneling
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].
各NASに関してというよりむしろ中心の位置で保守されるデータ。 それは中心で強制的なトンネリングを管理するのにRADIUSを使用する意味になります、RADIUSが広く配布されて、この情報の種類を運ぶように設計されたので。 新しいRADIUS属性が、RADIUSサーバからNASまでトンネリング情報を運ぶのに必要です。 それらの属性は[3]で定義されます。
3.1. Advantages of RADIUS-based compulsory tunneling
3.1. RADIUSベースの強制的なトンネリングの利点
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.
トンネル要求のルーティングのための現在の提案は静的なトンネリングを含んでいます、すべてのユーザが自動的に与えられた終点、および分野ベースのトンネリングにトンネルを堀られるところで、トンネル終点がuserIDの分野の部分から断固としているところで。 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の場合では、彼らがその分野で配布された既存のNASesを使用するのを許容するより与えられた顧客のためにむしろトンネリングサービスに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は、イントラネットへのアクセスだけを提供するアカウントをフレッドに提供することを望むかもしれません、営業部に位置するトンネルネットワークサーバでフレッドのイントラネットアクセスを提供していて。 そのような状況を分野ベースのトンネリングで設備することができませんが、[3]で定義された属性によって可能にされるようにユーザベースのトンネリングで収容できます。
4. Authentication alternatives
4. 認証代替手段
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認証を含んでいて、多くのモードが利用可能です。
Aboba & Zorn Informational [Page 3] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[3ページ]RFC2809L2TPコンパルソリーTunneling
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.
代替手段はさらに詳細に以下で説明されます。
4.1. Single authentication
4.1. ただ一つの認証
Single authentication alternatives include:
ただ一つの認証代替手段は:
NAS authentication NAS authentication with RADIUS reply forwarding Tunnel server authentication
RADIUS回答推進Tunnelサーバ証明によるNAS認証NAS認証
4.1.1. NAS authentication
4.1.1. 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に一度起こります。 このアプローチの利点は権限のない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だけ認証はLCP推進とトンネル認証と共に最も通常使われます。その両方が[2]で説明されたL2TPでサポートされます。 したがって、認証されたトンネルの中にPPP認証を必要としないで起こるすべての呼び出しを受け入れるためにトンネルサーバをセットアップできます。 しかしながら、このアプローチはローミングと互換性がありません、トンネルサーバがNASesの制限されたセットからトンネルを受け入れるために通常セットアップされるだけであるので。 典型的な開始系列はこれに似ています:
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: 接続クライアントとNASに電話をしてください: PPP LCP交渉のClientとNAS: RADIUS ServerへのPPP認証NAS: NASへのRADIUS Access-要求RADIUSサーバ: 半径は、トンネルサーバへのNASをアクセスして受け入れるか、またはアクセスして拒絶します: NASへのL2TP Incomingが、LCPと共に要求と呼んでいる推進Tunnel Server: トンネルサーバへのL2TP入って来る呼び出し回答NAS: L2TP入って来る接続完了クライアントとトンネルサーバ: NCP交渉
Aboba & Zorn Informational [Page 4] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[4ページ]RFC2809L2TPコンパルソリーTunneling
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 Access-要求をRADIUSサーバに送って、RADIUS Access受け入れている含んでいるトンネル属性、またはAccess-廃棄物を受けるでしょう。
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 renegotiationが受入れられるつもりであるなら、NAS SHOULD NOTはLCP CONFACKにLCP交渉を終了させます。 LCP CONFACKを送るよりむしろ、NASは代わりに[6]で説明されたLCP Configure-リクエスト・パケットを送るでしょう。 Clientを前方に、すべてのPPPパケットがクライアントから溯源したそのポイントからトンネルサーバに次に、LCPを再交渉するかもしれなくて、カプセル化して、送るでしょう。
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 MUST NOTはNCP交渉を始めます。 代わりに、NCP交渉はクライアントとトンネルサーバの間に起こるでしょう。
4.1.2. NAS authentication with RADIUS reply forwarding
4.1.2. RADIUS回答推進によるNAS認証
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 Access-回答をチェックできる唯一の方法であることで。
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.
このアプローチでは、トンネルサーバはすべてのNASesと関連RADIUSサーバと秘密を共有するでしょう、そして、トンネルサーバによるLCP renegotiationへの支給が全くありません。また、トンネルサーバは、どのようにRADIUS Access受け入れているメッセージについて扱って、確かめるかを知る必要があるでしょう。
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サーバよりむしろクライアントとプロキシによって共有された秘密を使用することで認証されるでしょう、したがって。その結果、この体系は非実用的です。
Aboba & Zorn Informational [Page 5] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[5ページ]RFC2809L2TPコンパルソリーTunneling
4.1.2.1. Tunnel server authentication
4.1.2.1. トンネルサーバ証明
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が、ユーザが、トンネルを堀られる(RADIUSかNAS構成を通して)必要を決定するのを必要とすると、起こります。 RADIUSが使用されているところでは、以下のメソッドの1つを使用することで決断をすることができます:
Telephone-number based authentication UserID
電話番号は認証UserIDを基礎づけました。
4.1.2.2. Telephone-number based authentication
4.1.2.2. 電話番号は認証を基礎づけました。
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.
Calling駅のイドとCalled駅のイドRADIUS属性、承認、およびその後のトンネル属性を使用するのは呼び出しを溯源する電話番号、または電話をされる数に基づくことができます。 これで、RADIUSサーバは、呼ぶ電話番号に基づくユーザに権限を与えるか、またはCalling駅イドかCalled駅のアイダホ州に基づくトンネル属性を提供します。 同様に、L2TPでは、トンネルサーバは、NASによって送られたL2TP Incoming呼び出しリクエスト・パケットでDialed Numberに基づいていて、Dialing Numberを含めて、呼び出しを拒絶するか、または受け入れるのを選ぶかもしれません。 また、会計はCalling駅のイドとCalled駅のアイダホ州に基づいて行われることができます。
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は、Access-リクエスト・パケットがCHAP-パスワードかUser-パスワード属性のどちらかと同様にUser-名前属性を含むのを必要とします。属性は非空であるに違いありません。 この要件を満たすために、Called駅のイドかCalling駅のイドがUser-名前属性で提供されるかもしれません、そして、ダミーの値はUser-パスワードかCHAP-パスワード属性に使用されるかもしれません。
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
クライアントとナノ秒: 接続NASを半径サーバに電話をしてください: NASへのRADIUS Access-要求RADIUSサーバ: 半径は、トンネルサーバへのNASをアクセスして受け入れるか、またはアクセスして拒絶します: NASへのL2TP入って来る発呼要求トンネルサーバ: トンネルサーバへのL2TP入って来る呼び出し回答NAS: L2TP入って来る接続完了クライアントとトンネルサーバ: PPP LCP交渉のClientとTunnel Server: RADIUS ServerへのPPP認証Tunnel Server: Tunnel ServerへのRADIUS Access-要求の(任意)のRADIUSサーバ: 半径は、クライアントとトンネルサーバをアクセスして受け入れるか、またはアクセスして拒絶します: NCP交渉
Aboba & Zorn Informational [Page 6] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[6ページ]RFC2809L2TPコンパルソリーTunneling
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はCalling駅のイドとCalled駅イド属性を含むRADIUS Access-要求を送ります。 次に、サーバがaがRADIUS Access受け入れていた状態で反応するか、またはAccess拒絶する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 MUST NOTはPPP認証を始めます。 タイミングが可能にするなら、同輩とのLCP交渉を始める前に、NAS MAYはトンネルを持って来ます。 これが完了していると、同輩とトンネルサーバの間で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-廃棄物を送ります。 この場合NAS MUSTが発信する、ユーザを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 Access受け入れて、L2TPトンネルに含まれているケースは示されて、なにも以前存在しなかったなら、NASは現在、コントロール接続を育てるでしょう。 これは、L2TP Startコントロール接続要求メッセージをトンネルサーバに送ることによって、達成されます。次に、トンネルサーバはL2TP Startコントロール接続回答で返答するでしょう。 このメッセージが誤りを示すか、またはコントロール接続が将来の何時でも終えられるならNAS MUSTが発信する、ユーザを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 Incoming呼び出し要求メッセージをトンネルサーバに送るでしょう。特に、このメッセージはCall Serial Numberを含むでしょう。(Call Serial Numberは、唯一呼び出しを特定するのにNAS IPアドレスとTunnelサーバ終点と共に使用されます)。 トンネルサーバはL2TP Incoming呼び出し応答メッセージで返答するでしょう。 このメッセージが誤りを示すならNAS MUSTが発信する、ユーザをLCP終えて、切断してください。 誤りが全く示されないなら、NASはL2TP Incoming呼び出しが接続しているメッセージで返答します。
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
再交渉が再交渉が始まる時に必要であるなら、NAS SHOULD NOTはLCP CONFACKにLCP交渉を終了させました、そして、クライアントとNAS MUST NOTはNCP交渉を始めました。 LCP CONFACKを送るよりむしろ、NASは代わりに[6]で説明されたLCP Configure-要求Packetを送るでしょう。 前方に、すべてのPPPパケットがクライアントから溯源したそのポイントからClientに次に、LCPを再交渉するかもしれなくて、カプセル化されて、発信するでしょう。
Aboba & Zorn Informational [Page 7] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[7ページ]RFC2809L2TPコンパルソリーTunneling
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.
. いつ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 renegotiationが必要であるなら、初期のセットアップ通知における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 Access要求を送ることができます。 後者のアプローチは認証推進がローミングなどのように可能にされるか、または共有される使用がネットワークでつなぐ場合で役に立ちます。 この場合、RADIUSとトンネルサーバは、同じ管理の下にあって、近くに通常一緒に位置しています、ことによると同じLANで。 したがって、RADIUSクライアントとしてトンネルサーバ条例を持っていると、統一されたユーザ管理は備えられます。 トンネルサーバのRADIUS Access-要求がプロキシを通して進めるよりむしろ直接ローカルの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.
電話番号に基づいている認証による強制的なトンネルの開始にかかわる相互作用は以下へまとめられます。 従うダイヤグラムを簡素化するために、私たちはクライアントを省きました。 しかしながら、クライアントがTunnel ServerとのPPP交渉、認証、および順次データ置き換えで参加するのが理解されています。
Aboba & Zorn Informational [Page 8] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[8ページ]RFC2809L2TPコンパルソリーTunneling
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
NASトンネルサーバ半径サーバ--- ------------- ------------- Called駅のイドとの接続Send RADIUS Access-要求に電話をしてください、そして、Send StartがTunnel Server Send Startコントロール接続回答に接続要求を制御していた状態で、認証がSend ACK ELSE Send NAK IF NAK DISCONNECT ELSE IFノー、を引き継ぐならLCPが始めるCalling駅のイドコントロール接続はNAS ENDIFに存在しています。
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Tunnel ServerへのNAS Send Incoming呼び出しが接続しているメッセージに関するTunnel Server Send Incoming呼び出し回答にIncoming呼び出し要求メッセージを送ってください。
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting
Re交渉しているトンネルLCPを通してデータを送ってください、そして、ユーザを認証してください、そして、IPCPを持って来てください、そして、説明し始めてください。
Aboba & Zorn Informational [Page 9] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[9ページ]RFC2809L2TPコンパルソリーTunneling
4.1.2.3. User-Name
4.1.2.3. ユーザ名
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サーバでuserIDのドメイン部分か属性特有の処理のどちらかを通常使用します。ユーザアイデンティティがNASによって決して確かめられないで、トンネルサーバ所有者が、すべてのかかってきた電話のために請求されても構わないと思っているに違いありませんか、または会計目的のためにユーザのアイデンティティについて確かめるのにCalling駅のイドなどの他の情報を使用しなければなりません。
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は使われるかもしれません、そして、属性は、トンネル開始に合図するのに使用されます。 例えば、User-パスワード属性がダミーの値(「トンネル」か"L2TP"などの)を含んでいるなら、トンネル属性を返送できます。 あるいはまた、トンネルを開始する必要性を示すのに特殊文字('*')で始まるuserIDは使用できました。 属性特有の処理が使用されているとき、トンネルサーバは、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.を扱うためにトンネルを堀られるでしょう。This提案は、強制的なトンネリングをサポートしますが、ユーザベースのトンネリングに備えません。
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:
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
クライアントとNAS: 接続クライアントとNASに電話をしてください: PPP LCP交渉のClientとNAS: トンネルサーバへの認証NAS: NASへのL2TP入って来る発呼要求トンネルサーバ: トンネルサーバへのL2TP入って来る呼び出し回答NAS: L2TP入って来る接続完了クライアントとトンネルサーバ: PPP LCP再交渉のClientとTunnel Server: RADIUS ServerへのPPP認証Tunnel Server: Tunnel ServerへのRADIUS Access-要求の(任意)のRADIUSサーバ: 半径は、クライアントとトンネルサーバをアクセスして受け入れるか、またはアクセスして拒絶します: NCP交渉
Aboba & Zorn Informational [Page 10] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[10ページ]RFC2809L2TPコンパルソリーTunneling
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へのかかってきた電話、およびClientと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 SHOULD NOTはLCP CONFACKにLCP交渉を終了させました、そして、クライアントとNAS MUST NOTはNCP交渉を始めました。 LCP CONFACKを送るよりむしろ、NASは代わりに[6]で説明されたLCP Configure-リクエスト・パケットを送るでしょう。 Clientを前方に、すべてのPPPパケットがクライアントから溯源したそのポイントからトンネルサーバに次に、LCPを再交渉するかもしれなくて、カプセル化して、送るでしょう。ただ一つの認証強制的なトンネリングでは、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 Access-要求を送るかもしれません。 トンネルが持って来られた後に、NASとトンネルサーバは、説明し始めることができます。
Aboba & Zorn Informational [Page 11] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[11ページ]RFC2809L2TPコンパルソリーTunneling
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
NASトンネルサーバ半径サーバ--- ------------- ------------- Send Startが接続回答をNAS ENDIFに制御していた状態でどんなコントロール接続も存在していないならSend Startが接続要求をTunnel Server ENDIFに制御していた状態でどんなコントロール接続も存在しないなら、着呼受付LCPはAuthenticationフェーズ始めを始めます。
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Tunnel ServerへのNAS Send Incoming呼び出しが接続しているメッセージに関するTunnel Server Send Incoming呼び出し回答にIncoming呼び出し要求メッセージを送ってください。
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting
Re交渉しているトンネルLCPを通してデータを送ってください、そして、ユーザを認証してください、そして、IPCPを持って来てください、そして、説明し始めてください。
4.2. Dual authentication
4.2. 二元的な認証
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を許容して、同じデータベースに対して認証するネットワークサーバにトンネルを堀るために、これは、トンネルネットワークサーバでRADIUSクライアント能力を必要として、NASエンドでことによるとRADIUSプロキシを必要とします。
Aboba & Zorn Informational [Page 12] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[12ページ]RFC2809L2TPコンパルソリーTunneling
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の実装を通したただ一つのuserID/パスワード組の使用。 電話番号のためのどんな要件も認証、または属性特有の処理を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交渉のClientとNAS: RADIUS ServerへのPPP認証NAS: NASへのRADIUS Access-要求RADIUSサーバ: 半径は、トンネルサーバへのNASをアクセスして受け入れるか、またはアクセスして拒絶します: NASへのL2TP入って来る発呼要求トンネルサーバ: トンネルサーバへのL2TP入って来る呼び出し回答NAS: L2TP入って来る接続完了クライアントとトンネルサーバ: PPP LCP再交渉(任意の)のクライアントとTunnel Server: RADIUS ServerへのPPP認証Tunnel Server: Tunnel ServerへのRADIUS Access-要求の(任意)の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 Access-要求メッセージをRADIUSサーバに送ります。認証がうまくいくなら、サーバがRADIUS Access受け入れている含有で反応させる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
L2TPトンネルが示される場合では、なにも以前存在しなかったなら、NASは現在、コントロール接続を育てて、NASとトンネルサーバは呼び出しを持って来るでしょう。 ここに、データはトンネルを通って流れ始めるかもしれません。 クライアントとトンネルサーバは、今、LCPを再交渉して、PPP認証の別のラウンドに直面するかもしれません。 この再交渉が始まる時に、NAS SHOULD NOTはそうしました。
Aboba & Zorn Informational [Page 13] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[13ページ]RFC2809L2TPコンパルソリーTunneling
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.
LCP交渉、クライアント、およびNAS MUST NOTを終了して、LCP CONFACKを送って、始まっているNCP交渉を持ってください。 LCP CONFACKを送るよりむしろ、NASは代わりに[6]で説明されたLCP Configure-リクエスト・パケットを送るでしょう。 Clientを前方に、すべてのPPPパケットがクライアントから溯源したそのポイントからトンネルサーバに次に、LCPを再交渉するかもしれなくて、カプセル化して、送るでしょう。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サーバを認証する場合で問題を生じさせることができます。 結果として、使われてください。そこでは、L2TP認証がSHOULD NOTを進めて、RADIUSを通したユーザベースのトンネリングが実装されます。
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 Access-要求を送るかもしれません。 トンネルが持って来られた後に、NASとトンネルサーバは、説明し始めることができます。
The interactions involved in initiation of a compulsory tunnel with dual authentication are summarized below.
二元的な認証による強制的なトンネルの開始にかかわる相互作用は以下へまとめられます。
Aboba & Zorn Informational [Page 14] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[14ページ]RFC2809L2TPコンパルソリーTunneling
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
NASトンネルサーバ半径サーバ--- ------------- ------------- PPP認証フェーズが始める着呼受付LCP始めは、userIDと認証データで認証がSend ACK ELSE Send NAK IF NAK DISCONNECT ELSE IFを引き継ぐならSend StartがTunnel Server Send Startコントロール接続回答に接続要求を制御していた状態でどんなコントロール接続もNAS ENDIFに存在しないようSend RADIUS Access要求します。
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Tunnel ServerへのNAS Send Incoming呼び出しが接続しているメッセージに関するTunnel Server Send Incoming呼び出し回答にIncoming呼び出し要求メッセージを送ってください。
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting
ENDIF
Re交渉しているトンネルLCPを通してデータを送ってください、そして、ユーザを認証してください、そして、IPCPを持って来てください、そして、ENDIFを説明し始めてください。
Aboba & Zorn Informational [Page 15] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[15ページ]RFC2809L2TPコンパルソリーTunneling
5. Termination sequence
5. 終止配列
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との相互作用にかかわります。電話番号が認証を基礎づけたかどうかにかかわらずこの相互作用は実際には同じです、ただ一つの認証、または、二元的な認証が使用されています。 場合のどれかでは、以下のイベントは起こります:
Tunnel Server to NAS: L2TP Call-Clear-Request (optional)
NAS to Tunnel Server: L2TP Call-Disconnect-Notify
NASにサーバにトンネルを堀ってください: トンネルサーバへのL2TPの呼び出しの明確な要求の(任意)のNAS: 分離が通知するL2TP呼び出し
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セッションを終えなければなりません。 トンネルサーバは次に、Callの明確な要求をNASに送らなければなりません。 次に、NAS MUSTはトンネルサーバへの分離して通知しているメッセージをCallに送ります、そして、呼び出しから切断するでしょう。
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.
また、トンネルサーバからクライアントによって要求された終了なしでCallの明確な要求を受け取るなら、NAS MUSTはCall分離に通知しているメッセージと断線で応じます。
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 MUSTは分離が通知するCallをトンネルサーバに送ります。次に、両側は呼び出しを取りこわすでしょう。
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終了と断線で参加するかもしれないのが理解されています。
Aboba & Zorn Informational [Page 16] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[16ページ]RFC2809L2TPコンパルソリーTunneling
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
NASトンネルサーバ半径サーバ--- ------------- ------------- ユーザが切断したなら、終了が呼び出し停止会計ENDIFでトンネルを堀るNAS Send Call分離に通知しているメッセージへのCallの明確な要求サーバDisconnectにユーザTearを送るという呼び出し停止会計ELSE IFクライアント要求でCall分離に通知しているメッセージをトンネルサーバTearに送ってください。
6. Use of distinct RADIUS servers
6. 異なったRADIUSサーバの使用
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サーバを使用していて、いくつかのおもしろいケースが強制的なトンネルの食糧を供給することで起こることができます。
6.1. Distinct userIDs
6.1. 異なったユーザID
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サーバが使用されていると、異なったuserID/パスワード組はRADIUSとトンネル認証を終了しそうになければならないでしょう。 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が、初期のセットアップ通知におけるトンネルサーバに認証情報を転送するのを試みるなら、意味があります。 トンネル認証に使用されるuserID/パスワード組がそれとNASに対して認証するのにおいて使用されていた状態で異なっているので、推進認証情報はこの様にトンネル認証に失敗されるでしょう。 結果として、使われてください。そこでは、L2TP認証がSHOULD NOTを進めて、RADIUSを通したユーザベースのトンネリングが実装されます。
Aboba & Zorn Informational [Page 17] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[17ページ]RFC2809L2TPコンパルソリーTunneling
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.
userID/パスワード組が同じであるケースの中に最大の使いやすさを供給するために、トンネルクライアントは初期のPPP交渉に使用されたのと同じuserID/パスワード組と共に認証を通常試みます。 これが失敗した後にだけ彼らは2番目の組のためにユーザをうながします。 認証失敗を示すエラーメッセージを提供するよりむしろ、トンネルuserID/パスワード組み合わせを要求する対話を提示するのは望ましいです。
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番目と2番目の認証に使用されるでしょう。 したがって、ユーザは、2番目のパスワードを入力するようにうながされる必要があるでしょう。
6.2. Multilink PPP issues
6.2. マルチリンクPPP問題
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サーバが異なったPort限界属性を返すのは、可能です。 例えば、NAS RADIUSサーバが単独のチャンネルの使用を承諾するだけであるのが想像できます、トンネルRADIUSサーバは1個以上のチャンネルを与えるでしょうが。 この場合、正しい振舞いはトンネルクライアントがトンネルサーバでマルチリンクバンドルを持って来るために別の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サーバより少ないチャンネルを許容するのが想像できます。この場合、クライアントは余分なチャンネルの使用を終えるべきです。
7. UserID Issues
7. ユーザID問題
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つはネットワークであり、ユーザのホームRADIUSサーバに認証要求を発送することであることができます。ローミングと共有された使用の食糧を供給することでは、ユーザによって初期のPPP認証でNASに提出されたuserIDに基づいてこの認証ルーティングは達成されます。 userIDは次にNASによってUser-名前属性におけるRADIUSサーバにリレーされます、RADIUS Access-要求の一部として。
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.
どのようにRADIUSかトンネルのためのガイドラインを提供しませんが、ルーティングは同様に、[2]がトンネル終点を決定することにおけるuserIDの使用について言及して、優れることです。 したがって、闘争解釈の可能性は存在しています。
Aboba & Zorn Informational [Page 18] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[18ページ]RFC2809L2TPコンパルソリーTunneling
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の使用は、二つの任務を果たさなければならないので、userIDを救います。 むしろ、userIDは現在、唯一RADIUS認証/承認要求のルーティングにともにトンネル終点の決断を求めるまた、RADIUS認証/承認要求のルーティングに使用されるより使用されます。 そして、RADIUS Access-応答で返されたトンネル属性は、トンネル終点を決定するのに使用されます。
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異なったuserID/パスワード組のメインテナンスに備えるので、この体系は高度合いの柔軟性を提供します。 RADIUSプロキシとトンネリングが採用しているところでは、ユーザがNASとトンネル終点の両方のただ一つのuserID/パスワード組と共に認証するのを許容するのにおいてそれは可能です。 これは同じRADIUSサーバへのNAS RADIUS Access-要求がトンネルサーバで使用したルーティングで達成されます。
8. References
8. 参照
[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.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(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] w.Townsley、バレンシア、A.、ルーベン(A.)は気がぬけます、G.、ゾルン、G.、あしらってください、B.、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、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] I.、「トンネルプロトコルサポートのための半径属性」というゾルン、G.、ライファー、D.、ルーベン、A.、シュライバー、J.、Holdrege、M.、およびGoyretは進行中で働いています。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Blunk, L. anf J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
1998年のL.anf J.Vollbrecht、「ppp拡張認証プロトコル(EAP)」、RFC2284行進の[5]Blunk。
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[6] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
Aboba & Zorn Informational [Page 19] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[19ページ]RFC2809L2TPコンパルソリーTunneling
9. Security Considerations
9. セキュリティ問題
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プロキシが配布されるところでは、NASによって受け取られる前に、RADIUSサーバによって送られたAccess-回答は1つ以上のプロキシによって処理されるかもしれません。 トンネル属性が変更なしで到着するのを確実にするために、Access-回答を進める中間的RADIUSプロキシはトンネル属性を変更してはいけません。 RADIUSプロキシがトンネル属性をサポートしないなら、それはAccess-廃棄物を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 MUSTはRADIUSサーバによって送られたどんなアドレス課題属性も無視します。さらに、NASとクライアントはNCP交渉を始めてはいけません、これが転送ネットワーク(強制的なトンネリングで受入れられない)にクライアントができる送付パケットのタイムウィンドウを作成するかもしれないので。
10. Acknowledgements
10. 承認
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.
このドキュメントの彼らのコメントをこの問題スペースの多くの役に立つ議論のためのマイクロソフトのGurdeepシンPallと、そして、ツタンカーメンSystemsのアラン・ルーベンスとAT&T LabsヨーロッパのバートランドBuclinをありがとうございます。
Most of the work on this document was performed while Glen Zorn was employed by the Microsoft Corporation.
マイクロソフト社はGlenゾルンを雇いましたが、このドキュメントへの作業の大部分をしました。
Aboba & Zorn Informational [Page 20] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[20ページ]RFC2809L2TPコンパルソリーTunneling
11. Chair's Address
11. 議長のアドレス
The RADIUS Working Group can be contacted via the current chair:
現在のいすを通してRADIUS作業部会に連絡できます:
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
Roadプレザントン、カールRigneyリビングストンエンタープライズ4464Willowカリフォルニア 94588
Phone: +1 510-426-0770 EMail: cdr@livingston.com
以下に電話をしてください。 +1 510-426-0770 メールしてください: cdr@livingston.com
12. Authors' Addresses
12. 作者のアドレス
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
谷間ゾルンシスコシステムズInc.500第108アベニューの東北、Suite500ベルビュー、ワシントン98004米国
Phone: +1 425 438 8218 FAX: +1 425 438 1848 EMail: gwz@cisco.com
以下に電話をしてください。 +1 425 438、8218Fax: +1 1848年の425 438メール: gwz@cisco.com
Aboba & Zorn Informational [Page 21] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[21ページ]RFC2809L2TPコンパルソリーTunneling
13. Intellectual Property Statement
13. 知的所有権声明
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。
Aboba & Zorn Informational [Page 22] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
RADIUS2000年4月を通したAbobaとゾルンInformational[22ページ]RFC2809L2TPコンパルソリーTunneling
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Aboba & Zorn Informational [Page 23]
AbobaとゾルンInformationalです。[23ページ]
一覧
スポンサーリンク
