[要約] RFC 6178は、IPv4オプションパケットのラベルエッジルーター転送に関する標準化された手順を提供します。このRFCの目的は、IPv4オプションパケットの効率的な転送を可能にするためのガイドラインを提供することです。
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
IPv4オプションパケットのラベルエッジルーター転送
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.
このドキュメントは、MPLSがヘッダーオプションを使用してIPv4パケットをカプセル化するかどうかを決定する際に、ラベルエッジルーター（LERS）が動作する方法を指定します。正式な基準の欠如により、プレフィックスベースの転送等価クラス（FEC）に関連付けられているにもかかわらず、ヘッダーオプションを備えたIPv4パケットのさまざまなLER転送動作が生じました。プレフィックスベースのFECに属するIPv4オプションパケットは、MPLSエンコールを変更することなくIPv4/MPLSネットワークに転送され、MPLSインフラストラクチャに対してセキュリティリスクを提示します。さらに、MPLSがヘッダーオプションを備えたIPv4パケットをカプセル化できないLERSは、特定の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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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オプションベースのセキュリティ攻撃の既存のリスクを軽減するために、Headerオプションを使用した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 Record Routeオプション：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オプションは、IPv4パケットヘッダーの長さを最小20オクテットを超えて拡張します。その結果、ヘッダーオプションで受信されたIPv4パケットは、通常、例外として処理され、それらの長さと複雑な処理要件のために、より効率的ではない方法で処理されます。たとえば、多くのルーター実装は、ハードウェア転送（高速）パスからソフトウェア転送（スロー）パスへのこのようなIPv4オプションパケットをパントし、高いCPU使用率を引き起こします。転送面が可変長ヘッダーを解析できる場合でも、転送面にはヘッダーオプションを処理するために必要なクロックサイクルまたはインテリジェンスがないため、コントロールプレーンにパントする必要がある場合があります。
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 Pingなど、この規則にはいくつかの例外があります。）多くのMPLS展開はLSRに依存して、ATMスイッチがレイヤーで透過的であるようにレイヤー3の透明度を提供するために依存しています。2.このような展開は、Transitパケットの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カプセル化の正式な標準はありません。正式な基準の欠如により、イングレスラベルエッジルーター（LERS）による一貫性のない転送行動が生じました。IPv4パケットがMPLSがイングレスLERによってカプセル化されている場合、たとえば、Transitパケットのオプションフィールドを含むIPv4ヘッダーは、MPLSラベルに基づいてフォワードする下流LSRによって作用されません。逆に、パケットがIPv4である場合、入り口によって転送されると、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に属するIPv4オプションパケットは、MPLSエンコールを変更することなくIPv4/MPLSネットワークに転送され、MPLSインフラストラクチャに対してセキュリティリスクを提示します。さらに、MPLSがヘッダーオプションを備えたIPv4パケットをカプセル化できないLERSは、特定のMPLS環境ではLERとして動作することはできません。この新しい要件により、LSRに対するIPv4オプションベースのセキュリティ攻撃のリスクが減り、LSRが運ぶIPv4ルーティング情報（たとえば、BGPトランジットルートなし）を最小限に抑えるMPLSネットワーク全体の操作を支援します。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
An ingress LER MUST implement the following policy:
イングレスは、次のポリシーを実装する必要があります。
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.
o MPLSラベルスタックをIPv4パケットにプッシュするかどうかを判断するとき、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で構成可能である場合がありますが、デフォルトでは有効にする必要があります。より具体的な転送ルールを備えた信号メッセージまたはデータパケットの処理が有効になっている場合、このポリシーは特定の処理ルールを変更してはなりません。これは、[RFC2205]に従ってリソース予約プロトコル（RSVP）、[RFC791]に従ってソースルーティング、および将来の仕様によって定義されるその他のFEC要素に適用されますが、これらに限定されません。さらに、MPLSドメインに入る前にこれらが処理されるため、MPLSカプセル化の前にIPv4ヘッダーオプションをパケットの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パケットが防止されます。また、このポリシーは、Router Alert（オプション値148）などの特定のオプションタイプを、MPLSルーターアラートラベル（ラベル値1）のMPLSの賦課を強制的に強制することを防ぎます。このポリシーがなければ、MPLSインフラストラクチャは、ヘッダーオプションで作成された正当なIPv4パケットを使用して、セキュリティ攻撃にさらされます。さらに、MPLSがヘッダーオプションを持つIPv4パケットをカプセル化できないLERは、セクション2で説明されているように、特定の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オプションパケットを使用した攻撃には2つの潜在的なカテゴリがあります。どちらも以下に説明します。これらの特定の攻撃のリスクを軽減するには、上記で指定された侵入ポリシーが必要です。
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パケットである場合があります。したがって、正当なIPv4オプションパケットの場合でも保護メカニズムを欠いている下流のトランジットIPv4ルーターでは、DOSのような条件をトリガーできます。
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:
接頭辞ベースのFECに属するIPv4オプションパケットは、イングレスLERでのMPLSカプセルをバイパスします。MPLSコアネットワーク全体で下流にルーティングされていない場合があります（ラベルスイッチではありません）。これにより、外部の攻撃者は、特定のIPv4ヘッダーオプションを備えた一見合法的なIPv4パケットを悪意を持って作成し、MPLSエッジ（つまり、イングレスLER）でのカプセル化を意図的にバイパスし、下流のLSRでDOS状態をトリガーする機会を可能にします。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.
o 接頭辞ベースのFECに属しているが、入り口でのMPLSカプセルをバイパスする作成されたIPv4オプションパケットを作成すると、ソフトウェア転送パスを飽和させることにより、攻撃者がDOS下流LSRSを使用する可能性があります。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.
o 接頭辞ベースのFECに属しているが、イングレスLERでのMPLSカプセルをバイパスしているCREFTED IPv4オプションパケットにより、IPv4時間の（TTL）有効期限のあるDOS攻撃がダウンストリームLSRSに対する攻撃を可能にする可能性があります。MPLSを有効にして、IPv4コアが隠れています。ただし、MPLS Core Hidingは、MPLSカプセル化をバイパスするパケットには適用されないため、DOS状態を引き起こす可能性のある下流LSRで有効期限が切れるIPv4オプションパケットが作成される場合があります。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 接頭辞ベースのFECに属しているが、イングレスLERでのMPLSカプセル化をバイパスしながら、Transit IPv4トラフィックを転送するために必要なIPv4ルーティング情報を運ばないダウンストリームLSRに対するDOS攻撃を可能にする可能性がある。このようなIPv4ルーティング情報の不足は、正当なIPv4オプションパケットがMPLSネットワークを通過するのを防ぐ可能性があり、さらに、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.
o 接頭辞ベースのFECに属するが、イングレスLERでのMPLSカプセルをバイパスすることにより、攻撃者がLSP DIFFSERVトンネル[RFC3270]および関連するMPLSクラス（cos）フィールド[RFC5462]のマークポリシーをバイパスすることにより、MPLSカプセルをバイパスする作成されたIPv4オプションパケットを作成しました。LERS、そしてそれにより、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 接頭辞ベースのFECに属しているが、入り口でのMPLSカプセルをバイパスすることにより、攻撃者がRSVPソフトステート[RFC2205] [RFC3209]を下流のLSRでRSVPソフトステート[RFC2205] [RFC3209]を構築する可能性のある作成されたRSVPパケットを作成し、未知のパーティまたは未承認のパーティーによるサービスの盗難につながる可能性があります。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に関連付けられたIPv4オプションパケットは、パケット転送が仮想転送/ルーティング（VRF）インスタンスを使用することを考えると、イングレスLERごとに常にMPLSをカプセル化します。したがって、BGP/MPLS IPv4 VPNサービスは、上記の脅威の対象ではありません[RFC4381]。さらに、IPv6 [RFC2460]は、ヘッダーオプションではなく拡張ヘッダーを使用しているため、このドキュメントの範囲外です。BGP/MPLS IPv4 VPNSと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パケットをより密接に調べるために、下流のLSRSに示します。MPLSルーターアラートラベルを備えたMPLSパケットは、LSRSによる例外としても、これも効率的ではない方法で処理されます。この執筆時点では、ルーターアラートラベルの唯一の正当な使用は、LSP Ping/Trace [RFC4379]用です。Ingress Lersでのルーターアラートラベルインポジションの正式な標準もないため：
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パケット（例：ルーターアラート）とプレフィックスベースのFECに属する可能性があります。攻撃者は、Ingress LERSでのルーターアラートラベルをMPLSに押し付け、それにより、下流のLSRSでDOS状態を引き起こすことができます。。これは、もちろん、下流の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] Postel、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[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月。
[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] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP Tunnelsの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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（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] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、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. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, February 2006.
[RFC4381] Behringer、M。、「BGP/MPLS IP仮想ネットワーク（VPNS）のセキュリティの分析」、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.、Gan、D.、Tappan、D.、およびC. Pignataro、「Multiprotocolラベルスイッチング用の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] Andersson、L。and 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
David J. Smith Cisco Systems 111 Wood Avenue South Iselin、NJ 08830メール：djsmith@cisco.com
John Mullooly Cisco Systems 111 Wood Avenue South Iselin, NJ 08830 EMail: jmullool@cisco.com
John Mullooly Cisco Systems 111 Wood Avenue South Iselin、NJ 08830メール：jmullool@cisco.com
William Jaeger AT&T 200 S. Laurel Avenue Middletown, NJ 07748 EMail: wjaeger@att.com
William Jaeger AT＆T 200 S.ローレルアベニューミドルタウン、ニュージャージー07748メール：wjaeger@att.com
Tom Scholl nLayer Communications 209 West Jackson, Suite 700 Chicago, IL 60606 EMail: tscholl@nlayer.net
Tom Scholl Nlayer Communications 209 West Jackson、Suite 700 Chicago、IL 60606メール：tscholl@nlayer.net