[要約] RFC 4817は、MPLSをLayer 2トンネリングプロトコルバージョン3でカプセル化する方法について説明しています。このRFCの目的は、MPLSネットワークをL2TPv3トンネル内で使用するためのガイドラインを提供することです。
Network Working Group M. Townsley
Request for Comments: 4817 C. Pignataro
Category: Standards Track S. Wainner
Cisco Systems
T. Seely
Sprint Nextel
J. Young
March 2007
Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3
レイヤー2トンネルプロトコルバージョン3上のMPLSのカプセル化
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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize an L2TPv3 encapsulation over an IP network instead.
レイヤー2トンネルプロトコル、バージョン3（L2TPV3）は、IPネットワーク上のさまざまなペイロードタイプをトンネル化するためのプロトコルを定義しています。このドキュメントでは、L2TPV3データカプセル化に対するMPLSラベルスタックとそのペイロードを運ぶ方法を定義します。これにより、従来、MPLS対応のコアネットワークを必要とするアプリケーションが可能になり、代わりにIPネットワーク上のL2TPV3カプセル化を利用できます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. MPLS over L2TPv3 Encoding .......................................2
3. Assigning the L2TPv3 Session ID and Cookie ......................4
4. Applicability ...................................................4
5. Congestion Considerations .......................................6
6. Security Considerations .........................................6
6.1. In the Absence of IPsec ....................................7
6.2. Context Validation .........................................7
6.3. Securing the Tunnel with IPsec .............................8
7. Acknowledgements ................................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
This document defines how to encapsulate an MPLS label stack and its payload inside the L2TPv3 tunnel payload. After defining the MPLS over L2TPv3 encapsulation procedure, other MPLS over IP encapsulation options, including IP, Generic Routing Encapsulation (GRE), and IPsec are discussed in context with MPLS over L2TPv3 in an Applicability section. This document only describes encapsulation and does not concern itself with all possible MPLS-based applications that may be enabled over L2TPv3.
このドキュメントでは、L2TPV3トンネルペイロード内のMPLSラベルスタックとそのペイロードをカプセル化する方法を定義します。L2TPV3カプセル化手順を介してMPLSを定義した後、IP、汎用ルーティングカプセル化（GRE）、およびIPSECを含むIPカプセル化オプションを介した他のMPLは、適用セクションのL2TPV3を介したMPLSのコンテキストで説明されています。このドキュメントは、カプセル化のみを記述しており、L2TPV3で有効になる可能性のあるすべてのMPLSベースのアプリケーションには関心がありません。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] and its payload over an IP network, utilizing the L2TPv3 encapsulation defined in [RFC3931]. The MPLS Label Stack and payload are carried in their entirety following IP (either IPv4 or IPv6) and L2TPv3 headers.
L2TPV3を介したMPLSは、[RFC3931]で定義されたL2TPV3カプセル化を使用して、MPLSスタック[RFC3032]とIPネットワーク上のペイロードのトンネリングを可能にします。MPLSラベルスタックとペイロードは、IP（IPv4またはIPv6）およびL2TPV3ヘッダーに続いて完全に運ばれます。
+-+-+-+-+-+-+-+-+-+-+
| IP |
+-+-+-+-+-+-+-+-+-+-+
| L2TPv3 |
+-+-+-+-+-+-+-+-+-+-+
| MPLS Label Stack |
+-+-+-+-+-+-+-+-+-+-+
| MPLS Payload |
+-+-+-+-+-+-+-+-+-+-+
Figure 2.1 MPLS Packet over L2TPv3/IP
図2.1 L2TPV3/IP上のMPLSパケット
The L2TPv3 encapsulation carrying a single MPLS label stack entry is as follows:
単一のMPLSラベルスタックエントリを運ぶL2TPV3カプセル化は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
| Label | Exp |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Figure 2.2 MPLS over L2TPv3 encapsulation
図2.2 L2TPV3カプセル化に関するMPL
When encapsulating MPLS over L2TPv3, the L2TPv3 L2-Specific Sublayer MAY be present. It is generally not present; hence, it is not included in Figure 2.2. The L2TPv3 Session ID MUST be present. The Cookie MAY be present.
L2TPV3を介してMPLSをカプセル化する場合、L2TPV3 L2特異的サブレイヤーが存在する可能性があります。通常は存在しません。したがって、図2.2には含まれていません。L2TPV3セッションIDが存在する必要があります。クッキーが存在する場合があります。
Session ID
セッションID
The L2TPv3 Session ID is a 32-bit identifier field locally selected as a lookup key for the context of an L2TP Session. An L2TP Session contains necessary context for processing a received L2TP packet. At a minimum, such context contains whether the Cookie (see description below) is present, the value it was assigned, the presence and type of an L2TPv3 L2-Specific Sublayer, as well as what type of tunneled encapsulation follows (i.e., Frame Relay, Ethernet, MPLS, etc.)
L2TPV3セッションIDは、L2TPセッションのコンテキストのルックアップキーとしてローカルに選択された32ビット識別子フィールドです。L2TPセッションには、受信したL2TPパケットを処理するために必要なコンテキストが含まれています。少なくとも、そのようなコンテキストには、Cookie（以下の説明を参照）が存在するかどうか、割り当てられた値、L2TPV3 L2固有のサブレイヤーの存在とタイプ、およびトンネー付きカプセル化のタイプ（すなわち、フレームリレーが続くかどうか）が含まれます。、イーサネット、MPLSなど）
Cookie
クッキー
The L2TPv3 Cookie field contains a variable-length (maximum 64 bits), randomly assigned value. It is intended to provide an additional level of guarantee that a data packet has been directed to the proper L2TP session by the Session ID. While the Session ID may be encoded and assigned any value (perhaps optimizing for local lookup capabilities, redirection in a distributed forwarding architecture, etc.), the Cookie MUST be selected as a cryptographically random value [RFC4086], with the added restriction that it not be the same as a recently used value for a given Session ID. A well-chosen Cookie will prevent inadvertent misdirection of a stray packet containing a recently reused Session ID, a Session ID that is subject to packet corruption, and protection against some specific malicious packet insertion attacks, as described in more detail in Section 4 of this document.
L2TPV3 Cookieフィールドには、変数長（最大64ビット）、ランダムに割り当てられた値が含まれています。これは、セッションIDによって適切なL2TPセッションにデータパケットが向けられていることを追加レベルの保証を提供することを目的としています。セッションIDは任意の値をエンコードして割り当てられる場合がありますが（おそらくローカルルックアップ機能、分散型転送アーキテクチャのリダイレクトなどの最適化など）、Cookieは暗号的にランダムな値[RFC4086]として選択する必要があります。特定のセッションIDの最近使用された値と同じではありません。適切に選択されたCookieは、最近再利用されたセッションID、パケット腐敗の対象となるセッションID、およびこの悪意のあるパケット挿入攻撃に対する保護を含む迷ったパケットの不注意な誤解を防ぎます。書類。
Label Stack Entry
ラベルスタックエントリ
An MPLS label stack entry as defined in [RFC3032].
[RFC3032]で定義されているMPLSラベルスタックエントリ。
The optional L2-Specific Sublayer (defined in [RFC3931]) is generally not present for MPLS over L2TPv3.
オプションのL2特異的サブレーヤー（[RFC3931]で定義）は、一般にL2TPV3を超えるMPLSには存在しません。
Generic IP encapsulation procedures, such as fragmentation and MTU considerations, handling of Time to Live (TTL), EXP, and Differentiated Services Code Point (DSCP) bits, etc. are the same as the "Common Procedures" for IP encapsulation of MPLS defined in Section 5 of [RFC4023] and are not reiterated here.
断片化やMTUの考慮事項、ライブへの時間の処理（TTL）、EXP、および差別化されたサービスコードポイント（DSCP）ビットなどの一般的なIPカプセル化手順は、定義されたMPLSのIPカプセル化の「一般的な手順」と同じです。[RFC4023]のセクション5では、ここでは繰り返されません。
Much like an MPLS label, the L2TPv3 Session ID and Cookie must be selected and exchanged between participating nodes before L2TPv3 can operate. These values may be configured manually, or distributed via a signaling protocol. This document concerns itself only with the encapsulation of MPLS over L2TPv3; thus, the particular method of assigning the Session ID and Cookie (if present) is out of scope.
MPLSラベルと同じように、L2TPV3が動作する前に、L2TPV3セッションIDとCookieを選択して交換する必要があります。これらの値は、手動で構成するか、シグナル伝達プロトコルを介して分布する場合があります。このドキュメントは、L2TPV3を介したMPLSのカプセル化のみに関係しています。したがって、セッションIDとCookie（存在する場合）を割り当てる特定の方法は範囲外です。
The methods defined in [RFC4023], [MPLS-IPSEC], and this document all describe methods for carrying MPLS over an IP network. Cases where MPLS over L2TPv3 is comparable to other alternatives are discussed in this section.
[RFC4023]、[MPLS-IPSEC]で定義されている方法、およびこのドキュメントはすべて、MPLSをIPネットワーク上で運ぶ方法について説明します。このセクションでは、L2TPV3を超えるMPLSが他の代替品に匹敵する場合について説明します。
It is generally simpler to have one's border routers refuse to accept an MPLS packet than to configure a router to refuse to accept certain MPLS packets carried in IP or GRE to or from certain IP sources or destinations. Thus, the use of IP or GRE to carry MPLS packets increases the likelihood that an MPLS label-spoofing attack will succeed. L2TPv3 provides an additional level of protection against packet spoofing before allowing a packet to enter a Virtual Private Network (VPN) (much like IPsec provides an additional level of protection at a Provider Edge (PE) router rather than relying on Access Control List (ACL) filters). Checking the value of the L2TPv3 Cookie is similar to any sort of ACL that inspects the contents of a packet header, except that we give ourselves the luxury of "seeding" the L2TPv3 header with a value that is very difficult to spoof.
一般に、特定のIPソースまたは目的地との間で、またはGREで運ばれる特定のMPLSパケットを受け入れることを拒否するルーターを構成するよりも、RouterをMPLSパケットの受け入れを拒否することを拒否する方が一般的に簡単です。したがって、MPLSパケットを運ぶためにIPまたはGREを使用すると、MPLSラベルスプーフィング攻撃が成功する可能性が高まります。L2TPV3は、パケットが仮想プライベートネットワーク（VPN）に入ることを許可する前に、パケットスプーフィングに対する追加レベルの保護を提供します（IPSECは、アクセス制御リストに頼るのではなく、プロバイダーエッジ（PE）ルーターで追加のレベルの保護を提供します（ACL）フィルター）。L2TPV3 Cookieの値をチェックすることは、パケットヘッダーの内容を検査するあらゆる種類のACLに似ていますが、L2TPV3ヘッダーを非常に困難な値で「シード」する贅沢を自分に与えることを除きます。
MPLS over L2TPv3 may be advantageous compared to [RFC4023], if:
L2TPV3を超えるMPLは、[RFC4023]と比較して有利な場合があります。
Two routers are already "adjacent" over an L2TPv3 tunnel established for some other reason, and wish to exchange MPLS packets over that adjacency.
他の理由で確立されたL2TPV3トンネルの上に2つの2つのルーターがすでに「隣接」しており、その隣接するMPLSパケットを交換したいと考えています。
Implementation considerations dictate the use of MPLS over L2TPv3. For example, a hardware device may be able to take advantage of the L2TPv3 encapsulation for faster or distributed processing.
実装の考慮事項は、L2TPV3を介したMPLSの使用を決定します。たとえば、ハードウェアデバイスは、L2TPV3カプセル化を利用して、より高速または分散処理を行うことができる場合があります。
Packet spoofing and insertion, service integrity and resource protection are of concern, especially given the fact that an IP tunnel potentially exposes the router to rogue or inappropriate IP packets from unknown or untrusted sources. IP Access Control Lists (ACLs) and numbering methods may be used to protect the PE routers from rogue IP sources, but may be subject to error and cumbersome to maintain at all edge points at all times. The L2TPv3 Cookie provides a simple means of validating the source of an L2TPv3 packet before allowing processing to continue. This validation offers an additional level of protection over and above IP ACLs, and a validation that the Session ID was not corrupted in transit or suffered an internal lookup error upon receipt and processing. If the Cookie value is assigned and distributed automatically, it is less subject to operator error, and if selected in a cryptographically random nature, less subject to blind guesses than source IP addresses (in the event that a hacker can insert packets within a core network).
特に、IPトンネルが不明または信頼できないソースからのルーグまたは不適切なIPパケットにルーターを潜在的に露出させる可能性があるという事実を考えると、パケットのスプーフィングと挿入、サービスの整合性、リソース保護は懸念されます。IPアクセス制御リスト（ACLS）と番号付け方法は、PEルーターをRogue IPソースから保護するために使用できますが、常にすべてのエッジポイントで維持するためにエラーと面倒な場合があります。L2TPV3 Cookieは、処理を続行する前に、L2TPV3パケットのソースを検証する簡単な手段を提供します。この検証は、IP ACL以上の追加レベルの保護を提供し、セッションIDが輸送中に破損していないか、受領および処理時に内部ルックアップエラーを被ったという検証を提供します。Cookie値が自動的に割り当てられ、配布される場合、オペレーターエラーの影響が少なく、暗号化されたランダムな性質で選択されている場合、ソースIPアドレスよりも盲目の推測の影響が少ない（ハッカーがコアネットワーク内にパケットを挿入できる場合には）。
(The first two of the above applicability statements were adopted from [RFC4023].)
（上記の適用性ステートメントの最初の2つは[RFC4023]から採用されました。）
In summary, L2TPv3 can provide a balance between the limited security against IP spoofing attacks offered by [RFC4023] vs. the greater security and associated operational and processing overhead offered by [MPLS-IPSEC]. Further, MPLS over L2TPv3 may be faster in some hardware, particularly if that hardware is already optimized to classify incoming L2TPv3 packets carrying IP framed in a variety of ways. For example, IP encapsulated by High-Level Data Link Control (HDLC) or Frame Relay over L2TPv3 may be equivalent in complexity to IP encapsulated by MPLS over L2TPv3.
要約すると、L2TPV3は、[RFC4023]が提供するIPスプーフィング攻撃に対して限られたセキュリティと、[MPLS-IPEC]が提供するより大きなセキュリティおよび関連する運用および処理間接間のバランスを提供できます。さらに、L2TPV3を介したMPLSは、特にハードウェアがすでにさまざまな方法でフレーム化されたIPを運ぶ着信L2TPV3パケットを分類するために最適化されている場合、一部のハードウェアでより速くなる可能性があります。たとえば、高レベルのデータリンクコントロール（HDLC）またはL2TPV3を介したフレームリレーによってカプセル化されたIPは、L2TPV3を介したMPLによってカプセル化されたIPと複雑になる可能性があります。
This document specifies an encapsulation method for MPLS inside the L2TPv3 tunnel payload. MPLS can carry a number of different protocols as payloads. When an MPLS/L2TPv3 flow carries IP-based traffic, the aggregate traffic is assumed to be TCP friendly due to the congestion control mechanisms used by the payload traffic. Packet loss will trigger the necessary reduction in offered load, and no additional congestion avoidance action is necessary.
このドキュメントは、L2TPV3トンネルペイロード内のMPLのカプセル化方法を指定します。MPLは、ペイロードとしてさまざまなプロトコルを運ぶことができます。MPLS/L2TPV3フローがIPベースのトラフィックを運ぶと、ペイロードトラフィックで使用される渋滞制御メカニズムにより、集約トラフィックがTCPに優しいと想定されます。パケットの損失は、提供された負荷の必要な減少を引き起こし、追加の混雑回避作用は必要ありません。
When an MPLS/L2TPv3 flow carries payload traffic that is not known to be TCP friendly and the flow runs across an unprovisioned path that could potentially become congested, the application that uses the encapsulation specified in this document MUST employ additional mechanisms to ensure that the offered load is reduced appropriately during periods of congestion. The MPLS/L2TPv3 flow should not exceed the average bandwidth that a TCP flow across the same network path and experiencing the same network conditions would achieve, measured on a reasonable timescale. This is not necessary in the case of an unprovisioned path through an over-provisioned network, where the potential for congestion is avoided through the over-provisioning of the network.
MPLS/L2TPV3フローがTCPフレンドリーであることが知られていないペイロードトラフィックを運ぶ場合、フローが潜在的に混雑する可能性のある未確認のパスを越えて実行される場合、このドキュメントで指定されたカプセル化を使用するアプリケーションは追加のメカニズムを使用して提供されるようにする必要があります。渋滞の期間中、負荷は適切に減少します。MPLS/L2TPV3フローは、同じネットワークパスを横切り、同じネットワーク条件を経験するTCPフローが合理的なタイムスケールで測定される平均帯域幅を超えてはなりません。これは、ネットワークの過剰な導入を通じて混雑の可能性が回避される、過剰に生成されたネットワークを通る未確認のパスの場合には必要ありません。
The comparison to TCP cannot be specified exactly but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the roundtrip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application using the encapsulation specified in this document on the best-effort Internet, which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude. One method of determining an acceptable bandwidth is described in [RFC3448]. Other methods exist, but are outside the scope of this document.
TCPとの比較は正確に指定することはできませんが、タイムスケールとスループットの「順序の順序」比較として意図されています。TCPスループットが測定されるタイムスケールは、接続の往復時間です。本質的に、この要件は、このドキュメントで指定されたカプセル化を使用してアプリケーションを展開することは受け入れられないと述べています。許容可能な帯域幅を決定する1つの方法は、[RFC3448]で説明されています。他の方法は存在しますが、このドキュメントの範囲外です。
There are three main concerns when transporting MPLS-labeled traffic between PEs using IP tunnels. The first is the possibility that a third party may insert packets into a packet stream between two PEs. The second is that a third party might view the packet stream between two PEs. The third is that a third party may alter packets in a stream between two PEs. The security requirements of the applications whose traffic is being sent through the tunnel characterizes how significant these issues are. Operators may use multiple methods to mitigate the risk, including access lists, authentication, encryption, and context validation. Operators should consider the cost to mitigate the risk.
IPトンネルを使用してPE間でMPLS標識トラフィックを輸送する場合、3つの主な懸念があります。1つ目は、第三者が2つのPEの間のパケットストリームにパケットを挿入できる可能性です。2つ目は、サードパーティが2つのPEの間でパケットストリームを表示する可能性があることです。3つ目は、第三者が2つのPEの間のストリーム内のパケットを変更する可能性があることです。トンネルを介してトラフィックが送信されているアプリケーションのセキュリティ要件は、これらの問題がどれほど重要かを特徴づけています。オペレーターは、アクセスリスト、認証、暗号化、コンテキスト検証など、複数の方法を使用してリスクを軽減できます。オペレーターは、リスクを軽減するためのコストを考慮する必要があります。
Security is also discussed as part of the applicability discussion in Section 4 of this document.
セキュリティについては、このドキュメントのセクション4で適用可能性の議論の一部としても説明されています。
If the tunnels are not secured with IPsec, then some other method should be used to ensure that packets are decapsulated and processed by the tunnel tail only if those packets were encapsulated by the tunnel head. If the tunnel lies entirely within a single administrative domain, address filtering at the boundaries can be used to ensure that no packet with the IP source address of a tunnel endpoint or with the IP destination address of a tunnel endpoint can enter the domain from outside.
トンネルがIPSECで固定されていない場合、他の方法を使用して、パケットがトンネルヘッドによってカプセル化された場合にのみ、トンネルテールによってパケットが脱カプセル化され、処理されるようにする必要があります。トンネルが完全に単一の管理ドメイン内にある場合、境界でのアドレスフィルタリングを使用して、トンネルエンドポイントのIPソースアドレス、またはトンネルエンドポイントのIP宛先アドレスが外部からドメインに入ることができるようにすることができます。
However, when the tunnel head and the tunnel tail are not in the same administrative domain, this may become difficult, and filtering based on the destination address can even become impossible if the packets must traverse the public Internet.
ただし、トンネルヘッドとトンネルの尾が同じ管理ドメインにない場合、これは困難になる可能性があり、パケットがパブリックインターネットを通過する必要がある場合、宛先アドレスに基づくフィルタリングは不可能になる可能性があります。
Sometimes, only source address filtering (but not destination address filtering) is done at the boundaries of an administrative domain. If this is the case, the filtering does not provide effective protection at all unless the decapsulator of MPLS over L2TPv3 validates the IP source address of the packet.
場合によっては、管理ドメインの境界でソースアドレスフィルタリング（宛先アドレスフィルタリングではなく）のみが実行される場合があります。この場合、L2TPV3を介したMPLSの脱カプセレーターがパケットのIPソースアドレスを検証しない限り、フィルタリングは効果的な保護をまったく提供しません。
Additionally, the "Data Packet Spoofing" considerations in Section 8.2 of [RFC3931] and the "Context Validation" considerations in Section 6.2 of this document apply. Those two sections highlight the benefits of the L2TPv3 Cookie.
さらに、[RFC3931]のセクション8.2の「データパケットスプーフィング」考慮事項と、このドキュメントのセクション6.2の「コンテキスト検証」の考慮事項が適用されます。これらの2つのセクションは、L2TPV3 Cookieの利点を強調しています。
The L2TPv3 Cookie does not provide protection via encryption. However, when used with a sufficiently random, 64-bit value that is kept secret from an off-path attacker, the L2TPv3 Cookie may be used as a simple yet effective packet source authentication check which is quite resistant to brute force packet-spoofing attacks. It also alleviates the need to rely solely on filter lists based on a list of valid source IP addresses, and thwarts attacks that could benefit by spoofing a permitted source IP address. The L2TPv3 Cookie provides a means of validating the currently assigned Session ID on the packet flow, providing context protection, and may be deemed complimentary to securing the tunnel utilizing IPsec. In the absence of cryptographic security on the data plane (such as that provided by IPsec), the L2TPv3 Cookie provides a simple method of validating the Session ID lookup performed on each L2TPv3 packet. If the Cookie is sufficiently random and remains unknown to an attacker (that is, the attacker has no way to predict Cookie values or monitor traffic between PEs), then the Cookie provides an additional measure of protection against malicious spoofed packets inserted at the PE over and above that of typical IP address and port ACLs.
L2TPV3 Cookieは、暗号化による保護を提供しません。ただし、パス外の攻撃者から秘密にされている十分にランダムな64ビット値で使用する場合、L2TPV3 Cookieは、ブルートフォースパケットスプーフィング攻撃に非常に耐性のあるシンプルで効果的なパケットソース認証チェックとして使用できます。。また、有効なソースIPアドレスのリストに基づいてフィルターリストのみに依存する必要性を軽減し、許可されたソースIPアドレスをスプーフィングすることで利益を得ることができる攻撃を阻止します。L2TPV3 Cookieは、パケットフローで現在割り当てられているセッションIDを検証し、コンテキスト保護を提供する手段を提供し、IPSECを利用するトンネルの固定に無料とみなされる場合があります。データプレーン（IPSECが提供するものなど）に暗号化セキュリティがない場合、L2TPV3 Cookieは、各L2TPV3パケットで実行されるセッションIDルックアップを検証する簡単な方法を提供します。Cookieが十分にランダムであり、攻撃者には知られていない場合（つまり、攻撃者はCookie値を予測したり、PE間のトラフィックを監視する方法がありません）、CookieはPEに挿入された悪意のあるスプーフィングパケットに対する保護の追加尺度を提供しますそして、典型的なIPアドレスとポートACLのそれよりも上。
L2TPv3 tunnels may also be secured using IPsec, as specified in Section 4.1.3 of [RFC3931]. IPSec may provide authentication, privacy protection, integrity checking, and replay protection. These functions may be deemed necessary by the operator. When using IPsec, the tunnel head and the tunnel tail should be treated as the endpoints of a Security Association. A single IP address of the tunnel head is used as the source IP address, and a single IP address of the tunnel tail is used as the destination IP address. The means by which each node knows the proper address of the other is outside the scope of this document. However, if a control protocol is used to set up the tunnels, such control protocol MUST have an authentication mechanism, and this MUST be used when the tunnel is set up. If the tunnel is set up automatically as the result of, for example, information distributed by BGP, then the use of BGP's Message Digest 5 (MD5)-based authentication mechanism can serve this purpose.
[RFC3931]のセクション4.1.3で指定されているように、L2TPV3トンネルもIPSECを使用して固定できます。IPSECは、認証、プライバシー保護、整合性チェック、およびリプレイ保護を提供する場合があります。これらの機能は、オペレーターによって必要とみなされる場合があります。IPSECを使用する場合、トンネルヘッドとトンネルの尾をセキュリティ協会のエンドポイントとして扱う必要があります。トンネルヘッドの単一のIPアドレスがソースIPアドレスとして使用され、トンネルテールの単一のIPアドレスが宛先IPアドレスとして使用されます。各ノードが他方の適切なアドレスを知っている手段は、このドキュメントの範囲外です。ただし、コントロールプロトコルを使用してトンネルのセットアップを行う場合、そのような制御プロトコルには認証メカニズムが必要であり、トンネルのセットアップ時に使用する必要があります。たとえば、BGPによって配布された情報の結果としてトンネルが自動的にセットアップされている場合、BGPのMessage Digest 5（MD5）ベースの認証メカニズムを使用すると、この目的に役立ちます。
The MPLS over L2TPv3 encapsulated packets should be considered as originating at the tunnel head and being destined for the tunnel tail; IPsec transport mode SHOULD thus be used.
L2TPV3カプセル化されたパケットを介したMPLSは、トンネルヘッドに由来し、トンネルテールに向けられていると見なされる必要があります。したがって、IPSECトランスポートモードを使用する必要があります。
Note that the tunnel tail and the tunnel head are Label Switched Path (LSP) adjacencies (for label distribution adjacencies, see [RFC3031]), which means that the topmost label of any packet sent through the tunnel must be one that was distributed by the tunnel tail to the tunnel head. The tunnel tail MUST know precisely which labels it has distributed to the tunnel heads of IPsec-secured tunnels. Labels in this set MUST NOT be distributed by the tunnel tail to any LSP adjacencies other than those that are tunnel heads of IPsec-secured tunnels. If an MPLS packet is received without an IPsec encapsulation, and if its topmost label is in this set, then the packet MUST be discarded.
トンネルテールとトンネルヘッドは、ラベルスイッチパス（LSP）隣接（ラベル分布の隣接については[RFC3031]を参照）であることに注意してください。つまり、トンネルから送信されたパケットの最上位ラベルは、トンネルヘッドのトンネルテール。トンネルの尾は、IPSECが測定したトンネルのトンネルヘッドに分布したラベルを正確に知る必要があります。このセットのラベルは、トンネルテールによって、IPSECが固定されたトンネルのトンネルヘッドであるもの以外のLSP隣接に分配してはなりません。MPLSパケットがIPSECカプセル化なしで受信され、その最上位ラベルがこのセットにある場合は、パケットを破棄する必要があります。
Securing L2TPv3 using IPsec MUST provide authentication and integrity. (Note that the authentication and integrity provided will apply to the entire MPLS packet, including the MPLS label stack.)
IPSECを使用してL2TPV3を保護するには、認証と整合性を提供する必要があります。（提供される認証と整合性は、MPLSラベルスタックを含むMPLSパケット全体に適用されることに注意してください。）
Consequently, the implementation MUST support Encapsulating Security Payload (ESP) with null encryption. ESP with encryption MAY be supported if a source requires confidentiality. If ESP is used, the tunnel tail MUST check that the source IP address of any packet received on a given Security Association (SA) is the one expected.
その結果、実装は、null暗号化を使用して、セキュリティペイロード（ESP）のカプセル化をサポートする必要があります。ソースが機密性を必要とする場合、暗号化付きのESPがサポートされる場合があります。ESPを使用する場合、トンネルテールは、特定のセキュリティ協会（SA）で受信したパケットのソースIPアドレスが予想されるものであることを確認する必要があります。
Key distribution may be done either manually or automatically by means of the Internet Key Exchange (IKE) Protocol [RFC2409] or IKEv2 [RFC4306]. Manual keying MUST be supported. If automatic keying is implemented, IKE in main mode with preshared keys MUST be supported. A particular application may escalate this requirement and request implementation of automatic keying. Manual key distribution is much simpler, but also less scalable, than automatic key distribution. If replay protection is regarded as necessary for a particular tunnel, automatic key distribution should be configured.
主要な分布は、インターネットキーエクスチェンジ（IKE）プロトコル[RFC2409]またはIKEV2 [RFC4306]によって手動または自動的に実行される場合があります。手動キーをサポートする必要があります。自動キーイングが実装されている場合、Presharedキーを備えたメインモードのIKEをサポートする必要があります。特定のアプリケーションは、この要件をエスカレートし、自動キーイングの実装を要求する場合があります。手動のキー分布は、自動キーディストリビューションよりもはるかに単純ですが、スケーラブルではありません。リプレイ保護が特定のトンネルに必要であると見なされる場合、自動キーディストリビューションを構成する必要があります。
Thanks to Robert Raszuk, Clarence Filsfils, and Eric Rosen for their review of this document. Some text was adopted from [RFC4023].
この文書のレビューをしてくれたロバート・ラシュク、クラレンス・フィルズ、エリック・ローゼンに感謝します。[RFC4023]からいくつかのテキストが採用されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、J.、Townsley、M。、およびI. Goyret、「レイヤー2つのトンネルプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023] Worster、T.、Rekhter、Y.、およびE. Rosen、「IPまたは汎用ルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[MPLS-IPSEC] Rosen, E., De Clercq, J., Paridaens, O., T'Joens, Y., and C. Sargor, "Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Work in Progress, August 2005.
[MPLS-IPSEC] Rosen、E.、De Clercq、J.、Paridaens、O.、T'Joens、Y.、およびC. Sargor、「BGP/MPLS IP VPNSでのPE-PE IPSECトンネルの使用のためのアーキテクチャ」"、進行中の作業、2005年8月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（TFRC）：プロトコル仕様」、RFC 3448、2003年1月。
Authors' Addresses
著者のアドレス
W. Mark Townsley Cisco Systems USA
W.マークタウンズリーシスコシステムUSA
Phone: +1-919-392-3741
EMail: mark@townsley.net
Carlos Pignataro Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
Carlos Pignataro Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park、NC 27709 USA
Phone: +1-919-392-7428
EMail: cpignata@cisco.com
Scott Wainner Cisco Systems 13600 Dulles Technology Drive Herndon, VA 20171 USA
Scott Wainner Cisco Systems 13600 Dulles Technology Drive Herndon、VA 20171 USA
EMail: swainner@cisco.com
Ted Seely Sprint Nextel 12502 Sunrise Valley Drive Reston, VA 20196 USA
Ted Seely Sprint Nextel 12502サンライズバレードライブレストン、バージニア州20196 USA
Phone: +1-703-689-6425
EMail: tseely@sprint.net
Jeff Young
ジェフ・ヤング
EMail: young@jsyoung.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。