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
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）IETFトラスト（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ラベルスタックとそのペイロードを運ぶ方法を定義します。これは、伝統的に代わりに、IPネットワーク上でのL2TPv3カプセル化を利用するために、MPLS対応のコアネットワークを必要とするアプリケーションを可能にします。
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.
この文書では、MPLSラベルスタックとのL2TPv3トンネルペイロード内部ペイロードをカプセル化する方法を定義します。 MPLS L2TPv3の上のカプセル化手順を定義した後、IP、総称ルーティングカプセル化（GRE）、およびIPsecを含むIPカプセル化オプションは、上の他のMPLSは、適用セクションの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].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの言葉は、多くの場合、資産計上されます。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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カプセル化を利用し、IPネットワーク上のMPLSスタック[RFC3032]およびそのペイロードのトンネリングを可能にします。 MPLSラベルスタックとペイロードはIP（IPv4またはIPv6のいずれか）とのL2TPv3ヘッダを以下にその全体が実行されます。
+-+-+-+-+-+-+-+-+-+-+
| IP |
+-+-+-+-+-+-+-+-+-+-+
| L2TPv3 |
+-+-+-+-+-+-+-+-+-+-+
| MPLS Label Stack |
+-+-+-+-+-+-+-+-+-+-+
| MPLS Payload |
+-+-+-+-+-+-+-+-+-+-+
Figure 2.1 MPLS Packet over L2TPv3/IP
L2TPv3の/ IPの上に2.1 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
L2TPv3のカプセル化の上に2.2 MPLS図
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パケットを処理するために必要なコンテキストが含まれています。最低でも、そのようなコンテキストは、クッキー（以下の説明を参照）が存在するかどうかを含んでおり、それが割り当てられた値は、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のクッキーフィールドは、可変長（最大64ビット）、無作為に割り当てられた値を含んでいます。データパケットがセッションIDによって適切なL2TPセッションに向けられている保証の追加レベルを提供することを意図しています。セッションIDは、符号化され、任意の値を割り当てることができるが、クッキーは、それが追加の制限と、暗号乱数値[RFC4086]として選択されなければならない（おそらく、ローカル検索機能、分散転送アーキテクチャのリダイレクション、等のために最適化）指定したセッションIDの最近使用した値と同じではありません。この4節で詳細に説明するように適切に選択されたクッキーは、不注意による最近、再利用、セッション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.
（[RFC3931]で定義された）任意L2特有サブレイヤは一般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のセッションIDとクッキーを選択したL2TPv3を動作させることができます前に、参加ノード間で交換する必要があります。これらの値は手動で設定、またはシグナリングプロトコルを介して配信してもよいです。このドキュメントの懸念自体だけL2TPv3のオーバーMPLSのカプセル化。従って、セッションIDとクッキーを（存在する場合）を割り当てるの特定の方法は、範囲外です。
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]、この文書は、すべてのIPネットワーク上でMPLSを運ぶための方法を記載しています。 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.
1つの境界ルータが特定のIPソースまたは宛先にまたはからIPまたはGREで運ばれ、特定のMPLSパケットを受け入れることを拒否するようにルータを設定するよりも、MPLSパケットを受け入れることを拒否持つことが一般的に簡単です。このように、MPLSパケットを運ぶためにIPまたはGREを使用すると、MPLSラベルスプーフィング攻撃が成功する可能性が高くなります。 L2TPv3のは、ACL（IPsecがプロバイダーエッジ（PE）ルータではなく、アクセス制御リストに頼っで追加の保護レベルを提供しているのと同じよう（パケットが仮想プライベートネットワーク（VPN）を入力できるようにする前に、パケットスプーフィングに対する保護の追加レベルを提供します） フィルター）。 L2TPv3のクッキーの値をチェックする私たち自身に偽装することは非常に困難である値でL2TPv3ヘッダーを「播種」の高級感を与えることを除いて、パケットヘッダの内容を検査ACLの任意の並べ替えに似ています。
MPLS over L2TPv3 may be advantageous compared to [RFC4023], if:
場合L2TPv3の上のMPLSは、[RFC4023]に比べて有利であり得ます。
Two routers are already "adjacent" over an L2TPv3 tunnel established for some other reason, and wish to exchange MPLS packets over that adjacency.
2台のルータがすでに他のいくつかの理由のために設立のL2TPv3トンネル上の「隣接」しており、その隣接の上に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アクセス制御リスト（ACL）と番号付け方法は、不正なIPソースからPEルータを保護するために使用することができるが、常にすべてのエッジ点に維持するために、エラーの対象と面倒であってもよいです。 L2TPv3のクッキーは、処理を継続することを可能にする前のL2TPv3パケットのソースを検証する簡単な手段を提供します。この検証は、追加の保護レベルを超えると、IP ACLの上記、およびセッションIDが輸送中に破損しているか領収書と処理時に内部のルックアップエラーに見舞われていないことを検証しています。クッキー値が割り当てられ、自動的に配布されている場合、それは、オペレータエラーを受けにくい、ハッカーは、コアネットワーク内のパケットを挿入することができた場合には（送信元IPアドレスよりブラインド推測されにくい暗号ランダムな性質に選択した場合）。
(The first two of the above applicability statements were adopted from [RFC4023].)
（上記適用文の最初の二つは、[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のは[MPLS-IPSEC]によって提供されるより高いセキュリティと関連する演算及び処理オーバーヘッド対[RFC4023]によって提供されるIPスプーフィング攻撃に対する限定されたセキュリティとの間のバランスを提供することができます。さらに、L2TPv3の上MPLSは、そのハードウェアが既に様々な方法で枠IPを搬送する入来のL2TPv3パケットを分類するために最適化されている場合は特に、いくつかのハードウェアで高速化することができます。たとえば、IPハイレベルデータリンク制御（HDLC）によりカプセル化またはL2TPv3の上でフレームリレーは、L2TPv3の上のMPLSによりカプセル化された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のトンネルペイロード内のMPLSのカプセル化方法を指定します。 MPLSは、ペイロードとして、多数の異なるプロトコルを運ぶことができます。 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のスループットが測定されているタイムスケールは、接続の往復時間です。本質的には、この要件は、任意の帯域幅を消費し、桁以内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ラベルされたトラフィックを転送する際に三つの主要な懸念があります。最初は、サードパーティは、2つのPE間のパケットストリームにパケットを挿入することができる可能性です。第二は、第三者が2つのPE間のパケットストリームを見るかもしれないということです。第三は、サードパーティは、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.
また、このドキュメントのセクション6.2で[RFC3931]のセクション8.2の「データパケットスプーフィング」考慮事項と「コンテキストの検証」の考慮事項が適用されます。これらの2つのセクションでは、L2TPv3のクッキーのメリットを強調します。
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のクッキーは暗号化を通じて保護を提供しません。オフ・パス攻撃者から秘密にされ、十分にランダム、64ビット値で使用した場合しかし、L2TPv3のクッキーは、ブルートフォースパケットスプーフィング攻撃に対して非常に耐性があるシンプルで効果的なパケットの送信元認証チェックとして使用することができます。また、有効な送信元IPアドレスのリストに基づいて、フィルタリストのみに依存する必要性を軽減し、許可されたソースIPアドレスを偽装することによって利益を得ることができるの攻撃を阻止し。 L2TPv3のクッキーは、パケットフローに現在割り当てられたセッションIDを検証するコンテキスト保護を提供する手段を提供し、IPsecを利用してトンネルを確保に相補的とみなすことができます。 （例えば、IPSecで提供されるような）データプレーン上の暗号セキュリティの非存在下で、L2TPv3のクッキーは、それぞれのL2TPv3パケットに対して実行セッションIDルックアップを検証する簡単な方法を提供します。クッキーが十分にランダムであり、攻撃者に未知のままである場合、クッキーは、上PEに挿入悪意のあるスプーフィングされたパケットに対する保護の追加の測定を提供する（つまり、攻撃者は、クッキー値を予測または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のメッセージダイジェスト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.
トンネルテールとトンネルヘッドはトンネルを介して送信されたパケットの最上位ラベルにより配布されたものでなければならないことを意味し、（ラベル配布隣接関係のために、[RFC3031]を参照）パス（LSP）隣接するラベルスイッチングされることに注意してくださいトンネルヘッドにトンネルテール。トンネルテールは、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アドレスが期待される1であることをチェックしなければなりません。
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]を用いて手動または自動で行うことができます。手動キー入力をサポートしなければなりません。自動キーが実装されている場合、事前共有鍵とメインモードでIKEをサポートしなければなりません。特定のアプリケーションは、自動キーのこの要件と要求実装をエスカレートすることができます。手動鍵配布は、自動キー分布よりも、はるかに簡単でなく、あまりスケーラブルです。リプレイ保護が特定のトンネルのために必要とみなされる場合、自動キー分布が構成されるべきです。
Thanks to Robert Raszuk, Clarence Filsfils, and Eric Rosen for their review of this document. Some text was adopted from [RFC4023].
このドキュメントの彼らのレビューのためのロバートRaszuk、クラレンスFilsfils、そしてエリック・ローゼンに感謝します。いくつかのテキストは、[RFC4023]から採用されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]ラウ、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.ローゼン、 "IP又は総称ルーティングカプセル化（GRE）でMPLSカプセル化"、RFC 4023、2005年3月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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]ローゼン、E.、デClercq、J.、Paridaens、O.、T'Joens、Y.、およびC. Sargor、「BGP / MPLS IP VPNの中のPE-PEのIPsecトンネルを使用するためのアーキテクチャ」、進歩、2005年8月に作業。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（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]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
Authors' Addresses
著者のアドレス
W. Mark Townsley Cisco Systems USA
W.マークTownsleyシスコシステムズUSA
Phone: +1-919-392-3741 EMail: mark@townsley.net
電話：+ 1-919-392-3741 Eメール：mark@townsley.net
Carlos Pignataro Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
カルロスPignataroシスコシステムズ7025キットクリーク道路私書箱14987リサーチトライアングルパーク、NC 27709 USA
Phone: +1-919-392-7428 EMail: cpignata@cisco.com
電話：+ 1-919-392-7428 Eメール：cpignata@cisco.com
Scott Wainner Cisco Systems 13600 Dulles Technology Drive Herndon, VA 20171 USA
スコット・ワイナーシスコシステムズ13600ダレステクノロジードライブハーンドン、VA 20171 USA
EMail: swainner@cisco.com
メールアドレス：swainner@cisco.com
Ted Seely Sprint Nextel 12502 Sunrise Valley Drive Reston, VA 20196 USA
テッド・シーリースプリント・ネクステル12502日の出バレードライブレストン、VA 20196 USA
Phone: +1-703-689-6425 EMail: tseely@sprint.net
電話：+ 1-703-689-6425 Eメール：tseely@sprint.net
Jeff Young
ジェフ・ヤング
EMail: young@jsyoung.net
メールアドレス：young@jsyoung.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。