Network Working Group P. Srisuresh
Request for Comments: 2888 Campio Communications
Category: Informational August 2000
Secure Remote Access with L2TP
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
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の仮想拡張したものです。 PPP終端サーバー（LNS）は、企業の敷地内に位置することを可能にしながら、アクセスコンセントレータ（LAC）は、リモートクライアントの近くであるためにはL2TPが可能になります。 L2TPは、企業がダイヤルインユーザの認証、認可およびアカウンタビリティ（AAA）を制御するために使用されるRADIUSデータベースの制御を保持することを可能にします。このドキュメントの目的は、彼らがダイヤルインとしてインターネットを通じて、リモートアクセスユーザーへのIPsecのセキュリティ特性を拡張することです。これは、新しいプロトコルを作成し、リモートアクセスとIPsecの既存の慣行を使用せずに達成されます。具体的には、文書には、リモートクライアントと企業間のネットワークレベルのセキュリティを強制するためにセキュアなリモートアクセスサーバー（SRAS）として動作する、LNSノードによって使用するための3つの新しいRADIUSパラメータを提案しています。文書はまた、アプローチの限界を論じています。
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).
文書は、インターネット経由のリモートアクセスが現実になる可能性があることにより、アプローチを示唆しています。アプローチは、すでに場所でよく知られた技術およびプロトコルの上に成り立っています。 IPSecで提供されるセキュリティと組み合わせるL2TP、に基づいてリモートアクセスの拡張機能は、インターネット上で現実をリモートアクセスを行うことができます。アプローチは、新しいプロトコル（複数可）を考案する必要はありません。
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を追求することがあります。つまり、エンタープライズエッジ装置によって課せられるセキュリティ要件に加えて、あろう。
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プロトコル文書の一つで見つけることができる[参考文献1]、（b）はIPセキュリティアーキテクチャ文書[参考文献5]、または（c）インターネット鍵交換（IKE）ドキュメント[参考文献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.
注、用語ネットワークアクセスサーバ（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.
この文書で定義された「セキュアリモートアクセスサーバー」（SRAS）は、そのリモート・クライアントとのトンネルモードIPsecをサポートしているNASを指します。具体的には、LNSは、参照されるNASです。さらに、不随意トンネリングはPPPセッション及びPPPセッションは別個の物理的実体であると推定されているトンネルLACを開始し、リモートクライアントに、L2TPトンネル設定のために想定されます。
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インフラを前提としています。信頼された民間輸送培地中（PPP内に埋め込まれた）IPパケットのセキュリティは、このドキュメントの目的のために、それほど心配です。
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）によるリモートクライアントの単なる認証以上のものです。認証、許可、アカウンティングおよびルーティングは、リモートアクセスに不可欠です。クライアントは、第1のネットワークへのリンクのアクセスが許可される前に、認証テストに合格しなければなりません。 （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（b）は、IPアドレスを割り当て、LACツーLNSトンネルの論理リンクの状態（すなわち、状態との間のリンクを監視する、（a）は、リモートユーザのAAA動作を実行するための焦点となりますリモートユーザとLAC）、および（c）リモートユーザネットワークへのホストルートを維持し、企業内ルーティングインフラストラクチャを提供します。
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は、確立終了し、（リモートユーザからLNSに）論理PPPセッションの状態を監視するための制御メッセージを使用します。これらは、データメッセージとは無関係です。 L2TPデータメッセージは、PPPパケットに続いてL2TPヘッダを含みます。 L2TPヘッダは、PPPパケットが属する（とりわけ）PPPセッションを識別する。リモートユーザへの/からの交換IPパケットはPPPパケット内で運ばれます。次のようにIP輸送媒体でエンドツーエンドのIPパケットを運ぶL2TPデータメッセージは、説明することができます。 L2TPプロトコルの正確な詳細は、[参考文献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.
上記のモデルでは、企業のプライベートリソースは、インターネットからのアクセスに制限されています。ファイアウォールは、時折、特定のリソースやサービスへのアクセスを許可するように構成することができるが、それは、企業にセキュリティ上の脅威を構成することができて、業務単位にはお勧めしません。これは、ファイアウォールが、事前に定義された外部ノード（複数可）からNFSなど多くの内部のサーバを、内部リソースへのアクセスを許可するように設定された場合にも、アドレスベースの認証を強制することに注意することが重要であると協働していない時に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.
このような構成は、インターネット経由でのリモートアクセスを可能にします。しかし、上記の設定は、インターネット上でのセキュリティ攻撃の様々な傾向があります。これは、リモートアクセスセッションを盗むし、企業の貴重な資源へのアクセスを得るために、インターネット上で誰かのために簡単です。したがって、同じことを認証することができない限り、セキュリティゲートウェイは、企業ネットワークへのIPパケットを許可しないように、すべてのパケットが、LNSの背後にあるセキュリティゲートウェイ（SGW）へのIPsecで保存されていることが重要です。
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ノードは途中エンド・ツー・エンドの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は、リモートアクセスパケットのルーティング経路であってもなくてもよいです。つまり、彼らは、リモートユーザに配信される前に、出力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ノードは、リモート・ユーザノード（s）は、単純に死亡したか、LAC-LNSトンネルが失敗したときに知る方法がありません。もはや存在しないユーザーのためにSAを削除することができないということはSGWのリソースを排出できます。 、SGWは、LNSノードによって使用されるユーザIDは異なるかもしれないIKEユーザーIDに基づいて、ピア・ノードを維持するので、さらに、LNSも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の機能を組み合わせることにより、セキュアなリモートアクセスのための実行可能なソリューションを提供することを約束します。これにより、リモートアクセスクライアントは、企業にNASサービスを提供する（a）の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.
SRASは、PPPセッションおよびIPsecトンネルエンドポイントの合流から大きな利益を得ることができます。 L2TPのPPPセッションの監視能力は直接IPsecトンネルを監視することができることにつながります。半径ベースのユーザ認証機能は、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セキュリティの一つです。あなたは、外部庇落ちの心配はありません単に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パケットを処理し、残りをドロップします。さらに、SRASは、自身に向けAHとESPパケットの1つであることをPPPの中に埋め込まれているすべてのIPパケットを、必要になります。また、SRASはまた、IKEネゴシエーションを実行し、動的にIPsecキーを生成するために、自分宛（500送信元ポートと宛先ポートセットを有する）IKE UDPパケットを可能にします。 PPPの中に埋め込まれた他のすべてのIPパケットはドロップされます。これは、企業にのみセキュアなリモートアクセスのパケットを許可することで、企業のセキュリティポリシーを適用します。 PPPセッションが削除されるとき、リモート・アクセス・ユーザに関連付けられたIPsecとISAKMP SAはSRASから削除されます。二つのシステム上の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).
エンドツーエンドのIPパケットがインターネットとSRASを横切るように、以下は、安全なリモート・アクセス・データ・フローを示す図です。パケットは、リモートアクセスホスト（RA-ホスト）と企業内のホスト（例えば、ENT-ホスト）との間で交換される例では、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.
他のすべてのパケットは単にIPパケットとして示され、一方、ノートは、由来又はRA-ホストに向けられたIPパケットは、PPPカプセル化の中に示されています。 L2TPトンネル内にカプセル化されたPPPパケットを強調するために、このように行われます。以下PPPヘッダは、括弧内のそれらの論理ソースと宛先によって識別されます。ノートは、しかし、PPPデータのソースと受信者情報は、PPPヘッダの一部ではありません。これは単に明確にするため、このように説明されます。 L2TPトンネルの場合には、L2TPヘッダを間接的LACとLNSにPPPエンドポイントを識別するPPPセッションIDを運びます。最後に、以下の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処理の追加の計算オーバヘッドを有します。これは、リモートユーザの多数のためにスケーリングするSRASの能力に大きなボトルネックになることができます。
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.断片化および再アセンブリ：大きなIPパケットはパケットにタグ付けされた複数のトンネルオーバーヘッドの結果として、LACまたはLNSにおけるフラグメンテーション及び再組み立てを受けるために必要とされ得ます。パケットのスループットとレイテンシの断片化と再構築缶大混乱。しかし、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.複数のアイデンティティと認証要件：リモートアクセスユーザーは、リンクへのアクセスを取得するために、SRASに自分自身を認証するために必要とされています。彼らはIPsecの鍵交換を自動化するためにIKEの使用を必要とする場合また、それらは同一でも異なってIDと個別の認証アプローチでもう一度認証する必要があります。 IKEフェーズ1 [参考文献8]、LCP [参考文献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.
しかし、単一の認証アプローチを有することが可能である（すなわち、単一のIDと認証機構）LCP及びIKEのフェーズ1の間で共有することができる拡張認証プロトコル（EAP）は、[参考文献4]塩基として使用することができますPPPへの輸送IKE認証メカニズム。設定のオーバーヘッドが機能それ自体の足かせではありません、注意してください。
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パケットがインターネットを横断すると、リモート・ユーザおよびパスワードのアイデンティティは、（パスワードが使用されている場合）をクリアして送信されます。これは、情報を盗み、リモートユーザーになりすますために、ネット上の誰かのためのターゲットになります。ただし、パスワードの盗用のこのタイプは、それ自体が企業のセキュリティを危険にさらすことはありませんが、リモートユーザへのサービス拒否が発生する可能性があり、注意してください。侵入者は、パスワードデータを収集し、単にリンクを盗むが、SRASは、非IPsecパケットデータを失敗すると、その後に任意の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）[参考文献4]を使用し、インターネットを介して盗むしにくい認証技術を選択することであろう。代わりに、LACとSRASは、独立して、すべてのLCPのトラフィックは自分たちの間で交換確保するためにIPsecを使用するように設定することができます。
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.
NONE（= 0）いいえIPsecはPPP内に埋め込まれたIPパケットに義務付けられていません。
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.
のみであればPPPセッションがLNSで終端するように、PPP内に埋め込まれたIPパケットにLNS_AS_SRAS（= 1）委任トンネルモードのIPsec。 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）委任トンネルモードのIPsec PPP内に埋め込まれたIPパケットに関係なく、PPPはで終端NAS型である。すなわち、IPsecの任務は、単独で、LNSに特定されず、任意のNASに適用可能であり、PPPを終了します。 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_SRAS又はSRASのいずれかに設定されている場合、それは、AHまたはESPプロトコルに関連付けられていないPPP内の任意のIPパケットをドロップするNASを導くであろう。例外として、NASは、リモートユーザから導か（ソース及び500に設定された宛先ポートと、UDPパケット）IKEパケットを処理し続けます。さらに、次のセクションで定義されたセキュリティプロファイルパラメータは、セキュリティは必須ではありませんそのための追加の基準を追加することができます。
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.
SECURITY-PROFILE属性は、文字列として、ファイル名を割り当てることができます。ファイルの内容は、ベンダ固有である可能性があります。しかし、内容は、（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）は、IKEユーザーのIDとSRAS、（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.
著者は、最初はこのアイデアを示唆するためにスティーブWillensに心からの感謝を表したいと思います。著者はまた、リモートアクセスエリアの多様なニーズを鑑賞することができるという著者のに尽力した多くの非公式の会話のためのスティーブに感謝です。
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.
この文書は3つの新しいRADIUSの合計は、IANAによって維持されるように属性を提案しています。認識半径タイプの定義と矛盾しないようにhttp://www.isi.edu/in-notes/iana/で定義されるように、これらの属性IPSEC_MANDATE、SECURITY_PROFILEとIKE_NEGOTIATION_PROFILEは、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.
以下のサブセクションは、セクション7.1で説明したIPSEC-委任属性の値として、追加の数字を割り当てるためにIANAによって使用される基準を説明する図です。
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コンセンサス[参考文献11]とIANAによって割り当てのために利用可能です。
REFERENCES
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.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、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.、ルーベンス、A.、シンプソン、W.及び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]ブルンク、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]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[6]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[7] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[7]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[8]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[9] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[9]パイパー、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]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、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.
、BCP 26、RFC 2434、1998年10月[11] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[12] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[12]マイヤー、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.およびG.メイヤー、 "PPP DES暗号化プロトコル、バージョン2（DESEビス）"、RFC 2419、1998年9月。
Author's Address
著者のアドレス
Pyda Srisuresh Campio Communications 630 Alder Drive Milpitas, CA 95035 U.S.A.
Pyda Srisuresh Campioコミュニケーションズ630アルダードライブミルピタス、CA 95035 U.S.A.
Phone: +1 (408) 519-3849 EMail: srisuresh@yahoo.com
電話：+1（408）519-3849 Eメール：srisuresh@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。