[要約] RFC 2888は、L2TPを使用した安全なリモートアクセスに関するガイドラインです。その目的は、セキュアなリモートアクセスの実装と運用に関するベストプラクティスを提供することです。
Network Working Group P. Srisuresh
Request for Comments: 2888 Campio Communications
Category: Informational August 2000
Secure Remote Access with L2TP
L2TPを使用してリモートアクセスを保護します
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
L2TP protocol is a virtual extension of PPP across IP network infrastructure. L2TP makes possible for an access concentrator (LAC) to be near remote clients, while allowing PPP termination server (LNS) to be located in enterprise premises. L2TP allows an enterprise to retain control of RADIUS data base, which is used to control Authentication, Authorization and Accountability (AAA) of dial-in users. The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This is accomplished without creating new protocols and using the existing practices of Remote Access and IPsec. Specifically, the document proposes three new RADIUS parameters for use by the LNS node, acting as Secure Remote Access Server (SRAS) to mandate network level security between remote clients and the enterprise. The document also discusses limitations of the approach.
L2TPプロトコルは、IPネットワークインフラストラクチャ全体のPPPの仮想拡張です。L2TPは、Access Concenconator（LAC）がリモートクライアントに近いことを可能にし、PPP終了サーバー（LNS）をエンタープライズ施設に配置できるようにします。L2TPを使用すると、エンタープライズは、ダイヤルインユーザーの認証、承認、および説明責任（AAA）を制御するために使用されるRADIUSデータベースの制御を維持できます。このドキュメントの目的は、インターネットを介してダイヤルインする際に、IPSECのセキュリティ特性をリモートアクセスユーザーに拡張することです。これは、新しいプロトコルを作成せず、リモートアクセスとIPSECの既存のプラクティスを使用せずに達成されます。具体的には、このドキュメントは、LNSノードで使用する3つの新しいRADIUSパラメーターを提案し、安全なリモートアクセスサーバー（SRA）として機能して、リモートクライアントとエンタープライズ間のネットワークレベルのセキュリティを義務付けています。ドキュメントでは、アプローチの制限についても説明します。
Now-a-days, it is common practice for employees to dial-in to their enterprise over the PSTN (Public Switched Telephone Network) and perform day-to-day operations just as they would if they were in corporate premises. This includes people who dial-in from their home and road warriors, who cannot be at the corporate premises. As the Internet has become ubiquitous, it is appealing to dial-in through the Internet to save on phone charges and save the dedicated voice lines from being clogged with data traffic.
現在、従業員がPSTN（公共の切り替えた電話ネットワーク）を介して企業にダイヤルインし、企業の施設にいる場合と同じように日常業務を実行することは一般的な慣行です。これには、自宅やロードウォリアーズからのダイヤルインが含まれます。インターネットがユビキタスになったため、電話料金を節約し、データトラフィックで詰まっているのを防ぐために、インターネットを介してダイヤルインすることが魅力的です。
The document suggests an approach by which remote access over the Internet could become a reality. The approach is founded on the well-known techniques and protocols already in place. Remote Access extensions based on L2TP, when combined with the security offered by IPSec can make remote access over the Internet a reality. The approach does not require inventing new protocol(s).
このドキュメントは、インターネット上のリモートアクセスが現実になるアプローチを提案しています。このアプローチは、すでに有名な手法とプロトコルに基づいています。L2TPに基づいたリモートアクセス拡張機能は、IPSECが提供するセキュリティと組み合わせると、インターネット経由のリモートアクセスを実現できます。このアプローチでは、新しいプロトコルを発明する必要はありません。
The trust model of remote access discussed in this document is viewed principally from the perspective of an enterprise into which remote access clients dial-in. A remote access client may or may not want to enforce end-to-end IPsec from his/her end to the enterprise. However, it is in the interest of the enterprise to mandate security of every packet that it accepts from the Internet into the enterprise. Independently, remote users may also pursue end-to-end IPsec, if they choose to do so. That would be in addition to the security requirement imposed by the enterprise edge device.
このドキュメントで議論されているリモートアクセスの信頼モデルは、主にリモートアクセスクライアントがダイヤルインする企業の観点から見られます。リモートアクセスクライアントは、エンドツーエンドのIPSECを自分のエンタープライズからエンタープライズまで実施したい場合としない場合があります。ただし、インターネットから企業に受け入れるすべてのパケットのセキュリティを義務付けるのは企業の利益です。独立して、リモートユーザーがそうすることを選択した場合、リモートユーザーはエンドツーエンドのIPSECを追求することもできます。これは、Enterprise Edgeデバイスによって課されるセキュリティ要件に追加されます。
Section 2 has reference to the terminology used throughout the document. Also mentioned are the limited scope in which some of these terms may be used in this document. Section 3 has a brief description of what constitutes remote access. Section 4 describes what constitutes network security from an enterprise perspective. Section 5 describes the model of secure remote access as a viable solution to enterprises. The solution presented in section 5 has some limitations. These limitations are listed in section 6. Section 7 is devoted to describing new RADIUS attributes that may be configured to turn a NAS device into Secure Remote Access Server.
セクション2は、ドキュメント全体で使用される用語を参照しています。また、これらの用語のいくつかをこのドキュメントで使用できる限られた範囲についても述べています。セクション3には、リモートアクセスを構成するものの簡単な説明があります。セクション4では、エンタープライズの観点からネットワークセキュリティを構成するものについて説明します。セクション5では、安全なリモートアクセスのモデルについて、企業に対する実行可能なソリューションとして説明しています。セクション5に示されているソリューションには、いくつかの制限があります。これらの制限は、セクション6にリストされています。セクション7は、NASデバイスを安全なリモートアクセスサーバーに変えるように構成される可能性のある新しいRADIUS属性を説明することに専念しています。
Definition of terms used in this document may be found in one of (a) L2TP Protocol document [Ref 1], (b) IP security Architecture document [Ref 5], or (c) Internet Key Exchange (IKE) document [Ref 8].
このドキュメントで使用される用語の定義は、（a）L2TPプロトコルドキュメント[Ref 1]、（b）IPセキュリティアーキテクチャドキュメント[参照5]、または（c）インターネットキーエクスチェンジ（IKE）ドキュメント[Ref 8のいずれかのいずれかに記載されている場合があります。]。
Note, the terms Network Access Server (NAS) and Remote Access Server(RAS) are used interchangeably throughout the document. While PPP may be used to carry a variety of network layer packets, the focus of this document is limited to carrying IP datagrams only.
注目すべきは、Network Access Server（NAS）とリモートアクセスサーバー（RAS）という用語がドキュメント全体で同じ意味で使用されています。PPPはさまざまなネットワークレイヤーパケットを運ぶために使用できますが、このドキュメントの焦点はIPデータグラムのみを運ぶことに限定されます。
"Secure Remote Access Server" (SRAS) defined in this document refers to a NAS that supports tunnel-mode IPsec with its remote clients. Specifically, LNS is the NAS that is referred. Further, involuntary tunneling is assumed for L2TP tunnel setup, in that remote clients initiating PPP session and the LAC that tunnels the PPP sessions are presumed to be distinct physical entities.
このドキュメントで定義されている「Secure Remote Access Server」（SRAS）は、リモートクライアントとトンネルモードIPSECをサポートするNASを指します。具体的には、LNSは参照されるNASです。さらに、L2TPトンネルのセットアップでは、PPPセッションを開始するリモートクライアントでは、PPPセッションのトンネルが明確な物理エンティティであると推定されるという不随意トンネルが想定されています。
Lastly, there are a variety of transport mediums by which to tunnel PPP packets between a LAC and LNS. Examples include Frame Relay or ATM cloud and IP network infrastructure. For simplicity, the document assumes a public IP infrastructure as the medium to transport PPP packets between LAC and LNS. Security of IP packets (embedded within PPP) in a trusted private transport medium is less of a concern for the purposes of this document.
最後に、LACとLNSの間にPPPパケットをトンネルするためのさまざまな輸送媒体があります。例には、フレームリレーまたはATMクラウドおよびIPネットワークインフラストラクチャが含まれます。簡単にするために、このドキュメントは、LACとLNSの間でPPPパケットを輸送する媒体としてパブリックIPインフラストラクチャを想定しています。信頼できるプライベート輸送媒体におけるIPパケット（PPP内に埋め込まれた）のセキュリティは、このドキュメントの目的ではあまり懸念事項ではありません。
Remote access is more than mere authentication of remote clients by a Network Access Server(NAS). Authentication, Authorization, Accounting and routing are integral to remote access. A client must first pass the authentication test before being granted link access to the network. Network level services (such as IP) are granted based on the authorization characteristics specified for the user in RADIUS. Network Access Servers use RADIUS to scale for large numbers of users supported. NAS also monitors the link status of the remote access clients.
リモートアクセスは、ネットワークアクセスサーバー（NAS）によるリモートクライアントの単なる認証以上のものです。認証、承認、会計、ルーティングは、リモートアクセスに不可欠です。クライアントは、ネットワークへのリンクアクセスが付与される前に、最初に認証テストに合格する必要があります。ネットワークレベルサービス（IPなど）は、RADIUSのユーザーに指定された承認特性に基づいて付与されます。ネットワークアクセスサーバーは、サポートされている多数のユーザーのためにRADIUSを使用してスケーリングします。NASは、リモートアクセスクライアントのリンクステータスも監視しています。
There are a variety of techniques by which remote access users are connected to their enterprise and the Internet. At a link level, the access techniques include ISDN digital lines, analog plain-old-telephone-service lines, xDSL lines, cable and wireless to name a few. PPP is the most common Layer-2 (L2)protocol used for carrying network layer packets over these remote access links. PPP may be used to carry a variety of network layer datagrams including IP, IPX and AppleTalk. The focus of this document is however limited to IP datagrams only.
リモートアクセスユーザーが企業とインターネットに接続されているさまざまな手法があります。リンクレベルでは、アクセス技術には、ISDNデジタルライン、アナログプレーンテレフォンサービスライン、XDSLライン、ケーブル、ワイヤレスが含まれます。PPPは、これらのリモートアクセスリンクにネットワークレイヤーパケットを運ぶために使用される最も一般的なレイヤー2（L2）プロトコルです。PPPは、IP、IPX、AppleTalkなど、さまざまなネットワークレイヤーデータグラムを運ぶために使用できます。ただし、このドキュメントの焦点は、IPデータグラムのみに限定されています。
L2TP is a logical extension of PPP over an IP infrastructure. While a LAC provides termination of Layer 2 links, LNS provides the logical termination of PPP. As a result, LNS becomes the focal point for (a) performing the AAA operations for the remote users, (b) assigning IP address and monitoring the logical link status (i.e., the status of LAC-to-LNS tunnel and the link between remote user and LAC), and (c) maintaining host-route to remote user network and providing routing infrastructure into the enterprise.
L2TPは、IPインフラストラクチャ上のPPPの論理的拡張です。LACはレイヤー2リンクの終了を提供しますが、LNSはPPPの論理終了を提供します。その結果、LNSは（a）リモートユーザーのAAA操作を実行し、（b）IPアドレスの割り当てと論理リンクステータスの監視（つまり、LAC対LNSトンネルのステータスとリンクの監視の焦点となります。リモートユーザーとLAC）、および（c）ホストROUTEをリモートユーザーネットワークに維持し、エンタープライズにルーティングインフラストラクチャを提供します。
L2TP uses control messages to establish, terminate and monitor the status of the logical PPP sessions (from remote user to LNS). These are independent of the data messages. L2TP data messages contain an L2TP header, followed by PPP packets. The L2TP header identifies the PPP session (amongst other things) to which the PPP packet belongs. The IP packets exchanged from/to the remote user are carried within the PPP packets. The L2TP data messages, carrying end-to-end IP packets in an IP transport medium may be described as follows. The exact details of L2TP protocol may be found in [Ref 1].
L2TPは、制御メッセージを使用して、論理PPPセッションのステータスを確立、終了、監視します（リモートユーザーからLNSまで）。これらはデータメッセージに依存しません。L2TPデータメッセージには、L2TPヘッダーが含まれ、その後PPPパケットが含まれます。L2TPヘッダーは、PPPパケットが属するPPPセッション（とりわけ）を識別します。リモートユーザーから交換されたIPパケットは、PPPパケット内で運ばれます。IP輸送媒体にエンドツーエンドのIPパケットを運ぶL2TPデータメッセージについては、次のように説明できます。L2TPプロトコルの正確な詳細は[Ref 1]に記載されている場合があります。
+----------------------+
| IP Header |
| (LAC <->LNS) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (Remote User<->LNS) |
+----------------------+
| End-to-end IP packet |
| (to/from Remote User)|
+----------------------+
Today's enterprises are aware of the various benefits of connecting to the Internet. Internet is a vast source of Information and a means to disseminate information and make available certain resources to the external world. However, enterprises are also aware that security breaches (by being connected to the Internet) can severely jeopardize internal network.
今日の企業は、インターネットに接続することのさまざまな利点を認識しています。インターネットは膨大な情報源であり、情報を広め、特定のリソースを外部世界に利用できるようにする手段です。ただし、企業は、セキュリティ侵害が（インターネットに接続されることにより）内部ネットワークを著しく危険にさらす可能性があることを認識しています。
As a result, most enterprises restrict access to a pre-defined set of resources for external users. Typically, enterprises employ a firewall to restrict access to internal resources and place externally accessible servers in the DeMilitarized Zone (DMZ), in front of the firewall, as described below in Figure 1.
その結果、ほとんどの企業は、外部ユーザー向けの事前定義されたリソースセットへのアクセスを制限します。通常、企業はファイアウォールを使用して内部リソースへのアクセスを制限し、図1に記載されているように、ファイアウォールの前に非武装ゾーン（DMZ）に外部アクセス可能なサーバーを配置します。
----------------
( )
( )
( Internet )
( )
(_______________ )
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
---------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server |
|
------------------
( )
( Internal Network )
( (private to the )
( enterprise) )
(_________________ )
Figure 1: Security model of an Enterprise using Firewall
図1：ファイアウォールを使用したエンタープライズのセキュリティモデル
Network Access Servers used to allow direct dial-in access (through the PSTN) to employees are placed within the private enterprise network so as to avoid access restrictions imposed by a firewall.
（PSTNを介して）従業員への直接的なダイヤルインアクセスを許可するために使用されるネットワークアクセスサーバーは、ファイアウォールによって課されるアクセス制限を避けるために、プライベートエンタープライズネットワーク内に配置されます。
With the above model, private resources of an enterprise are restricted for access from the Internet. Firewall may be configured to occasionally permit access to a certain resource or service but is not recommended on an operational basis as that could constitute a security threat to the enterprise. It is of interest to note that even when the firewall is configured to permit access to internal resources from pre-defined external node(s), many internal servers, such as NFS, enforce address based authentication and do not co-operate when the IP address of the external node is not in corporate IP address domain. In other words, with the above security model, it becomes very difficult to allow employees to access corporate resources, via the Internet, even if you are willing to forego security over the Internet.
上記のモデルを使用すると、インターネットからのアクセスのために企業のプライベートリソースが制限されています。ファイアウォールは、特定のリソースまたはサービスへのアクセスを時々許可するように構成されている場合がありますが、それは企業にとってセキュリティの脅威を構成する可能性があるため、運用ベースで推奨されません。Firewallが事前定義された外部ノードからの内部リソースへのアクセスを許可するように構成されている場合でも、NFSなどの多くの内部サーバーがアドレスベースの認証を強制し、IPがIPが協力しないことに注意してください。外部ノードのアドレスは、コーポレートIPアドレスドメインではありません。言い換えれば、上記のセキュリティモデルを使用すると、インターネットを介してセキュリティをめぐる意思がある場合でも、従業員がインターネットを介して企業リソースにアクセスできるようにすることが非常に困難になります。
With the advent of IPsec, it is possible to secure corporate data across the Internet by employing a Security Gateway within the enterprise. Firewall may be configured to allow IKE and IPsec packets directed to a specific Security Gateway behind the firewall. It then becomes the responsibility of the Security Gateway to employ the right access list for external connections seeking entry into the enterprise. Essentially, the access control functionality for IPsec secure packets would be shifted to the Security Gateway (while the access control for clear packets is retained with the firewall). The following figure illustrates the model where a combination of Firewall and Security Gateway control access to internal resources.
IPSECの出現により、エンタープライズ内のセキュリティゲートウェイを採用することにより、インターネット全体で企業データを保護することができます。ファイアウォールは、ファイアウォールの背後にある特定のセキュリティゲートウェイに向けられたIKEおよびIPSECパケットを許可するように構成できます。次に、エンタープライズへの参入を求める外部接続に適切なアクセスリストを使用するセキュリティゲートウェイの責任となります。基本的に、IPSECセキュアパケットのアクセス制御機能はセキュリティゲートウェイにシフトされます（クリアパケットのアクセス制御はファイアウォールで保持されます）。次の図は、ファイアウォールとセキュリティゲートウェイ制御の内部リソースへのアクセスの組み合わせのモデルを示しています。
------------
( )
( )
( Internet )
( )
(___________ )
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
------------------------------------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server etc. | LAN
|
------------------------------------
| |
+----------+ +------------------+
| LNS | | Security Gateway |
| Server | | (SGW) |
+----------+ +------------------+
|
------------------
( )
( Internal Network )
( (Private to the )
( enterprise) )
(_________________ )
Figure 2: Security Model based on Firewall and Security Gateway
図2：ファイアウォールとセキュリティゲートウェイに基づくセキュリティモデル
In order to allow employee dial-in over the Internet, an LNS may be placed behind a firewall, and the firewall may be configured to allow UDP access to the LNS from the Internet. Note, it may not be possible to know all the IP addresses of the LACs located on the Internet at configuration time. Hence, the need to allow UDP access from any node on the Internet. The LNS may be configured to process only the L2TP packets and drop any UDP packets that are not L2TP.
インターネット上で従業員のダイヤルインを許可するために、LNSをファイアウォールの後ろに配置し、ファイアウォールを設定して、インターネットからLNSへのUDPアクセスを許可する場合があります。注意してください。構成時間にインターネット上にあるLACのすべてのIPアドレスを知ることはできない場合があります。したがって、インターネット上の任意のノードからUDPアクセスを許可する必要があります。LNSは、L2TPパケットのみを処理し、L2TPではないUDPパケットをドロップするように構成できます。
Such a configuration allows remote access over the Internet. However, the above setup is prone to a variety of security attacks over the Internet. It is easy for someone on the Internet to steal a remote access session and gain access to precious resources of the enterprise. Hence it is important that all packets are preserved with IPsec to a security Gateway (SGW) behind the LNS, so the Security Gateway will not allow IP packets into corporate network unless it can authenticate the same.
このような構成により、インターネット上のリモートアクセスが可能になります。ただし、上記のセットアップは、インターネットを介したさまざまなセキュリティ攻撃を受ける傾向があります。インターネット上の誰かがリモートアクセスセッションを盗み、企業の貴重なリソースにアクセスするのは簡単です。したがって、すべてのパケットがLNSの後ろのセキュリティゲートウェイ（SGW）にIPSECを備えて保存されることが重要です。そのため、セキュリティゲートウェイは、同じものを認証できない限り、IPパケットをコーポレートネットワークに入れません。
The trust model of secure remote access assumes that the enterprise and the end user are trusted domains. Everything in between is not trusted. Any examination of the end-to-end packets by the nodes enroute would violate this trust model. From this perspective, even the LAC node enroute must not be trusted with the end-to-end IP packets. Hence, location and operation of LAC is not relevant for the discussion on security. On the other hand, location and operation of LNS and the Security Gateway (SGW) are precisely the basis for discussion.
安全なリモートアクセスの信頼モデルは、エンタープライズとエンドユーザーが信頼できるドメインであると想定しています。その間のすべては信頼されていません。ノードへのエンドツーエンドのパケットの調査は、この信頼モデルに違反します。この観点から見ると、LACノードのAnoteでさえ、エンドツーエンドのIPパケットで信頼されてはなりません。したがって、LACの場所と操作は、セキュリティに関する議論には関係ありません。一方、LNSおよびセキュリティゲートウェイ（SGW）の場所と操作は、まさに議論の基礎となっています。
Having security processing done on an independent Security gateway has the following shortcomings.
独立したセキュリティゲートウェイでセキュリティ処理を行うことには、次の欠点があります。
1. Given the trust model for remote access, the SGW must be configured with a set of security profiles, access control lists and IKE authentication parameters for each user. This mandates an independent provisioning of security parameters on a per-user basis. This may not be able to take advantage of the user-centric provisioning on RADIUS, used by the LNS node.
1. リモートアクセス用の信頼モデルを考えると、SGWは、各ユーザーのセキュリティプロファイル、アクセス制御リスト、IKE認証パラメーターで構成する必要があります。これは、ユーザーごとにセキュリティパラメーターの独立したプロビジョニングを義務付けています。これは、LNSノードで使用されているRADIUSでのユーザー中心のプロビジョニングを利用できない場合があります。
2. Unlike the LNS, SGW may not be in the routing path of remote access packets. I.e., there is no guarantee that the egress IP packets will go through the chain of SGW and LNS before they are delivered to remote user. As a result, packets may be subject to IPSec in one direction, but not in the other. This can be a significant threat to the remote access trust model.
2. LNSとは異なり、SGWはリモートアクセスパケットのルーティングパスにない場合があります。つまり、Egress IPパケットがリモートユーザーに配信される前にSGWとLNSのチェーンを通過するという保証はありません。その結果、パケットは一方向のIPSECの対象となる場合がありますが、もう一方の方向にはそうではありません。これは、リモートアクセストラストモデルにとって大きな脅威になる可能性があります。
3. Lastly, the SGW node does not have a way to know when a remote user node(s) simply died or the LAC-LNS tunnel failed. Being unable to delete the SAs for users that no longer exist could drain the resources of the SGW. Further, the LNS cannot even communicate the user going away to the SGW because, the SGW maintains its peer nodes based on IKE user ID, which could be different the user IDs employed by the LNS node.
3. 最後に、SGWノードには、リモートユーザーノードが単純に死亡したか、LAC-LNSトンネルが失敗したことを知る方法がありません。もはや存在しないユーザーのSASを削除できないと、SGWのリソースが消耗する可能性があります。さらに、LNSは、SGWがIKEユーザーIDに基づいてピアノードを維持しているため、SGWに去るユーザーを通信することさえできません。
Combining the functions of IPsec Security Gateway and LNS into a single system promises to offer a viable solution for secure remote access. By doing this, remote access clients will use a single node as both (a) PPP termination point providing NAS service, and (b) the Security gateway node into the enterprise. We will refer this node as "Secure Remote Access Server" (SRAS).
IPSECセキュリティゲートウェイとLNSの機能を単一のシステムに組み合わせることで、安全なリモートアクセスのための実行可能なソリューションを提供することが約束されます。これを行うことにより、リモートアクセスクライアントは、（a）NASサービスを提供するPPP終端ポイントと（b）エンタープライズへのセキュリティゲートウェイノードの両方として、単一のノードを使用します。このノードを「セキュアリモートアクセスサーバー」（SRAS）と呼びます。
The SRAS can benefit greatly from the confluence of PPP session and IPsec tunnel end points. PPP session monitoring capability of L2TP directly translates to being able to monitor IPsec tunnels. Radius based user authorization ability could be used to configure the security characteristics for IPsec tunnel. This includes setting access control filters and security preferences specific to each user. This may also be extended to configuring IKE authentication and other negotiation parameters, when automated key exchange is solicited. Security attributes that may be defined in Radius are discussed in detail in section 7. Needless to say, the centralized provisioning capability and scalability of Radius helps in the configuration of IPsec.
SRAは、PPPセッションとIPSECトンネルのエンドポイントの合流から大きな恩恵を受けることができます。L2TPのPPPセッション監視機能は、IPSECトンネルを監視できることに直接変換されます。RADIUSベースのユーザー認証機能を使用して、IPSECトンネルのセキュリティ特性を構成できます。これには、アクセス制御フィルターの設定と、各ユーザーに固有のセキュリティ設定が含まれます。これは、自動化されたキー交換が求められている場合、IKE認証およびその他のネゴシエーションパラメーターの構成に拡張される場合があります。半径で定義される可能性のあるセキュリティ属性については、セクション7で詳細に説明します。言うまでもなく、半径の集中化されたプロビジョニング能力とスケーラビリティは、IPSECの構成に役立ちます。
As for remote access, the benefit is one of IPsec security as befitting the trust model solicited by enterprises for the end-to-end IP packets traversing the Internet. You may use simply AH where there is no fear of external eaves-dropping, but you simply need to authenticate packet data, including the source of packet. You may use ESP (including ESP-authentication), where there is no trust of the network and you do not want to permit eaves-dropping on corporate activities.
リモートアクセスに関しては、インターネットを横断するエンドツーエンドのIPパケットのためにエンタープライズが求めているトラストモデルにふさわしいIPSECセキュリティの1つです。外部の軒を落とすことを恐れない場合は、単にAHを使用できますが、パケットのソースを含むパケットデータを認証する必要があります。ネットワークに信頼がなく、企業活動に軒を落とすことを許可したくない場合、ESP（ESP認証を含む）を使用できます。
Operation of SRAS requires that the firewall be configured to permit UDP traffic into the SRAS node. The SRAS node in turn will process just the L2TP packets and drop the rest. Further, the SRAS will require all IP packets embedded within PPP to be one of AH and ESP packets, directed to itself. In addition, the SRAS will also permit IKE UDP packets (with source and destination ports sets to 500) directed to itself in order to perform IKE negotiation and generate IPsec keys dynamically. All other IP packets embedded within PPP will be dropped. This enforces the security policy for the enterprise by permitting only the secure remote access packets into the enterprise. When a PPP session is dropped, the IPsec and ISAKMP SAs associated with the remote access user are dropped from the SRAS. All the shortcomings listed in the previous section with LNS and SGW on two systems disappear withe Secure Remote Access Server. Figure 3 below is a typical description of an enterprise supporting remote access users using SRAS system.
SRASの操作では、SRASノードへのUDPトラフィックを許可するようにファイアウォールを構成する必要があります。SRASノードは、L2TPパケットのみを処理し、残りをドロップします。さらに、SRAは、PPP内に埋め込まれたすべてのIPパケットがAHおよびESPパケットのいずれかで、それ自体に向けられたものにする必要があります。さらに、SRASは、IKEのネゴシエーションを実行し、IPSECキーを動的に生成するために、IKE UDPパケット（ソースポートと宛先ポートセットを500に設定します）を許可します。PPP内に埋め込まれた他のすべてのIPパケットが削除されます。これにより、安全なリモートアクセスパケットのみをエンタープライズに許可することにより、企業のセキュリティポリシーが実施されます。PPPセッションがドロップされると、リモートアクセスユーザーに関連付けられたIPSECおよびISAKMP SASがSRAから削除されます。前のセクションにリストされているすべての欠点は、2つのシステム上のLNSとSGWを使用して、安全なリモートアクセスサーバーで消えます。以下の図3は、SRASシステムを使用してリモートアクセスユーザーをサポートするエンタープライズの典型的な説明です。
------------
Remote Access +-------------+ ( )
+--+______ Link | Local Access| ( )
|__| /___________| Concentrator|----( Internet )
/____\ | (LAC) | ( )
RA-Host +-------------+ (____________)
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
------------------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server etc. | LAN
|
------------------------------------
|
+---------------+
| Secure Remote |
| Access Server |
| (SRAS) |
+---------------+
|
---------------------
( )
+--+ ( Internal Network )
|__|------( (Private to the )
/____\ ( enterprise) )
Ent-Host (______________________)
Figure 3: Secure Remote Access Server operation in an Enterprise
図3：エンタープライズでの安全なリモートアクセスサーバー操作
The following is an illustration of secure remote access data flow as end-to-end IP packets traverse the Internet and the SRAS. The example shows IP packet tunneling and IPsec transformation as packets are exchanged between a remote Access host (RA-Host) and a host within the enterprise (say, Ent-Host).
以下は、インターネットとSRAを横断するエンドツーエンドのIPパケットとしての安全なリモートアクセスデータフローのイラストです。この例は、パケットがリモートアクセスホスト（RA-HOST）とエンタープライズ内のホスト（ENT-HOSTなど）の間で交換されるため、IPパケットトンネルとIPSEC変換を示しています。
Note, the IP packets originating from or directed to RA-Host are shown within PPP encapsulation, whereas, all other packets are shown simply as IP packets. It is done this way to highlight the PPP packets encapsulated within L2TP tunnel. The PPP headers below are identified by their logical source and destination in parenthesis. Note, however, the source and recipient information of the PPP data is not a part of PPP header. This is described thus, just for clarity. In the case of an L2TP tunnel, the L2TP header carries the PPP session ID, which indirectly identifies the PPP end points to the LAC and the LNS. Lastly, the IPsec Headers section below include the tunneling overhead and the AH/ESP headers that are attached to the tunnel.
注、またはRA-HOSTに由来するまたは指示されたIPパケットはPPPカプセル化内に表示されますが、他のすべてのパケットは単にIPパケットとして表示されます。L2TPトンネル内でカプセル化されたPPPパケットを強調するためにこの方法で行われます。以下のPPPヘッダーは、括弧内の論理ソースと宛先によって識別されます。ただし、PPPデータのソースと受信者の情報は、PPPヘッダーの一部ではありません。これは、したがって、明確にするために説明されています。L2TPトンネルの場合、L2TPヘッダーにはPPPセッションIDが搭載されており、PPPエンドポイントをLACとLNSに間接的に識別します。最後に、以下のIPSECヘッダーセクションには、トンネリングオーバーヘッドとトンネルに取り付けられたAH/ESPヘッダーが含まれています。
RA-Host to Ent-Host Packet traversal:
------------------------------------
RA-Host LAC SRAS Ent-Host
=====================================================================
+----------------------+
| PPP Header |
| (RA-Host ->SRAS) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(RA-Host->SRAS)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
+----------------------+
| IP Header |
| (LAC->SRAS) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (RA-Host ->SRAS) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(RA-Host->SRAS)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
+----------------------+
| End-to-end IP packet |
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
Ent-Host to RA-Host Packet traversal:
------------------------------------
Ent-Host SRAS LAC RA-Host
=====================================================================
+----------------------+
| End-to-end IP packet |
| (Ent-Host->Ra-Host) |
+----------------------+
---------------------->
+----------------------+
| IP Header |
| (SRAS->LAC) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (SRAS->RA-Host) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(SRAS->RA-Host)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (Ent-Host->RA-Host) |
+----------------------+
---------------------->
+----------------------+
| PPP Header |
| (SRAS->RA-Host) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(SRAS->RA-Host)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (Ent-Host->RA-Host) |
+----------------------+
---------------------->
The SRAS model described is not without its limitations. Below is a list of the limitations.
説明されているSRASモデルには、制限がないわけではありません。以下は、制限のリストです。
1. Tunneling overhead: There is considerable tunneling overhead on the end-to-end IP packet. Arguably, there is overlap of information between tunneling headers. This overhead will undercut packet throughput.
1. トンネリングオーバーヘッド：エンドツーエンドのIPパケットにはかなりのトンネルオーバーヘッドがあります。間違いなく、トンネルヘッダーの間に情報の重複があります。このオーバーヘッドは、パケットスループットをアンダーカットします。
The overhead is particularly apparent at the LAC and SRAS nodes. Specifically, the SRAS has the additional computational overhead of IPsec processing on all IP packets exchanged with remote users. This can be a significant bottleneck in the ability of SRAS to scale for large numbers of remote users.
オーバーヘッドは、LACおよびSRASノードで特に明らかです。具体的には、SRASには、リモートユーザーと交換されたすべてのIPパケットでIPSEC処理の追加の計算オーバーヘッドがあります。これは、SRAが多数のリモートユーザーを拡大する能力における重要なボトルネックになる可能性があります。
2. Fragmentation and reassembly: Large IP packets may be required to undergo Fragmentation and reassembly at the LAC or the LNS as a result of multiple tunnel overhead tagged to the packet. Fragmentation and reassembly can havoc on packet throughput and latency. However, it is possible to avoid the overhead by reducing the MTU permitted within PPP frames.
2. 断片化と再組み立て：パケットにタグ付けされた複数のトンネルオーバーヘッドの結果として、LACまたはLNSで断片化と再組み立てを行うには、大きなIPパケットが必要になる場合があります。断片化と再組み立ては、パケットのスループットとレイテンシを大混乱させる可能性があります。ただし、PPPフレーム内で許可されているMTUを減らすことにより、オーバーヘッドを回避することができます。
3. Multiple identity and authentication requirement: Remote Access users are required to authenticate themselves to the SRAS in order to be obtain access to the link. Further, when they require the use of IKE to automate IPsec key exchange, they will need to authenticate once again with the same or different ID and a distinct authentication approach. The authentication requirements of IKE phase 1 [Ref 8] and LCP [Ref 3] are different.
3. 複数のIDと認証要件：リモートアクセスユーザーは、リンクへのアクセスを取得するためにSRAに認証するために必要です。さらに、IPSECキーエクスチェンジを自動化するためにIKEを使用する必要がある場合、同じまたは異なるIDと明確な認証アプローチで再度認証する必要があります。IKEフェーズ1 [Ref 8]およびLCP [Ref 3]の認証要件は異なります。
However, it is possible to have a single authentication approach (i.e., a single ID and authentication mechanism) that can be shared between LCP and IKE phase 1. The Extended Authentication Protocol(EAP) [Ref 4] may be used as the base to transport IKE authentication mechanism into PPP. Note, the configuration overhead is not a drag on the functionality perse.
ただし、LCPとIKEフェーズ1の間で共有できる単一の認証アプローチ（つまり、単一のIDおよび認証メカニズム）を持つことができます。IKE認証メカニズムをPPPに輸送します。注意、構成オーバーヘッドは、機能性の脳のドラッグではありません。
4. Weak security of Link level authentication: As LCP packets traverse the Internet, the Identity of the remote user and the password (if a password is used) is sent in the clear. This makes it a target for someone on the net to steal the information and masquerade as remote user. Note, however, this type of password stealing will not jeopardize the security of the enterprise per se, but could result in denial of service to remote users. An intruder can collect the password data and simply steal the link, but will not be able to run any IP applications subsequently, as the SRAS will fail non-IPsec packet data.
4. リンクレベル認証の弱いセキュリティ：LCPパケットがインターネットを横断すると、リモートユーザーのIDとパスワード（パスワードが使用されている場合）がクリアに送信されます。これにより、ネット上の誰かが情報を盗み、リモートユーザーを装備するためのターゲットになります。ただし、このタイプのパスワード盗みは、エンタープライズ自体のセキュリティを危険にさらすことはありませんが、リモートユーザーにサービスの拒否をもたらす可能性があります。侵入者はパスワードデータを収集してリンクを盗むことができますが、SRAが非IPIPSECパケットデータに失敗するため、その後はIPアプリケーションを実行できません。
A better approach would be to employ Extended Authentication Protocol (EAP) [Ref 4] and select an authentication technique that is not prone to stealing over the Internet. Alternately, the LAC and the SRAS may be independently configured to use IPsec to secure all LCP traffic exchanged between themselves.
より良いアプローチは、拡張認証プロトコル（EAP）[REF 4]を使用し、インターネット上で盗む傾向がない認証技術を選択することです。あるいは、LACとSRASは、IPSECを使用して、それ自体の間で交換されるすべてのLCPトラフィックを保護するように独立して構成されている場合があります。
7. Configuring RADIUS to support Secure Remote Access.
7. 安全なリモートアクセスをサポートするために半径を構成します。
A centralized RADIUS database is used by enterprises to maintain the authentication and authorization requirements of the dial-in Users. It is also believed that direct dial-in access (e.g., through the PSTN network is) safe and trusted and does not need any scrutiny outside of the link level authentication enforced in LCP. This belief is certainly not shared with the dial-in access through the Internet.
集中型RADIUSデータベースは、ダイヤルインユーザーの認証要件と承認要件を維持するために企業によって使用されます。また、直接的なダイヤルインアクセス（たとえば、PSTNネットワークを介した）は安全で信頼できると考えられており、LCPで実施されているリンクレベル認証以外では精査を必要としません。この信念は、確かにインターネットを介したダイヤルインアクセスと共有されていません。
So, while the same RADIUS database may be used for a user directly dialing-in or dialing in through the Internet, the security requirements may vary. The following RADIUS attributes may be used to mandate IPsec for the users dialing-in through the Internet. The exact values for the attributes and its values may be obtained from IANA (refer Section 10).
したがって、インターネットを介して直接ダイヤルインまたはダイヤルインするユーザーには同じRADIUSデータベースが使用される場合がありますが、セキュリティ要件は異なる場合があります。次のRADIUS属性を使用して、インターネットを介してダイヤルインするユーザーにIPSECを義務付けることができます。属性とその値の正確な値は、IANAから取得できます（セクション10を参照）。
A new RADIUS attribute IPSEC_MANDATE (91) may be defined for each user. This attribute may be given one of the following values.
新しいRADIUS属性IPSEC_MANDATE（91）は、各ユーザーに対して定義できます。この属性には、次の値のいずれかが与えられる場合があります。
NONE (=0) No IPsec mandated on the IP packets embedded within PPP.
なし（= 0）PPP内に埋め込まれたIPパケットに義務付けられていないIPSECなし。
LNS_AS_SRAS (=1) Mandates Tunnel mode IPsec on the IP packets embedded within PPP, only so long as the PPP session terminates at an LNS. LNS would be the tunnel mode IPsec end point.
LNS_AS_SRAS（= 1）は、PPPに埋め込まれたIPパケットにトンネルモードIPSECを義務付けます。PPPセッションがLNSで終了する限り。LNSは、トンネルモードIPSECエンドポイントになります。
SRAS (=2) Mandates Tunnel mode IPsec on the IP packets embedded within PPP, irrespective of the NAS type the PPP terminates in. I.e., the IPsec mandate is not specific to LNS alone, and is applicable to any NAS, terminating PPP. NAS would be the tunnel mode IPsec end point.
SRAS（= 2）は、PPPに埋め込まれたIPパケットのトンネルモードIPSECを義務付けます。PPPが終了するNASタイプに関係なく。NASは、トンネルモードIPSECエンドポイントになります。
When IPSEC_MANDATE attribute is set to one of LNS_AS_SRAS or SRAS, that would direct the NAS to drop any IP packets in PPP that are not associated with an AH or ESP protocol. As an exception, the NAS will continue to process IKE packets (UDP packets, with source and destination port set to 500) directed from remote users. Further, the security profile parameter, defined in the following section may add additional criteria for which security is not mandatory.
IPSEC_MANDATE属性がLNS_AS_SRAまたはSRASのいずれかに設定されている場合、AHまたはESPプロトコルに関連付けられていないPPPでIPパケットをドロップするようにNASに指示します。例外として、NASは、リモートユーザーから向けられたIKEパケット（UDPパケット、ソースと宛先ポートが500に設定されている）を処理し続けます。さらに、次のセクションで定義されているセキュリティプロファイルパラメーターは、セキュリティが必須ではない追加の基準を追加する場合があります。
A new SECURITY_PROFILE (92) parameter may be defined in RADIUS to describe security access requirements for the users. The profile could contain information such as the access control security filters, security preferences and the nature of Keys (manual or automatic generated via the IKE protocol) used for security purposes.
新しいSecurity_Profile（92）パラメーターをRADIUSで定義して、ユーザーのセキュリティアクセス要件を説明できます。プロファイルには、アクセス制御セキュリティフィルター、セキュリティ設定、セキュリティ目的で使用されるキー（IKEプロトコルを介して生成された手動または自動生成）などの情報が含まれている場合があります。
The SECURITY-PROFILE attribute can be assigned a filename, as a string of characters. The contents of the file could be vendor specific. But, the contents should include (a) a prioritized list access control security policies, (b) Security Association security preferences associated with each security policy.
セキュリティプロファイル属性は、文字列としてファイル名を割り当てることができます。ファイルの内容は、ベンダー固有のものである可能性があります。ただし、内容には、（a）優先順位付けされたリストアクセス制御セキュリティポリシー、（b）各セキュリティポリシーに関連付けられたセキュリティ協会のセキュリティ設定が含まれます。
If the security profile of a user requires dynamic generation of security keys, the parameters necessary for IKE negotiation may be configured separately using a new IKE_NEGOTIATION_PROFILE (93) parameter in RADIUS. IKE-NEGOTIATION_PROFILE attribute may be assigned a filename, as a string of characters. The contents of the file could however be vendor specific. The contents would typically include (a) the IKE ID of the user and SRAS, (b) preferred authentication approach and the associated parameters, such as a pre-shared-key or a pointer to X.509 digital Certificate, and, (c) ISAKMP security negotiation preferences for phase I.
ユーザーのセキュリティプロファイルにダイナミック生成のセキュリティキーが必要な場合、IKEネゴシエーションに必要なパラメーターは、RADIUSの新しいike_negotiation_profile（93）パラメーターを使用して個別に構成できます。ike-negotiation_profile属性には、文字列としてファイル名を割り当てることができます。ただし、ファイルの内容はベンダー固有の可能性があります。コンテンツには通常、（a）ユーザーとSRAのIKE ID、（b）優先認証アプローチ、およびX.509デジタル証明書のポインターや（cなどの関連パラメーターが含まれます。）フェーズIのISAKMPセキュリティ交渉の好み。
The author would like to express sincere thanks to Steve Willens for initially suggesting this idea. The author is also thankful to Steve for the many informal conversations which were instrumental in the author being able to appreciate the diverse needs of the Remote Access area.
著者は、最初にこのアイデアを提案してくれたスティーブ・ウィレンズに心から感謝したいと思います。著者はまた、著者がリモートアクセスエリアの多様なニーズを理解できることに貢献した多くの非公式の会話についてスティーブに感謝しています。
This document is about providing secure remote access to enterprises via the Internet. However, the document does not address security issues for network layers other than IP. While the document focus is on security over the Internet, the security model provided is not limited to the Internet or the IP infrastructure alone. It may also be applied over other transport media such as Frame Relay and ATM clouds. If the transport media is a trusted private network infrastructure, the security measures described may not be as much of an issue. The solution suggested in the document is keeping in view the trust model between a remote user and enterprise.
このドキュメントは、インターネットを介して企業への安全なリモートアクセスを提供することに関するものです。ただし、このドキュメントは、IP以外のネットワークレイヤーのセキュリティ問題に対処していません。ドキュメントの焦点はインターネット上のセキュリティに焦点を当てていますが、提供されるセキュリティモデルは、インターネットまたはIPインフラストラクチャのみに限定されません。また、フレームリレーやATMクラウドなど、他の輸送メディアにも適用される場合があります。トランスポートメディアが信頼できるプライベートネットワークインフラストラクチャである場合、説明されているセキュリティ対策はそれほど問題ではない可能性があります。ドキュメントで提案されているソリューションは、リモートユーザーとエンタープライズの間の信頼モデルを把握しています。
This document proposes a total of three new RADIUS attributes to be maintained by the IANA. These attributes IPSEC_MANDATE, SECURITY_PROFILE and IKE_NEGOTIATION_PROFILE may be assigned the values 91, 92 and 93 respectively so as not to conflict with the definitions for recognized radius types, as defined in http://www.isi.edu/in-notes/iana/assignments/radius-types.
このドキュメントでは、IANAによって維持される合計3つの新しい半径属性を提案しています。これらの属性IPSEC_MANDATE、security_profile、およびike_negotiation_profileは、http://www.isi.edu/in-notes/iana/で定義されているように、認識された半径タイプの定義と競合しないように、それぞれ値91、92、および93を割り当てることができます。割り当て/半径タイプ。
The following sub-section explains the criteria to be used by the IANA to assign additional numbers as values to the IPSEC-MANDATE attribute described in section 7.1.
次のサブセクションでは、IANAが使用する基準を説明して、セクション7.1で説明したIPSEC-Mandate属性に値として追加の数値を割り当てます。
Values 0-2 of the IPSEC-MANDATE-Type Attribute are defined in Section 7.1; the remaining values [3-255] are available for assignment by the IANA with IETF Consensus [Ref 11].
IPSEC-Mandate-Type属性の値0-2は、セクション7.1で定義されています。残りの値[3-255]は、IETFコンセンサス[Ref 11]を備えたIANAによる割り当てに利用できます。
REFERENCES
参考文献
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol L2TP", RFC 2661, August 1999.
[1] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。およびB. Palter、「レイヤー2トンネリングプロトコルL2TP」、RFC 2661、1999年8月。
[2] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[2] Rigney、C.、Rubens、A.、Simpson、W。and S. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[3] シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[4] Blunk, L. and Vollbrecht, J. "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[4] Blunk、L。およびVollbrecht、J。「PPP拡張可能な認証プロトコル（EAP）」、RFC 2284、1998年3月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[6] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[7] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[7] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[8] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[9] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[9] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also http://www.iana.org/numbers.html
[10] Reynolds、J。and J. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。http：//www.iana.org/numbers.htmlも参照してください。
[11] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[11] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[12] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[12] Meyer、G。、「PPP暗号化制御プロトコル（ECP）」、RFC 1968、1996年6月。
[13] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
[13] Sklower、K。and G. Meyer、「The Ppp des Encryption Protocol、バージョン2（DESE-BIS）」、RFC 2419、1998年9月。
Author's Address
著者の連絡先
Pyda Srisuresh Campio Communications 630 Alder Drive Milpitas, CA 95035 U.S.A.
Pyda Srisuresh Campio Communications 630 Alder Drive Milpitas、CA 95035 U.S.A.
Phone: +1 (408) 519-3849
EMail: srisuresh@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。