[要約] RFC 5575は、フロー仕様ルールの普及に関する標準化ドキュメントであり、BGPプロトコルを使用してネットワークフローの制御を行うための方法を提供しています。その目的は、ネットワークの可用性とセキュリティを向上させるために、フロー仕様の効果的な配布と適用を促進することです。
Network Working Group P. Marques
Request for Comments: 5575 Cisco Systems
Category: Standards Track N. Sheth
Juniper Networks
R. Raszuk
Cisco Systems
B. Greene
Juniper Networks
J. Mauch
NTT America
D. McPherson
Arbor Networks
August 2009
Dissemination of Flow Specification Rules
フロー仕様ルールの普及
Abstract
概要
This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
このドキュメントでは、トラフィックフローの仕様を配布するために使用できる新しいBorder Gateway Protocol Networkレイヤーリーチ可能性情報（BGP NLRI）エンコード形式を定義します。これにより、ルーティングシステムは、IP宛先プレフィックスによって定義されたトラフィック集約のより特定のコンポーネントに関する情報を伝播できます。
Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.
さらに、そのエンコード形式の2つのアプリケーションを定義します。1つは、サービス拒否攻撃を軽減するために必要なものなど、トラフィックフィルタリングのドメイン間調整を自動化するために使用できるものと、2番目のアプリケーションを定義できます。BGP/MPLS VPNサービスのコンテキストでトラフィックフィルタリングを提供します。
The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements.
この情報はBGPを介して伝達され、プロトコルアルゴリズム、運用経験、およびプロバイダー間のピアリング契約などの管理プロセスを再利用します。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions of Terms Used in This Memo ..........................5
3. Flow Specifications .............................................5
4. Dissemination of Information ....................................6
5. Traffic Filtering ..............................................12
5.1. Order of Traffic Filtering Rules ..........................13
6. Validation Procedure ...........................................14
7. Traffic Filtering Actions ......................................15
8. Traffic Filtering in BGP/MPLS VPN Networks .....................17
9. Monitoring .....................................................18
10. Security Considerations .......................................18
11. IANA Considerations ...........................................19
12. Acknowledgments ...............................................20
13. Normative References ..........................................21
Modern IP routers contain both the capability to forward traffic according to IP prefixes as well as to classify, shape, rate limit, filter, or redirect packets based on administratively defined policies.
最新のIPルーターには、IPプレフィックスに従ってトラフィックを転送する機能と、管理上定義されたポリシーに基づいてパケットを分類、形状、レート制限、フィルター、またはリダイレクトする機能の両方が含まれています。
These traffic policy mechanisms allow the router to define match rules that operate on multiple fields of the packet header. Actions such as the ones described above can be associated with each rule.
これらのトラフィックポリシーメカニズムにより、ルーターはパケットヘッダーの複数のフィールドで動作するマッチルールを定義できます。上記のようなアクションは、各ルールに関連付けられます。
The n-tuple consisting of the matching criteria defines an aggregate traffic flow specification. The matching criteria can include elements such as source and destination address prefixes, IP protocol, and transport protocol port numbers.
一致する基準で構成されるn-tupleは、集約されたトラフィックフロー仕様を定義します。一致する基準には、ソースおよび宛先アドレスのプレフィックス、IPプロトコル、輸送プロトコルポート番号などの要素を含めることができます。
This document defines a general procedure to encode flow specification rules for aggregated traffic flows so that they can be distributed as a BGP [RFC4271] NLRI. Additionally, we define the required mechanisms to utilize this definition to the problem of immediate concern to the authors: intra- and inter-provider distribution of traffic filtering rules to filter (distributed) denial-of-service (DoS) attacks.
このドキュメントでは、集約されたトラフィックフローのフロー仕様ルールをエンコードする一般的な手順を定義して、それらをBGP [RFC4271] NLRIとして配布できるようにします。さらに、この定義を著者に即時の懸念の問題に利用するために必要なメカニズムを定義します。トラフィックフィルタリングルールのプロバイダー間分布とサービス拒否（DOS）攻撃をフィルタリングします。
By expanding routing information with flow specifications, the routing system can take advantage of the ACL (Access Control List) or firewall capabilities in the router's forwarding path. Flow specifications can be seen as more specific routing entries to a unicast prefix and are expected to depend upon the existing unicast data information.
フロー仕様でルーティング情報を拡張することにより、ルーティングシステムは、ルーターの転送パスのACL（アクセス制御リスト）またはファイアウォール機能を活用できます。フロー仕様は、ユニキャストプレフィックスへのより具体的なルーティングエントリと見なすことができ、既存のユニキャストデータ情報に依存すると予想されます。
A flow specification received from an external autonomous system will need to be validated against unicast routing before being accepted. If the aggregate traffic flow defined by the unicast destination prefix is forwarded to a given BGP peer, then the local system can safely install more specific flow rules that may result in different forwarding behavior, as requested by this system.
外部の自律システムから受け取ったフロー仕様は、受け入れる前にユニキャストルーティングに対して検証する必要があります。ユニキャスト宛先のプレフィックスによって定義された集約されたトラフィックフローが特定のBGPピアに転送される場合、ローカルシステムは、このシステムが要求するように、異なる転送動作をもたらす可能性のあるより特定のフロールールを安全にインストールできます。
The key technology components required to address the class of problems targeted by this document are:
このドキュメントの対象となる問題のクラスに対処するために必要な主要なテクノロジーコンポーネントは次のとおりです。
1. Efficient point-to-multipoint distribution of control plane information.
1. コントロールプレーン情報の効率的なポイントツーマルチポイント分布。
2. Inter-domain capabilities and routing policy support.
2. ドメイン間の機能とルーティングポリシーサポート。
3. Tight integration with unicast routing, for verification purposes.
3. 検証目的で、ユニキャストルーティングとの緊密な統合。
Items 1 and 2 have already been addressed using BGP for other types of control plane information. Close integration with BGP also makes it feasible to specify a mechanism to automatically verify flow information against unicast routing. These factors are behind the choice of BGP as the carrier of flow specification information.
項目1と2は、他のタイプのコントロールプレーン情報に対してBGPを使用してすでに対処されています。BGPとの密接な統合により、ユニキャストルーティングに対するフロー情報を自動的に検証するメカニズムを指定することも可能になります。これらの要因は、フロー仕様情報のキャリアとしてBGPの選択の背後にあります。
As with previous extensions to BGP, this specification makes it possible to add additional information to Internet routers. These are limited in terms of the maximum number of data elements they can hold as well as the number of events they are able to process in a given unit of time. The authors believe that, as with previous extensions, service providers will be careful to keep information levels below the maximum capacity of their devices.
BGPへの以前の拡張機能と同様に、この仕様により、インターネットルーターに追加情報を追加することができます。これらは、保持できるデータ要素の最大数と、特定の時間単位で処理できるイベントの数に関して制限されています。著者は、以前の拡張機能と同様に、サービスプロバイダーは、情報レベルをデバイスの最大容量を下回るように注意するように注意すると考えています。
It is also expected that, in many initial deployments, flow specification information will replace existing host length route advertisements rather than add additional information.
また、多くの初期展開では、フロー仕様情報が追加情報を追加するのではなく、既存のホスト長いルート広告を置き換えることが期待されています。
Experience with previous BGP extensions has also shown that the maximum capacity of BGP speakers has been gradually increased according to expected loads. Taking into account Internet unicast routing as well as additional applications as they gain popularity.
以前のBGP拡張機能の経験は、BGPスピーカーの最大容量が予想される負荷に応じて徐々に増加していることも示しています。インターネットユニキャストルーティングと追加のアプリケーションが人気を博しているため、追加のアプリケーションを考慮しています。
From an operational perspective, the utilization of BGP as the carrier for this information allows a network service provider to reuse both internal route distribution infrastructure (e.g., route reflector or confederation design) and existing external relationships (e.g., inter-domain BGP sessions to a customer network).
運用上の観点から、この情報のキャリアとしてBGPを利用することにより、ネットワークサービスプロバイダーは内部ルート分布インフラストラクチャ（ルートリフレクターまたは連合設計など）と既存の外部関係（例えば、ドメイン間BGPセッションまでの両方の内部ルート分布インフラストラクチャ（例：顧客ネットワーク）。
While it is certainly possible to address this problem using other mechanisms, the authors believe that this solution offers the substantial advantage of being an incremental addition to already deployed mechanisms.
他のメカニズムを使用してこの問題に対処することは確かに可能ですが、著者は、このソリューションがすでに展開されているメカニズムに漸進的な追加であるという大きな利点を提供すると考えています。
In current deployments, the information distributed by the flow-spec extension is originated both manually as well as automatically. The latter by systems that are able to detect malicious flows. When automated systems are used, care should be taken to ensure their correctness as well as to limit the number and advertisement rate of flow routes.
現在の展開では、フロースペック拡張機能によって分配された情報は、自動的にも手動で発信されます。後者は、悪意のあるフローを検出できるシステムによるものです。自動化されたシステムを使用する場合、その正確性を確保するだけでなく、フロールートの数と広告率を制限するように注意する必要があります。
This specification defines required protocol extensions to address most common applications of IPv4 unicast and VPNv4 unicast filtering. The same mechanism can be reused and new match criteria added to address similar filtering needs for other BGP address families (for example, IPv6 unicast). The authors believe that those would be best to be addressed in a separate document.
この仕様では、IPv4ユニキャストとVPNV4ユニキャストフィルタリングの最も一般的なアプリケーションに対処するために、必要なプロトコル拡張機能を定義します。同じメカニズムを再利用でき、他のBGPアドレスファミリ（例えば、IPv6ユニキャスト）の同様のフィルタリングニーズに対応するために追加された新しい一致基準を追加できます。著者は、それらが別の文書で対処するのが最善であると考えています。
NLRI - Network Layer Reachability Information
NLRI-ネットワークレイヤーリーチビリティ情報
RIB - Routing Information Base
リブ - ルーティング情報ベース
Loc-RIB - Local RIB
loc -rib-ローカルリブ
AS - Autonomous System number
AS-自律システム番号
VRF - Virtual Routing and Forwarding instance
VRF-仮想ルーティングおよび転送インスタンス
PE - Provider Edge router
PE-プロバイダーエッジルーター
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
A flow specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. A given IP packet is said to match the defined flow if it matches all the specified criteria.
フロー仕様は、IPトラフィックに適用できるいくつかの一致する基準で構成されるNタプルです。指定されたIPパケットは、指定されたすべての基準と一致する場合、定義されたフローと一致すると言われています。
A given flow may be associated with a set of attributes, depending on the particular application; such attributes may or may not include reachability information (i.e., NEXT_HOP). Well-known or AS-specific community attributes can be used to encode a set of predetermined actions.
特定のアプリケーションに応じて、特定のフローは属性のセットに関連付けられている場合があります。このような属性には、到達可能な情報（つまり、next_hop）が含まれている場合と含まれない場合があります。よく知られているまたはAS固有のコミュニティ属性を使用して、所定のアクションのセットをエンコードできます。
A particular application is identified by a specific (Address Family Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs should be treated independently from each other in order to assure non-interference between distinct applications.
特定のアプリケーションは、特定の（アドレスファミリ識別子、後続のアドレスファミリ識別子（AFI、SAFI））ペア[RFC4760]によって識別され、異なるリブのセットに対応します。これらのrib骨は、異なるアプリケーション間の非干渉を保証するために、互いに独立して扱う必要があります。
BGP itself treats the NLRI as an opaque key to an entry in its databases. Entries that are placed in the Loc-RIB are then associated with a given set of semantics, which is application dependent. This is consistent with existing BGP applications. For instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast reverse-path information (AFI=1, SAFI=2) are handled by BGP without any particular semantics being associated with them until installed in the Loc-RIB.
BGP自体は、NLRIをデータベースのエントリの不透明な鍵として扱います。LOC-RIBに配置されたエントリは、アプリケーションに依存する特定のセマンティクスセットに関連付けられます。これは、既存のBGPアプリケーションと一致しています。たとえば、IPユニキャストルーティング（AFI = 1、SAFI = 1）およびIPマルチキャストリバースパス情報（AFI = 1、SAFI = 2）は、LOC-RIBにインストールされるまで特定のセマンティクスを関連付けることなくBGPによって処理されます。
Standard BGP policy mechanisms, such as UPDATE filtering by NLRI prefix and community matching, SHOULD apply to the newly defined NLRI-type. Network operators can also control propagation of such routing updates by enabling or disabling the exchange of a particular (AFI, SAFI) pair on a given BGP peering session.
NLRIプレフィックスによる更新フィルタリングやコミュニティマッチングなどの標準的なBGPポリシーメカニズムは、新しく定義されたNLRIタイプに適用する必要があります。ネットワークオペレーターは、特定のBGPピアリングセッションで特定の（AFI、SAFI）ペアの交換を有効または無効にすることにより、このようなルーティング更新の伝播を制御することもできます。
We define a "Flow Specification" NLRI type that may include several components such as destination prefix, source prefix, protocol, ports, etc. This NLRI is treated as an opaque bit string prefix by BGP. Each bit string identifies a key to a database entry with which a set of attributes can be associated.
宛先プレフィックス、ソースプレフィックス、プロトコル、ポートなどの複数のコンポーネントを含む「フロー仕様」NLRIタイプを定義します。このNLRIは、BGPによって不透明なビット文字列プレフィックスとして扱われます。各ビット文字列は、属性のセットを関連付けることができるデータベースエントリのキーを識別します。
This NLRI information is encoded using MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in RFC 4760 [RFC4760]. Whenever the corresponding application does not require Next-Hop information, this shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI attribute and ignored on receipt.
このNLRI情報は、RFC 4760 [RFC4760]で定義されているように、MP_REACH_NLRIおよびMP_UNREACH_NLRI属性を使用してエンコードされています。対応するアプリケーションがNext-Hop情報を必要としない場合はいつでも、これはMP_REACH_NLRI属性の0-OCTET長さの次のホップとしてエンコードされ、領収書で無視されます。
The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as a 1- or 2-octet NLRI length field followed by a variable-length NLRI value. The NLRI length is expressed in octets.
MP_REACH_NLRIとMP_UNREACH_NLRIのNLRIフィールドは、1または2-OCTET NLRI長さフィールドとしてエンコードされ、その後に可変長NLRI値が続きます。NLRIの長さはオクテットで表されます。
+------------------------------+
| length (0xnn or 0xfn nn) |
+------------------------------+
| NLRI value (variable) |
+------------------------------+
flow-spec NLRI
フロースペックNLRI
If the NLRI length value is smaller than 240 (0xf0 hex), the length field can be encoded as a single octet. Otherwise, it is encoded as an extended-length 2-octet value in which the most significant nibble of the first byte is all ones.
NLRIの長さの値が240（0xf0ヘキス）より小さい場合、長さフィールドは単一のオクテットとしてエンコードできます。それ以外の場合は、最初のバイトの最も重要なニブルがすべてである拡張長の2-OCTET値としてエンコードされています。
In the figure above, values less-than 240 are encoded using two hex digits (0xnn). Values above 240 are encoded using 3 hex digits (0xfnnn). The highest value that can be represented with this encoding is 4095. The value 241 is encoded as 0xf0f1.
上の図では、240よりも少ない値は、2ヘクス桁（0xNN）を使用してエンコードされています。240を超える値は、3ヘクス桁（0xFNNN）を使用してエンコードされます。このエンコードで表すことができる最高の値は4095です。値241は0xf0f1としてエンコードされます。
The Flow specification NLRI-type consists of several optional subcomponents. A specific packet is considered to match the flow specification when it matches the intersection (AND) of all the components present in the specification.
フロー仕様NLRIタイプは、いくつかのオプションのサブコンポーネントで構成されています。特定のパケットは、仕様に存在するすべてのコンポーネントの交差点（および）と一致するときに、フロー仕様と一致すると見なされます。
The following component types are defined:
次のコンポーネントタイプが定義されています。
Type 1 - Destination Prefix
タイプ1-宛先プレフィックス
Encoding: <type (1 octet), prefix length (1 octet), prefix>
Defines the destination prefix to match. Prefixes are encoded as in BGP UPDATE messages, a length in bits is followed by enough octets to contain the prefix information.
一致する宛先プレフィックスを定義します。プレフィックスはBGP更新メッセージのようにエンコードされ、ビットの長さの後にプレフィックス情報を含めるのに十分なオクテットが続きます。
Type 2 - Source Prefix
タイプ2-ソースプレフィックス
Encoding: <type (1 octet), prefix-length (1 octet), prefix>
Defines the source prefix to match.
一致するソースプレフィックスを定義します。
Type 3 - IP Protocol
タイプ3- IPプロトコル
Encoding: <type (1 octet), [op, value]+>
Contains a set of {operator, value} pairs that are used to match the IP protocol value byte in IP packets.
IPパケットのIPプロトコル値バイトと一致するために使用される{オペレーター、値}ペアのセットが含まれています。
The operator byte is encoded as:
演算子バイトは次のようにエンコードされます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | len | 0 |lt |gt |eq |
+---+---+---+---+---+---+---+---+
Numeric operator
数値演算子
e - end-of-list bit. Set in the last {op, value} pair in the list.
E-リストの終了ビット。リスト内の最後の{op、value}ペアに設定します。
a - AND bit. If unset, the previous term is logically ORed with the current one. If set, the operation is a logical AND. It should be unset in the first operator byte of a sequence. The AND operator has higher priority than OR for the purposes of evaluating logical expressions.
A-そしてビット。設定されていない場合、前の用語は現在の用語と論理的にオレッドです。設定されている場合、操作は論理的であり、。シーケンスの最初の演算子バイトでは、設定される必要があります。およびオペレーターは、論理式を評価する目的よりも優先度が高い。
len - The length of the value field for this operand is given as (1 << len).
LEN-このオペランドの値フィールドの長さは（1 << len）として与えられます。
lt - less than comparison between data and value.
LT-データと値の比較よりも少ない。
gt - greater than comparison between data and value.
GT-データと値の比較よりも大きい。
eq - equality between data and value.
EQ-データと値の間の平等。
The bits lt, gt, and eq can be combined to produce "less or equal", "greater or equal", and inequality values.
BITS LT、GT、およびEQを組み合わせて、「より少ないまたは「より大きく」、または等しい値、および不平等値を生成できます。
Type 4 - Port
タイプ4-ポート
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs that matches source OR destination TCP/UDP ports. This list is encoded using the numeric operand format defined above. Values are encoded as 1- or 2-byte quantities.
ソースまたは宛先TCP/UDPポートに一致する{操作、値}ペアのリストを定義します。このリストは、上記の数値オペランド形式を使用してエンコードされています。値は、1バイトまたは2バイトの量としてエンコードされます。
Port, source port, and destination port components evaluate to FALSE if the IP protocol field of the packet has a value other than TCP or UDP, if the packet is fragmented and this is not the first fragment, or if the system in unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.
ポート、ソースポート、および宛先ポートコンポーネントは、パケットのIPプロトコルフィールドにTCPまたはUDP以外の値がある場合、パケットが断片化されていて、これが最初のフラグメントではない場合、またはシステムが見つけることができない場合、falseとfalseを評価します。トランスポートヘッダー。さまざまな実装では、IPオプションの存在下やセキュリティペイロード（ESP）null [RFC4303]暗号化の存在下でトランスポートヘッダーをデコードできる場合とできない場合があります。
Type 5 - Destination port
タイプ5-宛先ポート
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the destination port of a TCP or UDP packet. Values are encoded as 1- or 2-byte quantities.
TCPまたはUDPパケットの宛先ポートと一致するために使用される{操作、値}ペアのリストを定義します。値は、1バイトまたは2バイトの量としてエンコードされます。
Type 6 - Source port
タイプ6-ソースポート
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the source port of a TCP or UDP packet. Values are encoded as 1- or 2-byte quantities.
TCPまたはUDPパケットのソースポートと一致するために使用される{操作、値}ペアのリストを定義します。値は、1バイトまたは2バイトの量としてエンコードされます。
Type 7 - ICMP type
タイプ7 -ICMPタイプ
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the type field of an ICMP packet. Values are encoded using a single byte.
ICMPパケットのタイプフィールドに一致するために使用される{操作、値}ペアのリストを定義します。値は、単一のバイトを使用してエンコードされます。
The ICMP type and code specifiers evaluate to FALSE whenever the protocol value is not ICMP.
ICMPタイプとコードの仕様は、プロトコル値がICMPではないときはいつでもfalseと評価されます。
Type 8 - ICMP code
タイプ8 -ICMPコード
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the code field of an ICMP packet. Values are encoded using a single byte.
ICMPパケットのコードフィールドと一致するために使用される{操作、値}ペアのリストを定義します。値は、単一のバイトを使用してエンコードされます。
Type 9 - TCP flags
タイプ9 -TCPフラグ
Encoding: <type (1 octet), [op, bitmask]+>
Bitmask values can be encoded as a 1- or 2-byte bitmask. When a single byte is specified, it matches byte 13 of the TCP header [RFC0793], which contains bits 8 though 15 of the 4th 32-bit word. When a 2-byte encoding is used, it matches bytes 12 and 13 of the TCP header with the data offset field having a "don't care" value.
ビットマスク値は、1バイトまたは2バイトのビットマスクとしてエンコードできます。単一のバイトが指定されると、TCPヘッダー[RFC0793]のバイト13と一致します。2バイトのエンコードを使用すると、TCPヘッダーのバイト12と13と一致し、データオフセットフィールドに「気にしない」値があります。
As with port specifiers, this component evaluates to FALSE for packets that are not TCP packets.
ポート指定器と同様に、このコンポーネントは、TCPパケットではないパケットのfalseと評価されます。
This type uses the bitmask operand format, which differs from the numeric operator format in the lower nibble.
このタイプは、ビットマスクオペランド形式を使用します。これは、下部ニブルの数値演算子形式とは異なります。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | len | 0 | 0 |not| m |
+---+---+---+---+---+---+---+---+
e, a, len - Most significant nibble: (end-of-list bit, AND bit, and length field), as defined for in the numeric operator format.
e、a、len-最も重要なニブル：（リストのビット、ビット、および長さフィールド）、数値演算子形式で定義されています。
not - NOT bit. If set, logical negation of operation.
そうではありません - ビットではありません。設定されている場合、操作の論理的否定。
m - Match bit. If set, this is a bitwise match operation defined as "(data & value) == value"; if unset, (data & value) evaluates to TRUE if any of the bits in the value mask are set in the data.
M-一致ビット。設定されている場合、これは「（データと値）==値」と定義されたビットワイズマッチ操作です。Unsetの場合、（データと値）は、値マスク内のビットのいずれかがデータに設定されている場合、Trueに評価します。
Type 10 - Packet length
タイプ10-パケット長
Encoding: <type (1 octet), [op, value]+>
Match on the total IP packet length (excluding Layer 2 but including IP header). Values are encoded using 1- or 2-byte quantities.
合計IPパケット長（レイヤー2を除くが、IPヘッダーを含む）を一致させます。値は、1バイトまたは2バイトの量を使用してエンコードされます。
Type 11 - DSCP (Diffserv Code Point)
タイプ11 -DSCP（Diffservコードポイント）
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the 6-bit DSCP field [RFC2474]. Values are encoded using a single byte, where the two most significant bits are zero and the six least significant bits contain the DSCP value.
6ビットDSCPフィールド[RFC2474]に一致するために使用される{操作、値}ペアのリストを定義します。値は単一のバイトを使用してエンコードされます。ここで、2つの最も重要なビットはゼロで、6つの最も重要なビットにはDSCP値が含まれています。
Type 12 - Fragment
タイプ12-フラグメント
Encoding: <type (1 octet), [op, bitmask]+>
Uses bitmask operand format defined above.
上記で定義されたビットマスクオペランド形式を使用します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Reserved |LF |FF |IsF|DF |
+---+---+---+---+---+---+---+---+
Bitmask values:
ビットマスク値：
+ Bit 7 - Don't fragment (DF)
+ ビット7-フラグメントしない（df）
+ Bit 6 - Is a fragment (IsF)
+ ビット6-はフラグメント（ISF）です
+ Bit 5 - First fragment (FF)
+ ビット5-最初のフラグメント（FF）
+ Bit 4 - Last fragment (LF)
+ ビット4-最後のフラグメント（LF）
Flow specification components must follow strict type ordering. A given component type may or may not be present in the specification, but if present, it MUST precede any component of higher numeric type value.
フロー仕様コンポーネントは、厳密なタイプの順序に従う必要があります。特定のコンポーネントタイプは、仕様に存在する場合と存在する場合がありますが、存在する場合は、より高い数値タイプ値のコンポーネントに先行する必要があります。
If a given component type within a prefix in unknown, the prefix in question cannot be used for traffic filtering purposes by the receiver. Since a flow specification has the semantics of a logical AND of all components, if a component is FALSE, by definition it cannot be applied. However, for the purposes of BGP route propagation, this prefix should still be transmitted since BGP route distribution is independent on NLRI semantics.
不明のプレフィックス内の特定のコンポーネントタイプの場合、問題のプレフィックスは、受信機によるトラフィックフィルタリングの目的に使用できません。フロー仕様には論理的およびすべてのコンポーネントのセマンティクスがあるため、コンポーネントが偽の場合、定義により適用できません。ただし、BGPルートの伝播の目的のために、BGPルート分布はNLRIセマンティクスで独立しているため、このプレフィックスは引き続き送信される必要があります。
The <type, value> encoding is chosen in order to account for future extensibility.
<タイプ、値>エンコードは、将来の拡張性を説明するために選択されます。
An example of a flow specification encoding for: "all packets to 10.0.1/24 and TCP port 25".
「10.0.1/24およびTCPポート25へのすべてのパケット」のエンコードのフロー仕様の例。
+------------------+----------+----------+
| destination | proto | port |
+------------------+----------+----------+
| 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 |
+------------------+----------+----------+
Decode for protocol:
プロトコル用のデコード：
+-------+----------+------------------------------+
| Value | | |
+-------+----------+------------------------------+
| 0x03 | type | |
| 0x81 | operator | end-of-list, value size=1, = |
| 0x06 | value | |
+-------+----------+------------------------------+
An example of a flow specification encoding for: "all packets to 10.0.1/24 from 192/8 and port {range [137, 139] or 8080}".
「192/8およびポート{範囲[137、139]または8080}から10.0.1/24までのすべてのパケット」のエンコードの例。
+------------------+----------+-------------------------+
| destination | source | port |
+------------------+----------+-------------------------+
| 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 |
+------------------+----------+-------------------------+
Decode for port:
ポート用のデコード：
+--------+----------+------------------------------+
| Value | | |
+--------+----------+------------------------------+
| 0x04 | type | |
| 0x03 | operator | size=1, >= |
| 0x89 | value | 137 |
| 0x45 | operator | &, value size=1, <= |
| 0x8b | value | 139 |
| 0x91 | operator | end-of-list, value-size=2, = |
| 0x1f90 | value | 8080 |
+--------+----------+------------------------------+
This constitutes an NLRI with an NLRI length of 16 octets.
Implementations wishing to exchange flow specification rules MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1) as defined in RFC 4760 [RFC4760]. The (AFI, SAFI) pair carried in the Multiprotocol Extension Capability MUST be the same as the one used to identify a particular application that uses this NLRI-type.
フロー仕様ルールを交換することを希望する実装は、BGPの機能広告施設を使用して、RFC 4760 [RFC4760]で定義されているように、マルチプロトコル拡張機能コード（コード1）を交換する必要があります。マルチプロトコル拡張機能に含まれる（AFI、SAFI）ペアは、このNLRIタイプを使用する特定のアプリケーションを識別するために使用されたものと同じでなければなりません。
Traffic filtering policies have been traditionally considered to be relatively static.
トラフィックフィルタリングポリシーは、伝統的に比較的静的であると考えられてきました。
The popularity of traffic-based, denial-of-service (DoS) attacks, which often requires the network operator to be able to use traffic filters for detection and mitigation, brings with it requirements that are not fully satisfied by existing tools.
トラフィックベースのサービス拒否（DOS）攻撃の人気は、多くの場合、ネットワークオペレーターが検出と緩和にトラフィックフィルターを使用できることを必要としますが、既存のツールによって完全に満たされないIT要件をもたらします。
Increasingly, DoS mitigation requires coordination among several service providers in order to be able to identify traffic source(s) and because the volumes of traffic may be such that they will otherwise significantly affect the performance of the network.
DOSの緩和は、トラフィックソースを特定できるようにするために、いくつかのサービスプロバイダー間の調整が必要になり、トラフィックの量がネットワークのパフォーマンスに大きく影響するようなものである可能性があるためです。
Several techniques are currently used to control traffic filtering of DoS attacks. Among those, one of the most common is to inject unicast route advertisements corresponding to a destination prefix being attacked. One variant of this technique marks such route advertisements with a community that gets translated into a discard Next-Hop by the receiving router. Other variants attract traffic to a particular node that serves as a deterministic drop point.
現在、DOS攻撃のトラフィックフィルタリングを制御するためにいくつかの手法が使用されています。これらの中で、最も一般的なものの1つは、攻撃されている宛先プレフィックスに対応するユニキャストルート広告を注入することです。この手法の1つのバリアントは、そのようなルート広告を、受信ルーターによって廃棄の次のホップに翻訳されるコミュニティとマークされています。他のバリアントは、決定論的なドロップポイントとして機能する特定のノードへのトラフィックを引き付けます。
Using unicast routing advertisements to distribute traffic filtering information has the advantage of using the existing infrastructure and inter-AS communication channels. This can allow, for instance, a service provider to accept filtering requests from customers for address space they own.
ユニキャストルーティング広告を使用してトラフィックフィルタリング情報を配布するには、既存のインフラストラクチャと通信間チャネルを使用するという利点があります。これにより、たとえば、サービスプロバイダーが所有するアドレススペースの顧客からのフィルタリング要求を受け入れることができます。
There are several drawbacks, however. An issue that is immediately apparent is the granularity of filtering control: only destination prefixes may be specified. Another area of concern is the fact that filtering information is intermingled with routing information.
ただし、いくつかの欠点があります。すぐに明らかな問題は、フィルタリング制御の粒度です。宛先プレフィックスのみが指定できます。懸念事項のもう1つの領域は、情報のフィルタリングがルーティング情報と混ざり合っているという事実です。
The mechanism defined in this document is designed to address these limitations. We use the flow specification NLRI defined above to convey information about traffic filtering rules for traffic that should be discarded.
このドキュメントで定義されているメカニズムは、これらの制限に対処するように設計されています。上記のフロー仕様NLRIを使用して、破棄すべきトラフィックのトラフィックフィルタリングルールに関する情報を伝えます。
This mechanism is primarily designed to allow an upstream autonomous system to perform inbound filtering in their ingress routers of traffic that a given downstream AS wishes to drop.
このメカニズムは、主に、上流の自律システムが、ドロップしたいと思われる下流のトラフィックの侵入ルーターでインバウンドフィルタリングを実行できるように設計されています。
In order to achieve this goal, we define an application-specific NLRI identifier (AFI=1, SAFI=133) along with specific semantic rules.
この目標を達成するために、特定のセマンティックルールとともに、アプリケーション固有のNLRI識別子（AFI = 1、SAFI = 133）を定義します。
BGP routing updates containing this identifier use the flow specification NLRI encoding to convey particular aggregated flows that require special treatment.
この識別子を含むBGPルーティングの更新は、フロー仕様NLRIエンコードを使用して、特別な処理を必要とする特定の集約フローを伝達します。
Flow routing information received via this (AFI, SAFI) pair is subject to the validation procedure detailed below.
この（AFI、SAFI）ペアを介して受信したフロールーティング情報は、以下に詳述されている検証手順の対象となります。
With traffic filtering rules, more than one rule may match a particular traffic flow. Thus, it is necessary to define the order at which rules get matched and applied to a particular traffic flow. This ordering function must be such that it must not depend on the arrival order of the flow specification's rules and must be constant in the network.
トラフィックのフィルタリングルールを使用すると、複数のルールが特定のトラフィックフローと一致する場合があります。したがって、ルールが一致して特定のトラフィックフローに適用される順序を定義する必要があります。この順序付け関数は、フロー仕様のルールの到着順序に依存してはならず、ネットワーク内で一定でなければならないようにする必要があります。
The relative order of two flow specification rules is determined by comparing their respective components. The algorithm starts by comparing the left-most components of the rules. If the types differ, the rule with lowest numeric type value has higher precedence (and thus will match before) than the rule that doesn't contain that component type. If the component types are the same, then a type-specific comparison is performed.
2つのフロー仕様ルールの相対順序は、それぞれのコンポーネントを比較することにより決定されます。アルゴリズムは、ルールの左端コンポーネントを比較することから始まります。タイプが異なる場合、数値タイプの値が最も低いルールは、そのコンポーネントタイプを含まないルールよりも優先されます（したがって、以前に一致します）。コンポーネントタイプが同じ場合、タイプ固有の比較が実行されます。
For IP prefix values (IP destination and source prefix) precedence is given to the lowest IP value of the common prefix length; if the common prefix is equal, then the most specific prefix has precedence.
IPプレフィックス値（IP宛先およびソースプレフィックス）の場合、一般的なプレフィックス長の最低IP値に優先順位が与えられます。共通のプレフィックスが等しい場合、最も具体的なプレフィックスに優先されます。
For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by the ISO C standard. For strings of different lengths, the common prefix is compared. If equal, the longest string is considered to have higher precedence than the shorter one.
他のすべてのコンポーネントタイプについては、特に指定されていない限り、ISO C標準で定義されたMEMCMP（）関数を使用してコンポーネントデータをバイナリ文字列として比較することにより、比較が実行されます。異なる長さの文字列の場合、共通のプレフィックスが比較されます。等しい場合、最長の文字列は短い文字列よりも優先されると見なされます。
Pseudocode:
pseudocode：
flow_rule_cmp (a, b)
{
comp1 = next_component(a);
comp2 = next_component(b);
while (comp1 || comp2) {
// component_type returns infinity on end-of-list
if (component_type(comp1) < component_type(comp2)) {
return A_HAS_PRECEDENCE;
}
if (component_type(comp1) > component_type(comp2)) {
return B_HAS_PRECEDENCE;
}
if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) {
common = MIN(prefix_length(comp1), prefix_length(comp2));
cmp = prefix_compare(comp1, comp2, common);
// not equal, lowest value has precedence
// equal, longest match has precedence
} else {
common =
MIN(component_length(comp1), component_length(comp2));
cmp = memcmp(data(comp1), data(comp2), common);
// not equal, lowest value has precedence
// equal, longest string has precedence
}
}
return EQUAL; }
平等に戻ります。}
Flow specifications received from a BGP peer and that are accepted in the respective Adj-RIB-In are used as input to the route selection process. Although the forwarding attributes of two routes for the same flow specification prefix may be the same, BGP is still required to perform its path selection algorithm in order to select the correct set of attributes to advertise.
BGPピアから受信し、それぞれのadj-rib-inで受け入れられるフロー仕様は、ルート選択プロセスへの入力として使用されます。同じフロー仕様プレフィックスの2つのルートの転送属性は同じかもしれませんが、BGPは、広告の正しい属性セットを選択するためにパス選択アルゴリズムを実行するためにまだ必要です。
The first step of the BGP Route Selection procedure (Section 9.1.2 of [RFC4271]) is to exclude from the selection procedure routes that are considered non-feasible. In the context of IP routing information, this step is used to validate that the NEXT_HOP attribute of a given route is resolvable.
BGPルート選択手順の最初のステップ（[RFC4271]のセクション9.1.2）は、不可能と見なされる選択手順ルートから除外することです。IPルーティング情報のコンテキストでは、この手順を使用して、特定のルートのnext_hop属性が解決可能であることを検証します。
The concept can be extended, in the case of flow specification NLRI, to allow other validation procedures.
フロー仕様NLRIの場合、概念を拡張して、他の検証手順を許可することができます。
A flow specification NLRI must be validated such that it is considered feasible if and only if:
フロー仕様NLRIは、次の場合にのみ実行可能と見なされるように検証する必要があります。
a) The originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification.
a) フロー仕様のオリジネーターは、フロー仕様に埋め込まれた宛先プレフィックスのベストマッチユニキャストルートのオリジネーターと一致します。
b) There are no more specific unicast routes, when compared with the flow destination prefix, that have been received from a different neighboring AS than the best-match unicast route, which has been determined in step a).
b) ステップa）で決定された最高の試合のユニキャストルートと同様に、異なる隣接する隣接から受信されたフロー宛先プレフィックスと比較した場合、これ以上特定のユニキャストルートはありません。
By originator of a BGP route, we mean either the BGP originator path attribute, as used by route reflection, or the transport address of the BGP peer, if this path attribute is not present.
BGPルートのオリジネーターとは、このパス属性が存在しない場合、ルートリフレクションで使用されるBGPオリジネーターパス属性、またはBGPピアの輸送アドレスのいずれかを意味します。
The underlying concept is that the neighboring AS that advertises the best unicast route for a destination is allowed to advertise flow-spec information that conveys a more or equally specific destination prefix. Thus, as long as there are no more specific unicast routes, received from a different neighboring AS, which would be affected by that filtering rule.
根本的な概念は、目的地に最適なユニキャストルートを宣伝する隣接するものが、より等しく特定の宛先プレフィックスを伝えるフロースペック情報を宣伝できることです。したがって、別の隣接するASから受け取った特定のユニキャストルートがなく、そのフィルタリングルールの影響を受ける限り。
The neighboring AS is the immediate destination of the traffic described by the flow specification. If it requests these flows to be dropped, that request can be honored without concern that it represents a denial of service in itself. Supposedly, the traffic is being dropped by the downstream autonomous system, and there is no added value in carrying the traffic to it.
隣接するのは、フロー仕様によって記述されたトラフィックの直近の目的地です。これらのフローの削除を要求する場合、その要求は、それがそれ自体がサービスの拒否を表すことを懸念なく尊重することができます。おそらく、トラフィックは下流の自律システムによって削除されており、トラフィックを運ぶ際に付加価値はありません。
BGP implementations MUST also enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the left-most position of the AS_PATH attribute. While this rule is optional in the BGP specification, it becomes necessary to enforce it for security reasons.
BGP実装は、AS_PATH属性の左左の位置のように、外部の境界ゲートウェイプロトコル（EBGP）を介して受信したルートのAS_PATH属性が隣接することを強制する必要があります。このルールはBGP仕様ではオプションですが、セキュリティ上の理由でそれを実施する必要があります。
This specification defines a minimum set of filtering actions that it standardizes as BGP extended community values [RFC4360]. This is not meant to be an inclusive list of all the possible actions, but only a subset that can be interpreted consistently across the network.
この仕様は、BGPがコミュニティ値を拡張するときに標準化するフィルタリングアクションの最小セットを定義します[RFC4360]。これは、すべての可能なアクションの包括的なリストであることではなく、ネットワーク全体で一貫して解釈できるサブセットのみです。
Implementations should provide mechanisms that map an arbitrary BGP community value (normal or extended) to filtering actions that require different mappings in different systems in the network. For instance, providing packets with a worse-than-best-effort, per-hop behavior is a functionality that is likely to be implemented differently in different systems and for which no standard behavior is currently known. Rather than attempting to define it here, this can be accomplished by mapping a user-defined community value to platform-/network-specific behavior via user configuration.
実装は、ネットワーク内の異なるシステムの異なるマッピングを必要とするアクションをフィルタリングする任意のBGPコミュニティ価値（通常または拡張）をマッピングするメカニズムを提供する必要があります。たとえば、パケットを最も悪化よりも悪いもので提供すると、ホップごとの動作は、異なるシステムで異なる方法で実装される可能性が高く、標準的な動作が現在知られていない機能です。ここで定義しようとするのではなく、ユーザー定義のコミュニティ価値をユーザー構成を介してプラットフォーム/ネットワーク固有の動作にマッピングすることで実現できます。
The default action for a traffic filtering flow specification is to accept IP traffic that matches that particular rule.
トラフィックフィルタリングフロー仕様のデフォルトアクションは、その特定のルールに一致するIPトラフィックを受け入れることです。
The following extended community values can be used to specify particular actions.
次の拡張されたコミュニティ値を使用して、特定のアクションを指定できます。
+--------+--------------------+--------------------------+
| type | extended community | encoding |
+--------+--------------------+--------------------------+
| 0x8006 | traffic-rate | 2-byte as#, 4-byte float |
| 0x8007 | traffic-action | bitmask |
| 0x8008 | redirect | 6-byte Route Target |
| 0x8009 | traffic-marking | DSCP value |
+--------+--------------------+--------------------------+
Traffic-rate: The traffic-rate extended community is a non-transitive extended community across the autonomous-system boundary and uses following extended community encoding:
交通量：交通率の拡張コミュニティは、自律システムの境界を越えて非転倒的な拡張コミュニティであり、拡張されたコミュニティエンコードに続いて使用します。
The first two octets carry the 2-octet id, which can be assigned from a 2-byte AS number. When a 4-byte AS number is locally present, the 2 least significant bytes of such an AS number can be used. This value is purely informational and should not be interpreted by the implementation.
最初の2つのオクテットには、2バイトから数値として割り当てることができます。数字としての4バイトが局所的に存在する場合、そのような数の2つの最小の有意なバイトを使用できます。この値は純粋に情報提供であり、実装によって解釈されるべきではありません。
The remaining 4 octets carry the rate information in IEEE floating point [IEEE.754.1985] format, units being bytes per second. A traffic-rate of 0 should result on all traffic for the particular flow to be discarded.
残りの4オクテットには、IEEEフローティングポイント[IEEE.754.1985]形式でレート情報があり、ユニットは毎秒バイトです。0のトラフィックレートは、特定のフローが破棄されるすべてのトラフィックにつながるはずです。
Traffic-action: The traffic-action extended community consists of 6 bytes of which only the 2 least significant bits of the 6th byte (from left to right) are currently defined.
トラフィックアクション：トラフィックアクション拡張コミュニティは6バイトで構成され、そのうち6バイト（左から右）の2つの最も重要なビットのみが定義されています。
40 41 42 43 44 45 46 47
+---+---+---+---+---+---+---+---+
| reserved | S | T |
+---+---+---+---+---+---+---+---+
* Terminal Action (bit 47): When this bit is set, the traffic filtering engine will apply any subsequent filtering rules (as defined by the ordering procedure). If not set, the evaluation of the traffic filter stops when this rule is applied.
* 端子アクション（ビット47）：このビットが設定されると、トラフィックフィルタリングエンジンは後続のフィルタリングルールを適用します（順序付け手順で定義されています）。設定されていない場合、このルールが適用されると、トラフィックフィルターの評価が停止します。
* Sample (bit 46): Enables traffic sampling and logging for this flow specification.
* サンプル（ビット46）：このフロー仕様のトラフィックサンプリングとロギングを有効にします。
Redirect: The redirect extended community allows the traffic to be redirected to a VRF routing instance that lists the specified route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected). This extended community uses the same encoding as the Route Target extended community [RFC4360].
リダイレクト：リダイレクト拡張コミュニティにより、インポートポリシーに指定されたルートターゲットをリストするVRFルーティングインスタンスにトラフィックをリダイレクトできます。いくつかのローカルインスタンスがこの基準と一致する場合、それらの間の選択はローカルの問題です（たとえば、最も低いルートの区別者値を持つインスタンスを選択することができます）。この拡張コミュニティは、ルートターゲット拡張コミュニティ[RFC4360]と同じエンコードを使用します。
Traffic Marking: The traffic marking extended community instructs a system to modify the DSCP bits of a transiting IP packet to the corresponding value. This extended community is encoded as a sequence of 5 zero bytes followed by the DSCP value encoded in the 6 least significant bits of 6th byte.
トラフィックマーキング：トラフィックマーキング拡張コミュニティは、システムに対応する値にDSCPビットを変更するように指示します。この拡張コミュニティは、5ゼロバイトのシーケンスとしてエンコードされ、その後、6番目のバイトの6つの最小重要なビットでエンコードされたDSCP値がエンコードされます。
Provider-based Layer 3 VPN networks, such as the ones using a BGP/ MPLS IP VPN [RFC4364] control plane, have different traffic filtering requirements than Internet service providers.
BGP/ MPLS IP VPN [RFC4364]コントロールプレーンを使用するようなプロバイダーベースのレイヤー3 VPNネットワークは、インターネットサービスプロバイダーとは異なるトラフィックフィルタリング要件を持っています。
In these environments, the VPN customer network often has traffic filtering capabilities towards their external network connections (e.g., firewall facing public network connection). Less common is the presence of traffic filtering capabilities between different VPN attachment sites. In an any-to-any connectivity model, which is the default, this means that site-to-site traffic is unfiltered.
これらの環境では、VPNカスタマーネットワークには、外部ネットワーク接続（たとえば、パブリックネットワーク接続に面したファイアウォール）に対してトラフィックフィルタリング機能があることがよくあります。あまり一般的ではないのは、さまざまなVPNアタッチメントサイト間のトラフィックフィルタリング機能の存在です。デフォルトであるすべての接続モデルでは、サイトからサイトへのトラフィックがフィルタリングされていないことを意味します。
In circumstances where a security threat does get propagated inside the VPN customer network, there may not be readily available mechanisms to provide mitigation via traffic filter.
セキュリティの脅威がVPNカスタマーネットワーク内で伝播される状況では、トラフィックフィルターを介して緩和を提供するための容易に利用できるメカニズムはない場合があります。
This document proposes an additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used to propagate traffic filtering information in a BGP/MPLS VPN environment.
このドキュメントでは、BGP/MPLS VPN環境のトラフィックフィルタリング情報を伝播するために使用できる追加のBGP NLRIタイプ（AFI = 1、SAFI = 134）値を提案します。
The NLRI format for this address family consists of a fixed-length Route Distinguisher field (8 bytes) followed by a flow specification, following the encoding defined in this document. The NLRI length field shall include both the 8 bytes of the Route Distinguisher as well as the subsequent flow specification.
このアドレスファミリのNLRI形式は、このドキュメントで定義されているエンコードに続いて、固定長のルート違いフィールド（8バイト）で構成され、フロー仕様が続きます。NLRIの長さフィールドには、ルートの違いの8バイトとその後のフロー仕様の両方が含まれます。
Propagation of this NLRI is controlled by matching Route Target extended communities associated with the BGP path advertisement with the VRF import policy, using the same mechanism as described in "BGP/ MPLS IP VPNs" [RFC4364] .
このNLRIの伝播は、「BGP/ MPLS IP VPNS」[RFC4364]で説明されているのと同じメカニズムを使用して、VRFインポートポリシーに関連するBGPパス広告に関連する拡張コミュニティを一致させることによって制御されます。
Flow specification rules received via this NLRI apply only to traffic that belongs to the VRF(s) in which it is imported. By default, traffic received from a remote PE is switched via an MPLS forwarding decision and is not subject to filtering.
このNLRIを介して受け取ったフロー仕様規則は、インポートされているVRFに属するトラフィックにのみ適用されます。デフォルトでは、リモートPEから受け取ったトラフィックは、MPLS転送決定を介して切り替えられ、フィルタリングの対象ではありません。
Contrary to the behavior specified for the non-VPN NLRI, flow rules are accepted by default, when received from remote PE routers.
非VPN NLRIに指定された動作とは反対に、リモートPEルーターから受信した場合、フロールールはデフォルトで受け入れられます。
Traffic filtering applications require monitoring and traffic statistics facilities. While this is an implementation-specific choice, implementations SHOULD provide:
トラフィックフィルタリングアプリケーションには、監視および交通統計施設が必要です。これは実装固有の選択ですが、実装は次のことを提供する必要があります。
o A mechanism to log the packet header of filtered traffic.
o フィルタリングされたトラフィックのパケットヘッダーを記録するメカニズム。
o A mechanism to count the number of matches for a given flow specification rule.
o 特定のフロー仕様ルールの一致数をカウントするメカニズム。
Inter-provider routing is based on a web of trust. Neighboring autonomous systems are trusted to advertise valid reachability information. If this trust model is violated, a neighboring autonomous system may cause a denial-of-service attack by advertising reachability information for a given prefix for which it does not provide service.
プロバイダー間ルーティングは、信頼のWebに基づいています。近隣の自律システムは、有効な到達可能性情報を宣伝すると信頼されています。この信頼モデルに違反した場合、隣接する自律システムは、サービスを提供しない特定のプレフィックスの広告リーチビリティ情報により、サービス拒否攻撃を引き起こす可能性があります。
As long as traffic filtering rules are restricted to match the corresponding unicast routing paths for the relevant prefixes, the security characteristics of this proposal are equivalent to the existing security properties of BGP unicast routing.
トラフィックフィルタリングルールが、関連するプレフィックスの対応するユニキャストルーティングパスに一致するように制限されている限り、この提案のセキュリティ特性は、BGPユニキャストルーティングの既存のセキュリティプロパティと同等です。
Where it is not the case, this would open the door to further denial-of-service attacks.
そうではない場合、これにより、サービス拒否攻撃への扉が開かれます。
Enabling firewall-like capabilities in routers without centralized management could make certain failures harder to diagnose. For example, it is possible to allow TCP packets to pass between a pair of addresses but not ICMP packets. It is also possible to permit packets smaller than 900 or greater than 1000 bytes to pass between a pair of addresses, but not packets whose length is in the range 900- 1000. Such behavior may be confusing and these capabilities should be used with care whether manually configured or coordinated through the protocol extensions described in this document.
集中管理のないルーターでファイアウォールのような機能を有効にすると、特定の障害が診断を難しくする可能性があります。たとえば、ICMPパケットではなく、TCPパケットが一対のアドレス間を通過できるようにすることができます。また、900バイト以下または1000バイトを超えるパケットを許可することも可能ですが、長さが900〜1000の範囲にあるパケットではありません。そのような動作は混乱している可能性があり、これらの機能は注意して使用する必要があります。このドキュメントで説明されているプロトコル拡張を介して手動で構成または調整されました。
A flow specification consists of a sequence of flow components, which are identified by a an 8-bit component type. Types must be assigned and interpreted uniquely. The current specification defines types 1 though 12, with the value 0 being reserved.
フロー仕様は、8ビットコンポーネントタイプで識別されるフロー成分のシーケンスで構成されています。タイプを割り当てて解釈する必要があります。現在の仕様では、値0は予約されていますが、タイプ1を定義します。
For the purpose of this work, IANA has allocated values for two SAFIs: SAFI 133 for IPv4 dissemination of flow specification rules and SAFI 134 for VPNv4 dissemination of flow specification rules.
この作業の目的のために、IANAは2つのSAFISに値を割り当てています：Flow SpecificationルールのIPv4普及のためのSAFI 133、およびVPNV4フロー仕様規則のVPNV4普及のためのSAFI 134。
The following traffic filtering flow specification rules have been allocated by IANA from the "BGP Extended Communities Type - Experimental Use" registry as follows:
次のトラフィックフィルタリングフロー仕様ルールは、「BGP拡張コミュニティタイプ - 実験的使用」レジストリからIANAによって割り当てられています。
0x8006 - Flow spec traffic-rate
0x8006-フロースペックトラフィックレート
0x8007 - Flow spec traffic-action
0x8007-フロースペックトラフィックアクション
0x8008 - Flow spec redirect
0x8008-フロースペックリダイレクト
0x8009 - Flow spec traffic-remarking
0x8009-フロースペックトラフィックレマーキング
IANA created and maintains a new registry entitled: "Flow Spec Component Types". The following component types have been registered:
IANAは、「フロー仕様コンポーネントタイプ」というタイトルの新しいレジストリを作成および維持しています。次のコンポーネントタイプが登録されています。
Type 1 - Destination Prefix
タイプ1-宛先プレフィックス
Type 2 - Source Prefix
タイプ2-ソースプレフィックス
Type 3 - IP Protocol
タイプ3- IPプロトコル
Type 4 - Port
タイプ4-ポート
Type 5 - Destination port
タイプ5-宛先ポート
Type 6 - Source port
タイプ6-ソースポート
Type 7 - ICMP type
タイプ7 -ICMPタイプ
Type 8 - ICMP code Type 9 - TCP flags
タイプ8 -ICMPコードタイプ9 -TCPフラグ
Type 10 - Packet length
タイプ10-パケット長
Type 11 - DSCP
タイプ11 -DSCP
Type 12 - Fragment
タイプ12-フラグメント
In order to manage the limited number space and accommodate several usages, the following policies defined by RFC 5226 [RFC5226] are used:
限られた数のスペースを管理し、いくつかの使用法に対応するために、RFC 5226 [RFC5226]で定義された次のポリシーが使用されます。
+--------------+-------------------------------+
| Range | Policy |
+--------------+-------------------------------+
| 0 | Invalid value |
| [1 .. 12] | Defined by this specification |
| [13 .. 127] | Specification Required |
| [128 .. 255] | First Come First Served |
+--------------+-------------------------------+
The specification of a particular "flow component type" must clearly identify what the criteria used to match packets forwarded by the router is. This criteria should be meaningful across router hops and not depend on values that change hop-by-hop such as TTL or Layer 2 encapsulation.
特定の「フローコンポーネントタイプ」の仕様は、ルーターによって転送されるパケットと一致するために使用された基準が何であるかを明確に識別する必要があります。この基準は、ルーターホップ全体で意味があり、TTLやレイヤー2カプセル化などのホップバイホップを変更する値に依存するものではありません。
The "traffic-action" extended community defined in this document has 46 unused bits, which can be used to convey additional meaning. IANA created and maintains a new registry entitled: "Traffic Action Fields". These values should be assigned via IETF Review rules only. The following traffic-action fields have been allocated:
このドキュメントで定義されている「トラフィックアクション」拡張コミュニティには、46個の未使用ビットがあり、追加の意味を伝えるために使用できます。IANAは、「トラフィックアクションフィールド」というタイトルの新しいレジストリを作成および維持しています。これらの値は、IETFレビュールールのみを介して割り当てる必要があります。以下の交通アクションフィールドが割り当てられています。
47 Terminal Action
47端末アクション
46 Sample
46サンプル
0-45 Unassigned
0-45割り当てなし
The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris Morrow, Charlie Kaufman, and David Smith for their comments.
著者は、Yakov Rekhter、Dennis Ferguson、Chris Morrow、Charlie Kaufman、David Smithのコメントに感謝したいと思います。
Chaitanya Kodeboyina helped design the flow validation procedure.
Chaitanya Kodeboyinaは、フロー検証手順の設計を支援しました。
Steven Lin and Jim Washburn ironed out all the details necessary to produce a working implementation.
Steven LinとJim Washburnは、実用的な実装を作成するために必要なすべての詳細を解決しました。
[IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985.
[IEEE.754.1985]電気およびエレクトロニクスエンジニアの研究所、「バイナリフローティングポイント算術の標準」、IEEE Standard 754、1985年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、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月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP拡張コミュニティ属性」、RFC 4360、2006年2月。
[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月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
Authors' Addresses
著者のアドレス
Pedro Marques Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US EMail: roque@cisco.com
Pedro Marques Cisco Systems 170 West Tasman Drive San Jose、CA 95134 US Email：roque@cisco.com
Nischal Sheth Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: nsheth@juniper.net
Nischal Sheth Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 US Email：nsheth@juniper.net
Robert Raszuk Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US EMail: raszuk@cisco.com
Robert Raszuk Cisco Systems 170 West Tasman Drive San Jose、CA 95134 US Email：raszuk@cisco.com
Barry Greene Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: bgreene@juniper.net
Barry Greene Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 US Email：bgreene@juniper.net
Jared Mauch NTT America 101 Park Ave 41st Floor New York, NY 10178 US EMail: jmauch@us.ntt.net
Jared Mauch ntt America 101 Park Ave 41st Floor New York、NY 10178 US Email：jmauch@us.ntt.net
Danny McPherson Arbor Networks EMail: danny@arbor.net
Danny McPherson Arbor Networksメール：danny@arbor.net