RFC3193 日本語訳
3193 Securing L2TP using IPsec. B. Patel, B. Aboba, W. Dixon, G. Zorn,S. Booth. November 2001. (Format: TXT=63804 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Patel
Request for Comments: 3193 Intel
Category: Standards Track B. Aboba
W. Dixon
Microsoft
G. Zorn
S. Booth
Cisco Systems
November 2001
コメントを求めるワーキンググループB.パテル要求をネットワークでつないでください: 3193年のインテルカテゴリ: 標準化過程B.Aboba W.ディクソンマイクロソフトG.ゾルンS.ブースシスコシステムズ2001年11月
Securing L2TP using IPsec
IPsecを使用することでL2TPを固定します。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed.
このドキュメントはL2TP(層のTwo Tunnelingプロトコル)がトンネル認証、プライバシー保護、保全の照合、および反復操作による保護に備えるのにどうIPsecを利用するかもしれないかについて議論します。 両方の自発的の、そして、強制的なトンネリングケースについて議論します。
Patel, et al. Standards Track [Page 1] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[1ページ]RFC3193
Table of Contents
目次
1. Introduction .................................................. 2 1.1 Terminology .................................................. 3 1.2 Requirements language ........................................ 3 2. L2TP security requirements ................................... 4 2.1 L2TP security protocol ....................................... 5 2.2 Stateless compression and encryption ......................... 5 3. L2TP/IPsec inter-operability guidelines ....................... 6 3.1. L2TP tunnel and Phase 1 and 2 SA teardown ................... 6 3.2. Fragmentation Issues ........................................ 6 3.3. Per-packet security checks .................................. 7 4. IPsec Filtering details when protecting L2TP .................. 7 4.1. IKE Phase 1 Negotiations .................................... 8 4.2. IKE Phase 2 Negotiations .................................... 8 5. Security Considerations ....................................... 15 5.1 Authentication issues ........................................ 15 5.2 IPsec and PPP interactions ................................... 18 6. References .................................................... 21 Acknowledgments .................................................. 22 Authors' Addresses ............................................... 23 Appendix A: Example IPsec Filter sets ............................ 24 Intellectual Property Statement .................................. 27 Full Copyright Statement ......................................... 28
1. 序論… 2 1.1用語… 3 1.2 要件言語… 3 2. L2TPセキュリティ要件… 4 2.1 L2TPセキュリティは議定書を作ります… 5 2.2の状態がない圧縮と暗号化… 5 3. L2TP/IPsec相互運用性ガイドライン… 6 3.1. L2TPトンネルとPhase1と2SA分解… 6 3.2. 断片化問題… 6 3.3. 1パケットあたりのセキュリティチェック… 7 4. IPsec FilteringはL2TPを保護しながら、いつかを詳しく述べます… 7 4.1. IKEフェーズ1交渉… 8 4.2. IKEは2つの交渉の位相を合わせます… 8 5. セキュリティ問題… 15 5.1 認証問題… 15 5.2 IPsecとPPP相互作用… 18 6. 参照… 21の承認… 22人の作者のアドレス… 23 付録A: 例のIPsec Filterはセットします… 24 知的所有権声明… 27 完全な著作権宣言文… 28
1. Introduction
1. 序論
L2TP [1] is a protocol that tunnels PPP traffic over variety of networks (e.g., IP, SONET, ATM). Since the protocol encapsulates PPP, L2TP inherits PPP authentication, as well as the PPP Encryption Control Protocol (ECP) (described in [10]), and the Compression Control Protocol (CCP) (described in [9]). L2TP also includes support for tunnel authentication, which can be used to mutually authenticate the tunnel endpoints. However, L2TP does not define tunnel protection mechanisms.
L2TP[1]はネットワーク(例えば、IP、Sonet、ATM)のバラエティーの上でPPPトラフィックにトンネルを堀るプロトコルです。 プロトコルがPPPをカプセル化するので、L2TPはPPP認証を引き継ぎます、PPP Encryption Controlプロトコル(ECP)と同様に([10])、およびCompression Controlでプロトコル(CCP)について説明する、([9])では、説明されます。 また、L2TPはトンネル認証のサポートを含んでいます。(互いにトンネル終点を認証するのに認証を使用できます)。 しかしながら、L2TPはトンネル保護メカニズムを定義しません。
IPsec is a protocol suite which is used to secure communication at the network layer between two peers. This protocol is comprised of IP Security Architecture document [6], IKE, described in [7], IPsec AH, described in [3] and IPsec ESP, described in [4]. IKE is the key management protocol while AH and ESP are used to protect IP traffic.
IPsecは2人の同輩の間のネットワーク層でコミュニケーションを保証するのに使用されるプロトコル群です。 このプロトコルはIP Security Architectureドキュメント[6]から成って、[7]、IPsec AHで説明されたIKEは[3]とIPsecで[4]で説明された超能力について説明しました。 AHと超能力はIPトラフィックを保護するのに使用されますが、IKEはかぎ管理プロトコルです。
This document proposes use of the IPsec protocol suite for protecting L2TP traffic over IP networks, and discusses how IPsec and L2TP should be used together. This document does not attempt to
このドキュメントは、IPsecプロトコル群のIPネットワークの上にL2TPトラフィックを保護する使用を提案して、IPsecとL2TPがどう一緒に使用されるべきであるかについて議論します。 このドキュメントは、試みません。
Patel, et al. Standards Track [Page 2] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[2ページ]RFC3193
standardize end-to-end security. When end-to-end security is required, it is recommended that additional security mechanisms (such as IPsec or TLS [14]) be used inside the tunnel, in addition to L2TP tunnel security.
終わりから終わりへのセキュリティを標準化してください。 終わりから終わりへのセキュリティが必要であるときに、その追加担保メカニズムはそれに推薦されます。(IPsecかTLS[14])としてのそのようなものがトンネルの中で使用されて、L2TPに加えてセキュリティにトンネルを堀ってください。
Although L2TP does not mandate the use of IP/UDP for its transport mechanism, the scope of this document is limited to L2TP over IP networks. The exact mechanisms for enabling security for non-IP networks must be addressed in appropriate standards for L2TP over specific non-IP networks.
L2TPはIP/UDPの移送機構の使用を強制しませんが、このドキュメントの範囲はIPネットワークの上でL2TPに制限されます。 特定の非IPネットワークの上でL2TPの適切な規格で非IPネットワークのためにセキュリティを可能にするための正確なメカニズムを扱わなければなりません。
1.1. Terminology
1.1. 用語
Voluntary Tunneling
In voluntary tunneling, a tunnel is created by the user,
typically via use of a tunneling client. As a result, the
client will send L2TP packets to the NAS which will forward
them on to the LNS. In voluntary tunneling, the NAS does
not need to support L2TP, and the LAC resides on the same
machine as the client. Another example of voluntary
tunneling is the gateway to gateway scenario. In this case
the tunnel is created by a network device, typically a
router or network appliance. In this scenario either side
may start the tunnel on demand.
自発的のTunneling In自発的のトンネリング、トンネルはそうです。通常トンネリングクライアントの使用でユーザによって作成されます。 その結果、クライアントは彼らをLNSに送るNASへのパケットをL2TPに送るでしょう。 自発的のトンネリングでは、NASはL2TPをサポートする必要はありません、そして、LACはクライアントと同じマシンの上に住んでいます。 自発的のトンネリングに関する別の例はゲートウェイシナリオへのゲートウェイです。 この場合、トンネルは通常ネットワークデバイス、ルータまたはネットワーク器具によって作成されます。 このシナリオでは、どちらの側もオンデマンドのトンネルを始動するかもしれません。
Compulsory Tunneling
In compulsory tunneling, a tunnel is created without any
action from the client and without allowing the client any
choice. As a result, the client will send PPP packets to
the NAS/LAC, which will encapsulate them in L2TP and tunnel
them to the LNS. In the compulsory tunneling case, the
NAS/LAC must be L2TP-capable.
強制的なTunneling In強制的なトンネリング、トンネルはクライアントからのどんな動作なしでもどんな選択もクライアントに許すことなしで作成されます。 その結果、クライアントはNAS/LACへのパケットをPPPに送るでしょう。(NAS/LACはL2TPでそれらをカプセル化して、LNSにそれらにトンネルを堀るでしょう)。 強制的なトンネリング場合では、NAS/LACはL2TPできなければなりません。
Initiator The initiator can be the LAC or the LNS and is the device
which sends the SCCRQ and receives the SCCRP.
創始者、創始者は、LACかLNSであることができ、SCCRQを送るデバイスであり、SCCRPを受け取ります。
Responder The responder can be the LAC or the LNS and is the device
which receives the SCCRQ and replies with a SCCRP.
応答者、応答者は、LACかLNSであることができ、a SCCRPとのSCCRQと回答を受け取るデバイスです。
1.2. Requirements language
1.2. 要件言語
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [2].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[2]で説明されるように解釈されることになっていてください、」であるべきです
Patel, et al. Standards Track [Page 3] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[3ページ]RFC3193
2. L2TP security requirements
2. L2TPセキュリティ要件
L2TP tunnels PPP traffic over the IP and non-IP public networks. Therefore, both the control and data packets of L2TP protocol are vulnerable to attack. Examples of attacks include:
L2TPはIPと非IP公衆通信回線の上でPPPトラフィックにトンネルを堀ります。 したがって、コントロールとL2TPプロトコルのデータ・パケットの両方が、攻撃するために被害を受け易いです。 攻撃に関する例は:
[1] An adversary may try to discover user identities by snooping data
packets.
[1] 敵は、データ・パケットについて詮索することによって、ユーザアイデンティティを発見しようとするかもしれません。
[2] An adversary may try to modify packets (both control and data).
[2] 敵はパケット(コントロールとデータの両方)を変更しようとするかもしれません。
[3] An adversary may try to hijack the L2TP tunnel or the PPP
connection inside the tunnel.
[3] 敵はトンネルの中でL2TPトンネルかPPP接続をハイジャックしようとするかもしれません。
[4] An adversary can launch denial of service attacks by terminating
PPP connections, or L2TP tunnels.
[4] PPP接続、またはL2TPトンネルを終えることによって、敵はサービス不能攻撃に着手できます。
[5] An adversary may attempt to disrupt the PPP ECP negotiation in
order to weaken or remove confidentiality protection.
Alternatively, an adversary may wish to disrupt the PPP LCP
authentication negotiation so as to weaken the PPP authentication
process or gain access to user passwords.
[5] 敵は、秘密性保護を弱めるか、または取り除くためにPPP ECP交渉を中断するのを試みるかもしれません。 あるいはまた、敵は、PPP認証過程を弱めるか、またはユーザパスワードへのアクセスを得るためにPPP LCP認証交渉を中断したがっているかもしれません。
To address these threats, the L2TP security protocol MUST be able to provide authentication, integrity and replay protection for control packets. In addition, it SHOULD be able to protect confidentiality for control packets. It MUST be able to provide integrity and replay protection of data packets, and MAY be able to protect confidentiality of data packets. An L2TP security protocol MUST also provide a scalable approach to key management.
これらの脅威を扱うために、L2TPセキュリティプロトコルはコントロールパケットのための認証、保全、および反復操作による保護を提供できなければなりません。 さらに、それ、SHOULD、コントロールパケットのために秘密性を保護できてください。 それは、データ・パケットの保全と反復操作による保護を提供できなければならなくて、データ・パケットの秘密性を保護できるかもしれません。 また、L2TPセキュリティプロトコルはかぎ管理へのスケーラブルなアプローチを提供しなければなりません。
The L2TP protocol, and PPP authentication and encryption do not meet the security requirements for L2TP. L2TP tunnel authentication provides mutual authentication between the LAC and the LNS at tunnel origination. Therefore, it does not protect control and data traffic on a per packet basis. Thus, L2TP tunnel authentication leaves the L2TP tunnel vulnerable to attacks. PPP authenticates the client to the LNS, but also does not provide per-packet authentication, integrity, or replay protection. PPP encryption meets confidentiality requirements for PPP traffic but does not address authentication, integrity, replay protection and key management requirements. In addition, PPP ECP negotiation, outlined in [10] does not provide for a protected ciphersuite negotiation. Therefore, PPP encryption provides a weak security solution, and in addition does not assist in securing L2TP control channel.
L2TPは議定書を作ります、そして、PPP認証と暗号化はL2TPのためのセキュリティ必要条件を満たしません。 L2TPトンネル認証はトンネル創作でLACとLNSの間に互いの認証を供給します。 したがって、それはパケット基礎あたりのaにおけるコントロールとデータ通信量を保護しません。 したがって、L2TPトンネル認証は攻撃に被害を受け易いトンネルにL2TPを発ちます。 また、1パケットあたりの認証、保全、または反復操作による保護を提供しないのを除いて、PPPはLNSにクライアントを認証します。 PPP暗号化は、PPPトラフィックのための機密保持の要求事項を満たしますが、認証、保全、反復操作による保護、およびかぎ管理に要件を扱いません。 さらに、交渉であって、[10]に概説されたPPP ECPは保護されたciphersuite交渉に備えません。 したがって、PPP暗号化は、弱いセキュリティ解決法を前提として、L2TPが制御チャンネルであると機密保護するのをさらに、助けません。
Patel, et al. Standards Track [Page 4] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[4ページ]RFC3193
Key management facilities are not provided by the L2TP protocol. However, where L2TP tunnel authentication is desired, it is necessary to distribute tunnel passwords.
かぎ管理施設はL2TPプロトコルによって提供されません。 しかしながら、L2TPトンネル認証が望まれているところでは、トンネルパスワードを分配するのが必要です。
Note that several of the attacks outlined above can be carried out on PPP packets sent over the link between the client and the NAS/LAC, prior to encapsulation of the packets within an L2TP tunnel. While strictly speaking these attacks are outside the scope of L2TP security, in order to protect against them, the client SHOULD provide for confidentiality, authentication, replay and integrity protection for PPP packets sent over the dial-up link. Authentication, replay and integrity protection are not currently supported by PPP encryption methods, described in [11]-[13].
L2TPトンネルの中のパケットのカプセル化の前にクライアントとNAS/LACとのリンクの上に送られたPPPパケットの上で上に概説されたいくつかの攻撃は行うことができることに注意してください。 厳密に言うと、L2TPセキュリティの範囲の外にこれらの攻撃がそれらから守るためにある間、クライアントSHOULDはダイヤルアップリンクの上に送られたPPPパケットのための秘密性、認証、再生、および保全保護に備えます。 認証、再生、および保全保護は現在、[11]で説明されたPPP暗号化メソッドでサポートされません--[13]。
2.1. L2TP Security Protocol
2.1. L2TPセキュリティプロトコル
The L2TP security protocol MUST provide authentication, integrity and replay protection for control packets. In addition, it SHOULD protect confidentiality of control packets. It MUST provide integrity and replay protection of data packets, and MAY protect confidentiality of data packets. An L2TP security protocol MUST also provide a scalable approach to key management.
L2TPセキュリティプロトコルはコントロールパケットのための認証、保全、および反復操作による保護を提供しなければなりません。 さらに、それ、SHOULDはコントロールパケットの秘密性を保護します。 それは、データ・パケットの保全と反復操作による保護を提供しなければならなくて、データ・パケットの秘密性を保護するかもしれません。 また、L2TPセキュリティプロトコルはかぎ管理へのスケーラブルなアプローチを提供しなければなりません。
To meet the above requirements, all L2TP security compliant implementations MUST implement IPsec ESP for securing both L2TP control and data packets. Transport mode MUST be supported; tunnel mode MAY be supported. All the IPsec-mandated ciphersuites (described in RFC 2406 [4] and RFC 2402 [3]), including NULL encryption MUST be supported. Note that although an implementation MUST support all IPsec ciphersuites, it is an operator choice which ones will be used. If confidentiality is not required (e.g., L2TP data traffic), ESP with NULL encryption may be used. The implementations MUST implement replay protection mechanisms of IPsec.
上記の必要条件を満たすために、すべてのL2TPのセキュリティ対応することの実装が、L2TPコントロールとデータ・パケットの両方を機密保護するためにIPsecが超能力であると実装しなければなりません。 交通機関をサポートしなければなりません。 トンネルモードはサポートされるかもしれません。 IPsecにすべての強制がciphersuitesされます。(RFC2406[4]とRFC2402[3])で説明されて、NULL暗号化を含んでいるのをサポートしなければなりません。 実装がすべてのIPsec ciphersuitesをサポートしなければなりませんが、それが使用されるオペレータ選択であることに注意してください。 秘密性は必要でないなら(例えば、L2TPデータ通信量)、NULL暗号化がある超能力は使用されるかもしれません。 実装は、反復操作による保護がIPsecのメカニズムであると実装しなければなりません。
L2TP security MUST meet the key management requirements of the IPsec protocol suite. IKE SHOULD be supported for authentication, security association negotiation, and key management using the IPsec DOI [5].
L2TPセキュリティはIPsecプロトコル群に関するかぎ管理必要条件を満たさなければなりません。 IKE SHOULDは、認証、セキュリティ協会交渉のためにサポートされて、IPsec DOI[5]を使用することで管理を合わせます。
2.2. Stateless compression and encryption
2.2. 状態がない圧縮と暗号化
Stateless encryption and/or compression is highly desirable when L2TP is run over IP. Since L2TP is a connection-oriented protocol, use of stateful compression/encryption is feasible, but when run over IP, this is not desirable. While providing better compression, when used without an underlying reliable delivery mechanism, stateful methods magnify packet losses. As a result, they are problematic when used over the Internet where packet loss can be significant. Although L2TP [1] is connection oriented, packet ordering is not mandatory,
L2TPがIPの上に実行されるとき、状態がない暗号化、そして/または、圧縮は非常に望ましいです。 L2TPが接続指向のプロトコルであるので、stateful圧縮/暗号化の使用は可能ですが、IPの上に実行される場合、これは望ましくはありません。 基本的な信頼できる配信メカニズムなしで使用されると、より良い圧縮を提供している間、statefulメソッドはパケット損失を拡大します。 その結果、パケット損失が重要である場合があるインターネットの上で使用されると、それらは問題が多いです。 L2TP[1]は適応する接続ですが、パケット注文は義務的ではありません。
Patel, et al. Standards Track [Page 5] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[5ページ]RFC3193
which can create difficulties in implementation of stateful compression/encryption schemes. These considerations are not as important when L2TP is run over non-IP media such as IEEE 802, ATM, X.25, or Frame Relay, since these media guarantee ordering, and packet losses are typically low.
stateful圧縮/暗号化体系の実装における困難を作成できます。 L2TPがIEEE802、ATM、X.25、またはFrame Relayなどの非IPメディアの上に実行されるとき、これらの問題は重要ではありません、これらのメディアが注文を保証して、パケット損失が通常低いので。
3. L2TP/IPsec inter-operability guidelines
3. L2TP/IPsec相互運用性ガイドライン
The following guidelines are established to meet L2TP security requirements using IPsec in practical situations.
以下のガイドラインは、実用的な状況でIPsecを使用することでL2TPセキュリティ必要条件を満たすために確立されます。
3.1. L2TP tunnel and Phase 1 and 2 SA teardown
3.1. L2TPトンネルとPhase1と2SA分解
Mechanisms within PPP and L2TP provide for both graceful and non- graceful teardown. In the case of PPP, an LCP TermReq and TermAck sequence corresponds to a graceful teardown. LCP keep-alive messages and L2TP tunnel hellos provide the capability to detect when a non- graceful teardown has occurred. Whenever teardown events occur, causing the tunnel to close, the control connection teardown mechanism defined in [1] must be used. Once the L2TP tunnel is deleted by either peer, any phase 1 and phase 2 SA's which still exist as a result of the L2TP tunnel between the peers SHOULD be deleted. Phase 1 and phase 2 delete messages SHOULD be sent when this occurs.
PPPとL2TPの中のメカニズムは優雅で非優雅の両方分解を生じます。 PPPの場合では、LCP TermReqとTermAck系列は優雅な分解に対応しています。 LCPはメッセージを生かします、そして、L2TPトンネルhellosは非優雅な分解がいつ起こったかを検出する能力を提供します。 トンネルが閉じることを引き起こして、分解イベントが起こるときはいつも、[1]で定義された制御接続分解メカニズムを使用しなければなりません。 L2TPトンネルがどちらの同輩によってもいったん削除されると、同輩SHOULDの間のL2TPトンネルの結果、まだ存在しているどんなフェーズ1とフェーズ2SAも削除されました。 フェーズ1とフェーズ2はメッセージSHOULDを削除します。いつを送って、これが起こるということになってください。
When IKE receives a phase 1 or phase 2 delete message, IKE should notify L2TP this event has occurred. If the L2TP state is such that a ZLB ack has been sent in response to a STOPCCN, this can be assumed to be positive acknowledgment that the peer received the ZLB ack and has performed a teardown of any L2TP tunnel state associated with the peer. The L2TP tunnel state and any associated filters can now be safely removed.
IKEは、IKEがいつフェーズ1かフェーズ2を受けるかがメッセージを削除するようにL2TPに通知するはずです。このイベントは起こりました。 L2TP状態がそのようなものであるのでSTOPCCNに対応してZLB ackを送ったなら、これは、同輩がZLB ackを受け取ったという肯定応答であると思うことができて、同輩に関連しているどんなL2TPトンネル州の分解も実行しました。 現在、安全にL2TPトンネル州とどんな関連フィルタも取り外すことができます。
3.2. Fragmentation Issues
3.2. 断片化問題
Since the default MRU for PPP connections is 1500 bytes, fragmentation can become a concern when prepending L2TP and IPsec headers to a PPP frame. One mechanism which can be used to reduce this problem is to provide PPP with the MTU value of the ingress/egress interface of the L2TP/IPsec tunnel minus the overhead of the extra headers. This should occur after the L2TP tunnel has been setup and but before LCP negotiations begin. If the MTU value of the ingress/egress interface for the tunnel is less than PPP's default MTU, it may replace the value being used. This value may also be used as the initial value proposed for the MRU in the LCP config req.
PPP接続のためのデフォルトMRUが1500バイトであるので、PPPフレームへのprepending L2TPとIPsecヘッダーであるときに、断片化は関心になることができます。 この問題を減少させるのに使用できる1つのメカニズムは付加的なヘッダーのオーバーヘッドを引いてL2TP/IPsecトンネルのイングレス/出口のインタフェースのMTU値をPPPに提供することです。 これはL2TPトンネルがセットアップであることの後としかし、交渉が始めるLCPの前に起こるべきです。 トンネルへのイングレス/出口のインタフェースのMTU値がPPPのデフォルトMTU以下であるなら、それは使用される値を取り替えるかもしれません。 また、初期の値がLCPコンフィグreqのMRUのために提案したようにこの値は使用されるかもしれません。
Patel, et al. Standards Track [Page 6] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[6ページ]RFC3193
If an ICMP PMTU is received by IPsec, this value should be stored in the SA as proposed in [6]. IPsec should also provide notification of this event to L2TP so that the new MTU value can be reflected into the PPP interface. Any new PTMU discoveries seen at the PPP interface should be checked against this new value and processed accordingly.
ICMP PMTUがIPsecによって受け取られるなら、この値は[6]で提案されるようにSAに保存されるべきです。 また、IPsecは、新しいMTU値をPPPインタフェースに反映できるようにこのイベントの通知をL2TPに供給するはずです。 PPPインタフェースで見られたどんな新しいPTMU発見も、この新しい値に対してチェックされて、それに従って、処理されるべきです。
3.3. Per-packet security checks
3.3. 1パケットあたりのセキュリティチェック
When a packet arrives from a tunnel which requires security, L2TP MUST:
パケットがセキュリティ、L2TP MUSTを必要とするトンネルから到着すると:
[1] Check to ensure that the packet was decrypted and/or
authenticated by IPsec. Since IPsec already verifies that the
packet arrived in the correct SA, L2TP can be assured that the
packet was indeed sent by a trusted peer and that it did not
arrive in the clear.
[1] チェックして、パケットがIPsecによって解読される、そして/または、認証されたのを保証してください。 IPsecが、パケットが正しいSAに到着したことを既に確かめるので、本当に、パケットが信じられた同輩によって送られて、それが明確に到着しなかったことをL2TPを保証できます。
[2] Verify that the IP addresses and UDP port values in the packet
match the socket information which was used to setup the L2TP
tunnel. This step prevents malicious peers from spoofing packets
into other tunnels.
[2] パケットのIPアドレスとUDPポート値がL2TPトンネルをセットアップするのに使用されたソケット情報に合っていることを確かめてください。 このステップによって、悪意がある同輩は他のトンネルにパケットを偽造することができません。
4. IPsec Filtering details when protecting L2TP
4. IPsec Filteringは、L2TPを保護しながら、いつかを詳しく述べます。
Since IKE/IPsec is agnostic about the nuances of the application it is protecting, typically no integration is necessary between the application and the IPsec protocol. However, protocols which allow the port number to float during the protocol negotiations (such as L2TP), can cause problems within the current IKE framework. The L2TP specification [1] states that implementations MAY use a dynamically assigned UDP source port. This port change is reflected in the SCCRP sent from the responder to the initiator.
IKE/IPsecがアプリケーションのニュアンスに関して不可知論者であるので、通常どんな統合もアプリケーションとIPsecプロトコルの間にそれを保護されている必要はありません。 しかしながら、ポートナンバーが議定書交渉(L2TPなどの)の間に浮くプロトコル、現在のIKEフレームワークの中の原因問題はそうすることができます。 L2TP仕様[1]は、実装がダイナミックに割り当てられたUDPソースポートを使用するかもしれないと述べます。 このポート変化は応答者から創始者に送られたSCCRPに反映されます。
Although the current L2TP specification allows the responder to use a new IP address when sending the SCCRP, implementations requiring protection of L2TP via IPsec SHOULD NOT do this. To allow for this behavior when using L2TP and IPsec, when the responder chooses a new IP address it MUST send a StopCCN to the initiator, with the Result and Error Code AVP present. The Result Code MUST be set to 2 (General Error) and the Error Code SHOULD be set to 7 (Try Another). If the Error Code is set to 7, then the optional error message MUST be present and the contents MUST contain the IP address (ASCII encoded) that the Responder desires to use for subsequent communications. Only the ASCII encoded IP address should be present in the error message. The IP address is encoded in dotted decimal format for IPv4 or in RFC 2373 [17] format for IPv6. The initiator MUST parse the result and error code information and send a new SCCRQ
SCCRPを送るとき、応答者は現在のL2TP仕様で新しいIPアドレスを使用できますが、IPsec SHOULDを通してL2TPの保護を必要とする実装がこれをしません。 応答者が新しいIPアドレスを選ぶとL2TPとIPsecを使用するときのこの振舞いを考慮するために、StopCCNを創始者に送らなければなりません、ResultとError Code AVPが存在していた状態で。 Result Codeは7へのセットが(トライAnother)であったなら2(Error司令官)とError Code SHOULDに用意ができなければなりません。 Error Codeが7に用意ができているなら、任意のエラーメッセージは存在していなければなりません、そして、コンテンツはResponderがその後のコミュニケーションに使用することを望んでいるIPアドレス(コード化されたASCII)を含まなければなりません。 コード化されたIPが扱うASCIIは単にエラーメッセージに存在しているべきです。 IPアドレスはIPv4のためのドット付き10進法形式かIPv6のためのRFC2373[17]形式でコード化されます。 創始者は、結果とエラーコード情報を分析して、新しいSCCRQを送らなければなりません。
Patel, et al. Standards Track [Page 7] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[7ページ]RFC3193
to the new IP address contained in the error message. This approach reduces complexity since now the initiator always knows precisely the IP address of its peer. This also allows a controlled mechanism for L2TP to tie IPsec filters and policy to the same peer.
エラーメッセージに含まれた新しいIPアドレスに。 創始者が今いつも正確に同輩のIPアドレスを知っているので、このアプローチは複雑さを減少させます。 また、L2TPがIPsecフィルタと方針を同じ同輩に結ぶように、これは制御メカニズムを許容します。
The filtering details required to accommodate this behavior as well as other mechanisms needed to protect L2TP with IPsec are discussed in the following sections.
以下のセクションでIPsecと共にL2TPを保護するのが必要である他のメカニズムと同様にこの振舞いを収容するのに必要であるフィルタリングの詳細について議論します。
4.1. IKE Phase 1 Negotiations
4.1. IKEフェーズ1交渉
Per IKE [7], when using pre-shared key authentication, a key must be present for each peer to which secure communication is required. When using Main Mode (which provides identity protection), this key must correspond to the IP address for the peer. When using Aggressive Mode (which does not provide identity protection), the pre-shared key must map to one of the valid id types defined in the IPsec DOI [5].
あらかじめ共有された主要な認証を使用するとき、IKE[7]に従って、キーは安全なコミュニケーションが必要である各同輩のために存在していなければなりません。 Main Mode(アイデンティティ保護を提供する)を使用するとき、このキーは同輩のためのIPアドレスに対応しなければなりません。 Aggressive Mode(アイデンティティ保護を提供しない)を使用するとき、あらかじめ共有されたキーはIPsec DOI[5]で定義されたタイプを有効なイドの1つに写像しなければなりません。
If the initiator receives a StopCCN with the result and error code AVP set to "try another" and a valid IP address is present in the message, it MAY bind the original pre-shared key used by IKE to the new IP address contained in the error-message.
創始者がAVPが「別のものを試みます」ように設定する結果とエラーコードでStopCCNを受け取って、有効なIPアドレスがメッセージに存在しているなら、それはIKEによってエラーメッセージに含まれた新しいIPアドレスに使用されたオリジナルのあらかじめ共有されたキーを縛るかもしれません。
One may may wish to consider the implications for scalability of using pre-shared keys as the authentication method for phase 1. As the number of LAC and LNS endpoints grow, pre-shared keys become increasingly difficult to manage. Whenever possible, authentication with certificates is preferred.
1は願うかもしれません。フェーズ1に認証方法としてあらかじめ共有されたキーを使用するスケーラビリティのために含意を考えることを願うかもしれません。 LACの数とLNS終点が発展するのに従って、あらかじめ共有されたキーは管理するのがますます難しくなります。 可能であるときはいつも、証明書による認証は好まれます。
4.2. IKE Phase 2 Negotiations
4.2. IKEフェーズ2交渉
During the IKE phase 2 negotiations, the peers agree on what traffic is to be protected by the IPsec protocols. The quick mode IDs represent the traffic which the peers agree to protect and are comprised of address space, protocol, and port information.
IKEフェーズ2交渉の間、同輩は、どんなトラフィックがIPsecプロトコルによって保護されるかことであるかに同意します。 迅速なモードIDは、同輩が保護するのに同意するトラフィックを表して、アドレス空間から成って、議定書を作って、情報を移植します。
When securing L2TP with IPsec, the following cases must be considered:
IPsecと共にL2TPを固定するとき、以下のケースを考えなければなりません:
Patel, et al. Standards Track [Page 8] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[8ページ]RFC3193
Cases:
ケース:
+--------------------------------------------------+ | Initiator Port | Responder Addr | Responder Port | +--------------------------------------------------+ | 1701 | Fixed | 1701 | +--------------------------------------------------+ | 1701 | Fixed | Dynamic | +--------------------------------------------------+ | 1701 | Dynamic | 1701 | +--------------------------------------------------+ | 1701 | Dynamic | Dynamic | +--------------------------------------------------+ | Dynamic | Fixed | 1701 | +--------------------------------------------------+ | Dynamic | Fixed | Dynamic | +--------------------------------------------------+ | Dynamic | Dynamic | 1701 | +--------------------------------------------------+ | Dynamic | Dynamic | Dynamic | +--------------------------------------------------+
+--------------------------------------------------+ | 創始者ポート| 応答者Addr| 応答者ポート| +--------------------------------------------------+ | 1701 | 修理されています。| 1701 | +--------------------------------------------------+ | 1701 | 修理されています。| 動力| +--------------------------------------------------+ | 1701 | 動力| 1701 | +--------------------------------------------------+ | 1701 | 動力| 動力| +--------------------------------------------------+ | 動力| 修理されています。| 1701 | +--------------------------------------------------+ | 動力| 修理されています。| 動力| +--------------------------------------------------+ | 動力| 動力| 1701 | +--------------------------------------------------+ | 動力| 動力| 動力| +--------------------------------------------------+
By solving the most general case of the above permutations, all cases are covered. The most general case is the last one in the list. This scenario is when the initiator chooses a new port number and the responder chooses a new address and port number. The L2TP message flow which occurs to setup this sequence is as follows:
上の順列の最も一般的なケースを解決することで、すべてのケースがカバーされています。 最も一般的なケースはリストで最後のものです。 このシナリオは創始者が新しいポートナンバーを選ぶ時です、そして、応答者は新しいアドレスとポートナンバーを選びます。 この系列をセットアップするために起こるL2TPメッセージ流動は以下の通りです:
-> IKE Phase 1 and Phase 2 to protect Initial SCCRQ
-Initial SCCRQを保護する>IKE Phase1とPhase2
SCCRQ -> (Fixed IP address, Dynamic Initiator Port)
<- STOPCCN (Responder chooses new IP address)
SCCRQ->(固定IPアドレス、Dynamic Initiator Port)<STOPCCN(応答者は新しいIPアドレスを選びます)
-> New IKE Phase 1 and Phase 2 to protect new SCCRQ
-新しいSCCRQを保護する>の新しいIKE Phase1とPhase2
SCCRQ -> (SCCRQ to Responder's new IP address)
SCCRQ->。(Responderの新しいIPアドレスへのSCCRQ)
<- New IKE Phase 2 to for port number change by the responder
<の新しいIKE Phase2、応答者によるポートナンバー変化
<- SCCRP (Responder chooses new port number)
SCCCN -> (L2TP Tunnel Establishment completes)
<SCCRP(応答者は新しいポートナンバーを選ぶ)SCCCN->。(L2TP Tunnel特権階級が完成する、)
Although the Initiator and Responder typically do not dynamically change ports, L2TP security must accommodate emerging applications such as load balancing and QoS. This may require that the port and IP address float during L2TP tunnel establishment.
InitiatorとResponderはダイナミックにポートを通常変えませんが、L2TPセキュリティはロードバランシングやQoSなどの現れているアプリケーションを収容しなければなりません。 これは、ポートとIPアドレスがL2TPトンネル設立の間流通するのを必要とするかもしれません。
Patel, et al. Standards Track [Page 9] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[9ページ]RFC3193
To support the general case, mechanisms must be designed into L2TP and IPsec which allow L2TP to inject filters into the IPsec filter database. This technique may be used by any application which floats ports and requires security via IPsec, and is described in the following sections.
一般的なケースを支えるために、L2TPにIPsecフィルタデータベースにフィルタを注がせるL2TPとIPsecにメカニズムを設計しなければなりません。 このテクニックは、ポートを浮かべて、IPsecを通してセキュリティを必要とするどんなアプリケーションでも使用されるかもしれなくて、以下のセクションで説明されます。
The responder is not required to support the ability to float its IP address and port. However, the initiator MUST allow the responder to float its port and SHOULD allow the responder to choose a new IP address (see section 4.2.3, below).
応答者はそのIPアドレスとポートを発行する能力をサポートする必要はありません。 しかしながら、創始者は応答者にポートを浮かべさせなければなりません、そして、SHOULDは応答者が新しいIPアドレスを選ぶのを許容します(以下でセクション4.2.3を見てください)。
Appendix A provides examples of these cases using the process described below.
付録Aは、以下で説明されたプロセスを使用することでこれらのケースに関する例を提供します。
4.2.1. Terminology definitions used for filtering statements
4.2.1. 声明をフィルターにかけるのに使用される用語定義
I-Port The UDP port number the Initiator chooses to
originate/receive L2TP traffic on. This can be a static
port such as 1701 or an ephemeral one assigned by the
socket.
溯源するか、または受けるInitiatorがL2TPトラフィックを選ぶUDPポートナンバーをIで移植してください。 これは、1701年などの静的なポートかソケットによって割り当てられたはかないものであるかもしれません。
R-Port The UDP port number the Responder chooses to
originate/receive L2TP traffic on. This can be the port
number 1701 or an ephemeral one assigned by the socket.
This is the port number the Responder uses after
receiving the initial SCCRQ.
溯源するか、または受けるResponderがL2TPトラフィックを選ぶUDPポートナンバーをRで移植してください。 これは、ポートNo.1701かソケットによって割り当てられたはかないものであるかもしれません。 これは初期のSCCRQを受けた後にResponderが使用するポートナンバーです。
R-IPAddr1 The IP address the Responder listens on for initial
SCCRQ. If the responder does not choose a new IP
address, this address will be used for all subsequent
L2TP traffic.
IPがResponderを扱うR-IPAddr1は聴きます。初期のSCCRQにおいて、オンです。 応答者が新しいIPアドレスを選ばないと、このアドレスはすべてのその後のL2TPトラフィックに使用されるでしょう。
R-IPAddr2 The IP address the Responder chooses upon receiving the
SCCRQ. This address is used to send the SCCRP and all
subsequent L2TP tunnel traffic is sent and received on
this address.
SCCRQを受けるとき、IPがResponderを扱うR-IPAddr2は選びます。 このアドレスがSCCRPを送るのに使用されて、このアドレスにすべてのその後のL2TPトンネルトラフィックを送って、受け取ります。
R-IPAddr The IP address which the responder uses for sending and
receiving L2TP packets. This is either the initial value
of R-IPAddr1 or a new value of R-IPAddr2.
R-IPAddr IPは応答者が送受信L2TPパケットに使用するものを扱います。 これは、R-IPAddr1の初期の値かR-IPAddr2の新しい値のどちらかです。
I-IPAddr The IP address the Initiator uses to communicate with for
the L2TP tunnel.
I-IPAddr IPはL2TPトンネルに交信するInitiator用途を扱います。
Any-Addr The presence of Any-Address defines that IKE should
accept any single address proposed in the local address
of the quick mode IDs sent by the peer during IKE phase 2
negotiations. This single address may be formatted as an
Any-アドレスの存在はそれを定義します。いくらか、-、Addr、IKEはIDがIKE段階の間の同輩で2つの交渉を送った迅速なモードのローカルアドレスで提案されたどんなただ一つのアドレスも受け入れるはずです。 このただ一つのアドレスはフォーマットされるかもしれません。
Patel, et al. Standards Track [Page 10] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[10ページ]RFC3193
IP Single address, an IP Netmask address with the Netmask
set to 255.255.255.255, and IP address Range with the
range being 1, or a hostname which can be resolved to one
address. Refer to [5] for more information on the format
for quick mode IDs.
IP Singleアドレス、NetmaskとのIP Netmaskアドレスは1、または1まで決議できるホスト名である範囲でのRangeが扱う255.255の.255の.255、およびIPアドレスにセットしました。 迅速なモードIDについて形式に関する詳しい情報のための[5]を参照してください。
Any-Port The presence of Any-Port defines that IKE should accept a
value of 0 or a specific port value for the port value in
the port value in the quick mode IDs negotiated during
IKE phase 2.
Any-ポートの存在はそれを定義します。いくらか、-、ポート、IKEはIKE段階2の間に交渉された迅速なモードIDにおけるポート値におけるポート値のために0の値か特定のポート値を受け入れるはずです。
The filters defined in the following sections are listed from highest priority to lowest priority.
以下のセクションで定義されたフィルタは最優先から最も低い優先度まで記載されています。
4.2.2. Initial filters needed to protect the SCCRQ
4.2.2. 初期のフィルタは、SCCRQを保護する必要がありました。
The initial filter set on the initiator and responder is necessary to protect the SCCRQ sent by the initiator to open the L2TP tunnel. Both the initiator and the responder must either be pre-configured for these filters or L2TP must have a method to inject this information into the IPsec filtering database. In either case, this filter MUST be present before the L2TP tunnel setup messages start to flow.
創始者と応答者の上に設定された初期のフィルタが、L2TPトンネルを開けるために創始者によって送られたSCCRQを保護するのに必要です。 これらのフィルタのために創始者と応答者の両方をあらかじめ設定しなければなりませんか、またはL2TPにはIPsecフィルタリングデータベースにこの情報を注ぐメソッドがなければなりません。 どちらかの場合では、L2TPトンネルセットアップメッセージが流れ始める前にこのフィルタは存在していなければなりません。
Responder Filters:
Outbound-1: None. They should be be dynamically created by IKE
upon successful completion of phase 2.
応答者フィルタ: 外国行きの1: なし。 それらはそうであるべきです。フェーズ2の無事終了のときにIKEによってダイナミックに作成されてください。
Inbound-1: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst
1701
本国行きの1: R-IPAddr1、UDP、src Any-ポート、dst1701へのAny-Addrから
Initiator Filters:
Outbound-1: From I-IPAddr, to R-IPAddr1, UDP, src I-Port,
dst 1701
創始者フィルタ: 外国行きの1: R-IPAddr1、UDP、src I-ポート、dst1701へのI-IPAddrから
Inbound-1: From R-IPAddr1, to I-IPAddr, UDP, src 1701,
dst I-Port
Inbound-2: From R-IPAddr1, to I-IPAddr, UDP, src Any-Port,
dst I-Port
本国行きの1: R-IPAddr1からI-IPAddrまで、UDP(src1701)はInbound-2をdst I移植します: I-IPAddr、UDP、src Any-ポート、dst I-ポートへのR-IPAddr1から
When the initiator uses dynamic ports, L2TP must inject the filters into the IPsec filter database, once its source port number is known. If the initiator uses a fixed port of 1701, these filters MAY be statically defined.
創始者がダイナミックなポートを使用すると、L2TPはIPsecフィルタデータベースにフィルタを注がなければなりません、ソースポート番号がいったん知られていると。 創始者が1701年の固定ポートを使用するなら、これらのフィルタは静的に定義されるかもしれません。
The Any-Port definition in the initiator's inbound-2 filter statement is needed to handle the potential port change which may occur as the result of the responder changing its port number.
創始者の本国行きの2フィルタ声明とのAny-ポート定義が、応答者がポートナンバーを変えるという結果として起こるかもしれない潜在的ポート変化を扱うのに必要です。
Patel, et al. Standards Track [Page 11] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[11ページ]RFC3193
If a phase 2 SA bundle is not already present to protect the SCCRQ, the sending of a SCCRQ by the initiator SHOULD cause IKE to setup the necessary SAs to protect this packet. Alternatively, L2TP may also request IKE to setup the SA bundle. If the SA cannot be setup for some reason, the packet MUST be dropped.
フェーズ2SAバンドルがSCCRQを保護するために既に存在していないなら、このパケットを保護するように必要なSAsにセットアップする創始者SHOULD原因IKEはSCCRQについて発信します。 あるいはまた、また、L2TPは、SAバンドルをセットアップするようIKEに要求するかもしれません。 SAがある理由でセットアップであるはずがないなら、パケットを下げなければなりません。
The port numbers in the Quick Mode IDs sent by the initiator MUST contain the specific port numbers used to identify the UDP socket. The port numbers would be either I-Port/1701 or 1701/1701 for the initial SCCRQ. The quick mode IDs sent by the initiator will be a subset of the Inbound-1 filter at the responder. As a result, the quick mode exchange will finish and IKE should inject a specific filter set into the IPsec filter database and associate this filter set with the phase 2 SA established between the peers. These filters should persist as long as the L2TP tunnel exists. The new filter set at the responder will be:
創始者によって送られたクィックMode IDにおけるポートナンバーはUDPソケットを特定するのに使用される特定のポートナンバーを含まなければなりません。 ポートナンバーはI-ポート/1701であるだろうかイニシャルのための1701/1701がSCCRQです。 創始者によって送られた迅速なモードIDは応答者のInbound-1フィルタの部分集合になるでしょう。 その結果、迅速なモード交換が終わって、IKEはIPsecフィルタデータベースに特定のフィルタセットを注いで、2SAが同輩の間で確立したフェーズにこのフィルタセットを関連づけるはずです。 L2TPトンネルが存在している限り、これらのフィルタは持続するはずです。 応答者に設定された新しいフィルタは以下の通りになるでしょう。
Responder Filters:
Outbound-1: From R-IPAddr1, to I-IPAddr, UDP, src 1701,
dst I-Port
応答者フィルタ: 外国行きの1: I-IPAddr、UDP、src1701、dst I-ポートへのR-IPAddr1から
Inbound-1: From I-IPAddr, to R-IPAddr1, UDP, src I-Port,
dst 1701
Inbound-2: From Any-Addr, to R-IPAddr1, UDP, src Any-Port,
dst 1701
本国行きの1: I-IPAddrからR-IPAddr1、UDP、src I-ポート、dst1701Inbound-2まで: R-IPAddr1、UDP、src Any-ポート、dst1701へのAny-Addrから
Mechanisms SHOULD exist between L2TP and IPsec such that L2TP is not retransmitting the SCCRQ while the SA is being established. L2TP's control channel retransmit mechanisms should start once the SA has been established. This will help avoid timeouts which may occur as the result of slow SA establishment.
メカニズムSHOULDがL2TPとIPsecの間に存在しているので、SAが設立されている間、L2TPはSCCRQを再送していません。 L2TPの制御チャンネルはメカニズムを再送します。SAがいったん設立されると、始まるべきです。 これは、遅いSA設立の結果として起こるかもしれないタイムアウトを避けるのを助けるでしょう。
Once the phase 2 SA has been established between the peers, the SCCRQ should be sent from the initiator to the responder.
かつての2SAが持っているフェーズが同輩の間で確立されて、創始者から応答者にSCCRQを送るべきです。
If the responder does not choose a new IP address or a new port number, the L2TP tunnel can now proceed to establish.
応答者が新しいIPアドレスを選ばないか、そして、新しいポートナンバー、L2TPトンネルが現在、設立できかけます。
4.2.3. Responder chooses new IP Address
4.2.3. 応答者は新しいIP Addressを選びます。
This step describes the process which should be followed when the responder chooses a new IP address. The only opportunity for the responder to change its IP address is after receiving the SCCRQ but before sending a SCCRP.
このステップは応答者が新しいIPアドレスを選ぶとき続かれるべきであるプロセスについて説明します。 SCCRQを受けた後にもかかわらず、SCCRPを送る前に、応答者がIPアドレスを変える唯一の機会があります。
The new address the responder chooses to use MUST be reflected in the result and error code AVP of a STOPCCN message. The Result Code MUST be set to 2 (General Error) and the Error Code MUST be set to 7 (Try
応答者が使用するのを選ぶ新しいアドレスをSTOPCCNメッセージの結果とエラーコードAVPに反映しなければなりません。 Result Codeが2(Error司令官)に用意ができなければならなくて、Error Codeが7に用意ができなければならない、(トライ
Patel, et al. Standards Track [Page 12] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[12ページ]RFC3193
Another). The optional error message MUST be present and the contents MUST contain the IP address (ASCII encoded) the Responder desires to use for subsequent communications. Only the ASCII encoded IP address should be present in the error message. The IP address is encoded in dotted decimal format for IPv4 or in RFC 2373 [17] format for IPv6.
別のもの) 任意のエラーメッセージは存在していなければなりません、そして、コンテンツはResponderがその後のコミュニケーションに使用することを望んでいるIPアドレス(コード化されたASCII)を含まなければなりません。 コード化されたIPが扱うASCIIは単にエラーメッセージに存在しているべきです。 IPアドレスはIPv4のためのドット付き10進法形式かIPv6のためのRFC2373[17]形式でコード化されます。
The STOPCCN Message MUST be sent using the same address and UDP port information which the initiator used to send the SCCRQ. This message will be protecting using the initial SA bundle setup to protect the SCCRQ.
STOPCCN Messageに創始者がSCCRQを送るのに使用した同じアドレスとUDPポート情報を使用させなければなりません。 このメッセージは、SCCRQを保護するのに初期のSAバンドルセットアップを使用することで保護されるでしょう。
Upon receiving the STOPCCN, the initiator MUST parse the IP address from the Result and Error Code AVP and perform the necessary sanity checks to verify this is a correctly formatted address. If no errors are found L2TP should inject a new set of filters into the IPsec filter database. If using pre-shared key authentication, L2TP MAY request IKE to bind the new IP address to the pre-shared key which was used for the original IP address.
STOPCCNを受けるとき、創始者は、ResultとError Code AVPからのIPアドレスを分析して、確かめる必要な健全度チェックを実行しなければなりません。これは正しくフォーマットされたアドレスです。 誤りが全く見つけられないなら、L2TPはIPsecフィルタデータベースに新しいセットのフィルタを注ぐはずです。 あらかじめ共有された主要な認証を使用するなら、L2TP MAYは、オリジナルのIPアドレスに使用されたあらかじめ共有されたキーに新しいIPアドレスを縛るようIKEに要求します。
Since the IP address of the responder changed, a new phase 1 and phase 2 SA must be established between the peers before the new SCCRQ is sent.
応答者のIPアドレスが変化したので、新しいSCCRQを送る前に、同輩の間に新しいフェーズ1とフェーズ2SAを設立しなければなりません。
Assuming the initial tunnel has been torn down and the filters needed to create the tunnel removed, the new filters for the initiator and responder will be:
初期のトンネルを取りこわして、トンネルを作成するのに必要であるフィルタが取り外されたと仮定すると、創始者と応答者のための新しいフィルタは以下の通りになるでしょう。
Initiator Filters:
Outbound-1: From I-IPAddr, to R-IPAddr2, UDP, src I-Port,
dst 1701
創始者フィルタ: 外国行きの1: R-IPAddr2、UDP、src I-ポート、dst1701へのI-IPAddrから
Inbound-1: From R-IPAddr2, to I-IPAddr, UDP, src 1701,
dst I-Port
Inbound-2: From R-IPAddr2, to I-IPAddr, UDP, src Any-Port,
dst I-Port
本国行きの1: R-IPAddr2からI-IPAddrまで、UDP(src1701)はInbound-2をdst I移植します: I-IPAddr、UDP、src Any-ポート、dst I-ポートへのR-IPAddr2から
Once IKE phase 2 completes, the new filter set at the responder will be:
一度、2が完成するIKEフェーズ、応答者に設定された新しいフィルタは以下の通りになるでしょう。
Responder Filters:
Outbound-1: From R-IPAddr2, to I-IPAddr, UDP, src 1701,
dst I-Port
応答者フィルタ: 外国行きの1: I-IPAddr、UDP、src1701、dst I-ポートへのR-IPAddr2から
Inbound-1: From I-IPAddr, to R-IPAddr2, UDP, src I-Port,
dst 1701
Inbound-2: From Any-Addr, to R-IPAddr1, UDP, src Any-Port,
dst 1701
本国行きの1: I-IPAddrからR-IPAddr2、UDP、src I-ポート、dst1701Inbound-2まで: R-IPAddr1、UDP、src Any-ポート、dst1701へのAny-Addrから
Patel, et al. Standards Track [Page 13] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[13ページ]RFC3193
If the responder chooses not to move to a new port number, the L2TP tunnel setup can now complete.
応答者が、新しいポートナンバーに移行しないのを選ぶなら、L2TPトンネルセットアップは現在、完全な状態で選ぶことができます。
4.2.4. Responder chooses new Port Number
4.2.4. 応答者は新しいPort Numberを選びます。
The responder MAY choose a new UDP source port to use for L2TP tunnel traffic. This decision MUST be made before sending the SCCRP. If a new port number is chosen, then L2TP must inject new filters into the IPsec filter database. The responder must start new IKE phase 2 negotiations with the initiator.
応答者はL2TPトンネルトラフィックに使用する新しいUDPソースポートを選ぶかもしれません。 SCCRPを送る前に、この決定をしなければなりません。 新しいポートナンバーが選ばれているなら、L2TPはIPsecフィルタデータベースに新しいフィルタを注がなければなりません。 応答者は創始者との新しいIKEフェーズ2交渉を始めなければなりません。
The final filter set at the initiator and responder is as follows.
創始者と応答者に設定されたファイナルフィルタは以下の通りです。
Initiator Filters:
Outbound-1: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst
R-Port
Outbound-2: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst
1701
創始者フィルタ: 外国行きの1: I-IPAddrからR-IPAddrまで、UDP(src I-ポート)はOutbound-2をdst R移植します: R-IPAddr、UDP、src I-ポート、dst1701へのI-IPAddrから
Inbound-1: From R-IPAddr, to I-IPAddr, UDP, src R-Port, dst
I-Port
Inbound-2: From R-IPAddr, to I-IPAddr, UDP, src 1701, dst
I-Port
Inbound-3: From R-IPAddr, to I-IPAddr, UDP, src Any-Port, dst
I-Port
本国行きの1: R-IPAddrからI-IPAddrまで、UDP(src R-ポート)はInbound-2をdst I移植します: R-IPAddrからI-IPAddrまで、UDP(src1701)はInbound-3をdst I移植します: I-IPAddr、UDP、src Any-ポート、dst I-ポートへのR-IPAddrから
The Inbound-1 filter for the initiator will be injected by IKE
upon successful completion of the phase 2 negotiations
initiated by the peer.
創始者のためのInbound-1フィルタは2つの交渉が同輩で開始したフェーズの無事終了のときにIKEによって注入されるでしょう。
Responder Filters:
Outbound-1: From R-IPAddr, to I-IPAddr, UDP, src R-Port, dst
I-Port
Outbound-2: From R-IPAddr, to I-IPAddr, UDP, src 1701, dst
I-Port
応答者フィルタ: 外国行きの1: R-IPAddrからI-IPAddrまで、UDP(src R-ポート)はOutbound-2をdst I移植します: I-IPAddr、UDP、src1701、dst I-ポートへのR-IPAddrから
Inbound-1: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst
R-Port
Inbound-2: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst
1701
Inbound-3: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst
1701
本国行きの1: I-IPAddrからR-IPAddrまで、UDP(src I-ポート)はInbound-2をdst R移植します: I-IPAddrからR-IPAddr、UDP、src I-ポート、dst1701Inbound-3まで: R-IPAddr1、UDP、src Any-ポート、dst1701へのAny-Addrから
Once the negotiations have completed, the SCCRP is sent and the L2TP tunnel can complete establishment. After the L2TP tunnel has been established, any residual SAs and their associated filters may be deleted.
一度、交渉は終了したことがあります。完成されて、SCCRPを送ります、そして、L2TPトンネルは設立を終了できます。 L2TPトンネルが確立された後に、どんな残りのSAsと彼らの関連フィルタも削除されるかもしれません。
Patel, et al. Standards Track [Page 14] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[14ページ]RFC3193
4.2.5. Gateway-gateway and L2TP Dial-out considerations
4.2.5. ゲートウェイゲートウェイと外のL2TP Dial問題
In the gateway-gateway or the L2TP dial-out scenario, either side may initiate L2TP. The process outlined in the previous steps should be followed with one addition. The initial filter set at both sides MUST include the following filter:
ゲートウェイゲートウェイかL2TPダイヤルアウトシナリオでは、どちらの側もL2TPを開始するかもしれません。 前のステップに概説されたプロセスは1つの追加で続かれるべきです。 両側に設定された初期のフィルタは以下のフィルタを含まなければなりません:
Inbound Filter:
1: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701
本国行きのフィルタ: 1: R-IPAddr1、UDP、src Any-ポート、dst1701へのAny-Addrから
When either peer decides to start a tunnel, L2TP should inject the necessary inbound and outbound filters to protect the SCCRQ. Tunnel establishment then proceeds exactly as stated in the previous sections.
どちらの同輩も、トンネルを出発させると決めると、L2TPは、SCCRQを保護するために必要な本国行きの、そして、外国行きのフィルタを注入するはずです。 そして、トンネル設立はまさに前項で述べられているように続きます。
5. Security Considerations
5. セキュリティ問題
5.1. Authentication issues
5.1. 認証問題
IPsec IKE negotiation MUST negotiate an authentication method specified in the IKE RFC 2409 [7]. In addition to IKE authentication, L2TP implementations utilize PPP authentication methods, such as those described in [15]-[16]. In this section, we discuss authentication issues.
IPsec IKE交渉はIKE RFC2409[7]で指定された認証方法を交渉しなければなりません。 IKE認証に加えて、L2TP実装は[15]で説明されたものなどのPPP認証方法を利用します--[16]。 このセクションで、私たちは認証問題について議論します。
5.1.1. Differences between IKE and PPP authentication
5.1.1. IKEとPPP認証の違い
While PPP provides initial authentication, it does not provide per- packet authentication, integrity or replay protection. This implies that the identity verified in the initial PPP authentication is not subsequently verified on reception of each packet.
PPPが初期の認証を提供している間、提供しない、-、パケット認証、保全または反復操作による保護。 これは、初期のPPP認証で確かめられたアイデンティティが次にそれぞれのパケットのレセプションで確かめられないのを含意します。
With IPsec, when the identity asserted in IKE is authenticated, the resulting derived keys are used to provide per-packet authentication, integrity and replay protection. As a result, the identity verified in the IKE conversation is subsequently verified on reception of each packet.
IKEで断言されたアイデンティティが認証されるとき、IPsecと共に、結果として起こる派生しているキーは、1パケットあたりの認証、保全、および反復操作による保護を提供するのに使用されます。 その結果、IKEの会話で確かめられたアイデンティティは次に、それぞれのパケットのレセプションで確かめられます。
Let us assume that the identity claimed in PPP is a user identity, while the identity claimed within IKE is a machine identity. Since only the machine identity is verified on a per-packet basis, there is no way to verify that only the user authenticated within PPP is using the tunnel. In fact, IPsec implementations that only support machine authentication typically have no way to enforce traffic segregation. As a result, where machine authentication is used, once an L2TP/IPsec tunnel is opened, any user on a multi-user machine will typically be able to send traffic down the tunnel.
PPPで要求されたアイデンティティがユーザアイデンティティであると仮定しましょう、IKEの中で要求されたアイデンティティはマシンのアイデンティティですが。 マシンのアイデンティティだけが1パケットあたり1個のベースで確かめられるので、PPPの中で認証されたユーザだけがトンネルを使用していることを確かめる方法が全くありません。 事実上、マシン認証をサポートするだけであるIPsec実装が交通分離を実施する方法を全く通常持っていません。 その結果、マシン認証が使用されているところでは、L2TP/IPsecトンネルがいったん開けられると、マルチユーザマシンの上のどんなユーザもトンネルの下側にトラフィックを通常送ることができるでしょう。
Patel, et al. Standards Track [Page 15] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[15ページ]RFC3193
If the IPsec implementation supports user authentication, this problem can be averted. In this case, the user identity asserted within IKE will be verified on a per-packet basis. In order to provide segregation of traffic between users when user authentication is used, the client MUST ensure that only traffic from that particular user is sent down the L2TP tunnel.
IPsec実装がユーザー認証をサポートするなら、この問題を逸らすことができます。 この場合、IKEの中で断言されたユーザアイデンティティは1パケットあたり1個のベースで確かめられるでしょう。 ユーザー認証が使用されているとき、ユーザの間に交通分離を提供するために、クライアントは、その特定のユーザからのトラフィックだけがL2TPトンネルの下側に送られるのを保証しなければなりません。
5.1.2. Certificate authentication in IKE
5.1.2. IKEでの証明書認証
When X.509 certificate authentication is chosen within IKE, the LNS is expected to use an IKE Certificate Request Payload (CRP) to request from the client a certificate issued by a particular certificate authority or may use several CRPs if several certificate authorities are trusted and configured in its IPsec IKE authentication policy.
X.509証明書認証がIKEの中で選ばれていると、LNSはクライアントから特定の認証局によって発行された証明書を要求するためにIKE Certificate Request有効搭載量(CRP)を使用すると予想されるか、またはいくつかの認証局がIPsec IKE認証方針で信じられて、構成されるなら、数個のCRPsを使用するかもしれません。
The LNS SHOULD be able to trust several certificate authorities in order to allow tunnel client end-points to connect to it using their own certificate credential from their chosen PKI. Client and server side certificate revocation list checking MAY be enabled on a per-CA basis, since differences in revocation list checking exist between different PKI providers.
LNS SHOULD、トンネルクライアントエンドポイントがそれに接続するのをそれらの選ばれたPKIからそれら自身の証明書資格証明書を使用することで許容するためにいくつかの認証局を信じることができてください。 クライアントとサーバサイド証明書失効リストの照合は1カリフォルニアあたり1個のベースで可能にされるかもしれません、取消しリストの照合の違いが異なったPKIプロバイダーの間に存在しているので。
L2TP implementations MAY use dynamically assigned ports for both source and destination ports only if security for each source and destination port combination can be successfully negotiated by IKE.
IKEが首尾よく各ソースと仕向港組み合わせのためのセキュリティを交渉できる場合にだけ、L2TP実装はソースと仕向港の両方にダイナミックに割り当てられたポートを使用するかもしれません。
5.1.3. Machine versus user certificate authentication in IKE
5.1.3. IKEでユーザー証明書に対して認証を機械加工してください。
The certificate credentials provided by the L2TP client during the IKE negotiation MAY be those of the machine or of the L2TP user. When machine authentication is used, the machine certificate is typically stored on the LAC and LNS during an enrollment process. When user certificates are used, the user certificate can be stored either on the machine or on a smartcard.
IKE交渉の間にL2TPクライアントによって提供された証明書資格証明書はマシンかL2TPユーザのものであるかもしれません。 マシン認証が使用されているとき、マシン証明書は登録プロセスの間、LACとLNSに通常保存されます。 ユーザー証明書が使用されているとき、マシンの上、または、スマートカードの上にユーザー証明書を保存できます。
Since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one under false pretenses, it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate.
マシン証明書の値が逆に攻撃者が偽って1つを得ることができる容易さに変化しているので、マシン証明書登録プロセスが厳密に制御されるのは、賢明です。 例えば、管理者だけには、マシン証明書でマシンを登録する能力があるかもしれません。
While smartcard certificate storage lessens the probability of compromise of the private key, smartcards are not necessarily desirable in all situations. For example, some organizations deploying machine certificates use them so as to restrict use of non-approved hardware. Since user authentication can be provided
スマートカード証明書ストレージは秘密鍵の感染の確率を少なくしますが、スマートカードは必ずすべての状況で望ましいというわけではありません。 例えば、マシン証明書を配布するいくつかの組織が、非承認されたハードウェアの使用を制限するのにそれらを使用します。 ユーザー認証を提供できるので
Patel, et al. Standards Track [Page 16] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[16ページ]RFC3193
within PPP (keeping in mind the weaknesses described earlier), support for machine authentication in IPsec makes it is possible to authenticate both the machine as well as the user.
IPsecでのマシン認証がそれを作るので、PPP(より早く説明された弱点を覚えておく)の中では、サポートはマシンとユーザの両方を認証するのにおいて可能です。
In circumstances in which this dual assurance is considered valuable, enabling movement of the machine certificate from one machine to another, as would be possible if the machine certificate were stored on a smart card, may be undesirable.
マシン証明書がスマートカードに保存されたなら可能であるようにマシン証明書の1台のマシンから別のマシンまでの動きを可能にして、この二元的な保証が貴重であると考えられる事情では、望ましくないかもしれません。
Similarly, when user certificate are deployed, it is advisable for the user enrollment process to be strictly controlled. If for example, a user password can be readily used to obtain a certificate (either a temporary or a longer term one), then that certificate has no more security value than the password. To limit the ability of an attacker to obtain a user certificate from a stolen password, the enrollment period can be limited, after which password access will be turned off. Such a policy will prevent an attacker obtaining the password of an unused account from obtaining a user certificate once the enrollment period has expired.
ユーザー証明書が配布されるとき、同様に、ユーザ登録プロセスが厳密に制御されるのは、賢明です。 例えば、証明書(一時的な期間か、より長い期間1)を入手するのに容易にユーザパスワードを使用できるなら、その証明書には、パスワードが値でないことのようなどんなセキュリティ値もありません。 攻撃者が盗まれたパスワードからユーザー証明書を入手する能力を制限するために、受講期間(パスワードアクセスはオフにされる)を制限できます。 そのような方針によって、受講期間がいったん期限が切れると、未使用のアカウントに関するパスワードを得る攻撃者はユーザー証明書を入手できないでしょう。
5.1.4. Pre-shared keys in IKE
5.1.4. IKEのあらかじめ共有されたキー
Use of pre-shared keys in IKE main mode is vulnerable to man-in-the- middle attacks when used in remote access situations. In main mode it is necessary for SKEYID_e to be used prior to the receipt of the identification payload. Therefore the selection of the pre-shared key may only be based on information contained in the IP header. However, in remote access situations, dynamic IP address assignment is typical, so that it is often not possible to identify the required pre-shared key based on the IP address.
中の男性にとって、IKEの主なモードにおけるあらかじめ共有されたキーの使用が被害を受け易い、-、-遠隔アクセスの状況で使用されると、中央は攻撃されます。 主なモードで、SKEYID_eが識別ペイロードの領収書の前で使用されるのが必要です。 したがって、あらかじめ共有されたキーの選択はIPヘッダーに含まれた情報に基づくだけであるかもしれません。 しかしながら、遠隔アクセスの状況で、動的IPアドレス課題は典型です、IPアドレスに基づく必要なあらかじめ共有されたキーを特定するのがしばしば可能であるというわけではないように。
Thus when pre-shared keys are used in remote access scenarios, the same pre-shared key is shared by a group of users and is no longer able to function as an effective shared secret. In this situation, neither the client nor the server identifies itself during IKE phase 1; it is only known that both parties are a member of the group with knowledge of the pre-shared key. This permits anyone with access to the group pre-shared key to act as a man-in-the-middle.
したがって、あらかじめ共有されたキーが遠隔アクセスのシナリオで使用されるとき、同じあらかじめ共有されたキーは、ユーザー層によって共有されて、もう有効な共有秘密キーとして機能できません。 この状況で、IKE段階1の間、クライアントもサーバもそれ自体を特定しません。 双方があらかじめ共有されたキーに関する知識があるグループのメンバーであることが知られているだけです。 これは中央の男性として作動するあらかじめ共有されたキーをグループへのアクセスのだれにも可能にします。
This vulnerability does not occur in aggressive mode since the identity payload is sent earlier in the exchange, and therefore the pre-shared key can be selected based on the identity. However, when aggressive mode is used the user identity is exposed and this is often considered undesirable.
この脆弱性は交換で、より早くアイデンティティペイロードを送るので、攻撃的なモードで起こりません、そして、したがって、アイデンティティに基づいてあらかじめ共有されたキーは選択できます。 しかしながら、攻撃的なモードが使用されているとき、ユーザアイデンティティは暴露されます、そして、これは望ましくないとしばしば考えられます。
As a result, where main mode is used with pre-shared keys, unless PPP performs mutual authentication, the server is not authenticated. This enables a rogue server in possession of the group pre-shared key
その結果、主なモードがあらかじめ共有されたキーと共に使用されるところでは、PPPが互いの認証を実行しない場合、サーバは認証されません。 これは主要な状態であらかじめ共有されたグループの所有物で凶暴なサーバを可能にします。
Patel, et al. Standards Track [Page 17] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[17ページ]RFC3193
to successfully masquerade as the LNS and mount a dictionary attack on legacy authentication methods such as CHAP [15]. Such an attack could potentially compromise many passwords at a time. This vulnerability is present in some existing IPsec tunnel mode implementations.
首尾よくLNSのふりをして、辞書を取り付けるには、CHAP[15]などのレガシー認証方法で攻撃してください。 そのような攻撃は一度に、潜在的に多くのパスワードに感染するかもしれません。 この脆弱性はいくつかの既存のIPsecトンネルモード実装で存在しています。
To avoid this problem, L2TP/IPsec implementations SHOULD NOT use a group pre-shared key for IKE authentication to the LNS. IKE pre- shared authentication key values SHOULD be protected in a manner similar to the user's account password used by L2TP.
この問題を避けるために、L2TP/IPsec実装SHOULD NOTはIKE認証にLNSに主要な状態であらかじめ共有されたグループを使用します。 IKEは保護されたコネがL2TPによって使用されたユーザのアカウントパスワードと同様の方法であったなら認証キー値SHOULDをあらかじめ共有しました。
5.2. IPsec and PPP security interactions
5.2. IPsecとPPPセキュリティ相互作用
When L2TP is protected with IPsec, both PPP and IPsec security services are available. Which services are negotiated depends on whether the tunnel is compulsory or voluntary. A detailed analysis of voluntary and compulsory tunneling scenarios is included below. These scenarios are non-normative and do not create requirements for an implementation to be L2TP security compliant.
L2TPがIPsecと共に保護されるとき、PPPとIPsecセキュリティー・サービスの両方が利用可能です。 どのサービスが交渉されるかはトンネルが強制的であるか自発的であるかよります。 自発的の、そして、強制的なトンネリングシナリオの詳細に渡る分析は以下に含まれています。 これらのシナリオは、非規範的であり、セキュリティ対応することで実装がL2TPであるという要件を作成しません。
In the scenarios below, it is assumed that both L2TP clients and servers are able to set and get the properties of IPsec security associations, as well as to influence the IPsec security services negotiated. Furthermore, it is assumed that L2TP clients and servers are able to influence the negotiation process for PPP encryption and compression.
以下のシナリオでは、L2TPクライアントとサーバの両方がIPsecセキュリティ協会の資産を設定して、得ることができると思われます、IPsecセキュリティー・サービスがよく影響に関して交渉されたので。 その上、L2TPクライアントとサーバがPPP暗号化と圧縮のために交渉プロセスに影響を及ぼすことができると思われます。
5.2.1. Compulsory tunnel
5.2.1. 強制的なトンネル
In the case of a compulsory tunnel, the client sends PPP frames to the LAC, and will typically not be aware that the frames are being tunneled, nor that any security services are in place between the LAC and LNS. At the LNS, a data packet will arrive, which includes a PPP frame encapsulated in L2TP, which is itself encapsulated in an IP packet. By obtaining the properties of the Security Association set up between the LNS and the LAC, the LNS can obtain information about security services in place between itself and the LAC. Thus in the compulsory tunneling case, the client and the LNS have unequal knowledge of the security services in place between them.
強制的なトンネルの場合をクライアントは、LACへのフレームをPPPに送って、フレームがトンネルを堀られていて、LACとLNSの間には、どんなセキュリティー・サービスも適所にあるのを通常意識しないでしょう。 LNSに、データ・パケット(IPパケットでカプセル化されるL2TPでカプセル化されたPPPフレームを含んでいる)は到着するでしょう。 LNSとLACの間でセットアップされたSecurity Associationの資産を入手することによって、LNSは適所でそれ自体とLACの間としてセキュリティー・サービスの情報を得ることができます。 したがって、強制的なトンネリング場合では、クライアントとLNSはそれらの間に適所にあるセキュリティー・サービスに関する不平等な知識を持っています。
Since the LNS is capable of knowing whether confidentiality, authentication, integrity and replay protection are in place between itself and the LAC, it can use this knowledge in order to modify its behavior during PPP ECP [10] and CCP [9] negotiation. Let us assume that LNS confidentiality policy can be described by one of the following terms: "Require Encryption," "Allow Encryption" or "Prohibit Encryption." If IPsec confidentiality services are in place, then an LNS implementing a "Prohibit Encryption" policy will
LNSが、それ自体とLACの間には、秘密性、認証、保全、および反復操作による保護が適所にあるかを知ることができるので、それはPPP ECP[10]とCCP[9]交渉の間、振舞いを変更するのにこの知識を使用できます。 次の用語の1つがLNS秘密性方針を説明できると仮定しましょう: 「暗号化を必要としてください」か「暗号化を許容してください」か「暗号化を禁止してください。」 IPsec秘密性サービスが適所にあると、「暗号化を禁止してください」という政策を実施するLNSはそうするでしょう。
Patel, et al. Standards Track [Page 18] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[18ページ]RFC3193
act as though the policy had been violated. Similarly, an LNS implementing a "Require Encryption" or "Allow Encryption" policy will act as though these policies were satisfied, and would not mandate use of PPP encryption or compression. This is not the same as insisting that PPP encryption and compression be turned off, since this decision will depend on client policy.
まるで方針が違反されたかのように、行動してください。 同様に、「暗号化を必要としてください」か「暗号化を許容してください」政策を実施するLNSはまるでこれらの方針が満たされるかのように行動して、PPP暗号化か圧縮の使用を強制しないでしょう。 これはPPP暗号化と圧縮がオフにされると主張するのと同じではありません、この決定がクライアント方針によるので。
Since the client has no knowledge of the security services in place between the LAC and the LNS, and since it may not trust the LAC or the wire between itself and the LAC, the client will typically want to ensure sufficient security through use of end-to-end IPsec or PPP encryption/compression between itself and the LNS.
クライアントがLACとLNSの間に適所にあるセキュリティー・サービスに関する知識を全く持たないで、またそれ自体とLACの間でLACかワイヤを信じないかもしれなくて、クライアントはそれ自体とLNSの間の終わりから終わりへのIPsecかPPP暗号化/圧縮の使用で十分なセキュリティを通常確実にしたくなるでしょう。
A client wishing to ensure security services over the entire travel path would not modify this behavior even if it had knowledge of the security services in place between the LAC and the LNS. The client negotiates confidentiality services between itself and the LNS in order to provide privacy on the wire between itself and the LAC. The client negotiates end-to-end security between itself and the end- station in order to ensure confidentiality on the portion of the path between the LNS and the end-station.
それにLACとLNSの間に適所にあるセキュリティー・サービスに関する知識があったとしても、全体の旅行経路にわたるセキュリティー・サービスを確実にしたがっているクライアントはこの振舞いを変更しないでしょうに。 クライアントは、それ自体とLACの間のワイヤの上にプライバシーを提供するためにそれ自体とLNSの間の秘密性サービスを交渉します。 クライアントは、LNSの間の経路の部分と端ステーションで秘密性を確実にするためにそれ自体と端のステーションの間の終わりから終わりへのセキュリティを交渉します。
The client will typically not trust the LAC and will negotiate confidentiality and compression services on its own. As a result, the LAC may only wish to negotiate IPsec ESP with null encryption with the LNS, and the LNS will request replay protection. This will ensure that confidentiality and compression services will not be duplicated over the path between the LAC and the LNS. This results in better scalability for the LAC, since encryption will be handled by the client and the LNS.
クライアントは、LACを通常信じないで、それ自身のものに関して秘密性と圧縮サービスを交渉するでしょう。 その結果、LACはLNSとのヌル暗号化がある超能力、およびLNSが保護を再演するよう要求するIPsecを交渉するだけでありたいかもしれません。 これは、秘密性と圧縮サービスがLACとLNSの間の経路の上にコピーされないのを確実にするでしょう。 暗号化がクライアントとLNSによって扱われるので、これはLACには、より良いスケーラビリティをもたらします。
The client can satisfy its desire for confidentiality services in one of two ways. If it knows that all end-stations that it will communicate with are IPsec-capable (or if it refuses to talk to non- IPsec capable end-stations), then it can refuse to negotiate PPP encryption/compression and negotiate IPsec ESP with the end-stations instead. If the client does not know that all end-stations it will contact are IPsec capable (the most likely case), then it will negotiate PPP encryption/compression. This may result in duplicate compression/encryption which can only be eliminated if PPP compression/encryption can be turned off on a per-packet basis. Note that since the LNS knows that the client's packets are being tunneled but the client does not, the LNS can ensure that stateless compression/encryption is used by offering stateless compression/encryption methods if available in the ECP and CCP negotiations.
クライアントは秘密性サービスのために2つの方法の1つで欲望を充足できます。 それがコミュニケートするすべての端ステーションがIPsecできるのを知っているなら(できる端ステーションについて非IPsecと話すのを拒否するなら)、それは、PPP暗号化/圧縮を交渉して、IPsecを交渉するのを拒否できます。代わりに端ステーションがある超能力。 クライアントが、それが接触するすべての端ステーションができるIPsec(最もありそうなケース)であることを知らないと、それはPPP暗号化/圧縮を交渉するでしょう。 これは1パケットあたり1個のベースでPPP圧縮/暗号化をオフにすることができる場合にだけ排除できる写し圧縮/暗号化をもたらすかもしれません。 LNSが、LNSが、クライアントのパケットがトンネルを堀られているのを知っていますが、クライアントが非常に知らないので状態がない圧縮/暗号化がECPとCCP交渉に利用可能であるなら状態がない圧縮/暗号化メソッドを提供することによって使用されるのを確実にすることができることに注意してください。
Patel, et al. Standards Track [Page 19] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[19ページ]RFC3193
5.2.2. Voluntary tunnel
5.2.2. 自発的のトンネル
In the case of a voluntary tunnel, the client will be send L2TP packets to the NAS, which will route them to the LNS. Over a dialup link, these L2TP packets will be encapsulated in IP and PPP. Assuming that it is possible for the client to retrieve the properties of the Security Association between itself and the LNS, the client will have knowledge of any security services negotiated between itself and the LNS. It will also have knowledge of PPP encryption/compression services negotiated between itself and the NAS.
自発的のトンネルの場合では、クライアントは彼らをLNSに発送するNASへのパケットをL2TPに送るためにことになるでしょう。 ダイアルアップリンクの上では、これらのL2TPパケットはIPとPPPでカプセルに入れられるでしょう。 クライアントがそれ自体とLNSの間のSecurity Associationの特性を検索するのが、可能であると仮定すると、クライアントはそれ自体とLNSの間でどんなセキュリティー・サービスに関する知識も交渉させるでしょう。 また、それで、それ自体とNASの間でPPP暗号化/圧縮サービスに関する知識を交渉するでしょう。
From the LNS point of view, it will note a PPP frame encapsulated in L2TP, which is itself encapsulated in an IP packet. This situation is identical to the compulsory tunneling case. If LNS retrieves the properties of the Security Association set up between itself and the client, it can be informed of the security services in place between them. Thus in the voluntary tunneling case, the client and the LNS have symmetric knowledge of the security services in place between them.
LNS観点から、それは、PPPフレームがL2TPで要約されたことに注意するでしょう。(L2TPはIPパケットでカプセル化されます)。 この状況は強制的なトンネリングケースと同じです。 LNSがそれ自体とクライアントの間でセットアップされたSecurity Associationの特性を検索するなら、それらの間に適所にあるセキュリティー・サービスについてそれを知らすことができます。 したがって、自発的のトンネリング場合では、クライアントとLNSはそれらの間に適所にあるセキュリティー・サービスに関する左右対称の知識を持っています。
Since the LNS is capable of knowing whether confidentiality, authentication, integrity check or replay protection is in place between the client and itself, it is able to use this knowledge to modify its PPP ECP and CCP negotiation stance. If IPsec confidentiality is in place, the LNS can behave as though a "Require Encryption" directive had been fulfilled, not mandating use of PPP encryption or compression. Typically the LNS will not insist that PPP encryption/compression be turned off, instead leaving this decision to the client.
LNSが、クライアントとそれ自体の間には、秘密性、認証、保全チェックまたは反復操作による保護が適所にあるかを知ることができるので、それはそのPPP ECPとCCP交渉姿勢を変更するのにこの知識を使用できます。 IPsec秘密性が適所にあるなら、まるで「暗号化を必要としてください」という指示が実現したかのようにLNSは振る舞うことができます、PPP暗号化か圧縮の使用を強制しないで。 代わりにこの決定をクライアントに任せて、通常、LNSは、PPP暗号化/圧縮がオフにされると主張しないでしょう。
Since the client has knowledge of the security services in place between itself and the LNS, it can act as though a "Require Encryption" directive had been fulfilled if IPsec ESP was already in place between itself and the LNS. Thus, it can request that PPP encryption and compression not be negotiated. If IP compression services cannot be negotiated, it will typically be desirable to turn off PPP compression if no stateless method is available, due to the undesirable effects of stateful PPP compression.
クライアントにはそれ自体とLNSの間に適所にあるセキュリティー・サービスに関する知識があるので、まるで「暗号化を必要としてください」という指示がIPsecであるなら実現して、それ自体とLNSの間には、超能力が既に適所にあったということであったかのように、それは行動できます。 したがって、それは、PPP暗号化と圧縮が交渉されないよう要求できます。 どんな状態がないメソッドも利用可能でなく、IP圧縮サービスを交渉できないと、PPP圧縮をオフにするのは通常望ましくなるでしょう、stateful PPP圧縮の望ましくない効果のため。
Thus in the voluntary tunneling case the client and LNS will typically be able to avoid use of PPP encryption and compression, negotiating IPsec Confidentiality, Authentication, and Integrity protection services instead, as well as IP Compression, if available.
したがって、自発的のトンネリング場合では、クライアントとLNSはPPP暗号化と圧縮の使用を通常避けることができるでしょう、代わりにIPsec Confidentiality、Authentication、およびIntegrity保護サービスを交渉して、IP Compressionと同様に、利用可能であるなら。
This may result in duplicate encryption if the client is communicating with an IPsec-capable end-station. In order to avoid duplicate encryption/compression, the client may negotiate two
クライアントがIPsecできる端ステーションとコミュニケートしているなら、これは写し暗号化をもたらすかもしれません。 写し暗号化/圧縮を避けるために、クライアントは2を交渉するかもしれません。
Patel, et al. Standards Track [Page 20] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[20ページ]RFC3193
Security Associations with the LNS, one with ESP with null encryption, and one with confidentiality/compression. Packets going to an IPsec- capable end-station would run over the ESP with null encryption security association, and packets to a non-IPsec capable end-station would run over the other security association. Note that many IPsec implementations cannot support this without allowing L2TP packets on the same tunnel to be originated from multiple UDP ports. This requires modifications to the L2TP specification.
LNSとセキュリティAssociations、ヌル暗号化がある超能力を伴う1、および秘密性/圧縮がある1。 IPsecのできる端ステーションに行くパケットはヌル暗号化セキュリティ関係と共に超能力をひくでしょう、そして、非IPsecのできる端ステーションへのパケットはもう片方のセキュリティ協会をひくでしょう。 同じトンネルの上のL2TPパケットが複数のUDPポートから溯源されるのを許容しない多くのIPsec実現がこれを支持できないことに注意してください。 これはL2TP仕様への変更を必要とします。
Also note that the client may wish to put confidentiality services in place for non-tunneled packets traveling between itself and the NAS. This will protect the client against eavesdropping on the wire between itself and the NAS. As a result, it may wish to negotiate PPP encryption and compression with the NAS. As in compulsory tunneling, this will result in duplicate encryption and possibly compression unless PPP compression/encryption can be turned off on a per-packet basis.
また、クライアントがそれ自体とNASの間を移動する非トンネルを堀られたパケットのために秘密性サービスを適所に置きたがっているかもしれないことに注意してください。 これは、それ自体とNASの間のワイヤを立ち聞きしないようにクライアントを保護するでしょう。 その結果、それはPPP暗号化と圧縮をNASと交渉したがっているかもしれません。 強制的なトンネリングのように、1パケットあたり1個のベースでPPP圧縮/暗号化をオフにすることができないと、これは写し暗号化とことによると圧縮をもたらすでしょう。
6. References
6. 参照
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and
B. Palter, "Layer Two Tunneling Protocol L2TP", RFC 2661,
August 1999.
[1] w.Townsley、バレンシア、A.、ルーベンス(A.)は気がぬけます、G.、ゾルン、G.、B.はあしらわれます、「層TwoはプロトコルL2TPにトンネルを堀っ」て、RFC2661、1999年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[3] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[4] ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
[5] Piper, D., "The Internet IP Security Domain of Interpretation
of ISAKMP", RFC 2407, November 1998.
[5] パイパー、D.、「ISAKMPの解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[6] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[6] アトキンソンとR.とS.ケント、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[7] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[8] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[8] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[9] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
1962, June 1996.
D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962 1996年6月の[9]底ならし革。
Patel, et al. Standards Track [Page 21] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[21ページ]RFC3193
[10] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC
1968, June 1996.
[10] マイヤー、G.、「ppp暗号化制御プロトコル(ECP)」、RFC1968 1996年6月。
[11] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol
(DESE)", RFC 1969, June 1996.
[11]SklowerとK.とG.マイヤー、「ppp DES暗号化プロトコル(DESE)」、RFC1969 1996年6月。
[12] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
Version 2 (DESE-bis)", RFC 2419, September 1998.
[12]SklowerとK.とG.マイヤー、「ppp DES暗号化プロトコル、バージョン2(2回DESE)」、RFC2419 1998年9月。
[13] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)",
RFC 2420, September 1998.
K.、「ppp三重のDES暗号化プロトコル(3DESE)」、RFC2420 1998年9月の[13]Hummert。
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, November 1998.
[14] Dierks、T.、およびC.アレン、「TLSは1998年11月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[15] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)," RFC 1994, August 1996.
[15] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[16] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)," RFC 2284, March 1998.
[16]BlunkとL.と1998年のJ.Vollbrecht、「ppp拡張認証プロトコル(EAP)」、RFC2284行進。
[17] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[17]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
Acknowledgments
承認
Thanks to Gurdeep Singh Pall, David Eitelbach, Peter Ford, and Sanjay Anand of Microsoft, John Richardson of Intel and Rob Adams of Cisco for useful discussions of this problem space.
この問題スペースの役に立つ議論をGurdeepシンPall、デヴィッドEitelbach、ピーター・フォード、およびマイクロソフトのSanjayアナンド、シスコのインテルとロブ・アダムスのジョン・リチャードソンをありがとうございます。
Patel, et al. Standards Track [Page 22] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[22ページ]RFC3193
Authors' Addresses
作者のアドレス
Baiju V. Patel Intel Corp 2511 NE 25th Ave Hillsboro, OR 97124
第25Baiju V.パテルインテルCorp2511Ne Aveヒースボロー、または97124
Phone: +1 503 702 2303 EMail: baiju.v.patel@intel.com
以下に電話をしてください。 +1 2303年の503 702メール: baiju.v.patel@intel.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 706-6605 EMail: bernarda@microsoft.com
以下に電話をしてください。 +1 425 706-6605 メールしてください: bernarda@microsoft.com
William Dixon Microsoft Corporation One Microsoft Way Redmond, WA 98052
ウィリアムディクソンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 703 8729 EMail: wdixon@microsoft.com
以下に電話をしてください。 +1 8729年の425 703メール: wdixon@microsoft.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, Washington 98004
ワシントン 谷間ゾルンシスコシステムズInc.500第108アベニューの東北、Suite500ベルビュー、98004
Phone: +1 425 438 8218 Fax: +1 425 438 1848 EMail: gwz@cisco.com
以下に電話をしてください。 +1 425 438、8218Fax: +1 1848年の425 438メール: gwz@cisco.com
Skip Booth Cisco Systems 7025 Kit Creek Road RTP, NC 27709
ブースシスコシステムズ7025キットクリーク道路RTP、NC 27709をスキップしてください。
Phone: +1 919 392 6951 EMail: ebooth@cisco.com
以下に電話をしてください。 +1 6951年の919 392メール: ebooth@cisco.com
Patel, et al. Standards Track [Page 23] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[23ページ]RFC3193
Appendix A: Example IPsec Filter sets for L2TP Tunnel Establishment
付録A: L2TP Tunnel特権階級のための例のIPsec Filterセット
This section provides examples of IPsec filter sets for L2TP tunnel establishment. While example filter sets are for IPv4, similar examples could just as easily be constructed for IPv6.
このセクションはIPsecフィルタセットに関する例をL2TPトンネル設立に提供します。 例のフィルタセットがIPv4のためのものである間、IPv6のためにただ同じくらい容易に同様の例を構成できました。
A.1 Initiator and Responder use fixed addresses and ports
A.1創始者とResponderは定番地とポートを使用します。
This is the most simple of the cases since nothing changes during L2TP tunnel establishment. Since the initiator does not know whether the responder will change its port number, it still must be prepared for this case. In this example, the initiator will use an IPv4 address of 1.1.1.1 and the responder will use an IPv4 address of 2.2.2.1.
何もL2TPトンネル設立の間、変化しないので、場合でこれは最も簡単です。 創始者が、応答者がポートナンバーを変えるかどうかを知らないので、このような場合まだそれを準備しなければなりません。 この例、意志がIPv4アドレスを使用する創始者では、1.1に、.1と応答者が望んでいる.1は2.2のIPv4アドレスを使用します。.2 .1。
The filters for this scenario are:
このシナリオのためのフィルタは以下の通りです。
A.1.1 Protect the SCCRQ
A.1.1はSCCRQを保護します。
Initiator Filters:
Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701, dst 1701
創始者フィルタ: 外国行きの1: 1.1、.1、.1対2.2、.2、.1、UDP、src1701、dst1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 1701
Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701
本国行きの1: 2.2 .2 .1、1.1 .1 .1 UDP、src1701、dst1701Inbound-2: 2.2、.2、.1対1.1、.1(UDP)がsrc Any移植する.1、dst1701
Responder Filters:
Outbound-1: None, dynamically injected when IKE Phase 2 completes
応答者フィルタ: 外国行きの1: IKE Phase2であるときにダイナミックに注入されなかったなにも完成
Inbound-1: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
本国行きの1: Any-Addrから2.2、.1(UDP)がsrc Any移植する.2、dst1701
After IKE Phase 2 completes the filters at the initiator and responder will be:
IKE Phase2が創始者と応答者でフィルタを完成した後にである:
Initiator Filters:
Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701, dst 1701
創始者フィルタ: 外国行きの1: 1.1、.1、.1対2.2、.2、.1、UDP、src1701、dst1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 1701
Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701
本国行きの1: 2.2 .2 .1、1.1 .1 .1 UDP、src1701、dst1701Inbound-2: 2.2、.2、.1対1.1、.1(UDP)がsrc Any移植する.1、dst1701
Responder Filters:
Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 1701
応答者フィルタ: 外国行きの1: 2.2、.2、.1対1.1、.1、.1、UDP、src1701、dst1701
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701, dst 1701
Inbound-2: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
本国行きの1: 1.1 .1 .1、2.2 .2 .1 UDP、src1701、dst1701Inbound-2: Any-Addrから2.2、.1(UDP)がsrc Any移植する.2、dst1701
Patel, et al. Standards Track [Page 24] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[24ページ]RFC3193
A.2 Gateway to Gateway Scenario where Initiator and Responder use
dynamic ports
InitiatorとResponderがダイナミックなポートを使用するゲートウェイScenarioへのA.2ゲートウェイ
In this scenario either side is allowed to initiate the tunnel. Since dynamic ports will be used, an extra phase 2 negotiation must occur to protect the SCCRP sent from the responder to the initiator. Other than the additional phase 2 setup, the only other difference is that L2TP on the responder must inject an additional filter into the IPsec database once the new port number is chosen.
このシナリオでは、どちらの側もトンネルを開始できます。 ダイナミックなポートが使用されるので、余分なフェーズ2交渉は応答者から創始者に送られたSCCRPを保護するために起こらなければなりません。 追加フェーズ2セットアップ以外の、他の唯一の違いは新しいポートナンバーがいったん選ばれていると応答者の上のL2TPがIPsecデータベースに追加フィルタを注がなければならないということです。
This example also shows the additional filter needed by the initiator which allows either side to start the tunnel. In either the dial-out or the gateway to gateway scenario this additional filter is required.
また、この例は創始者によって必要とされた追加フィルタを示しています(どちらの側もトンネルを始動できます)。 ゲートウェイシナリオへのダイヤルアウトかゲートウェイのどちらかでは、この追加フィルタが必要です。
For this example, assume the dynamic port given to the initiator is 5000 and his IP address is 1.1.1.1. The responder will use an IP address of 2.2.2.1 and a port number of 6000.
この例に関して、創始者に与えられたダイナミックなポートが5000であり、彼のIPアドレスが5000であると仮定してください。1.1 .1 .1。 応答者は6000年について.2の.1とaポートが達する2.2のIPアドレスを使用するでしょう。
The filters for this scenario are:
このシナリオのためのフィルタは以下の通りです。
A.2.1 Initial Filters to allow either side to respond to negotiations
A.2.1は、どちらの側がも交渉に応じるのを許容するためにFiltersに頭文字をつけます。
In this case both peers must be able to accept phase 2 negotiations to from L2TP peers. My-IPAddr is defined as whatever IP address the device is willing to accept L2TP negotiations on.
この場合同輩がL2TP同輩からフェーズ2交渉を受け入れることができなければならない両方。 私、-、IPAddr、装置が受け入れても構わないとL2TP交渉を思っているいかなるIPアドレスとも定義されます。
Responder Filters present at both peers:
Inbound-1: From Any-Addr, to My-IPAddr, UDP, src Any-Port, dst 1701
両方の現在の応答者Filtersはじっと見ます: 本国行きの1: My-IPAddr、UDP、src Any-ポート、dst1701へのAny-Addrから
Note: The source IP in the inbound-1 filter above for gateway to gateway tunnels can be IP specific, such as 1.1.1.1, not necessarily Any-Addr.
以下に注意してください。 ゲートウェイトンネルへのゲートウェイにおける、上の本国行きの1個のフィルタのソースIPは1.1などのように特定のIPであるかもしれません。.1 必ずAny-Addrではなく、.1。
A.2.2 Protect the SCCRQ, one peer is now the initiator
A.2.2はSCCRQを保護して、現在、1人の同輩が創始者です。
Initiator Filters:
Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
創始者フィルタ: 外国行きの1: 1.1、.1、.1対2.2、.2、.1、UDP、src5000、dst1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 5000
Inbound-3: From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701
本国行きの1: 2.2 .2 .1、1.1 .1 .1 UDP、src1701、dst5000Inbound-2: 2.2 .2 .1、1.1 .1 .1 UDP、src Any-ポート、dst5000Inbound-3: Any-Addrから1.1、.1(UDP)がsrc Any移植する.1、dst1701
Responder Filters:
Outbound-1: None, dynamically injected when IKE Phase 2 completes
応答者フィルタ: 外国行きの1: IKE Phase2であるときにダイナミックに注入されなかったなにも完成
Inbound-1: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
本国行きの1: Any-Addrから2.2、.1(UDP)がsrc Any移植する.2、dst1701
Patel, et al. Standards Track [Page 25] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[25ページ]RFC3193
After IKE Phase 2 completes the filters at the initiator and responder will be:
IKE Phase2が創始者と応答者でフィルタを完成した後にである:
Initiator Filters:
Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
創始者フィルタ: 外国行きの1: 1.1、.1、.1対2.2、.2、.1、UDP、src5000、dst1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 5000
本国行きの1: 2.2 .2 .1、1.1 .1 .1 UDP、src1701、dst5000Inbound-2: 2.2、.2、.1対1.1、.1(UDP)がsrc Any移植する.1、dst5000
Inbound-3: From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701
本国行きの3: Any-Addrから1.1、.1(UDP)がsrc Any移植する.1、dst1701
Responder Filters:
Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
応答者フィルタ: 外国行きの1: 2.2、.2、.1対1.1、.1、.1、UDP、src1701、dst5000
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
Inbound-2: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
本国行きの1: 1.1 .1 .1、2.2 .2 .1 UDP、src5000、dst1701Inbound-2: Any-Addrから2.2、.1(UDP)がsrc Any移植する.2、dst1701
A.2.3 Protect the SCCRP after port change
A.2.3はポート変化の後にSCCRPを保護します。
At this point the responder knows which port number it is going to use. New filters should be injected by L2TP to reflect this new port assignment.
ここに、応答者は、それがどのポートナンバーを使用するかを知っています。 新しいフィルタは、この新しいポート課題を反映するためにL2TPによって注入されるはずです。
The new filter set at the responder is:
応答者に設定された新しいフィルタは以下の通りです。
Responder Filters:
Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 6000, dst 5000
Outbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
応答者フィルタ: 外国行きの1: 2.2 .2 .1、1.1 .1 .1 UDP、src6000、dst5000Outbound-2: 2.2、.2、.1対1.1、.1、.1、UDP、src1701、dst5000
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 6000
Inbound-2: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
Inbound-3: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
本国行きの1: 1.1 .1 .1、2.2 .2 .1 UDP、src5000、dst6000Inbound-2: 1.1 .1 .1、2.2 .2 .1 UDP、src5000、dst1701Inbound-3: Any-Addrから2.2、.1(UDP)がsrc Any移植する.2、dst1701
The second phase 2 will start once L2TP sends the SCCRP. Once the phase 2 negotiations complete, the new filter set at the initiator and the responder will be:
フェーズ2が一度始まる秒に、L2TPはSCCRPを送ります。 一度、2つの交渉が完成するフェーズ、創始者で用意ができている新しいフィルタ、および応答者は以下の通りになるでしょう。
Initiator Filters:
Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 6000
Outbound-2: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
創始者フィルタ: 外国行きの1: 1.1 .1 .1、2.2 .2 .1 UDP、src5000、dst6000Outbound-2: 1.1、.1、.1対2.2、.2、.1、UDP、src5000、dst1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 6000, dst 5000
Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
Inbound-3: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701
本国行きの1: 2.2 .2 .1、1.1 .1 .1 UDP、src6000、dst5000Inbound-2: 2.2 .2 .1、1.1 .1 .1 UDP、src1701、dst5000Inbound-3: 2.2、.2、.1対1.1、.1(UDP)がsrc Any移植する.1、dst1701
Patel, et al. Standards Track [Page 26] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[26ページ]RFC3193
Responder Filters:
Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 6000, dst 5000
Outbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
応答者フィルタ: 外国行きの1: 2.2 .2 .1、1.1 .1 .1 UDP、src6000、dst5000Outbound-2: 2.2、.2、.1対1.1、.1、.1、UDP、src1701、dst5000
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 6000
Inbound-2: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
Inbound-3: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
本国行きの1: 1.1 .1 .1、2.2 .2 .1 UDP、src5000、dst6000Inbound-2: 1.1 .1 .1、2.2 .2 .1 UDP、src5000、dst1701Inbound-3: Any-Addrから2.2、.1(UDP)がsrc Any移植する.2、dst1701
Once the L2TP tunnel has been successfully established, the original phase 2 may be deleted. This allows the Inbound-2 and Outbound-2 filter statements to be removed as well.
L2TPトンネルがいったん首尾よく確立されると、元のフェーズ2は削除されるかもしれません。 これは、また、Inbound-2とOutbound-2フィルタ声明が取り外されるのを許容します。
Intellectual Property Statement
知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
Patel, et al. Standards Track [Page 27] RFC 3193 Securing L2TP using IPsec November 2001
パテル、他 2001年11月にIPsecを使用することでL2TPを固定する標準化過程[27ページ]RFC3193
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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機能のための基金は現在、インターネット協会によって提供されます。
Patel, et al. Standards Track [Page 28]
パテル、他 標準化過程[28ページ]
一覧
スポンサーリンク
