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
Securing L2TP using IPsec
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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（レイヤ2トンネリングプロトコル）トンネル認証、プライバシー保護、整合性チェックやリプレイ保護を提供するためにIPsecを利用することができる方法について説明します。両方の自発的および強制トンネリングケースが考察されています。
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
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認証、ならびに（[10]に記載の）PPP暗号化制御プロトコル（ECP）、および圧縮制御プロトコル（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セキュリティアーキテクチャ文書で構成されている[6]に記載のIKE、[7]に記載の[3]に記載のIPsec AH、およびIPsec ESP、[4]。 AHとESPは、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 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.
この文書では、IPネットワーク上でL2TPトラフィックを保護するためのIPsecプロトコルスイートの使用を提案し、IPsecとL2TPを一緒に使用する方法について説明します。この文書では、エンドツーエンドのセキュリティを標準化しようとしません。エンドツーエンドのセキュリティが必要とされる場合には、追加のセキュリティメカニズム（例えば、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ネットワークのセキュリティを有効にするための正確なメカニズムは、特定の非IPネットワーク上でL2TPのための適切な基準に取り組まなければなりません。
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.
自発的トンネリングで自発的トンネリングは、トンネルは、典型的には、トンネルクライアントの使用を介して、ユーザによって作成されます。その結果、クライアントは、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.
強制的トンネリングで強制的トンネリングは、トンネルは、クライアントからの操作なしとクライアントに任意の選択を許可せずに作成されます。その結果、クライアントは、L2TPとLNSへのトンネルそれらを、それらをカプセル化しますこれは、NAS / LACにPPPパケットを送信します。強制トンネリング場合、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であるとSCCRQを受け取り、SCCRPで応答するデバイスであることができます。
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [2].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "任意"、 "推奨"、 "SHOULD"、および "the" はならない、[2]に記載のように解釈されるべきです。
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のセキュリティプロトコルは、制御パケットの認証、完全性、リプレイ保護を提供できなければなりません。また、制御パケットの機密性を保護することができるべきです。データパケットの完全性および再生保護を提供できなければならない、とのデータパケットの機密性を保護することができるかもしれません。 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との間の相互認証を提供します。したがって、パケット単位で制御およびデータトラフィックを保護しません。このように、L2TPトンネル認証は、攻撃に対して脆弱にL2TPトンネルを残します。 PPPは、LNSにクライアントを認証するだけでなく、パケットごとの認証、完全性、または再生保護を提供していません。 PPPの暗号化はPPPトラフィックの機密性の要件を満たしているが、認証、整合性、再生保護とキー管理の要件に対応していません。また、[10]に概説PPP ECPネゴシエーションは、保護されたciphersuiteネゴシエーションを提供しません。したがって、PPP暗号化は弱いセキュリティソリューションを提供し、加えて、L2TP制御チャネルを確保するのを助けるありません。
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セキュリティの範囲外で話している間、クライアントは、ダイヤルアップリンクを介して送信されるPPPパケットの機密性、認証、リプレイおよび完全性保護を提供すべきです。認証、再生及び完全性保護が現在に記載のPPP暗号化方法によってサポートされていない[11] - [13]。
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のセキュリティプロトコルは、制御パケットの認証、整合性および再生保護を提供しなければなりません。また、制御パケットの機密性を保護する必要があります。これは、データパケットの完全性および再生保護を提供しなければならない、とのデータパケットの機密性を保護することができます。 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 ESPを実装しなければなりません。トランスポート・モードをサポートしなければなりません。トンネルモードをサポートすることができます。 NULL暗号化を含む（RFC 2406に記載され[4]、RFC 2402 [3]）すべてのIPSec-義務付け暗号スイートは、サポートしなければなりません。実装は、すべてのIPsec暗号スイートをサポートしなければならないが、それはものが使用されるオペレータの選択であることに注意してください。機密性が必要とされていない場合（例えば、L2TPデータトラフィック）は、ESP 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は、IPsec DOIを使用して、認証、セキュリティアソシエーションのネゴシエーション、およびキー管理のためにサポートするべきである[5]。
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はコネクション指向のプロトコルであるので、ステートフルな圧縮/暗号化の使用が可能であるが、IP上で実行したときに、これは望ましいことではありません。優れた圧縮を提供しながら、基本的な信頼性の高い配信メカニズムなしで使用する場合、ステートフルな方法は、パケット損失を拡大します。パケットロスが大きくなる可能性がインターネット上で使用された場合その結果、彼らは問題があります。 L2TPは、[1]接続指向ですが、パケットの順序は必須ではありません、
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.
これはステートフルな圧縮/暗号化方式の実装の難しさを作成することができます。 L2TPは、これらのメディア保証発注するので、そのようなIEEE 802、ATM、X.25、またはフレームリレーなどの非IPメディア上で実行されたときにこれらの考慮事項は、同様に重要ではない、とパケット損失は一般的に低いです。
The following guidelines are established to meet L2TP security requirements using IPsec in practical situations.
次のガイドラインは、実際の状況にIPsecを使用したL2TPのセキュリティ要件を満たすために設立されています。
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トンネルのhelloは非優雅なティアダウンが発生したときを検出する機能を提供します。トンネルを引き起こすティアダウンイベント発生は、閉鎖するときはいつでも、で定義された制御接続ティアダウン機構[1]を使用しなければなりません。 L2TPトンネルがいずれかのピアで削除されると、ピアとの間のL2TPトンネルの結果が削除されるべきこととして、任意のフェーズ1とフェーズ2 SAの依然として存在します。これが発生すると、フェーズ1とフェーズ2つの削除メッセージを送ってください。
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は、フェーズ1またはフェーズ2削除メッセージを受信した場合に、IKEは、このイベントが発生したL2TPを通知しなければなりません。 L2TP状態はZLB ACKがSTOPCCNに応答して送信されたものである場合、これはピアがZLB ACKを受信したピアに関連する任意のL2TPトンネル状態のティアダウンを実行したことを肯定応答であると仮定することができます。 L2TPトンネル状態と関連するフィルタは安全に取り外すことができます。
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フレームにL2TPとIPsecヘッダを付加するとき、断片化が問題になることができます。この問題を軽減するために使用することができる1つの機構は、L2TP / IPsecトンネルの入口/出口インタフェースマイナスエクストラヘッダのオーバーヘッドのMTU値とPPPを提供することです。これは、セットアップとが、LCP交渉が始まる前に、L2TPトンネルがされた後に発生する必要があります。トンネルの入口/出口インターフェイスのMTU値は、PPPのデフォルトのMTUよりも小さい場合は、それが使用されている値を置き換えることができます。この値は、LCPコンフィグREQにMRUために提案されている初期値として用いてもよいです。
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に格納されるべきです。新しいMTU値がPPPインターフェースに反映させることができるように、IPsecはまた、L2TPに、このイベントの通知を提供すべきです。 PPPインターフェースで見られるすべての新しいPTMUの発見は、この新しい値に照らしてチェックし、それに応じて処理されるべきです。
When a packet arrives from a tunnel which requires security, L2TP MUST:
パケットがセキュリティを必要とトンネルから到着すると、L2TPの必要があります。
[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トンネルを設定するために使用されたソケット情報と一致することを確認します。このステップでは、他のトンネルにパケットをスプーフィングから悪意のあるピアを防ぐことができます。
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 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.
現在のL2TP仕様はSCCRPを送信するときに、応答が新しいIPアドレスを使用することができますが、IPsecの経由でL2TPの保護を必要とする実装はこれをすべきではありません。 L2TPとIPsecを使用している場合、この動作を可能にするため、応答者は、新しいIPアドレスを選択したとき、それは結果で、イニシエータにStopCCNを送信し、コードAVPの存在をエラーしなければなりません。結果コードは2に設定しなければならない（一般エラー）とエラーコードは（別のを試してみてください）7に設定する必要があります。エラーコードは7に設定されている場合、任意のエラーメッセージが存在しなければならないし、内容物をレスポンダが後続の通信に使用したい（ASCIIで符号化された）IPアドレスを含まなければなりません。唯一のASCIIエンコードされたIPアドレスは、エラーメッセージ中に存在すべきです。 IPアドレスは、IPv6のIPv4またはRFC 2373にドット付き10進形式でエンコードされた[17]の形式です。イニシエータは、結果とエラーコード情報を解析し、エラーメッセージに含まれる新しいIPアドレスに新しいSCCRQを送らなければなりません。今イニシエータは、常に正確にそのピアの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を保護するために必要な他の機構を収容するために必要なフィルタリングの詳細は次のセクションで説明されています。
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]は、キーが存在しなければなりません。 （アイデンティティ保護を提供します）メインモードを使用する場合は、このキーは、ピアのIPアドレスに対応している必要があります。 （アイデンティティ保護を提供しない）アグレッシブモードを使用する場合は、事前共有キーが、[5]のIPsec DOIで定義された有効なIDタイプのいずれかにマップしなければなりません。
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アドレスがメッセージに存在している、それが中に含まれる新しいIPアドレスにIKEで使用されたオリジナルの事前共有キーを結合することができますエラーメッセージ。
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.
一つは、キーが管理することがますます困難になっ事前共有、LACとLNSエンドポイントの数が成長するフェーズ1の認証方法として事前共有キーを使用しての拡張性に影響を考慮することを望むかもしれないことがあります。可能な限り、証明書による認証が好ましいです。
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を確保すると、次のケースを考慮する必要があります。
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 |
+--------------------------------------------------+
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
- > IKEフェーズ1とフェーズ2の初期SCCRQを保護するために、
SCCRQ -> (Fixed IP address, Dynamic Initiator Port)
<- STOPCCN (Responder chooses new IP address)
-> New IKE Phase 1 and Phase 2 to protect new SCCRQ
- >新規IKEフェーズ1とフェーズ2の新しいSCCRQを保護するために、
SCCRQ -> (SCCRQ to Responder's new IP address)
SCCRQ - >（レスポンダの新しいIPアドレスにSCCRQ）
<- New IKE Phase 2 to for port number change by the responder
< - 新しいIKEフェーズ2のポート番号の変更のために応答することにより
<- SCCRP (Responder chooses new port number)
SCCCN -> (L2TP Tunnel Establishment completes)
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.
イニシエータとレスポンダは、一般的にポートを動的に変更しませんが、L2TPセキュリティは、このようなロードバランシングやQoSなどの新しいアプリケーションに対応しなければなりません。これは、L2TPトンネル確立中にそのポートとIPアドレスのフロートが必要な場合があります。
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アドレスとポートをフロートする機能をサポートするために必要とされていません。しかし、イニシエータは、応答者がそのポートをフロートすると応答が新しいIPアドレスを（以下、セクション4.2.3を参照）を選択できるようにする必要があり許容しなければなりません。
Appendix A provides examples of these cases using the process described below.
付録Aは、下記の方法を用いて、これらのケースの例を提供します。
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.
I-ポート] UDPポート番号は、イニシエータは/発信にL2TPトラフィックを受信することを選択します。この1701のような静的ポートまたはソケットによって割り当てられた短命1つであることができます。
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トラフィックを受信/発信することを選択したR-ポート] UDPポート番号。これは、ポート番号1701またはソケットによって割り当てられた短命いずれかになります。これは、Responderが初期SCCRQを受けた後に使用するポート番号です。
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.
R-IPAddr1ザ・IPは、Responderが初期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.
R-IPAddr2ザIPはResponderがSCCRQを受けて選択取り組みます。このアドレスは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をレスポンダはL2TPパケットを送信及び受信するために使用するIPアドレス。これは、R-IPAddr1の初期値やR-IPAddr2の新しい値のいずれかです。
I-IPAddr The IP address the Initiator uses to communicate with for the L2TP tunnel.
I-たIPAddrザIPイニシエータは、L2TPトンネルのと通信するために使用するアドレス。
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
任意-ADDR任意-アドレスの存在は、IKEは、IKEフェーズ2つのネゴシエーションの間にピアによって送信されたクイックモードIDのローカルアドレスで提案されている任意の単一のアドレスを受け入れる必要があることを規定しています。この単一のアドレスは次のようにフォーマットされてもよいです
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.
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.
任意のポートの任意のポートの存在は、IKEは、0の値またはIKEフェーズ2中にネゴシエートクイックモードIDのポート値のポート値のための特定のポート値を受け入れる必要があることを規定しています。
The filters defined in the following sections are listed from highest priority to lowest priority.
以下のセクションで定義されたフィルタは、最低の優先度を最優先に記載されています。
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：どれ-ADDRから、任意のポートSRC、DST 1701 R-IPAddr1、UDP、へ
Initiator Filters: Outbound-1: From I-IPAddr, to R-IPAddr1, UDP, src I-Port, dst 1701
イニシエータフィルタ：アウトバウンド-1：I-たIPAddrから、R-IPAddr1、UDP、SRC I-ポート、DST 1701
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に、任意のポートSRC、DST I-ポート：R-IPAddr1から、I-たIPAddr、UDP、SRC 1701、I-ポートインバウンド-2 DSTへ
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のフィルタ文で任意のポートの定義は、そのポート番号を変更する応答の結果として生じる可能性がある潜在的なポートの変更を処理するために必要とされます。
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.
フェーズ2 SAバンドルがSCCRQを保護するために、既に存在していない場合は、イニシエータによってSCCRQの送信は、このパケットを保護するために、セットアップに必要なSAをIKEが発生する必要があります。また、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:
イニシエータによって送信されたクイックモードIDのポート番号は、UDPソケットを識別するために使用される特定のポート番号を含まなければなりません。ポート番号は、初期SCCRQのためのI-ポート/ 1701または1701分の1701のどちらかだろう。イニシエータによって送信されたクイックモードIDは、レスポンダでインバウンド-1のフィルタのサブセットであろう。結果として、クイックモードの交換が終了し、IKEは、IPsecフィルタデータベースに設定された特定のフィルタを注入し、ピア間で確立フェーズ2 SAと設定されたこのフィルタを関連付けるべきです。これらのフィルタは限りL2TPトンネルが存在する持続すべきです。応答者に設定され、新しいフィルタは次のようになります。
Responder Filters: Outbound-1: From R-IPAddr1, to I-IPAddr, UDP, src 1701, dst I-Port
レスポンダフィルタ：アウトバウンド-1：R-IPAddr1から、I-たIPAddr、UDP、SRC 1701、DST I-ポートへ
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：どれ-ADDRから、任意のポート、DST 1701 SRC R-IPAddr1、UDP、へ：I-たIPAddrから、R-IPAddr1、UDP、SRC I-ポート、DST 1701インバウンド-2へ
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.
メカニズムは、SAが確立されている間にL2TPがSCCRQを再送しないようにL2TPとIPsecの間に存在すべきです。 SAが確立されるとL2TPの制御チャネルの再送メカニズムが開始する必要があります。これは、低速のSA確立の結果として発生する可能性がタイムアウトを防ぐことができます。
Once the phase 2 SA has been established between the peers, the SCCRQ should be sent from the initiator to the responder.
フェーズ2 SAは、ピア間で確立されると、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トンネルは現在確立に進むことができます。
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アドレスを選択したときに従うべきプロセスについて説明します。そのIPアドレスを変更するには、応答者のための唯一の機会はSCCRQを受けた後が、SCCRPを送信する前です。
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に反映されなければなりません。 （試してみてください結果コードは、2（一般エラー）に設定しなければならなくて、エラーコードは7に設定しなければなりません
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.
別）。レスポンダは、その後の通信に使用することを望む任意のエラーメッセージが存在している必要があり、内容はIPアドレス（符号化されたASCII）を含まなければなりません。唯一のASCIIエンコードされたIPアドレスは、エラーメッセージ中に存在すべきです。 IPアドレスは、IPv6のIPv4またはRFC 2373にドット付き10進形式でエンコードされた[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メッセージは、イニシエータが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を受信すると、イニシエータは、結果からIPアドレスを解析し、コードAVPをエラーと、これは正しくフォーマットアドレスであることを確認するために必要な健全性チェックを実行しなければなりません。エラーが検出されない場合はL2TPは、IPsecフィルタのデータベースにフィルタの新しいセットを注入しなければなりません。事前共有キー認証を使用している場合、L2TPは、元の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とフェーズ2 SAは、ピア間で確立されなければなりません。
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：I-たIPAddrから、R-IPAddr2、UDP、SRC I-ポート、DST 1701
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に、任意のポートSRC、DST I-ポート：R-IPAddr2から、I-たIPAddr、UDP、SRC 1701、I-ポートインバウンド-2 DSTへ
Once IKE phase 2 completes, the new filter set at the responder will be:
IKEフェーズ2が完了したら、応答者に設定され、新しいフィルタは次のようになります。
Responder Filters: Outbound-1: From R-IPAddr2, to I-IPAddr, UDP, src 1701, dst I-Port
レスポンダフィルタ：アウトバウンド-1：R-IPAddr2から、I-たIPAddr、UDP、SRC 1701、DST I-ポートへ
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：どれ-ADDRから、任意のポート、DST 1701 SRC R-IPAddr1、UDP、へ：I-たIPAddrから、R-IPAddr2、UDP、SRC I-ポート、DST 1701インバウンド-2へ
If the responder chooses not to move to a new port number, the L2TP tunnel setup can now complete.
応答者は、新しいポート番号に移動しないことを選択した場合、L2TPトンネルのセットアップは完了することができます。
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ポートに、DST R-ポートは、発信-2：I-たIPAddrから、R-たIPAddr、UDP、SRC Iポート、DSTへ1701
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 1701、DST I-ポートInbound-へ：R-たIPAddrから、I-たIPAddr、UDP、SRC R-ポート、I-ポートインバウンド-2 DSTへ3：R-たIPAddrから、DST I-ポート、任意のポートSRC、I-たIPAddr、UDPへ
The Inbound-1 filter for the initiator will be injected by IKE upon successful completion of the phase 2 negotiations initiated by the peer.
イニシエータのインバウンド-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-ポート、DSTへのI-ポートアウトバウンド-2：R-たIPAddrから、I-たIPAddr、UDP、SRC 1701、DST I-港
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-ポート、DST 1701 Inbound-へ：I-たIPAddrから、R-たIPAddr、UDP、SRC I-ポート、DST R-ポートインバウンド-2へ3：任意-ADDRから、R-IPAddr1、UDP、にどれポートSRC、DST 1701
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およびそれらの関連するフィルタを削除してもよいです。
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を開始することができます。前のステップで概説したプロセスは、一加えて従うべきです。両側に設定された初期フィルタは、次のフィルタを含める必要があります。
Inbound Filter: 1: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701
インバウンドフィルタ：1：どれ-ADDRから、任意のポートSRC、DST 1701 R-IPAddr1、UDP、へ
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を保護するために必要なインバウンドとアウトバウンドフィルタを挿入する必要があります。トンネルの確立は、前のセクションで述べたとおりに進めます。
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 RFC 2409に指定された認証方法を交渉しなければならない[7]。 [16] - IKE認証に加えて、L2TPの実装は、[15]に記載されているような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は、認証されると、結果として得られたキーは、パケットごとの認証、整合性および再生保護を提供するために使用されています。結果として、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.
アイデンティティがIKEがマシンのアイデンティティである内主張しながら、私たちは、PPPに記載アイデンティティがユーザアイデンティティであると仮定しよう。唯一のマシンIDは、パケット単位で検証されているので、PPP内で認証されたユーザのみがトンネルを使用していることを確認する方法はありません。実際には、唯一のマシン認証をサポートするIPsec実装は、一般的に、トラフィックの分離を強制する方法はありません。 L2TP / IPsecトンネルが開かれたら、マシン認証が使用される結果として、マルチユーザマシン上のユーザは、典型的には、トンネルダウントラフィックを送信することができるであろう。
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内アサートのユーザーIDは、パケット単位で検証されます。ユーザ認証が使用されているユーザ間のトラフィックの分離を提供するために、クライアントは、その特定のユーザからのトラフィックのみがL2TPトンネルを下されていることを確認しなければなりません。
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証明書要求ペイロード（CRP）を使用することが予想されるか、いくつかの認証局が信頼されている場合は、いくつかのCRPを使用することができますし、そのIPsecのIKE認証ポリシーで設定。
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はトンネルクライアントエンドポイントは、自分が選んだPKIから自分自身の証明書の資格情報を使用して接続することを可能にするために、いくつかの認証局を信頼することができるべきです。失効リストのチェックの違いは、異なるPKIプロバイダの間に存在するので、クライアントとサーバー側の証明書失効リストのチェックは、あたり-CAベースで有効にすることができます。
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.
L2TPの実装は、各送信元および宛先ポートの組み合わせのセキュリティが正常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 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.
スマートカード証明書ストレージは、秘密鍵の妥協の可能性を軽減しながら、スマートカードは、すべての状況では必ずしも望ましいものではありません。非承認されたハードウェアの使用を制限するように例えば、マシン証明書を導入するいくつかの組織では、それらを使用しています。ユーザ認証が（心の中で、前述の弱点を保つ）PPP内に設けることができるので、IPsecの中にマシン認証のサポートは、マシンだけでなく、ユーザーの両方を認証することが可能になることができます。
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.
この二重保証が別のマシンからマシン証明書の移動を可能にする、貴重な考慮した状況では、マシン証明書は、スマートカードに格納された場合に可能であるように、望ましくない場合があります。
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のいずれか）の証明書を取得するために使用することができた場合は、その証明書は、パスワードよりも多くのセキュリティ値を持っていません。盗まれたパスワードからユーザ証明書を取得するために、攻撃者の能力を制限するには、登録期間は、パスワードアクセスがオフになり、その後、制限することができます。登録期間が終了した後、このような政策は、ユーザ証明書の取得から未使用のアカウントのパスワードを取得する攻撃を防ぐことができます。
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メインモードでの事前共有キーの使用は、man-in-the-middle攻撃に対して脆弱です。 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の間に自分自身を識別します。唯一の双方が事前共有鍵の知識を持つグループのメンバーであることが知られています。これは、man-in-the-ミドルとして機能するグループ事前共有キーへのアクセス権を持つ誰もが可能になります。
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 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.
PPPは、相互認証を実行しない限り、主モードは事前共有キーと共に使用される結果として、サーバーは認証されていません。これは、正常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実装はLNSへのIKE認証のためのグループ事前共有キーを使用しないでください。 IKEの事前共有認証キーの値は、L2TPで使用するユーザのアカウントのパスワードと同様に保護する必要があります。
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の暗号化および圧縮のための交渉プロセスに影響を与えることができると仮定する。
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の間で設定セキュリティアソシエーションの性質を得ることにより、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 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は、機密性、認証、完全性、再生保護は、自身とLACの間で所定の位置にあるかどうかを知ることができるので、それはPPP ECP [10]とCCP [9]ネゴシエーション中にその動作を変更するためにこの知識を使用することができます。私たちはLNSの機密保持ポリシーは、以下の条件のいずれかによって記述できると仮定しよう：「暗号化を要求する、」「暗号化を許可」または「暗号化を禁止します」。 IPsecの機密性サービスが整っている場合は、「暗号化を禁止する」ポリシーを実装LNSは、ポリシーに違反していたかのように動作します。同様に、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とのヌル暗号化IPsecのESPを交渉することを望むかもしれない、とLNSは、再生保護を要求します。これは、機密性と圧縮サービスは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.
クライアントは、次のいずれかの方法で機密性サービスのためにその欲求を満たすことができます。それは、それが通信するすべてのエンドステーションがIPsecで可能であることを知っている（または、それが非IPsecの可能エンドステーションに話を拒否した場合）、それはとのIPsec ESPをPPPの暗号化/圧縮を交渉し、交渉することを拒否することができる場合代わりに、エンドステーション。クライアントは、それが接触することになるすべてのエンドステーションがIPsecの対応（ほとんどの場合）であることを知らない場合、それはPPPの暗号化/圧縮をネゴシエートします。これは、PPP圧縮/暗号化は、パケット単位でオフにすることができる場合にのみ除去することができ、重複圧縮/暗号化をもたらすことができます。 LNSは、クライアントのパケットがトンネル化されていることを知っているが、クライアントはしないので、LNSが利用可能な場合ステートレス圧縮/暗号化がECPとCCP交渉にステートレス圧縮/暗号化方法を提供することによって、使用されていることを確実にすることができることに注意してください。
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間のセキュリティアソシエーションのプロパティを取得することが可能であると仮定すると、クライアントは、それ自体と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点から、それ自体がIPパケットにカプセル化されるL2TPでカプセル化されたPPPフレームを、留意されたいです。この状況は、強制的トンネリングの場合と同じです。 LNSは、自分自身とクライアントの間に設定セキュリティアソシエーションのプロパティを取得する場合は、それらの間の場所でセキュリティサービスを知ることができます。したがって、自発的トンネリング場合には、クライアントと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の機密性が所定の位置にある場合は、「暗号化を要求する」ディレクティブは、PPPの暗号化や圧縮の使用を義務付けるない、満たされていたかのように、LNSは振る舞うことができます。通常、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 ESPは、それ自体とLNSの間の場所ですでにだった場合は、「暗号化を要求する」ディレクティブが満たされたかのように行動することができます。したがって、それはPPPの暗号化と圧縮が交渉されないことを要求することができます。 IP圧縮サービスが交渉することができない場合、一般的に何のステートレス方法は、ステートフルPPP圧縮の望ましくない影響による利用できない場合は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は一般的に、代わりにIPsecの機密性、認証、および整合性の保護サービスを交渉、PPPの暗号化および圧縮の使用を避けることができるだけでなく、IP圧縮されます。
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を交渉することができます
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でのセキュリティアソシエーション、ヌル暗号化、および機密性/圧縮を1とESPとの1。 IPSec対応のエンドステーションに向かうパケットは、ヌル暗号化セキュリティアソシエーションとESP上で実行されます、そして非のIPsec対応のエンドステーションへのパケットは、他のセキュリティ・アソシエーション上で実行します。多くのIPsec実装が同じトンネル上のL2TPパケットが複数のUDPポートから発信されることを可能にすることなく、これをサポートすることができないことに留意されたいです。これは、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間のワイヤ上で盗聴に対してクライアントを保護します。その結果、NASとPPPの暗号化と圧縮を交渉することを望むかもしれません。 PPP圧縮/暗号化は、パケット単位でオフにすることができない限り、強制的トンネリングのように、これは重複した暗号化と、おそらく圧縮になります。
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol L2TP", RFC 2661, August 1999.
[1] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコルL2TP"、RFC 2661、1999年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[3]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[4]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[5] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[5]パイパー、D.、 "ISAKMPの解釈のインターネットIPセキュリティー領域"、RFC 2407、1998年11月。
[6] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[6]アトキンソン、R.とS.ケント、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[7]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[8] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[8]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[9] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[9]ランド、D.、 "PPP圧縮制御プロトコル（CCP）"、RFC 1962、1996年6月。
[10] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[10]マイヤー、G.、 "PPP暗号化制御プロトコル（ECP）"、RFC 1968、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）"、RFC 1969、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（DESEビス）"、RFC 2419、1998年9月。
[13] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998.
[13] Hummert、K.、 "PPPトリプルDES暗号化プロトコル（3DESE）"、RFC 2420、1998年9月。
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998.
[14]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1998年11月。
[15] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)," RFC 1994, August 1996.
[15]シンプソン、W.、 "PPPチャレンジハンドシェイク認証プロトコル（CHAP）、" RFC 1994、1996年8月。
[16] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)," RFC 2284, March 1998.
[16]ブルンク、L.及びJ. Vollbrecht、 "PPP拡張認証プロトコル（EAP）、" RFC 2284、1998年3月。
[17] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[17] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、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.
この問題空間の有益な議論のためのガーディープ・シンポール、デビッドEitelbach、ピーター・フォード、そしてマイクロソフトのサンジェイ・アナンド、シスコのインテルとロブ・アダムスのジョン・リチャードソンに感謝します。
Authors' Addresses
著者のアドレス
Baiju V. Patel Intel Corp 2511 NE 25th Ave Hillsboro, OR 97124
Baiju V.パテル米Intel Corp. 2511 NE 25日アベニューヒルズボロ、OR 97124
Phone: +1 503 702 2303 EMail: baiju.v.patel@intel.com
電話：+1 503 702 2303 Eメール：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 Eメール：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 425 703 8729 Eメール：wdixon@microsoft.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, Washington 98004
グレンツォルンシスコシステムズ社500第108アベニューN.E.、スイート500ベルビュー、ワシントン98004
Phone: +1 425 438 8218 Fax: +1 425 438 1848 EMail: gwz@cisco.com
電話：+1 425 438 8218ファックス：+1 425 438 1848 Eメール：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 919 392 6951 Eメール：ebooth@cisco.com
Appendix A: Example IPsec Filter sets for L2TP Tunnel Establishment
付録A：L2TPトンネルの設立のための例のIPsecフィルタセット
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.
このセクションでは、L2TPトンネル確立のIPSecフィルタセットの例を提供します。例えば、フィルタセットがIPv4であるが、同様の例は、同じように簡単にIPv6用に構成することができます。
A.1 Initiator and Responder use fixed addresses and ports
A.1イニシエータとレスポンダは、固定アドレスとポートを使用します
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トンネル確立中に変化しないので、これは例最も簡単です。イニシエータは、応答者がそのポート番号を変更するかどうかわからないので、それはまだこのような場合のために準備しなければなりません。この例では、開始剤は、1.1.1.1のIPv4アドレスを使用すると、レスポンダは2.2.2.1のIPv4アドレスを使用します。
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
イニシエータフィルタ：2.2.2.1に1.1.1.1から、UDP、SRC 1701、DST 1701：アウトバウンド-1
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、任意のポートSRC、DST 1701：2.2.2.1から、1.1.1.1、UDP、SRC 1701、DST 1701インバウンド-2へ
Responder Filters: Outbound-1: None, dynamically injected when IKE Phase 2 completes
レスポンダフィルタ：アウトバウンド-1：なし、動的IKEフェーズ2が完了注入しません
Inbound-1: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
インバウンド-1：どれ-ADDRから、2.2.2.1に、UDP、任意のポートSRC、DST 1701
After IKE Phase 2 completes the filters at the initiator and responder will be:
IKEフェーズ2は、イニシエータとレスポンダでフィルターを完了した後になります。
Initiator Filters: Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701, dst 1701
イニシエータフィルタ：2.2.2.1に1.1.1.1から、UDP、SRC 1701、DST 1701：アウトバウンド-1
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、任意のポートSRC、DST 1701：2.2.2.1から、1.1.1.1、UDP、SRC 1701、DST 1701インバウンド-2へ
Responder Filters: Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 1701
レスポンダフィルタ：1.1.1.1に2.2.2.1から、UDP、SRC 1701、DST 1701：アウトバウンド-1
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：どれ-ADDRから、と2.2.2.1、UDP、任意のポートSRC、DST 1701：1.1.1.1から、2.2.2.1、UDP、SRC 1701、DST 1701インバウンド-2へ
A.2 Gateway to Gateway Scenario where Initiator and Responder use dynamic ports
イニシエータとレスポンダは、動的ポートを使用ゲートウェイシナリオに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アドレスが1.1.1.1であると仮定します。応答者は、2.2.2.1のIPアドレスと6000のポート番号を使用します。
The filters for this scenario are:
このシナリオのためのフィルタは、次のとおりです。
A.2.1 Initial Filters to allow either side to respond to negotiations
A.2.1初期フィルタはどちらの側が交渉に応じることを可能にします
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
両方のピアに存在レスポンダフィルタ：インバウンド-1：どれ-ADDRから、私の-たIPAddr、UDP、にどれポートSRC、DST 1701
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は、IPを特定することができ、例えば、1.1.1.1、必ずしも任意-ADDRを。
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
イニシエータフィルタ：2.2.2.1に1.1.1.1から、UDP、SRC 5000、DST 1701：アウトバウンド-1
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、SRC 1701、DST 5000インバウンド-2：2.2.2.1から、1.1.1.1に、UDP、任意のポートSRC、DST 5000インバウンド-3：いずれかから-addr、1.1.1.1、UDP、任意のポートSRC、DST 1701
Responder Filters: Outbound-1: None, dynamically injected when IKE Phase 2 completes
レスポンダフィルタ：アウトバウンド-1：なし、動的IKEフェーズ2が完了注入しません
Inbound-1: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
インバウンド-1：どれ-ADDRから、2.2.2.1に、UDP、任意のポートSRC、DST 1701
After IKE Phase 2 completes the filters at the initiator and responder will be:
IKEフェーズ2は、イニシエータとレスポンダでフィルターを完了した後になります。
Initiator Filters: Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
イニシエータフィルタ：2.2.2.1に1.1.1.1から、UDP、SRC 5000、DST 1701：アウトバウンド-1
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、任意のポートSRC、DST 5000：2.2.2.1から、1.1.1.1、UDP、SRC 1701、DST 5000インバウンド-2へ
Inbound-3: From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701
インバウンド-3：どれ-ADDRから、1.1.1.1に、UDP、任意のポートSRC、DST 1701
Responder Filters: Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
レスポンダフィルタ：1.1.1.1に2.2.2.1から、UDP、SRC 1701、DST 5000：アウトバウンド-1
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：どれ-ADDRから、と2.2.2.1、UDP、任意のポートSRC、DST 1701：1.1.1.1から、2.2.2.1、UDP、SRC 5000、DST 1701インバウンド-2へ
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、SRC 6000、DST 5000アウトバウンド-2：2.2.2.1から、1.1.1.1に、UDP、SRC 1701、DST 5000
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
2.2.2.1に1.1.1.1から、UDP、SRC 5000、DST 6000インバウンド-2：インバウンド-1 1.1.1.1から、2.2.2.1に、UDP、SRC 5000、DST 1701インバウンド-3：どれ-アドレスから、 、2.2.2.1、UDP、任意のポートSRC、DST 1701
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:
L2TPはSCCRPを送信したら、第二フェーズ2が開始されます。 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、SRC 5000、DST 6000アウトバウンド-2：1.1.1.1から、2.2.2.1に、UDP、SRC 5000、DST 1701
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、SRC 6000、DST 5000インバウンド-2：2.2.2.1から、1.1.1.1に、UDP、SRC 1701、DST 5000インバウンド-3：2.2.2.1から、1.1.1.1、UDP、任意のポートSRC、DST 1701
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、SRC 6000、DST 5000アウトバウンド-2：2.2.2.1から、1.1.1.1に、UDP、SRC 1701、DST 5000
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
2.2.2.1に1.1.1.1から、UDP、SRC 5000、DST 6000インバウンド-2：インバウンド-1 1.1.1.1から、2.2.2.1に、UDP、SRC 5000、DST 1701インバウンド-3：どれ-アドレスから、 、2.2.2.1、UDP、任意のポートSRC、DST 1701
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を削除してもよいです。これは、インバウンド-2及びアウトバウンド-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は、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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専務に情報を扱ってください。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。