[要約] RFC 3193は、L2TP（Layer 2 Tunneling Protocol）をIPsec（Internet Protocol Security）でセキュアにするためのガイドラインです。このRFCの目的は、L2TPトンネルのセキュリティを向上させることです。
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
IPSECを使用してL2TPを保護します
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.
Copyright（c）The Internet Society（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認証を継承し、PPP暗号化制御プロトコル（ECP）（[10]に記載）および圧縮制御プロトコル（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つのピア間のネットワークレイヤーでの通信を確保するために使用されるプロトコルスイートです。このプロトコルは、[3]、IPSEC AH、[3]およびIPSEC ESPで説明されているIPセキュリティアーキテクチャドキュメント[6]、IKE、[4]で説明されているIPセキュリティアーキテクチャドキュメント[6]で構成されています。IKEは主要な管理プロトコルであり、AHとESPはIPトラフィックを保護するために使用されます。
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を一緒に使用する方法について説明します。このドキュメントでは、エンドツーエンドのセキュリティの標準化を試みません。エンドツーエンドのセキュリティが必要な場合は、L2TPトンネルセキュリティに加えて、トンネル内で追加のセキュリティメカニズム（IPSECやTLS [14]など）を使用することをお勧めします。
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.
自発的なトンネリング自発的トンネリングでは、通常、トンネルクライアントの使用を介してトンネルがユーザーによって作成されます。その結果、クライアントはL2TPパケットをNASに送信し、LNSに転送します。自発的トンネルでは、NASはL2TPをサポートする必要がなく、LACはクライアントと同じマシンに存在します。自発的トンネリングのもう1つの例は、ゲートウェイのシナリオへのゲートウェイです。この場合、トンネルはネットワークデバイス、通常はルーターまたはネットワークアプライアンスによって作成されます。このシナリオでは、どちらの側もオンデマンドでトンネルを開始する場合があります。
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.
強制トンネリング強制トンネリングでは、クライアントからのアクションなしで、クライアントに選択肢を許可することなくトンネルが作成されます。その結果、クライアントは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であり、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].
このドキュメントでは、キーワードは「可能性があります」、「必要はない」、「オプション」、「推奨」、「必要」、「必要はありません」は、[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トンネルPPPトラフィックIPおよび非IPパブリックネットワーク上のトラフィック。したがって、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交渉は、保護された暗号化された交渉を提供していません。したがって、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パケットの機密性、認証、リプレイ、および整合性の保護を提供する必要があります。[11] - [13]で説明されているPPP暗号化方法では、認証、リプレイ、および整合性の保護は現在サポートされていません。
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を実装する必要があります。輸送モードをサポートする必要があります。トンネルモードがサポートされる場合があります。すべてのIPSEC義務のあるシファースーツ（RFC 2406 [4]およびRFC 2402 [3]に記載）を含むすべてのヌル暗号化をサポートする必要があります。実装はすべてのIPSec ciphersuitesをサポートする必要がありますが、使用するオペレーターの選択であることに注意してください。機密性が必要でない場合（例：L2TPデータトラフィックなど）、null暗号化付きのESPが使用される場合があります。実装は、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, 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がIPで実行されると、ステートレス暗号化および/または圧縮が非常に望ましいです。L2TPは接続指向のプロトコルであるため、ステートフル圧縮/暗号化の使用は実行可能ですが、IPで実行すると、これは望ましくありません。より良い圧縮を提供しながら、基礎となる信頼できる送達メカニズムなしで使用すると、ステートフルな方法はパケット損失を拡大します。その結果、パケットの損失が重要になる可能性のあるインターネット上で使用される場合、それらは問題があります。L2TP [1]は接続指向ですが、パケットの順序は必須ではありません。これにより、ステートフル圧縮/暗号化スキームの実装が困難になります。これらのメディアは注文を保証し、パケット損失が通常低いため、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 Keep-AliveメッセージとL2TPトンネルHellosは、不利な分解がいつ発生したかを検出する能力を提供します。分解イベントが発生し、トンネルが閉じられるたびに、[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状態がSTOPCCNに応じてZLB ACKが送信されているような場合、これはピアが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バイトであるため、L2TPとIPSECヘッダーをPPPフレームに準備すると、断片化が懸念される可能性があります。この問題を減らすために使用できるメカニズムの1つは、L2TP/IPSECトンネルのイングレス/出口インターフェイスのMTU値を追加ヘッダーのオーバーヘッドから差し引くことです。これは、L2TPトンネルがセットアップされた後、LCP交渉が始まる前に発生するはずです。トンネルのイングレス/出口インターフェイスの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に保存する必要があります。IPSECは、新しいMTU値をPPPインターフェイスに反映できるように、このイベントの通知を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仕様により、ResponderはSCCRPを送信するときに新しいIPアドレスを使用できますが、IPSECを介してL2TPの保護を必要とする実装はこれを行わないはずです。L2TPとIPSECを使用するときにこの動作を許可するには、Responderが新しいIPアドレスを選択するときに、結果とエラーコードAVPが表示され、InitiatorにSTOPCCNを送信する必要があります。結果コードは2（一般的なエラー）に設定する必要があり、エラーコードを7に設定する必要があります（別のエラーを試してください）。エラーコードが7に設定されている場合、オプションのエラーメッセージが存在する必要があり、コンテンツには、レスポンダーが後続の通信に使用したいIPアドレス（ASCIIエンコード）を含める必要があります。ASCIIエンコードされたIPアドレスのみがエラーメッセージに存在する必要があります。IPアドレスは、IPv4の点線10進形式またはIPv6のRFC 2373 [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]によれば、事前に共有キー認証を使用する場合、安全な通信が必要なピアごとにキーが存在する必要があります。メインモード（ID保護を提供する）を使用する場合、このキーはピアのIPアドレスに対応する必要があります。アグレッシブモードを使用する場合（アイデンティティ保護を提供しない）、事前に共有キーは、IPSEC DOI [5]で定義されている有効な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アドレスがメッセージに存在する場合、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.
フェーズ1の認証方法として、事前共有キーを使用することのスケーラビリティの意味を考慮することができます。LACおよびLNSエンドポイントの数が増加するにつれて、株式前のキーはますます困難になります。可能な場合はいつでも、証明書を使用した認証が推奨されます。
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: Cases:
IPSECでL2TPを保護する場合、次のケースを考慮する必要があります。
+--------------------------------------------------+
| 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
- >初期SCCRQを保護するためのフェーズ1とフェーズ2
SCCRQ -> (Fixed IP address, Dynamic Initiator Port) <- STOPCCN (Responder chooses new IP address)
SCCRQ->（IPアドレスを修正、動的イニシエーターポートを修正）<-StopCCN（Responderが新しいIPアドレスを選択します）
-> New IKE Phase 1 and Phase 2 to protect new SCCRQ
- >新しいSCCRQを保護するための新しいIKEフェーズ1とフェーズ2
SCCRQ -> (SCCRQ to Responder's new IP address)
sccrq->（sccrqからレスポンダーの新しいIPアドレスへ）
<- New IKE Phase 2 to for port number change by the responder
<-Responderによるポート番号の変化のための新しいIKEフェーズ2
<- SCCRP (Responder chooses new port number) SCCCN -> (L2TP Tunnel Establishment completes)
<-SCCRP（レスポンダーが新しいポート番号を選択）SCCCN->（L2TPトンネルの確立が完了）
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セキュリティはロードバランシングやQOなどの新興アプリケーションに対応する必要があります。これには、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).
Responderは、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-port udpポート番号イニシエーターがL2TPトラフィックを発信/受信することを選択します。これは、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.
r-port ResponderがL2TPトラフィックを発信/受信することを選択したUDPポート番号。これは、ポート番号1701またはソケットによって割り当てられたはかないものです。これは、最初の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アドレスは、最初の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イニシエーターがL2TPトンネルと通信するために使用するIPアドレス。
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 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.
ADDDR Any-Addressの存在は、IKEフェーズフェーズ2の交渉中にピアが送信したクイックモードIDのローカルアドレスで提案されている単一のアドレスをIKEが受け入れる必要があることを定義しています。この単一のアドレスは、IP単一アドレス、ネットマスクが255.255.255.255に設定されたIPネットマスクアドレス、および範囲が1であるIPアドレス範囲、または1つのアドレスに解決できるホスト名としてフォーマットされる場合があります。クイックモード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.
任意のポート任意のポートの存在は、IKEがIKEフェーズフェーズ2で交渉されたクイックモードIDのポート値のポート値の0または特定のポート値を受け入れる必要があることを定義しています。
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
Inbound-1：Any-ADDRからR-IPADDR1、UDP、SRC ANY-PORT、DST 1701まで
Initiator Filters: Outbound-1: From I-IPAddr, to R-IPAddr1, UDP, src I-Port, dst 1701
イニシエーターフィルター：アウトバウンド-1：I-IPADDRからR-IPADDR1、UDP、SRC I-PORT、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
Inbound-1：R-IPADDR1、I-IPADDR、UDP、SRC 1701、DST I-Port Inbound-2：R-IPADDR1からI-IPADDR、UDP、SRC ANY-PORT、DST I-PORTまで
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.
SCCRQを保護するためにフェーズ2 SAバンドルがまだ存在していない場合、イニシエーターによるSCCRQの送信により、IKEがこのパケットを保護するために必要なSASをセットアップする必要があります。または、L2TPはIKEにSAバンドルのセットアップを要求する場合もあります。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-Port/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
レスポンダーフィルター：Autbound-1：R-IPADDR1、I-IPADDR、UDP、SRC 1701、DST I-PORTへ
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-PORT、DST 1701 Inbound-2：Any-ADDRからR-IPADDR1、UDP、SRC Any-Port、DST 1701
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.
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.
ピアの間にフェーズ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アドレスを選択したときに従うべきプロセスについて説明します。Responderが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 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が使用することを選択した新しいアドレスは、STOPCCNメッセージの結果とエラーコードAVPに反映する必要があります。結果コードは2（一般的なエラー）に設定する必要があり、エラーコードは7に設定する必要があります（別のエラーを試してください）。オプションのエラーメッセージが存在する必要があり、コンテンツには、その後の通信に使用するResponderが必要とするIPアドレス（ASCIIエンコード）を含める必要があります。ASCIIエンコードされたIPアドレスのみがエラーメッセージに存在する必要があります。IPアドレスは、IPv4の点線10進形式またはIPv6のRFC 2373 [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を受信すると、イニシエーターは結果とエラーコードAVPからIPアドレスを解析し、必要な正気チェックを実行して、これが正しくフォーマットされたアドレスであることを確認する必要があります。エラーが見つからない場合、L2TPは新しいフィルターのセットをIPSECフィルターデータベースに挿入する必要があります。事前に共有キー認証を使用している場合、L2TPはIKEに、新しいIPアドレスを元のIPアドレスに使用した事前に共有キーにバインドするよう要求する場合があります。
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-PORT、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
Inbound-1：r-Ipaddr2、i-ipaddr、udp、src 1701、dst i-port inbound-2：r-ipaddr2からi-ipaddr、udp、src any-port、dst i-port
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-PORTへ
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-PORT、DST 1701 Inbound-2：Any-ADDRからR-IPADDR1、UDP、SRC Any-Port、DST 1701まで
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 Phase 2交渉を開始者との新しい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-PORT、DST R-PORT OUTBOUND-2：I-IPADDRからR-IPADDR、UDP、SRC I-PORT、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
Inbound-1：R-IpaddrからI-Ipaddr、UDP、SRC R-Port、DST I-Port Inbound-2：R-IPADDRからI-IPADDR、UDP、SRC 1701、DST I-Port Inbound-3：R-IPADDRからI-IPADDR、UDP、SRC ANY-PORT、DST I-PORTまで
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-PORT、DST I-Port Outbound-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
Inbound-1：I-IPADDRからR-IPADDR、UDP、SRC I-PORT、DST R-PORT INBOUND-2：I-IPADDRからR-IPADDR、UDP、SRC I-PORT、DST 1701インバウンド - 3：Any-AddrからR-Ipaddr1、UDP、SRC Any-Port、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を開始する場合があります。前の手順で概説されているプロセスには、1回追加されたプロセスに従う必要があります。両側に設定された初期フィルターには、次のフィルターを含める必要があります。
Inbound Filter: 1: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701
インバウンドフィルター：1：任意のADDRからR-IPADDR1、UDP、SRC ANY-PORT、DST 1701まで
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]で指定された認証方法をネゴシエーションする必要があります。IKE認証に加えて、L2TP実装は[15] - [16]に記載されているような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認証で検証されたIDが、各パケットの受信時にその後検証されないことを意味します。
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.
IPSECを使用すると、IKEで主張されたIDが認証されると、結果の派生キーがパケットごとの認証、整合性、リプレイ保護を提供するために使用されます。その結果、IKEの会話で検証されたIDは、各パケットの受信でその後検証されます。
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内で主張されているアイデンティティはマシンのアイデンティティであると仮定しましょう。マシンのアイデンティティのみがパケットごとに検証されるため、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.
機械証明書の値は、攻撃者が誤ったふりをして容易に容易になることに反比例するため、マシン証明書の登録プロセスを厳密に制御することをお勧めします。たとえば、管理者のみがマシン証明書を使用してマシンを登録する機能を持つ場合があります。
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.
SmartCard証明書ストレージは、秘密鍵の妥協の可能性を軽減しますが、スマートカードはすべての状況で必ずしも望ましいものではありません。たとえば、一部の組織は、マシン証明書を展開している組織では、承認されていないハードウェアの使用を制限するように使用しています。ユーザー認証は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.
同様に、ユーザー証明書が展開される場合、ユーザー登録プロセスを厳密に制御することをお勧めします。たとえば、ユーザーのパスワードを使用して証明書（一時的または長期の証明書または長期のいずれか）を取得できる場合、その証明書にはパスワードよりもセキュリティ値がありません。攻撃者が盗まれたパスワードからユーザー証明書を取得する機能を制限するために、登録期間を制限することができ、その後パスワードアクセスがオフになります。このようなポリシーにより、攻撃者が未使用のアカウントのパスワードを取得して、登録期間が失効したらユーザー証明書を取得することができなくなります。
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 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が相互認証を実行しない限り、メインモードが事前共有キーで使用される場合、サーバーは認証されません。これにより、グループの事前共有キーを所有するRogueサーバーが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.
強制トンネルの場合、クライアントはPPPフレームをLACに送信し、通常、フレームがトンネルにされていることも、LACとLNSの間にセキュリティサービスが整っていることを認識しません。LNSでは、L2TPにカプセル化されたPPPフレームを含むデータパケットが到着します。これは、それ自体がIPパケットにカプセル化されています。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とのnull暗号化と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.
クライアントは、2つの方法のいずれかで機密保持サービスに対する欲求を満たすことができます。通信するすべてのエンドステーションがIPSEC対応であることを知っている場合（または非IPSEC対応のエンドステーションとの話を拒否した場合）、PPP暗号化/圧縮の交渉を拒否し、IPSEC ESPの交渉を拒否できます代わりにエンドステーション。クライアントが接触するすべてのエンドステーションが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.
自発的トンネルの場合、クライアントはL2TPパケットをNASに送信し、LNSにルーティングします。ダイヤルアップリンクで、これらの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の観点からは、L2TPにカプセル化されたPPPフレームがIPパケットにカプセル化されていることに注意してください。この状況は、強制的なトンネルの場合と同じです。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の機密性が導入されている場合、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 ESPがそれ自体とLNSの間に既に施行されている場合、「暗号化が必要」指令が満たされていたかのように動作する可能性があります。したがって、PPP暗号化と圧縮を交渉しないことを要求できます。IP圧縮サービスを交渉できない場合、ステートレスメソッドが利用できない場合、ステートレスメソッドがない場合、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の機密性、認証、および整合性保護サービスの交渉、および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 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.
これにより、クライアントがIPSEC対応エンドステーションと通信している場合、暗号化が重複する場合があります。重複した暗号化/圧縮を回避するために、クライアントはLNSと2つのセキュリティ関連、1つはnull暗号化を備えたESP、もう1つは機密性/圧縮を伴う場合があります。IPSECABLE ENDSTATIONに行くパケットは、NULL暗号化セキュリティ協会で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の間のワイヤーの盗聴から保護されます。その結果、PPP暗号化とNASとの圧縮を交渉することをお勧めします。強制トンネルのように、これにより、パケットごとに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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[3] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[4] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[5] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[5] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[6] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[6] Atkinson、R。およびS. Kent、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[7] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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] Rand、D。、「PPP圧縮制御プロトコル（CCP）」、RFC 1962、1996年6月。
[10] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[10] Meyer、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. Meyer、「The Ppp des Incryption Protocol（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。and G. Meyer、「The Ppp des Encryption Protocol、バージョン2（DESE-BIS）」、RFC 2419、1998年9月。
[13] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998.
[13] Hummert、K。、「The PPP Triple-Des暗号化プロトコル（3Dese）」、RFC 2420、1998年9月。
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998.
[14] Dierks、T。およびC. Allen、「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] Blunk、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。and S. Deering、「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.
Gurdeep Singh Pall、David Eitelbach、Peter Ford、MicrosoftのSanjay Anand、IntelのJohn Richardson、CiscoのRob Adamsに感謝します。
Authors' Addresses
著者のアドレス
Baiju V. Patel Intel Corp 2511 NE 25th Ave Hillsboro, OR 97124
Baiju V. Patel Intel Corp 2511 Ne 25th Ave Hillsboro、または97124
Phone: +1 503 702 2303
EMail: baiju.v.patel@intel.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: +1 425 706-6605
EMail: bernarda@microsoft.com
William Dixon Microsoft Corporation One Microsoft Way Redmond, WA 98052
William Dixon Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: +1 425 703 8729
EMail: wdixon@microsoft.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, Washington 98004
Glen Zorn Cisco Systems、Inc。500 108th Avenue N.E.、Suite 500 Bellevue、Washington 98004
Phone: +1 425 438 8218
Fax: +1 425 438 1848
EMail: gwz@cisco.com
Skip Booth Cisco Systems 7025 Kit Creek Road RTP, NC 27709
スキップブースCisco Systems 7025 Kit Creek Road RTP、NC 27709
Phone: +1 919 392 6951
EMail: 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用に簡単に構築できます。
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:
このシナリオのフィルターは次のとおりです。
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、SRC 1701、DST 1701
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
Inbound-1：2.2.2.1、1.1.1.1、UDP、SRC 1701、DST 1701インバウンド2：2.2.2.1から1.1.1.1、UDP、SRC Any-Port、DST 1701
Responder Filters: Outbound-1: None, dynamically injected when IKE Phase 2 completes
レスポンダーフィルター：Autbound-1：なし、IKEフェーズ2が完了したときに動的に注入されます
Inbound-1: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
Inbound-1：Any-ADDRから2.2.2.1、UDP、SRC Any-Port、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
イニシエーターフィルター：アウトバウンド-1：1.1.1.1から2.2.2.1、UDP、SRC 1701、DST 1701
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
Inbound-1：2.2.2.1、1.1.1.1、UDP、SRC 1701、DST 1701インバウンド2：2.2.2.1から1.1.1.1、UDP、SRC Any-Port、DST 1701
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、SRC 1701、DST 1701
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
Inbound-1：1.1.1.1から2.2.2.1、UDP、SRC 1701、DST 1701インバウンド2：Any-ADDRから2.2.2.1、UDP、SRC Any-Port、DST 1701
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.
このシナリオでは、どちらの側もトンネルを開始できます。動的ポートが使用されるため、レスポンダーからイニシエーターに送信されるSCCRPを保護するために、追加のフェーズ2ネゴシエーションが発生する必要があります。追加のフェーズ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:
このシナリオのフィルターは次のとおりです。
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の交渉を受け入れることができなければなりません。My-IPADDRは、デバイスがL2TP交渉を受け入れる意思があるIPアドレスとして定義されます。
Responder Filters present at both peers: Inbound-1: From Any-Addr, to My-IPAddr, UDP, src Any-Port, dst 1701
両方のピアに存在するレスポンダーフィルター：Inbound-1：any-Addr、my-ipaddr、udp、src any-port、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は、1.1.1.1などのIP固有であり、必ずしもADDRではありません。
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、SRC 5000、DST 1701
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
Inbound-1：2.2.2.1、1.1.1.1、UDP、SRC 1701、DST 5000 Inbound-2：2.2.2.1、1.1.1.1、UDP、SRC Any-Port、DST 5000 Inbound-3：-Addr、1.1.1.1、UDP、SRC Any-Port、DST 1701
Responder Filters: Outbound-1: None, dynamically injected when IKE Phase 2 completes
レスポンダーフィルター：Autbound-1：なし、IKEフェーズ2が完了したときに動的に注入されます
Inbound-1: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
Inbound-1：Any-ADDRから2.2.2.1、UDP、SRC Any-Port、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
イニシエーターフィルター：アウトバウンド-1：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 1701, dst 5000 Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 5000
Inbound-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 Any-Port、DST 5000
Inbound-3: From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701
Inbound-3：Any-ADDRから1.1.1.1、UDP、SRC Any-Port、DST 1701まで
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、SRC 1701、DST 5000
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
Inbound-1：1.1.1.1から2.2.2.1、UDP、SRC 5000、DST 1701インバウンド-2：任意のADDRから2.2.2.1、UDP、SRC Any-Port、DST 1701
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
Inbound-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インバウンド3：、2.2.2.1、UDP、SRC Any-Port、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が開始されます。フェーズ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
Inbound-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.11から、1.1.1.1、UDP、SRC Any-Port、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
Inbound-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インバウンド3：、2.2.2.1、UDP、SRC Any-Port、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が削除される場合があります。これにより、Inbound-2およびAutbound-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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。