RFC2888 日本語訳
2888 Secure Remote Access with L2TP. P. Srisuresh. August 2000. (Format: TXT=41255 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Srisuresh Request for Comments: 2888 Campio Communications Category: Informational August 2000
Srisureshがコメントのために要求するワーキンググループP.をネットワークでつないでください: 2888年のCampioコミュニケーションカテゴリ: 情報の2000年8月
Secure Remote Access with L2TP
L2TPがある安全な遠隔アクセス
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
要約
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で、PPP終了サーバ(LNS)が企業構内に位置するのを許容している間、アクセス集中装置(LAC)が、リモートクライアントの近くにあるように可能になります。 L2TPは企業にRADIUSデータベースのコントロールを保有させます。(データベースは、ダイヤルインのユーザのAuthentication、Authorization、およびAccountability(AAA)を制御するのに使用されます)。 このドキュメントの目的はIPsecのセキュリティの特性を遠隔アクセスのユーザに与えることです、彼らのように。インターネットを通してダイヤルインです。 新しいプロトコルを作成して、Remote AccessとIPsecの既存の習慣を使用しないで、これは達成されます。 明確に、ドキュメントはLNSノードで使用のための3つの新しいRADIUSパラメタを提案します、ネットワークを強制するSecure Remote Access Server(SRAS)がリモートクライアントと企業の間のセキュリティを平らにするので行動して。 また、ドキュメントはアプローチの制限について議論します。
1. Introduction and Overview
1. 序論と概要
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.
現在1日間、それはPSTN(公共のSwitched Telephone Network)の上の彼らの企業へのダイヤルインへの従業員のための一般的な習慣です、そして、ちょうどそれらが法人の構内にあるなら実行するようにその日その日の操作を実行してください。 このインクルードはそれらのホームと道行く戦士からダイヤルインでだれを住ませるか。(その道行く戦士は、法人の構内にいるはずがありません)。 インターネットが遍在するようになったので、インターネットを通したダイヤルインに、データ通信量で妨げられるので電話充電のときに節約して、ひたむきな声が系列であると保存するのは魅力的です。
Srisuresh Informational [Page 1] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[1ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
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に基づくリモートAccess拡張子は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を追求するかもしれません。 それは企業エッジデバイスによって課されたセキュリティ要件に加えているでしょう。
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デバイスをSecure Remote Access Serverに変えるために構成されるかもしれない新しいRADIUS属性について説明するのにささげられます。
2. Terminology and scope
2. 用語と範囲
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つにインターネット・キー・エクスチェンジ(IKE)が記録するプロトコルドキュメント[審判1]、(b)IPセキュリティArchitectureドキュメント[審判5]、または(c)[審判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)、およびRemote Access Server(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.
本書では定義された「安全なRemote Access Server」(SRAS)はリモートクライアントと共にトンネルモードがIPsecであるとサポートするNASを示します。 明確に、LNSは参照されるNASです。 さらに、不本意なトンネリングはL2TPトンネルセットアップのために想定されます、PPPセッションを開始するリモートクライアントとPPPセッションにトンネルを堀るLACがあえて異なった物理的実体であるので。
Srisuresh Informational [Page 2] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[2ページ]のRFC2888は2000年8月に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パケットにトンネルを堀るさまざまな輸送霊媒がいます。 例はFrame RelayかATM雲とIPネットワークインフラを含んでいます。 簡単さのために、ドキュメントはLACとLNSの間のPPPパケットを輸送する媒体として公共のIPインフラストラクチャを仮定します。 このドキュメントの目的に関する心配では信じられた個人的な輸送培地のIPパケット(PPPの中で埋め込まれている)のセキュリティは、より少ないです。
3. Remote Access operation
3. リモートAccess操作
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.
遠隔アクセスはNetwork Access Serverによるリモートクライアントの単なる認証以上(NAS)です。 認証、Authorization、Accounting、およびルーティングは遠隔アクセスに不可欠です。 ネットワークへのリンクアクセスが承諾される前にクライアントは最初に、認証テストに合格しなければなりません。 平らなサービス(IPなどの)が承認の特性に基づいて承諾されるネットワークはRADIUSのユーザに指定しました。 ネットワークAccess Serversは、サポートされた多くのユーザのために比例するのに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はこれらの遠隔アクセスのリンクの上までネットワーク層パケットを運ぶのに使用される中で最も一般的なLayer-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はLayer2リンクの終了を提供しますが、LNSはPPPの論理的な終了を提供します。 その結果、LNSはリモート・ユーザーのためにAAA操作を実行しながら、(a)のための焦点になります、(b) IPアドレスを割り当てて、論理的なリンク状態(すなわち、LACからLNSへのトンネルとリモート・ユーザーと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は論理的なPPPセッション(リモート・ユーザーからLNSまでの)の状態を設立して、終えて、モニターするコントロールメッセージを使用します。 これらはデータメッセージから独立しています。 L2TPデータメッセージはL2TPヘッダーを含んでいます、続いて、PPPパケットを含みます。 L2TPヘッダーはPPPパケットが属するPPPセッション(他のものの中の)を特定します。 /からリモート・ユーザーまで交換されたIPパケットはPPPパケットの中で運ばれます。 L2TPデータメッセージであり、IP輸送培地で終わりから終わりへのIPパケットを運ぶのは以下の通り説明されるかもしれません。 L2TPプロトコルの正確な詳細は[審判1]で見つけられるかもしれません。
Srisuresh Informational [Page 3] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[3ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
+----------------------+
| 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)|
+----------------------+
+----------------------+ | IPヘッダー| | (ラック<->、LNS) | +----------------------+ | UDPヘッダー| +----------------------+ | L2TPヘッダー| | (incl。 PPP Sess-ID) | +----------------------+ | pppヘッダー| | (リモート・ユーザー<->、LNS) | +----------------------+ | 終わりから終わりへのIPパケット| | (リモート・ユーザーからの/への)| +----------------------+
4. Requirements of an enterprise Security Gateway
4. 企業Securityの要件、ゲートウェイ
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.
その結果、ほとんどの企業が社外利用者のためにアクセスを事前に定義されたセットのリソースに制限します。 通常、企業はアクセスを社内資源に制限して、DeMilitarized Zone(DMZ)に外部的にアクセスしやすいサーバを置くのにファイアウォールを使います、ファイアウォールの正面で、図1で以下で説明されるように。
Srisuresh Informational [Page 4] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[4ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
----------------
( )
( )
( Internet )
( )
(_______________ )
---------------- ( ) ( ) (インターネット) ( ) (_______________ )
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
---------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server |
|
------------------
( )
( Internal Network )
( (private to the )
( enterprise) )
(_________________ )
WAN| .........|\|.... | +-----------------+ |エンタープライズルータ| +-----------------+ | | 非武装地帯--ネットワーク--------------------------------- | | | +--+ +--+ +----------+ |__| |__| | ファイアウォール| /____\ /____\ +----------+ 非武装地帯名の非武装地帯ウェブ… | サーバサーバ| | ------------------ ( ) (内部のネットワーク) (個人的である、)、(企業) (_________________ )
Figure 1: Security model of an Enterprise using Firewall
図1: Firewallを使用するエンタープライズの機密保護モデル
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を通して)ネットワークAccess Serversは、ファイアウォールによって課されたアクセス制限を避けるために私企業ネットワークの中に置かれます。
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
上のモデルと共に、企業の個人的なリソースはアクセスのためにインターネットから制限されます。 ファイアウォールは、時折あるリソースかサービスへのアクセスを可能にするために構成されるかもしれませんが、それが企業への軍事的脅威を構成するかもしれないように操作上ベースでは推薦されません。 それは、ファイアウォールが(s)、NFSなどの内部の多くのサーバが実施する事前に定義された外部ノードからの社内資源へのアクセスを可能にするために構成さえされるとき、アドレスが認証を基礎づけたことに注意して、外部ノードのIPアドレスが法人のIPアドレスドメインにないとき共同作動しないように興味があります。 言い換えれば、上のセキュリティでモデル化してください、それ
Srisuresh Informational [Page 5] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[5ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
becomes very difficult to allow employees to access corporate resources, via the Internet, even if you are willing to forego security over the Internet.
あなたが、インターネットの上でセキュリティに先立っても構わないと思っても、従業員がインターネットを通して企業の諸資源にアクセスするのを許容するのが非常に難しくなります。
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の到来では、インターネットの向こう側に企業の中でSecurityゲートウェイを使うことによって法人のデータを保証するのは可能です。 ファイアウォールはIKEを許容するために構成されていたかもしれません、そして、IPsecパケットはファイアウォールの後ろに特定のSecurityにゲートウェイを向けました。 そして、企業にエントリーを求めている外部の接続に正しいアクセスリストを使うのはSecurityゲートウェイの責任になります。 本質的には、IPsecの安全なパケットのためのアクセス制御の機能性はSecurityゲートウェイに移行するでしょう(明確なパケットのためのアクセス制御がファイアウォールで保有されますが)。 以下の図はFirewallとSecurityゲートウェイの組み合わせが社内資源へのアクセスを制御するモデルを例証します。
Srisuresh Informational [Page 6] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[6ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
------------
( )
( )
( 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) )
(_________________ )
WAN| .........|\|.... | +-----------------+ |エンタープライズルータ| +-----------------+ | | 非武装地帯--ネットワーク------------------------------------------------------------ | | | +--+ +--+ +----------+ |__| |__| | ファイアウォール| /____\ /____\ +----------+ 非武装地帯名の非武装地帯ウェブ… | サーバサーバなど | LAN| ------------------------------------ | | +----------+ +------------------+ | LNS| | セキュリティゲートウェイ| | サーバ| | (SGW) | +----------+ +------------------+ | ------------------ ( ) (内部のネットワーク) (個人的である、)、(企業) (_________________ )
Figure 2: Security Model based on Firewall and Security Gateway
図2: FirewallとSecurityゲートウェイに基づくセキュリティModel
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はファイアウォールの後ろに置かれるかもしれません、そして、ファイアウォールはインターネットからUDPにLNSへのアクセスを許すために構成されるかもしれません。 注意、構成時にインターネットに位置したLACsのすべてのIPアドレスを知るのは可能でないかもしれません。 したがって、インターネットのどんなノードからもUDPにアクセスを許す必要性。 LNSは、L2TPパケットだけを処理して、L2TPでないどんなUDPパケットも下げるために構成されるかもしれません。
Srisuresh Informational [Page 7] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[7ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
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.
そのような構成はインターネットの上に遠隔アクセスを許容します。 しかしながら、上のセットアップはインターネットの上のさまざまなセキュリティー攻撃に傾向があります。 インターネットのだれかが遠隔アクセスのセッションを横取りして、企業に関する貴重な資源へのアクセスを得るのは、簡単です。 したがって、同じくらい認証できないならSecurityゲートウェイがIPパケットを企業ネットワークに許容しないように、すべてのパケットがIPsecと共にLNSの後ろのセキュリティゲートウェイ(SGW)として保存されるのは、重要です。
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.
安全な遠隔アクセスの信頼モデルは、企業とエンドユーザが信じられたドメインであると仮定します。 間のすべてが信じられません。 途中ノードによる終わりから終わりへのパケットのどんな試験もこの信頼モデルに違反するでしょう。 この見解から、終わりから終わりへのIPパケットで途中LACノードさえ信じてはいけません。 したがって、セキュリティについての議論において、LACの位置と操作は関連していません。 他方では、LNSとSecurityゲートウェイ(SGW)の位置と操作は正確に議論の基礎です。
Having security processing done on an independent Security gateway has the following shortcomings.
独立しているSecurityゲートウェイでセキュリティ処理をさせるのにおいて、以下の短所があります。
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. 遠隔アクセスのための信頼モデルを考えて、各ユーザのために1セットのセキュリティプロフィール、アクセスコントロールリスト、およびIKE認証パラメタでSGWを構成しなければなりません。 これは1ユーザあたり1個のベースに関するセキュリティパラメタに食糧を供給する独立者を強制します。 これは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ノードはリモート・ユーザーノードがいつ単に死んだかを知る方法かLAC-LNSトンネルに失敗されません。 もう存在しないユーザのためにSAsを削除できないなら、SGWはリソースから消されるかもしれません。 さらに、LNSはSGWが、同輩ノードが異なるかもしれないユーザIDをIKEに基礎づけたと主張するのでSGWへ立ち去るユーザを伝えることさえできません。LNSノードによって使われたユーザID。
Srisuresh Informational [Page 8] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[8ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
5. Secure Remote Access
5. 安全な遠隔アクセス
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 SecurityゲートウェイとLNSの機能をただ一つのシステムに結合するのは、安全な遠隔アクセスのために実行可能なソリューションを提供すると約束します。 そうすれば、遠隔アクセスのクライアントは(b) サービスをNASに供給する(a)PPP終了ポイントとSecurityゲートウェイノードの両方としてただ一つのノードを企業に使用するでしょう。 私たちは「安全な遠隔アクセスのサーバ」(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で詳細にRadiusで定義されるかもしれないセキュリティー属性について議論します。 言うまでもなく、Radiusの集結された食糧を供給する能力とスケーラビリティは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.
遠隔アクセスに関して、利益は信頼に適するとしてのセキュリティがモデル化するIPsecのひとりが終わりから終わりへのIPインターネットを横断するパケットのために企業で請求したということです。 あなたは単に、外部の盗聴への恐怖が全くありませんが、パケットデータを認証するのが単に必要であるAHを使用できます、パケットの源を含んでいて。 あなたは超能力を使用できます(超能力認証を含んでいて)、ネットワークの信頼が全くなくて、あなたが、企業行動を立ち聞きすることを許可したがっていないところで。
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の1つであるPPPと超能力パケットの中で埋め込まれて、それ自体に向けられたすべてのIPパケットを必要とするでしょう。 また、さらに、SRASはIKE交渉を実行して、ダイナミックにIPsecにキーを生成するためにそれ自体に向けられたパケット(500へのソースと仕向港セットがある)をIKE UDPに可能にするでしょう。 PPPの中で埋め込まれた他のすべてのIPパケットが下げられるでしょう。 これは、企業のために安全な遠隔アクセスのパケットだけを企業に可能にすることによって、安全保障政策を実施します。 PPPセッションが下げられるとき、遠隔アクセスのユーザに関連しているIPsecとISAKMP SAsはSRASから下げられます。 2台のシステムの上のLNSとSGWと共に前項で記載されたすべての短所が見えなくなります。小枝Secure Remote Access Server図3 以下に、遠隔アクセスがユーザであるとSRASシステムを使用することでサポートしながら、企業の典型的な記述があります。
Srisuresh Informational [Page 9] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[9ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
------------
Remote Access +-------------+ ( )
+--+______ Link | Local Access| ( )
|__| /___________| Concentrator|----( Internet )
/____\ | (LAC) | ( )
RA-Host +-------------+ (____________)
------------ 遠隔アクセス+-------------+ ( ) +--+______ リンク| 地方のアクセス| ( ) |__| /___________| 集中装置|----(インターネット) /____\ | (ラック) | ( ) RA-ホスト+-------------+ (____________)
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 (______________________)
WAN| .........|\|.... | +-----------------+ |エンタープライズルータ| +-----------------+ | | 非武装地帯--ネットワーク------------------------------------------ | | | +--+ +--+ +----------+ |__| |__| | ファイアウォール| /____\ /____\ +----------+ 非武装地帯名の非武装地帯ウェブ… | サーバサーバなど | LAN| ------------------------------------ | +---------------+ | 安全である、リモート| | アクセス・サーバー| | (SRAS) | +---------------+ | --------------------- ( ) +--+ (内部のネットワーク)|__|------(個人的である、)、/____\(企業) Ent-ホスト(______________________)
Figure 3: Secure Remote Access Server operation in an Enterprise
図3: エンタープライズでの安全なRemote Access Server操作
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を横断するとき、↓これは安全な遠隔アクセスのデータフローのイラストです。 企業(たとえば、Ent-ホスト)の中でリモートAccessホスト(RA-ホスト)とホストの間でパケットを交換するとき、例はIPパケットトンネリングとIPsec変換を示しています。
Srisuresh Informational [Page 10] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[10ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
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-ホストに向けたIPはPPPカプセル化の中で見せられますが、他のすべてのパケットが単にIPパケットとして見せられます。 L2TPトンネルの中でカプセル化されて、ずっとPPPパケットを目立たせるようにそれにこれをします。 以下のPPPヘッダーは挿入句の彼らの論理的なソースと目的地によって特定されます。 しかしながら、PPPデータのソースと受取人情報がPPPヘッダーの一部でないことに注意してください。 これはまさしく明快なようにこのようにして説明されます。 L2TPトンネルの場合では、L2TPヘッダーはPPPセッションIDを運びます。(間接的に、それは、LACとLNSにPPPエンドポイントを特定します)。 最後に、下のIPsec Headers部はトンネルに取り付けられるトンネリングオーバーヘッドとAH/超能力ヘッダーを含めます。
Srisuresh Informational [Page 11] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[11ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
RA-Host to Ent-Host Packet traversal: ------------------------------------
Ent-ホストPacket縦断へのRA-ホスト: ------------------------------------
RA-Host LAC SRAS Ent-Host =====================================================================
RA-ホストラックSRAS Ent-ホスト=====================================================================
+----------------------+
| 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) |
+----------------------+
---------------------->
+----------------------+ | pppヘッダー| | (>をRA接待しているSRAS) | +----------------------+ | トンネル・モードIPsec| | Hdr(s)(>を接待しているRA SRAS)| +----------------------+ | 終わりから終わりへのIPパケット| | 必要に応じて、変形します。| | (RA>を接待しているEnt-ホスト) | +----------------------+ ---------------------->。
+----------------------+
| 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) |
+----------------------+
---------------------->
+----------------------+ | IPヘッダー| | (ラック、-、>SRAS) | +----------------------+ | UDPヘッダー| +----------------------+ | L2TPヘッダー| | (incl。 PPP Sess-ID) | +----------------------+ | pppヘッダー| | (>をRA接待しているSRAS) | +----------------------+ | トンネル・モードIPsec| | Hdr(s)(>を接待しているRA SRAS)| +----------------------+ | 終わりから終わりへのIPパケット| | 必要に応じて、変形します。| | (RA>を接待しているEnt-ホスト) | +----------------------+ ---------------------->。
+----------------------+
| End-to-end IP packet |
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
+----------------------+ | 終わりから終わりへのIPパケット| | (RA>を接待しているEnt-ホスト) | +----------------------+ ---------------------->。
Srisuresh Informational [Page 12] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[12ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
Ent-Host to RA-Host Packet traversal: ------------------------------------
RA-ホストPacket縦断へのEnt-ホスト: ------------------------------------
Ent-Host SRAS LAC RA-Host =====================================================================
Ent-ホストSRASラックRA-ホスト=====================================================================
+----------------------+
| End-to-end IP packet |
| (Ent-Host->Ra-Host) |
+----------------------+
---------------------->
+----------------------+ | 終わりから終わりへのIPパケット| | (Ent>を接待しているRa-ホスト) | +----------------------+ ---------------------->。
+----------------------+
| 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) |
+----------------------+
---------------------->
+----------------------+ | IPヘッダー| | (SRAS->、ラック、) | +----------------------+ | UDPヘッダー| +----------------------+ | L2TPヘッダー| | (incl。 PPP Sess-ID) | +----------------------+ | pppヘッダー| | (SRAS->がRA接待する、) | +----------------------+ | トンネル・モードIPsec| | Hdr(s)、(SRAS->がRA接待する、)| +----------------------+ | 終わりから終わりへのIPパケット| | 必要に応じて、変形します。| | (Ent>を接待しているRA-ホスト) | +----------------------+ ---------------------->。
+----------------------+
| 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ヘッダー| | (SRAS->がRA接待する、) | +----------------------+ | トンネル・モードIPsec| | Hdr(s)、(SRAS->がRA接待する、)| +----------------------+ | 終わりから終わりへのIPパケット| | 必要に応じて、変形します。| | (Ent>を接待しているRA-ホスト) | +----------------------+ ---------------------->。
Srisuresh Informational [Page 13] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[13ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
6. Limitations to Secure Remote Access using L2TP
6. L2TPを使用して、遠隔アクセスを保証する制限
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でFragmentationを受けて、再アセンブリしなければならないかもしれません。 断片化と再アセンブリはパケットスループットと潜在に関する大破壊をそうすることができます。 しかしながら、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. 複数のアイデンティティと認証要件: リモートAccessユーザは、リンクへのアクセスを得ることになるように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.
しかしながら、LCPとIKEフェーズ1の間で共有できるただ一つの認証アプローチ(すなわち、単一のIDと認証機構)を持っているのは可能です。 Extended Authenticationプロトコル(EAP)[審判4]は、IKE認証機構をPPPに輸送するのにベースとして使用されるかもしれません。 注意、構成オーバーヘッドは機能性perseへの抗力ではありません。
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. Linkの弱いセキュリティは認証を平らにします: LCPパケットがインターネットを横断するとき、明確でリモート・ユーザーとパスワード(パスワードが使用されているなら)のIdentityを送ります。 これは、ネットのだれかが情報を横取りして、リモート・ユーザーのふりをするようにそれを目標にします。 しかしながら、このタイプのパスワード横取りがそういうものとして企業のセキュリティを危険にさらしませんが、リモート・ユーザーに対するサービスの否定をもたらすかもしれないことに注意してください。 侵入者は、パスワードデータを集めて、単にリンクを横取りできますが、次にどんなIPアプリケーションも実行できないでしょう、SRASが非IPsecパケットデータに失敗するとき。
Srisuresh Informational [Page 14] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[14ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
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.
より良いアプローチは、Extended Authenticationプロトコル(EAP)[審判4]を使って、インターネットをいつの間にか襲うことの傾向がない認証のテクニックを選択するだろうことです。 交互に、LACとSRASは、すべてのLCPが自分たちの間で交換されたトラフィックであると機密保護するのにIPsecを使用するために独自に構成されるかもしれません。
7. Configuring RADIUS to support Secure Remote Access.
7. Secure Remote AccessをサポートするためにRADIUSを構成します。
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データベースは、ダイヤルインのUsersの認証と承認要件を維持するのに企業によって使用されます。 それは、また、そのダイレクトダイヤルインのアクセス(ネットワークは例えば、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を参照してください)。
7.1. Security mandate based on access method
7.1. アクセス法に基づくセキュリティ命令
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)は各ユーザのために定義されるかもしれません。 以下の値の1つをこの属性に与えるかもしれません。
NONE (=0) No IPsec mandated on the IP packets
embedded within PPP.
NONE(=0)いいえ、IPsecはIPでPPPの中で埋め込まれたパケットを強制しました。
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パケットの上でTunnelモード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パケットの上でTunnelモードIPsecを強制します、PPPが終わるNASタイプの如何にかかわらず。 すなわち、IPsec命令は、単独でLNSに特定でなく、PPPを終えて、どんなNASにも適切です。 NASはトンネルモードIPsecエンドポイントでしょう。
Srisuresh Informational [Page 15] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[15ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
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.
MANDATEが結果と考えるIPSEC_がLNS_AS_SRASの1つへのセットかSRASであるときに、それは、AHか超能力プロトコルに関連づけられないPPPであらゆるIPパケットを下げるようNASに指示するでしょう。 例外として、NASは、リモート・ユーザーから指示されたIKEパケット(500に用意ができているソースと仕向港があるUDPパケット)を処理し続けるでしょう。 さらに、パラメタであって、以下のセクションで定義されたセキュリティプロフィールはセキュリティが義務的でない追加評価基準を加えるかもしれません。
7.2. Security profile for the user
7.2. ユーザへのセキュリティプロフィール
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) (各安全保障政策に関連しているセキュリティAssociationセキュリティ好み)を含むべきです。
7.3. IKE negotiation profile for the user
7.3. ユーザへのIKE交渉プロフィール
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の新しいイケ_NEGOTIATION_PROFILE(93)パラメタを使用することで構成されるかもしれません。 イケ、-ファイル名は一連のキャラクタとしてPROFILEが結果と考えるNEGOTIATION_に割り当てられるかもしれません。 しかしながら、ファイルのコンテンツはベンダー特有であるかもしれません。 コンテンツは(a) ユーザとSRASのIKE IDを通常含んでいるでしょう、そして、(b)はX.509のデジタルCertificateよりあらかじめ共有されたキーか指針などの認証アプローチと関連パラメタを好みました。(c) フェーズIのためのISAKMPセキュリティ交渉好み。
8. Acknowledgements
8. 承認
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.
作者は、初めはようにこの考えを示しながら、スティーブ・ウィレンスに心からの感謝を申し上げたがっています。 また、スティーブに、作者も多くの作者でRemote Access領域のさまざまの必要性に感謝できるのにおいて手段になっている非公式会談のために感謝しています。
Srisuresh Informational [Page 16] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[16ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
9. Security Considerations
9. セキュリティ問題
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インフラストラクチャに制限されません。 また、それはFrame RelayやATM雲などの他の輸送メディアの上に適用されるかもしれません。 輸送メディアが信じられた個人的なネットワークインフラであるなら、問題の多くとして測定が説明したセキュリティがないかもしれません。 ドキュメントに示されたソリューションは視点でリモート・ユーザーと企業の間の信頼モデルを保っています。
10. IANA Considerations
10. IANA問題
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つの新しいRADIUS属性を提案します。 値91、92、および93は認識された半径タイプのために定義と衝突しないようにそれぞれこれらの属性のIPSEC_MANDATE、SECURITY_PROFILE、およびイケ_NEGOTIATION_PROFILEに割り当てられるかもしれません、 http://www.isi.edu/in-notes/iana/assignments/radius-types で定義されるように。
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.
以下の小区分で、IPSEC-MANDATE属性への値がセクション7.1で説明したように追加数を割り当てるのにIANAによって使用されるように、評価基準がわかります。
10.1. IPSEC-MANDATE attribute Value
10.1. IPSEC-MANDATE属性Value
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-タイプAttributeの値0-2はセクション7.1で定義されます。 残余価値[3-255]はIETF Consensus[審判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.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらわれます、「層TwoはプロトコルL2TPにトンネルを堀っ」て、RFC2661、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.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[3] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[4] Blunk, L. and Vollbrecht, J. "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[4]BlunkとL.と1998年のVollbrecht、J.「ppp拡張認証プロトコル(EAP)」、RFC2284行進。
Srisuresh Informational [Page 17] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[17ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
[5] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[5] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[6] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[7] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[7] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[8] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[9] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[9] パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、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.ポステル、「規定番号」、STD2、RFC1700、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 Considerationsセクションに書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[12] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC
1968, June 1996.
[12] マイヤー、G.、「ppp暗号化制御プロトコル(ECP)」、RFC1968 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(2回DESE)」、RFC2419 1998年9月。
Author's Address
作者のアドレス
Pyda Srisuresh Campio Communications 630 Alder Drive Milpitas, CA 95035 U.S.A.
Pyda Srisuresh Campioコミュニケーション630ハンノキDriveカリフォルニア95035ミルピタス(米国)
Phone: +1 (408) 519-3849 EMail: srisuresh@yahoo.com
以下に電話をしてください。 +1 (408) 519-3849 メールしてください: srisuresh@yahoo.com
Srisuresh Informational [Page 18] RFC 2888 Secure Remote Access with L2TP August 2000
Srisureshの情報[18ページ]のRFC2888は2000年8月にL2TPと共に遠隔アクセスを保証します。
Full Copyright Statement
完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Srisuresh Informational [Page 19]
Srisuresh情報です。[19ページ]
一覧
スポンサーリンク
