Internet Engineering Task Force (IETF) D. Smith
Request for Comments: 6178 J. Mullooly
Updates: 3031 Cisco Systems
Category: Standards Track W. Jaeger
ISSN: 2070-1721 AT&T
T. Scholl
nLayer Communications
March 2011
Label Edge Router Forwarding of IPv4 Option Packets
Abstract
抽象
This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in different LER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS-encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke.
この文書では、ヘッダオプション付きIPv4パケットをカプセル化MPLSするかどうかを決定する際にラベルエッジルータ（LERは）がどのように振る舞うべきかを指定します。正式な規格の欠如は、プレフィックスベースの転送等価クラス（FEC）に関連しているにもかかわらず、ヘッダ・オプションとIPv4パケットのための異なるLERの転送動作をもたらしました。プレフィックスベースFECに属し、まだMPLSカプセル化されずにはIPv4 / MPLSネットワークに転送されたIPv4オプションパケット、MPLSインフラストラクチャに対するセキュリティ上のリスクを提示します。さらに、ヘッダ・オプションとIPv4パケットをカプセル化するMPLSすることができないのLERは、特定のMPLS環境で動作することができません。この新しく定義されたLERの挙動は、実装が必須ですが、起動するオプションです。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6178.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6178で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Motivation ......................................................2
2. Introduction ....................................................2
3. Specification of Requirements ...................................4
4. Ingress Label Edge Router Requirement ...........................4
5. Security Considerations .........................................5
5.1. IPv4 Option Packets That Bypass MPLS Encapsulation .........5
5.2. Router Alert Label Imposition ..............................7
6. Acknowledgements ................................................7
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
This document is motivated by the need to formalize MPLS encapsulation processing of IPv4 packets with header options in order to mitigate the existing risks of IPv4 options-based security attacks against MPLS infrastructures. We believe that this document adds details that have not been fully addressed in [RFC3031] and [RFC3032], and that the methods presented in this document update [RFC3031] as well as complement [RFC3270], [RFC3443], and [RFC4950].
この文書は、MPLSインフラストラクチャに対してIPv4オプションベースのセキュリティ攻撃の既存のリスクを軽減するために、ヘッダ・オプションを使用してIPv4パケットのMPLSカプセル化処理を形式化する必要性によって動機付けされます。私たちは、この文書は完全に[RFC3031]と[RFC3032]で扱われていない詳細情報を追加していることを信じて、そして、この文書更新[RFC3031]と同様に補完[RFC3270]、[RFC3443]、および[RFC4950]に提示した方法。
The IPv4 packet header provides for various IPv4 options as originally specified in [RFC791]. IPv4 header options are used to enable control functions within the IPv4 data forwarding plane that are required in some specific situations but not necessary for most common IPv4 communications. Typical IPv4 header options include provisions for timestamps, security, and special routing. Example IPv4 header options and applications include but are not limited to the following:
IPv4パケットヘッダは元々[RFC791]で指定されたような様々なIPv4のオプションを提供します。 IPv4ヘッダーオプションは、いくつかの特定の状況で必要な最も一般的なIPv4の通信のために必要されていないIPv4のデータ転送プレーン内の制御機能を有効にするために使用されます。典型的なIPv4ヘッダーオプションはタイムスタンプのための規定、セキュリティ、および特別なルーティングが含まれます。例えばIPv4ヘッダーオプションとアプリケーションとしては、以下に限定されません。
o Strict and Loose Source Route Options: Used to IPv4 route the IPv4 packet based on information supplied by the source.
O厳格かつルーズソースルートオプション：ソースによって供給された情報に基づいて、IPv4パケットのIPv4ルーティングするために使用。
o Record Route Option: Used to trace the route an IPv4 packet takes.
O経路記録オプション：IPv4パケットが取るルートをトレースするために使用します。
o Router Alert Option: Indicates to downstream IPv4 routers to examine these IPv4 packets more closely.
Oルータアラートオプション：より密接にこれらのIPv4パケットを調べるために、下流のIPv4ルータに示します。
The list of current IPv4 header options can be accessed at [IANA].
現在のIPv4ヘッダーオプションのリストは、[IANA]でアクセスすることができます。
IPv4 packets may or may not use IPv4 header options (they are optional), but IPv4 header option handling mechanisms must be implemented by all IPv4 protocol stacks (hosts and routers). Each IPv4 header option has distinct header fields and lengths. IPv4 options extend the IPv4 packet header length beyond the minimum of 20 octets. As a result, IPv4 packets received with header options are typically handled as exceptions and in a less efficient manner due to their variable length and complex processing requirements. For example, many router implementations punt such IPv4 option packets from the hardware forwarding (fast) path into the software forwarding (slow) path causing high CPU utilization. Even when the forwarding plane can parse a variable-length header, it may still need to punt to the control plane because the forwarding plane may not have the clock cycles or intelligence required to process the header option.
IPv4パケットは、または（それらがオプションである）IPv4ヘッダーオプションを使用してもしなくてもよいが、IPv4のヘッダ・オプション処理機構は、すべてのIPv4プロトコルスタック（ホストおよびルータ）によって実装されなければなりません。各IPv4ヘッダーオプションは、個別のヘッダフィールドと長さを有しています。 IPv4オプションは、20オクテットの最小値を超えたIPv4パケットヘッダの長さを延長します。結果として、ヘッダオプションを受信したIPv4パケットは、典型的には、それらの変数の長さと複雑な処理要件を例外として、より少ない効率的な方法で処理されます。例えば、多くのルータ実装はCPU使用率が高い状態を引き起こすソフトウェア転送（遅い）パスにハードウェア転送（高速）経路からそのようなIPv4のオプションパケットをパント。転送プレーンは可変長ヘッダを解析できた場合であっても、それはまだ転送プレーンは、ヘッダ・オプションを処理するのに必要なクロック・サイクルまたはインテリジェンスを有していなくてもよいので、制御プレーンにパントする必要があるかもしれません。
Multi-Protocol Label Switching (MPLS) [RFC3031] is a technology in which packets associated with a prefix-based Forwarding Equivalence Class (FEC) are encapsulated with a label stack and then switched along a label switched path (LSP) by a sequence of label switch routers (LSRs). These intermediate LSRs do not generally perform any processing of the IPv4 header as packets are forwarded. (There are some exceptions to this rule, such as ICMP processing and LSP ping, as described in [RFC3032] and [RFC4379], respectively.) Many MPLS deployments rely on LSRs to provide layer 3 transparency much like ATM switches are transparent at layer 2. Such deployments often minimize the IPv4 routing information (e.g., no BGP transit routes) carried by LSRs since it is not necessary for MPLS forwarding of transit packets.
マルチプロトコルラベルスイッチング（MPLS）[RFC3031]はラベルスタックを用いてカプセル化されるプレフィックスベースの転送等価クラス（FEC）に関連し、その後の配列によってパス（LSP）をラベルスイッチ沿っ交換パケットた技術でありますラベルスイッチルータ（LSRの）。パケットが転送されるように、これらの中間のLSRは、一般に、IPv4ヘッダの任意の処理を行いません。 （[RFC3032]及び[RFC4379]に記載されているようなICMP処理及びLSPピング、このルールにはいくつかの例外は、それぞれ、、がある。）の展開は、多くのATMスイッチのように層3の透明性を提供するためのLSRに依存している多くのMPLSは、層に透明です2.このような展開は、しばしば、それが通過パケットのMPLS転送のために必要がないのでのLSRによって運ばIPv4ルーティング情報（例えば、無BGP通過経路）を最小化します。
Even though MPLS encapsulation seems to offer a viable solution to provide layer 3 transparency, there is currently no formal standard for MPLS encapsulation of IPv4 packets with header options that belong to a prefix-based FEC. Lack of a formal standard has resulted in inconsistent forwarding behaviors by ingress Label Edge Routers (LERs). When IPv4 packets are MPLS encapsulated by an ingress LER, for example, the IPv4 header including option fields of transit packets are not acted upon by downstream LSRs that forward based on the MPLS label(s). Conversely, when a packet is IPv4 forwarded by an ingress LER two undesirable behaviors can result. First, a downstream LSR may not have sufficient IPv4 routing information to forward the packet resulting in packet loss. Second, downstream LSRs must apply IPv4 forwarding rules that may expose them to IPv4 security attacks.
MPLSカプセル化は、レイヤ3の透明性を提供するために、実行可能なソリューションを提供しているようだにもかかわらず、プレフィックスベースFECに属しヘッダオプション付きIPv4パケットのMPLSカプセル化のための正式な標準は現在ありません。正式な標準の欠如は、入口ラベルエッジルータ（LERは）することによって、矛盾の転送動作をもたらしました。 IPv4パケットがイングレスLERによってカプセル化されたMPLSある場合、例えば、通過パケットのオプションフィールドを含むIPv4ヘッダは、前方MPLSラベル（S）に基づいて、下流のLSRによって作用されません。パケットがIPv4のイングレスLERによって転送されたときに、逆に、2つの望ましくない動作が生じる可能性があります。まず、ダウンストリームLSRは、パケット損失が生じるパケットを転送するのに十分なIPv4ルーティング情報を有していなくてもよいです。第二に、下流のLSRは、IPv4セキュリティ攻撃にそれらを公開することのIPv4転送ルールを適用する必要があります。
IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS-encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate as an LER in certain MPLS environments. This new requirement will reduce the risk of IPv4 options-based security attacks against LSRs as well as assist LER operation across MPLS networks that minimize the IPv4 routing information (e.g., no BGP transit routes) carried by LSRs.
プレフィックスベースFECに属し、まだMPLSカプセル化されずにはIPv4 / MPLSネットワークに転送されたIPv4オプションパケット、MPLSインフラストラクチャに対するセキュリティ上のリスクを提示します。さらに、ヘッダ・オプションとIPv4パケットをカプセル化するMPLSすることができないのLERは、特定のMPLS環境におけるLERとして動作することができません。この新しい要件は、のLSRに対してIPv4オプションベースのセキュリティ攻撃のリスクを低減するだけでなく、のLSRによって運ばIPv4ルーティング情報（例えば、無BGP通過経路）を最小MPLSネットワークを横切ってLERの動作を支援します。
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]に記載されているように解釈されます。
An ingress LER MUST implement the following policy:
イングレスLERは次のポリシーを実装する必要があります。
o When determining whether to push an MPLS label stack onto an IPv4 packet, the determination is made without considering any IPv4 options that may be carried in the IPv4 packet header. Further, the label values that appear in the label stack are determined without considering any such IPv4 options.
IPv4パケットにMPLSラベルスタックにプッシュするかどうかを決定するとき、O、決意は、IPv4パケットのヘッダで運ばれてもよい任意のIPv4オプションを考慮せずに行われます。さらに、ラベルスタックに表示されるラベルの値は、このようなIPv4オプションを考慮せずに決定されています。
This policy MAY be configurable on an ingress LER, however, it SHOULD be enabled by default. When processing of signaling messages or data packets with more specific forwarding rules is enabled, this policy SHOULD NOT alter the specific processing rules. This applies to, but is not limited to, Resource Reservation Protocol (RSVP) as per [RFC2205], source routing as per [RFC791], as well as other FEC elements defined by future specifications. Further, how an ingress LER processes the IPv4 header options of packets before MPLS encapsulation is out of scope since these are processed before they enter the MPLS domain.
このポリシーは、しかし、それはデフォルトで有効にされるべきで、入口LERに設定可能であってもよいです。より具体的な転送ルールとメッセージまたはデータパケットのシグナリング処理が有効になっている場合、このポリシーは、特定の処理規則を変更しないでください。これは、ソースが[RFC791]あたり、ならびに将来の仕様によって定義された他のFEC要素としてルーティング、[RFC2205]の通りに適用されるが、これらに限定されない、リソース予約プロトコル（RSVP）。 MPLSカプセル化は、彼らがMPLSドメインに入る前に、これらが処理されるので、範囲外である前に、さらに、どのように入口LERは、パケットのIPv4ヘッダーオプションを処理します。
Implementation of the above policy prevents IPv4 packets that belong to a prefix-based FEC from bypassing MPLS encapsulation due to header options. The policy also prevents specific option types such as Router Alert (option value 148) from forcing MPLS imposition of the MPLS Router Alert Label (label value 1) at ingress LERs. Without this policy, the MPLS infrastructure is exposed to security attacks using legitimate IPv4 packets crafted with header options. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate as an LER in certain MPLS environments as described in Section 2.
上記方針の実装は、オプションヘッダによるMPLSカプセル化を迂回プレフィックスベースFECに属するIPv4パケットを防ぎます。ポリシーはまた、入口のLERでMPLSルータ警告ラベル（ラベル値1）のMPLSインポジションを強制するから、ルータ警告（オプション値148）などの特定のオプションの種類を防止します。このポリシーがないと、MPLSインフラストラクチャは、ヘッダオプションで細工正当なIPv4パケットを使用してセキュリティ攻撃にさらされています。さらに、第2節で説明したように、特定のMPLS環境におけるLERとして動作することができないヘッダ・オプションとIPv4パケットをカプセル化するMPLSすることができないのLER。
There are two potential categories of attacks using crafted IPv4 option packets that threaten existing MPLS infrastructures. Both are described below. To mitigate the risk of these specific attacks, the ingress LER policy specified above is required.
既存のMPLSインフラストラクチャを脅かす細工されたIPv4オプションパケットを使用した攻撃の二つの潜在的なカテゴリがあります。どちらも、以下で説明されています。これらの特定の攻撃のリスクを軽減するために、上記の指定されたイングレスLERポリシーが必要です。
Given that a router's exception handling process (i.e., CPU, processor line-card bandwidth, etc.) used for IPv4 header option processing is often shared with IPv4 control and management protocol router resources, a flood of IPv4 packets with header options may adversely affect a router's control and management protocols, thereby, triggering a denial-of-service (DoS) condition. Note, IPv4 packets with header options may be valid transit IPv4 packets with legitimate sources and destinations. Hence, a DoS-like condition may be triggered on downstream transit IPv4 routers that lack protection mechanisms even in the case of legitimate IPv4 option packets.
IPv4ヘッダオプションの処理のために使用しているルータの例外処理（すなわち、CPU、プロセッサのラインカードの帯域幅など）は、多くの場合、IPv4の制御および管理プロトコルルータのリソースと共有されていること、ヘッダオプション付きIPv4パケットの洪水に悪影響を及ぼす可能性を考えますルータの制御および管理プロトコル、それによって、サービス拒否（DoS）状態をトリガー。音符、ヘッダ・オプションとIPv4パケットは、正当なソースと宛先との有効な通過IPv4パケットであってもよいです。したがって、DoS攻撃のような条件であっても正規のIPv4オプションパケットの場合に保護機構を欠いて下流トランジットIPv4ルーターにトリガされてもよいです。
IPv4 option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may be inadvertently IPv4 routed downstream across the MPLS core network (not label switched). This allows an external attacker the opportunity to maliciously craft seemingly legitimate IPv4 packets with specific IPv4 header options in order to intentionally bypass MPLS encapsulation at the MPLS edge (i.e., ingress LER) and trigger a DoS condition on downstream LSRs. Some of the specific types of IPv4 option-based security attacks that may be leveraged against MPLS networks include the following:
イングレスLERにおけるプレフィックスベースFECまだバイパスMPLSカプセル化に所属するのIPv4オプションパケットは不注意であってもよいのIPv4は、MPLSコアネットワークを介して下流ルーティング（しないラベルを切り替えます）。これは、外部の攻撃者に悪意を持って意図的にMPLSエッジ（すなわち、イングレスLER）でMPLSカプセル化をバイパスして下流のLSRにDoS状態を誘発するために、特定のIPv4ヘッダーオプションと一見正当なIPv4パケットを作る機会を可能にします。 MPLSネットワークに対して活用することができるのIPv4オプション・ベースのセキュリティ攻撃の特定の種類のいくつかは、次のものがあります。
o Crafted IPv4 option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may allow an attacker to DoS downstream LSRs by saturating their software forwarding paths. By targeting a LSR's exception path, control and management protocols may be adversely affected and, thereby, an LSR's availability. This assumes, of course, that downstream LSRs lack protection mechanisms.
イングレスLERにおけるプレフィックスベースFECまだバイパスMPLSカプセル化に属するO細工のIPv4オプションのパケットは、それらのソフトウェアの転送パスを飽和させることによってDoSの下流のLSRへの攻撃を可能にすることができます。 LSRの例外経路を標的とすることによって、制御および管理プロトコルに悪影響、それによって、LSRの可用性に影響を与えてもよいです。これは、下流のLSRは、保護メカニズムを欠いていることはもちろん、前提としています。
o Crafted IPv4 option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may allow for IPv4 Time to Live (TTL) expiry-based DoS attacks against downstream LSRs. MPLS enables IPv4 core hiding whereby transit IPv4 traffic flows see the MPLS network as a single router hop [RFC3443]. However, MPLS core hiding does not apply to packets that bypass MPLS encapsulation and, therefore, IPv4 option packets may be crafted to expire on downstream LSRs which may trigger a DoS condition. Bypassing MPLS core hiding is an additional security consideration since it exposes the network topology.
IPv4の時間（TTL）をライブするためにOイングレスLERのバイパスMPLSカプセル化はまだプレフィックスベースFECに属し細工のIPv4オプション・パケットは、下流のLSRに対する有効期限ベースのDoS攻撃を可能にすることができます。トランジットIPv4トラフィックが単一のルータホップ[RFC3443]としてMPLSネットワークを参照して流れることにより、MPLSは、IPv4コア隠蔽を可能にします。しかし、隠蔽は、MPLSカプセル化を回避し、パケットには適用されないMPLSコアは、従って、IPv4のオプションパケットは、DoS状態を誘発し得る下流のLSRに期限切れに細工されてもよいです。それは、ネットワークトポロジを公開するので、MPLSコアの隠蔽をバイパスする追加のセキュリティ考慮事項です。
o Crafted IPv4 option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may allow for DoS attacks against downstream LSRs that do not carry the IPv4 routing information required to forward transit IPv4 traffic. Lack of such IPv4 routing information may prevent legitimate IPv4 option packets from transiting the MPLS network and, further, may trigger generation of ICMP destination unreachable messages, which could lead to a DoS condition. This assumes, of course, that downstream LSRs lack protection mechanisms and do not carry the IPv4 routing information required to forward transit traffic.
OイングレスLERのバイパスMPLSカプセル化はまだプレフィックスベースFECに属し細工のIPv4オプションパケットがトランジットのIPv4トラフィックを転送するために必要なIPv4のルーティング情報を運ばない下流のLSRに対してDoS攻撃を可能にしてもよいです。このようなIPv4ルーティング情報の欠如は、MPLSネットワークを通過するから、正規のIPv4オプションパケットを防ぐことができると、さらに、DoS状態につながる可能性がICMP宛先到達不能メッセージの生成をトリガすることができます。これは、下流のLSRは、保護メカニズムを欠いており、トランジットトラフィックを転送するために必要なIPv4のルーティング情報を運ばないことを、もちろん、前提としています。
o Crafted IPv4 option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may allow an attacker to bypass LSP Diffserv tunnels [RFC3270] and any associated MPLS Class of Service (CoS) field [RFC5462] marking policies at ingress LERs and, thereby, adversely affect (i.e., DoS) high-priority traffic classes within the MPLS core. Further, this could also lead to theft of high-priority services by unauthorized parties. This assumes, of course, that the [RFC3270] Pipe model is deployed within the MPLS core.
イングレスLERにおけるプレフィックスベースFECまだバイパスMPLSカプセル化に属する細工のIPv4オプションパケットoは、攻撃者がでLSPのDiffservトンネル[RFC3270]及びサービス（COS）の任意の関連するMPLSクラスフィールド[RFC5462]マーキングポリシーをバイパスすることを可能にし得ます入口のLERとは、それによって、悪MPLSコア内（すなわち、DoS）の優先度の高いトラフィッククラスに影響を与えます。さらに、これはまた、権限のない者によって優先度の高いサービスの窃盗につながる可能性があります。これは[RFC3270]管モデルがMPLSコア内に配置されていることを、もちろん、想定しています。
o Crafted RSVP packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may allow an attacker to build RSVP soft-states [RFC2205] [RFC3209] on downstream LSRs which could lead to theft of service by unauthorized parties or to a DoS condition caused by locking up LSR resources. This assumes, of course, that the MPLS network is enabled to process RSVP packets.
OイングレスLERでバイパスMPLSカプセル化まだプレフィックスベースFECに属する細工のRSVPパケットは、RSVPソフトステートを構築する攻撃を可能にすることができる[RFC2205]、[RFC3209]権限のない者によってサービスの窃盗につながる下流のLSRに又はLSRリソースをロックすることにより引き起こされDoS状態に。これは、MPLSネットワークがRSVPパケットを処理するために有効であることを、もちろん、前提としています。
The security attacks outlined above specifically apply to IPv4 option packets that belong to a prefix-based FEC yet bypass ingress LER label stack imposition. Additionally, these attacks only apply to IPv4 option packets forwarded using the global routing table (i.e., IPv4 address family) of a ingress LER. IPv4 option packets associated with a BGP/MPLS IPv4 VPN service are always MPLS encapsulated by the ingress LER per [RFC4364] given that packet forwarding uses a Virtual Forwarding/Routing (VRF) instance. Therefore, BGP/MPLS IPv4 VPN services are not subject to the threats outlined above [RFC4381]. Further, IPv6 [RFC2460] makes use of extension headers not header options and is therefore outside the scope of this document. A separate security threat that does apply to both BGP/MPLS IPv4 VPNs and the IPv4 address family makes use of the Router Alert Label. This is described directly below.
特に上記で概説したセキュリティ攻撃はプレフィックスベースFECまだバイパス入口LERラベルスタックの賦課に属しているIPv4のオプションのパケットに適用されます。さらに、これらの攻撃はイングレスLERのグローバルルーティングテーブル（すなわち、IPv4アドレスファミリ）を使用して転送のIPv4オプションのパケットに適用されます。 BGP / MPLS VPNのIPv4サービスに関連付けられたIPv4オプションパケットは常に、パケット転送が仮想転送/ルーティング（VRF）インスタンスを使用することを考えると[RFC4364]あたりイングレスLERによってカプセル化MPLSれます。したがって、BGP / MPLS VPNのIPv4サービスは、[RFC4381]上に概説した脅威を受けません。さらに、IPv6の[RFC2460]はオプションヘッダない拡張ヘッダを利用すると、この文書の範囲外ことです。 BGP / MPLS VPNとIPv4のIPv4アドレスファミリの両方に適用されない個別のセキュリティ脅威はルータアラートラベルを使用しています。これは、直接以下に説明します。
[RFC3032] defines a Router Alert Label (label value of 1), which is analogous to the Router Alert IPv4 header option (option value of 148). The MPLS Router Alert Label (when exposed and processed only) indicates to downstream LSRs to examine these MPLS packets more closely. MPLS packets with the MPLS Router Alert Label are also handled as an exception by LSRs and, again, in a less efficient manner. At the time of this writing, the only legitimate use of the Router Alert Label is for LSP ping/trace [RFC4379]. Since there is also no formal standard for Router Alert Label imposition at ingress LERs:
[RFC3032]はルータ警告IPv4ヘッダオプション（148のオプション値）に類似しており、ルータ警告ラベル（1のラベル値）を規定します。 MPLSルータアラートラベル（露光およびのみ処理）より密接にこれらのMPLSパケットを検査するために、下流のLSRに示します。 MPLSルータ警告ラベルを有するMPLSパケットはまた、より少ない効率的な方法で、再度、のLSRによって例外として扱われています。この記事の執筆時点では、ルータアラートラベルの唯一の合法的な使用は、LSPピング/トレース[RFC4379]のためです。また、侵入のLERのルータアラートラベル面付けのための正式な標準が存在しないので：
o Crafted IPv4 packets with specific IPv4 header options (e.g., Router Alert) and that belong to a prefix-based FEC may allow an attacker to force MPLS imposition of the Router Alert Label at ingress LERs and, thereby, trigger a DoS condition on downstream LSRs. This assumes, of course, that downstream LSRs lack protection mechanisms.
O特定のIPv4ヘッダーオプション（例えば、ルータ警告）とそれに細工IPv4パケットは、攻撃者がそれによって、入口のLERのルータ警告ラベルのMPLSインポジションを強制的にすることを可能にするプレフィックスベースFECに属する下流にDoS状態をトリガLSR。これは、下流のLSRは、保護メカニズムを欠いていることはもちろん、前提としています。
The authors would like to thank Adrian Cepleanu, Bruce Davie,
Rick Huber, Chris Metz, Pradosh Mohapatra, Ashok Narayanan,
Carlos Pignataro, Eric Rosen, Mark Szczesniak, and Yung Yu for
their valuable comments and suggestions.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[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月。
[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月。
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443] Agarwalさん、P.とB. Akyol、 "（MPLS）ネットワークのマルチプロトコルラベルスイッチングにおける生存時間（TTL）処理"、RFC 3443、2003年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, February 2006.
[RFC4381]ベリンガー、M.、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）のセキュリティの分析"、RFC 4381、2006年2月。
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007.
[RFC4950] Bonica、R.、ガン、D.、タッパン、D.、およびC. Pignataro、 "ICMP拡張マルチプロトコルラベルスイッチングのため"、RFC 4950、2007年8月。
[IANA] "IP Option Numbers," IANA, February 15, 2007, <www.iana.org>.
[IANA] "IPオプション番号、" IANA、2007年2月15日、<www.iana.org>。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]アンデション、L.およびR. Asatiは、 "マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ： "EXPトラフィッククラス "フィールド"、RFC 5462、2009年2月" フィールドに改名します"。
Authors' Addresses
著者のアドレス
David J. Smith Cisco Systems 111 Wood Avenue South Iselin, NJ 08830 EMail: djsmith@cisco.com
デビッド・J.スミスシスコシステムズ111ウッドアベニュー南アイセリン、NJ 08830 Eメール：djsmith@cisco.com
John Mullooly Cisco Systems 111 Wood Avenue South Iselin, NJ 08830 EMail: jmullool@cisco.com
ジョンMulloolyシスコシステムズ111ウッドアベニュー南アイセリン、NJ 08830 Eメール：jmullool@cisco.com
William Jaeger AT&T 200 S. Laurel Avenue Middletown, NJ 07748 EMail: wjaeger@att.com
ウィリアム・イェーガーAT＆T 200 S.ローレルアベニューミドルタウン、NJ 07748 Eメール：wjaeger@att.com
Tom Scholl nLayer Communications 209 West Jackson, Suite 700 Chicago, IL 60606 EMail: tscholl@nlayer.net
トム・ショルnLayerコミュニケーションズ209西ジャクソン、スイート700シカゴ、IL 60606 Eメール：tscholl@nlayer.net