[要約] RFC 9117は、BGPフロースペックの検証手順を改訂したものです。この文書の目的は、インターネットの安全性と効率性を向上させるために、より厳格で効果的なフロー情報の検証プロセスを提供することにあります。主に、DDoS攻撃の緩和やトラフィックエンジニアリングの改善など、ネットワーク管理とセキュリティの文脈で利用されます。
Internet Engineering Task Force (IETF) J. Uttaro
Request for Comments: 9117 AT&T
Updates: 8955 J. Alcaide
Category: Standards Track C. Filsfils
ISSN: 2070-1721 D. Smith
Cisco
P. Mohapatra
Sproute Networks
August 2021
Revised Validation Procedure for BGP Flow Specifications
BGPフロー仕様の検証手順を修正しました
Abstract
概要
This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications as specified in RFC 8955 requires that the originator of the Flow Specification match the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. For an Internal Border Gateway Protocol (iBGP) received route, the originator is typically a border router within the same autonomous system (AS). The objective is to allow only BGP speakers within the data forwarding path to originate BGP Flow Specifications. Sometimes it is desirable to originate the BGP Flow Specification from any place within the autonomous system itself, for example, from a centralized BGP route controller. However, the validation procedure described in RFC 8955 will fail in this scenario. The modification proposed herein relaxes the validation rule to enable Flow Specifications to be originated within the same autonomous system as the BGP speaker performing the validation. Additionally, this document revises the AS_PATH validation rules so Flow Specifications received from an External Border Gateway Protocol (eBGP) peer can be validated when such a peer is a BGP route server.
この文書では、BGPフロー仕様の普及のために定義された検証手順の変更について説明します。 RFC 8955で指定されたBGPフロー仕様の普及は、フロー仕様の発信元がフロー仕様に埋め込まれ、宛先プレフィックスのベストマッチユニキャストルートの創始者と一致していることが必要です。内部ボーダーゲートウェイプロトコル（iBGPの）受信経路の場合、発信者は、通常、同じ自律システム（AS）内の境界ルータです。目的は、データ転送パス内のみBGPスピーカーがBGPフロー仕様を発信できるようにすることです。時には集中BGPルート・コントローラから、例えば、自律システム自体内の任意の場所からBGPフロー仕様を発信することが望ましいです。しかし、RFC 8955で説明した検証手順は、このシナリオでは失敗します。本明細書で提案された変更は、検証を実行するBGPスピーカと同じ自律システム内で発信するフロー仕様を可能にするための検証ルールを緩和します。このようなピアがBGPルートサーバである場合にフロー仕様外部ボーダーゲートウェイプロトコル（のeBGP）ピアから受信したので、さらに、この文書はAS_PATH検証ルールを修正検証することができます。
This document updates the validation procedure in RFC 8955.
この文書はRFC 8955の検証手順を更新します。
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 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9117.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9117で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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ドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Definitions of Terms Used in This Memo
3. Motivation
4. Revised Validation Procedure
4.1. Revision of Route Feasibility
4.2. Revision of AS_PATH Validation
5. Topology Considerations
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
[RFC8955] defines BGP Network Layer Reachability Information (NLRI) [RFC4760] that can be used to distribute traffic Flow Specifications amongst BGP speakers in support of traffic filtering. The primary intention of [RFC8955] is to enable downstream autonomous systems to signal traffic filtering policies to upstream autonomous systems. In this way, traffic is filtered closer to the source and the upstream autonomous systems avoid carrying the traffic to the downstream autonomous systems only to be discarded. [RFC8955] also enables more granular traffic filtering based upon upper-layer protocol information (e.g., protocol or port numbers) as opposed to coarse IP destination prefix-based filtering. Flow Specification NLRIs received from a BGP peer is subject to validity checks before being considered feasible and subsequently installed within the respective Adj-RIB-In.
[RFC8955]トラフィックフィルタリングをサポートしているBGPスピーカーの間でトラフィックフローの仕様を配信するために使用できるBGPネットワーク層到達可能性情報（NLRI）[RFC4760]を定義します。[RFC8955]の主な意図は、ダウンストリーム自律システムがトラフィックフィルタリングポリシーを上流の自律システムにシグナリングできるようにすることです。このようにして、トラフィックはソースおよび上流の自律システムに近いシステムに近いものになり、下流の自律システムへのトラフィックを廃棄することを回避しない。[RFC8955]は、粗いIP宛先プレフィックスベースのフィルタリングとは対照的に、上位プロトコル情報（例えば、プロトコルまたはポート番号）に基づいてより粒状のトラフィックフィルタリングを可能にする。Flow Specification BGPピアから受信したNLRIは、実行可能であると考えられ、続いてそれぞれのADJ-RIB-IN内に設置される前に有効性チェックを受けます。
The validation procedure defined within [RFC8955] requires that the originator of the Flow Specification NLRI match the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. The aim is to make sure that only speakers on the forwarding path can originate the Flow Specification. Let's consider the particular case where the Flow Specification is originated in any location within the same Local Domain as the speaker performing the validation (for example, by a centralized BGP route controller), and the best-match unicast route is originated in another Local Domain. In order for the validation to succeed for a Flow Specification received from an iBGP peer, it would be necessary to disseminate such Flow Specification NLRI directly from the specific border router (within the Local Domain) that is advertising the corresponding best-match unicast route to the Local Domain. Those border routers would be acting as de facto route controllers. This approach would be, however, operationally cumbersome in a Local Domain with numerous border routers having complex BGP policies.
[RFC8955]内で定義されている検証手順では、フロー仕様NLRIの発信者がフロー仕様に埋め込まれている宛先プレフィックスの最適なユニキャストルートの発信者と一致することが必要です。目的は、転送経路上のスピーカーのみがフロー仕様を発生させることができることを確認することです。フロー仕様が（例えば集中型BGPルートコントローラによって）検証を実行するスピーカーと同じローカルドメイン内の任意の場所で発信され、最適なユニキャストルートが別のローカルドメインで発生しました。 。 IBGPピアから受信されたフロー仕様に対して検証が成功するためには、対応する最適なユニキャストルートをアドバタイズしている特定のボーダールータ（ローカルドメイン内）からそのようなフロー仕様NLRIを直接統合する必要があります。ローカルドメイン。これらの境界ルータは、事実上のルートコントローラとして機能します。しかしながら、このアプローチは、複雑なBGPポリシーを有する多数の境界ルータを有するローカルドメイン内で動作上煩雑になるであろう。
Figure 1 illustrates this principle. R1 (the upstream router) and RR (a route reflector) need to validate the Flow Specification whose embedded destination prefix has a best-match unicast route (dest-route) originated by ASBR2. ASBR2 could originate the Flow Specification, and it would be validated when received by RR and R1 (from their point of view, the originator of both the Flow Specification and the best-match unicast route will be ASBR1). Sometimes the Flow Specification needs to be originated within AS1. ASBR1 could originate it, and the Flow Specification would still be validated. In both cases, the Flow Specification is originated by a router in the same forwarding path as the dest-route. For the case where AS1 has thousands of ASBRs, it becomes impractical to originate different Flow Specification rules on each ASBR in AS1 based on which ASBR each dest-route is learned from. To make the situation more tenable, the objective is to advertise all the Flow Specifications from the same route controller.
図1はこの原理を示しています。 R1（アップストリームルータ）およびRR（経路リフレクタ）は、埋め込まれた宛先プレフィックスがASBR2によって発信された最良の一致のユニキャストルート（DEST-ROUT）を有するフロー仕様を検証する必要がある。 ASBR2はフロー仕様を発信する可能性があり、RRおよびR1によって（それらの観点からは、フロー仕様および最良の一致のユニキャストルートの両方の発信者はASBR1になる）によって検証されます。フロー仕様はAS1内で発信される必要があります。 ASBR1はそれを起因する可能性があり、フロー仕様はまだ検証されます。どちらの場合も、フロー仕様は、DEST-ROUTEと同じ転送パス内のルータによって発生します。 AS1が何千ものASBRを持っている場合には、各DEST-ROUTEが学習したAS1で各ASBの各ASBで異なるフロー仕様ルールを発信することが実用的ではない。状況をよりテーバブルにするために、目的は同じルートコントローラからすべてのフロー仕様をアドバタイズすることです。
R1(AS1) --- RR(AS1) --- ASBR1(AS1) --- ASBR2(AS2)
|
route controller(AS1)
Figure 1
図1
This document describes a modification to the validation procedure described in [RFC8955], by allowing Flow Specification NLRIs to be originated from a centralized BGP route controller located within the Local Domain and not necessarily in the data-forwarding path. While the proposed modification cannot be used for inter-domain coordination of traffic filtering, it greatly simplifies distribution of intra-domain traffic filtering policies within a Local Domain that has numerous border routers having complex BGP policies. By relaxing the validation procedure for iBGP, the proposed modification allows Flow Specifications to be distributed in a standard and scalable manner throughout the Local Domain.
このドキュメントでは、フロー仕様NLRIがローカルドメイン内にある集中型BGPルートコントローラから発生し、必ずしもデータ転送パス内には発生することを許可することで、[RFC8955]に記載されている検証手順の変更について説明します。提案された修正はトラフィックフィルタリングのドメイン間調整に使用できないが、複雑なBGPポリシーを有する多数の境界ルータを有するローカルドメイン内のドメイン内トラフィックフィルタリングポリシーの分布を大幅に単純化する。IBGPの検証手順をリラックスすることで、提案された修正により、ローカルドメイン全体でフロー仕様を標準およびスケーラブルな方法で分散させることができます。
Throughout this document, some references are made to AS_CONFED_SEQUENCE segments; see Sections 4.1 and 5. If AS_CONFED_SET segments are also present in the AS_PATH, the same considerations apply to them. Note, however, that the use of AS_CONFED_SET segments is not recommended [RFC6472]. Refer to [CONFED-SET] as well.
この文書を通して、AS_CONFED_SEQUENCEセグメントを参照しています。4.1と5を参照してください.AS_CONFED_SETセグメントもAS_PATHに存在する場合、同じ考慮事項が適用されます。ただし、AS_CONFED_SETセグメントの使用は推奨されていません[RFC6472]。[Confed-Set]を参照してください。
Local Domain: the local AS or the local confederation of ASes [RFC5065].
ローカルドメイン：ローカルのASまたはASESの局所連想[RFC5065]。
eBGP: BGP peering to a router not within the Local Domain.
EBGP：ローカルドメイン内にないルータへのBGPピアリング。
iBGP: Both classic iBGP and any form of eBGP peering with a router within the same confederation (i.e., iBGP peering is a peering that is not eBGP as defined above).
IBGP：Classic IBGPと同じコンファレーション内のルータを持つ任意の形式のEBGPピアリング（すなわち、IBGPピアリングは、上で定義されたようにeBGPではないピアミーです）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Step (b) of the validation procedure in Section 6 of [RFC8955] is defined with the underlying assumption that the Flow Specification NLRI traverses the same path, in the inter-domain and intra-domain route distribution graph, as that of the longest-match unicast route for the destination prefix embedded in the Flow Specification.
[RFC8955]のセクション6の検証手順のステップ（b）は、ドメイン間およびドメイン内ルート配布グラフ、ドメイン間およびドメイン内ルート配布グラフで、LONGEST - を長期のものとすると、基礎となる仮定で定義されています。フロー仕様に埋め込まれた宛先プレフィックスのユニキャストルートを一致させます。
In the case of inter-domain traffic filtering, the Flow Specification originator at the egress border routers of an AS (e.g., RTR-D and RTR-E of AS1 in Figure 2) matches the eBGP neighbor that advertised the longest match destination prefix (see RTR-F and RTR-G, respectively, in Figure 2).
ドメイン間トラフィックフィルタリングの場合、ASの出力境界ルータ（例えば、図2のAS1のRTR-DおよびRTR-E）のフロー仕様オリジオは、最長のマッチ先プレフィックスをアドバタイズしたEBGPネイバーと一致します。図2のRTR-FとRTR-Gを参照してください）。
Similarly, at the upstream routers of an AS (see RTR-A and RTR-B of AS1 in Figure 2), the Flow Specification originator matches the egress iBGP border routers that had advertised the unicast route for the best-match destination prefix (see RTR-D and RTR-E, respectively, in Figure 2). This is true even when upstream routers select paths from different egress border routers as the best route based upon IGP distance. For example, in Figure 2:
同様に、ASのアップストリームルータ（図2のAS1のRTR-AおよびRTR-B参照）で、フロー仕様オリジネータは、最適な宛先プレフィックスのユニキャストルートをアドバタイズした出力IBGPボーダールータと一致します（参照）。図2のRTR - DおよびRTR - E）。アップストリームルータがIGP距離に基づいて最良のルートとして異なる出力境界ルータからのパスを選択しても、これは当てはまります。たとえば、図2では
RTR-A chooses RTR-D as the best route
RTR-Aが最良のルートとしてRTR-Dを選択
RTR-B chooses RTR-E as the best route
RTR-Bは最良のルートとしてRTR-Eを選択します
/ - - - - - - - - - - - - - -
| AS1 |
+-------+ +-------+
| | | | | |
| RTR-A | | RTR-B |
| | | | | |
+-------+ +-------+
| \ / |
iBGP \ / iBGP
| \ / |
+-------+
| | | |
| RTR-C |
| | RC | |
+-------+
| / \ |
/ \
| iBGP / \ iBGP |
+-------+ +-------+
| | RTR-D | | RTR-E | |
| | | |
| | | | | |
+-------+ +-------+
| | | |
- - -|- - - - - - - - -|- - -/
| eBGP eBGP |
- - -|- - - - - - - - -|- - -/
| | | |
+-------+ +-------+
| | | | | |
| RTR-F | | RTR-G |
| | | | | |
+-------+ +-------+
| AS2 |
/ - - - - - - - - - - - - - -
Figure 2
図2.
It is highly desirable that mechanisms exist to protect each AS independently from network security attacks using the BGP Flow Specification NLRI for intra-AS purposes only. Network operators often deploy a dedicated Security Operations Center (SOC) within their AS to monitor and detect such security attacks. To mitigate attacks within an AS, operators require the ability to originate intra-AS Flow Specification NLRIs from a central BGP route controller that is not within the data forwarding plane. In this way, operators can direct border routers within their AS with specific attack-mitigation actions (drop the traffic, forward to a pipe-cleaning location, etc.).
Intra-AS目的のためのBGPフロー仕様NLRIを使用して、ネットワークセキュリティ攻撃とは独立してそれぞれを保護するためのメカニズムが存在することが非常に望ましい。ネットワーク事業者は、そのようなセキュリティ攻撃を監視および検出するために専用のセキュリティオペレーションセンター（SoC）を展開しています。AS内の攻撃を軽減するために、演算子は、データ転送プレーン内にない中央BGPルートコントローラからINTRA-ASフロー仕様NLRIを発信する機能を必要とします。このようにして、オペレータは特定の攻撃緩和アクション（トラフィックをドロップし、パイプクリーニングの場所などに転送される）と同じ境界ルータを直接直接転送できます。
In addition, an operator may extend the requirements above for a group of ASes via policy. This is described in Section 4.1 (b.2.3) of the validation procedure.
さらに、オペレータは、ポリシーを介してASEのグループについて上記の要件を拡張することができます。これは検証手順の4.1（B.2.3）に記載されています。
A central BGP route controller that originates Flow Specification NLRI should be able to avoid the complexity of having to determine the egress border router whose path was chosen as the best for each of its neighbors. When a central BGP route controller originates Flow Specification NLRI, the rest of the speakers within the AS will see the BGP route controller as the originator of the Flow Specification in terms of the validation procedure rules. Thus, it is necessary to modify step (b) of the validation procedure described in [RFC8955] such that an iBGP peer that is not within the data forwarding plane may originate Flow Specification NLRIs.
フロー仕様NLRIを発信する中央BGPルートコントローラは、そのパスがその隣接者のそれぞれに最善として選択された出力境界ルータを決定することの複雑さを回避することができなければならない。Central BGP Route ControllerがFlow Specification NLRIを発信すると、AS内のスピーカーの残りのスピーカーはBGPルートコントローラを検証手順ルールの点でフロー仕様の発信元として表示されます。したがって、データ転送プレーン内にないIBGPピアがフロー仕様NLRIを起源にすることができるように、[RFC8955]に記載されている検証手順のステップ（b）を変更する必要がある。
Step (b) of the validation procedure specified in Section 6 of [RFC8955] is redefined as follows:
[RFC8955]の6項で指定された検証手順のステップ（b）は、次のように再定義されます。
| b) One of the following conditions MUST hold true:
|
| 1. The originator of the Flow Specification matches the
| originator of the best-match unicast route for the
| destination prefix embedded in the Flow Specification (this
| is the unicast route with the longest possible prefix
| length covering the destination prefix embedded in the Flow
| Specification).
|
| 2. The AS_PATH attribute of the Flow Specification is empty or
| contains only an AS_CONFED_SEQUENCE segment [RFC5065].
|
| 1. This condition SHOULD be enabled by default.
|
| 2. This condition MAY be disabled by explicit
| configuration on a BGP speaker.
|
| 3. As an extension to this rule, a given non-empty AS_PATH
| (besides AS_CONFED_SEQUENCE segments) MAY be permitted
| by policy.
Explanation:
説明：
Receiving either an empty AS_PATH or one with only an AS_CONFED_SEQUENCE segment indicates that the Flow Specification was originated inside the Local Domain.
空のAS_PATHまたはAS_CONFED_SEQUENCEセグメントのみを持つ空のAS_PATHを受信すると、フロー仕様がローカルドメイン内で発信されたことを示します。
With the above modification to the [RFC8955] validation procedure, a BGP peer within the Local Domain that is not within the data-forwarding path can originate a Flow Specification.
上記の[RFC8955]検証手順の変更により、データ転送経路内にないローカルドメイン内のBGPピアはフロー仕様を発信することができる。
Disabling the new condition above (see step b.2.2 in Section 4.1) could be a good practice if the operator knew with certainty that a Flow Specification would not be originated inside the Local Domain. An additional case would be if it was known for a fact that only the right egress border routers (i.e., those that were also egress border routers for the best routes) were originating Flow Specification NLRI.
上記の新しい状態を無効にする（セクション4.1のステップB.2.2を参照）、オペレータが、フロー仕様がローカルドメイン内で発生しないことを確実に知っていることを確認することができます。追加のケースは、右の出口境界ルータのみ（すなわち、最良の経路のための出力境界ルータもまた、）発信フロー仕様NLRIであるという事実で知られている場合であろう。
Also, policy may be useful to permit a specific set of non-empty AS_PATHs (see step b.2.3 in Section 4.1). For example, it could validate a Flow Specification whose AS_PATH contained only an AS_SEQUENCE segment with ASes that were all known to belong to the same administrative domain.
また、ポリシーは、空の非空のAS_PATHSのセットを許可するのに役立ちます（セクション4.1のステップB.2.3を参照）。たとえば、AS_PATHがAS_PATHに含まれているAS_SEQUENCEセグメントのみが、同じ管理ドメインに属することが知られているAS_SEQUENCEセグメントのみを含んでいました。
Section 6 of [RFC8955] states:
[RFC8955]の第6章
| 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
| here for security reasons.
This rule prevents the exchange of BGP Flow Specification NLRIs at Internet exchanges with BGP route servers, which by design don't insert their own AS number into the AS_PATH (Section 2.2.2.1 of [RFC7947]). Therefore, this document also redefines the [RFC8955] AS_PATH validation procedure referenced above as follows:
この規則は、BGP経路サーバーとのインターネット交換時のBGPフロー仕様NLRIの交換を防ぎます。これは、設計によって独自のものをAS_PATHに挿入しない（[RFC7947]のセクション2.2.2.1）。したがって、この文書では、次のように上記の[RFC8955] AS_PATH検証手順も再定義します。
| BGP Flow Specification implementations MUST enforce that the AS
| in the left-most position of the AS_PATH attribute of a Flow
| Specification route received via the External Border Gateway
| Protocol (eBGP) matches the AS in the left-most position of the
| AS_PATH attribute of the best-match unicast route for the
| destination prefix embedded in the Flow Specification NLRI.
Explanation:
説明：
For clarity, the AS in the left-most position of the AS_PATH means the AS that was last added to an AS_SEQUENCE.
明確にするために、AS_PATHのほとんどの位置のように、AS_Sequenceに最後に追加されたASを意味します。
This proposed modification enables the exchange of BGP Flow Specification NLRIs at Internet exchanges with BGP route servers while at the same time, for security reasons, prevents an eBGP peer from advertising an inter-domain Flow Specification for a destination prefix that it does not provide reachability information for.
この提案された修正により、BGP経路サーバとのインターネット交換時のBGPフロー仕様NLRIの交換が同時に、セキュリティ上の理由から、到達可能性を提供しないように宛先接頭辞のドメイン間フロー仕様を広告することを妨げる。のための情報。
Comparing only the left-most AS in the AS-PATH for eBGP-learned Flow Specification NLRIs is roughly equivalent to checking the neighboring AS. If the peer is a route server, security is necessarily weakened for the Flow Specification NLRI, as it is for any unicast route advertised from a route server. An example is discussed in the Security Considerations section.
EBGP学習フロー仕様のASパス内のように左のみを比較するNLRISは、隣接するのとほぼ同じです。ピアがルートサーバーの場合、ルートサーバーからアドバタイズされたユニキャストルートのためのものであるため、セキュリティは必ずしもフロー仕様NLRIに対して弱くなります。例をセキュリティ上の考慮事項のセクションで説明します。
Redefinition of this AS_PATH validation rule for a Flow Specification does not mean that the original rule in [RFC8955] cannot be enforced as well. Its enforcement remains optional per Section 6.3 of [RFC4271]. That is, a BGP speaker can enforce the first AS in the AS_PATH to be the same as the neighbor AS for a route belonging to any Address Family (including Flow Specification Address Family). If the BGP speaker peer is not a route server, when enforcing this optional rule, the security characteristics are exactly equivalent to those specified in [RFC8955].
フロー仕様のこのAS_PATH検証規則の再定義は、[RFC8955]の元の規則も適用できないという意味ではありません。その執行は[RFC4271]のセクション6.3あたりオプションのままです。すなわち、BGPスピーカは、AS_PATHのように最初のものを任意のアドレスファミリ（フロー仕様アドレスファミリを含む）に属する経路についても隣接することができる。BGPスピーカーピアがルートサーバーではない場合、このオプションのルールを適用するときに、セキュリティ特性は[RFC8955]で指定されたものと正確に同じです。
Alternatively, enforcing this optional rule for unicast routes (even if not enforced on Flow Specification NLRIs) achieves exactly the same security characteristics. The reason is that, after all validations, the neighboring AS will be the same as the left-most AS in the AS-PATH for the unicast route, and the left-most AS in the AS_PATH for the unicast route will be the same as the left-most AS in the AS_PATH for the Flow Specification NLRI. Therefore, the neighboring AS will be the same as the left-most AS in the AS_PATH for the Flow Specification NLRI (as the original AS_PATH validation rule in [RFC8955] states).
あるいは、ユニキャストルートのこのオプションのルールを施行する（Flow Specification NLRISに適用されなくても）同じセキュリティ特性を実現します。その理由は、すべての検証の後、ユニキャストルートのASパスのように左端と同じになるように、隣接は、ユニキャストルートのAS_PATHのように左端が同じになります。フロー仕様NLRIの場合は、最も左側のAS_PATHのように。したがって、隣接隣接は、フロー仕様NLRIのAS_PATHと同じ（[RFC8955]状態の元のAS_PATH検証規則として）と同じです。
Note, however, that not checking the full AS_PATH allows any rogue or misconfigured AS the ability to originate undesired Flow Specifications. This is a BGP security threat, already present in [RFC8955], but out of the scope of this document.
ただし、完全なAS_PATHをチェックしないことで、不要なフロー仕様を発信する機能として、任意の不正または誤って設定できます。これはすでに[RFC8955]に存在するBGPセキュリティの脅威ですが、この文書の範囲外です。
Using the new rule to validate a Flow Specification route received from a peer belonging to the same Local Domain is out of the scope of this document. Note that although it's possible, its utility is dubious. Although it is conceivable that a router in the same Local Domain could send a rogue update, only eBGP risk is considered within this document (in the same spirit as the aforementioned AS_PATH validation in [RFC4271]).
新しいルールを使用して同じローカルドメインに属するピアから受信したフロー仕様ルートを検証することは、この文書の範囲外です。可能性がありますが、そのユーティリティは疑わしいです。同じローカルドメイン内のルータが不正なアップデートを送信することができると考えられるが、EBGPリスクのみがこの文書内で（前述のAS_PATH検証と同じ精神では、RFC4271の[RFC4271]）と見なされます。
[RFC8955] indicates that the originator may refer to the originator path attribute (ORIGINATOR_ID) or (if the attribute is not present) the transport address of the peer from which the BGP speaker received the update. If the latter applies, a network should be designed so it has a congruent topology amongst unicast routes and Flow Specification routes. By congruent topology, it is understood that the two routes (i.e., the Flow Specification route and its best-match unicast route) are learned from the same peer across the AS. That would likely not be true, for instance, if some peers only negotiated one Address Family or if each Address Family peering had a different set of policies. Failing to have a congruent topology would result in step (b.1) of the validation procedure to fail.
[RFC8955]発信者が発信者パス属性（orentator_id）または（属性が存在しない場合）BGPスピーカーが更新を受けたピアのトランスポートアドレスを参照することを示します。後者が適用される場合は、ネットワークを設計する必要があるため、ユニキャストルートとフロー仕様ルートの中で一致するトポロジーがあります。一致トポロジーによって、2つのルート（すなわち、フロー仕様ルートおよびその最良の一致ユニキャストルート）は、同じピアからASを介して学習されることが理解される。たとえば、一部のピアが1つのアドレスファミリだけを交渉した場合、または各アドレスファミリのピアリングが異なるポリシーを持っていた場合には、当てはまりません。一致トポロジーを持つことに失敗すると、検証手順のステップ（B.1）が失敗することがあります。
With the additional second condition (b.2) in the validation procedure, non-congruent topologies are supported within the Local Domain if the Flow Specification is originated within the Local Domain.
検証手順で追加の2番目の条件（B.2）では、フロー指定がローカルドメイン内で発生した場合、非一致トポロジがローカルドメイン内でサポートされています。
Explanation:
説明：
Consider the following scenarios of a non-congruent topology without the second condition (b.2) being added to the validation procedure:
検証手順に2番目の条件（B.2）が追加されていない、一致しないトポロジの次のシナリオを検討してください。
1. Consider a topology with two BGP speakers with two iBGP peering sessions between them, one for unicast and one for Flow Specification. This is a non-congruent topology. Let's assume that the ORIGINATOR_ID attribute was not received (e.g., a route reflector receiving routes from its clients). In this case, the Flow Specification validation procedure will fail because of the first condition (b.1).
1. 2つのBGPスピーカーを持つ2つのBGPスピーカーを、それらの間の2つのIBGPピアリングセッションがユニキャスト用、1つはフロー仕様のためのものを考慮してください。これは一致しないトポロジです。originator_id属性が受信されなかったと仮定しましょう（例えば、ルートリフレクタはそのクライアントからルートを受信します）。この場合、最初の条件（B.1）によりフロー仕様検証手順が失敗します。
2. Consider a confederation of ASes with local AS X and local AS Y (both belonging to the same Local Domain), and a given BGP speaker X1 inside local AS X. The ORIGINATOR_ID attribute is not advertised when propagating routes across local ASes. Let's assume the Flow Specification route is received from peer Y1 and the best-match unicast route is received from peer Y2. Both peers belong to local AS Y. The Flow Specification validation procedure will also fail because of the first condition (b.1).
2. XとローカルのXとローカルのようなaとの連合（同じローカルドメインに属している）、xとしてローカル内の特定のBGPスピーカーx1を使用してください.Originator_ID属性は、ローカルなASESを介してルートを伝播するときにアドバタイズされません。ピアY1からフロー仕様経路を受信し、最適なユニキャストルートをピアY2から受信するとしましょう。両方のピアはYとしてローカルに属します。フロー仕様検証手順は、最初の条件（B.1）のために失敗します。
Consider now that the second condition (b.2) is added to the validation procedure. In the scenarios above, if Flow Specifications are originated in the same Local Domain, the AS_PATH will be empty or contain only an AS_CONFED_SEQUENCE segment. Condition (b.2) will evaluate to true. Therefore, using the second condition (b.2), as defined by this document, guarantees that the overall validation procedure will pass. Thus, non-congruent topologies are supported if the Flow Specification is originated in the same Local Domain.
検証手順に第2の条件（B.2）が追加されたことを考慮してください。上記のシナリオでは、フロー指定が同じローカルドメイン内で発信された場合、AS_PATHは空またはAS_CONFED_SEQUENCEセグメントのみを含んでいます。条件（B.2）はTRUEに評価されます。したがって、この文書で定義されているように、2番目の状態（B.2）を使用して、検証手順全体が通過することを保証します。したがって、フロー指定が同じローカルドメイン内で発信された場合、一致しないトポロジがサポートされています。
Flow Specifications originated in a different Local Domain sill need a congruent topology. The reason is that in a non-congruent topology, the second condition (b.2) evaluates to false and only the first condition (b.1) is evaluated.
異なるローカルドメインシルで発生したフロー仕様は、一致トポロジーを必要としています。その理由は、非一致トポロジにおいて、第2条件（B.2）が誤って評価され、第1条件（B.1）のみが評価されるからである。
This document has no IANA actions.
この文書にはIANAの行動がありません。
This document updates the route feasibility validation procedures for Flow Specifications learned from iBGP peers and through route servers. This change is in line with the procedures described in [RFC8955] and, thus, security characteristics remain essentially equivalent to the existing security properties of BGP unicast routing, except as detailed below.
このドキュメントは、IBGPピアとルートサーバーから学んだフロー仕様のためのルート実現可能性検証手順を更新します。この変更は[RFC8955]に記載されている手順に沿って行われ、したがって、セキュリティ特性は本質的にBGPユニキャストルーティングの既存のセキュリティプロパティと同等のままになります。
The security considerations discussed in [RFC8955] apply to this specification as well.
[RFC8955]で説明したセキュリティ上の考慮事項もこの仕様にも適用されます。
This document makes the original AS_PATH validation rule (Section 6.3 of [RFC4271]) again OPTIONAL (Section 4.2) for Flow Specification Address Family (the rule is no longer mandatory as had been specified by [RFC8955]). If that original rule is not enforced for Flow Specification, it may introduce some new security risks. A speaker in AS X peering with a route server could advertise a rogue Flow Specification route whose first AS in AS_PATH was Y. Assume Y is the first AS in the AS_PATH of the best-match unicast route. When the route server advertises the Flow Specification to a speaker in AS Z, it will be validated by that speaker. This risk is impossible to prevent if the Flow Specification route is received from a route server peer. If configuration (or other means beyond the scope of this document) indicates that the peer is not a route server, that optional rule SHOULD be enforced for unicast and/or for Flow Specification routes (as discussed in the Revision of AS_PATH Validation section, just enforcing it in one of those Address Families is enough). If the indication is that the peer is not a route server or there is no conclusive indication, that optional rule SHOULD NOT be enforced.
フロー仕様アドレスファミリのオプション（RFC4271のセクション6.3）を再びオリジナルのAS_PATH検証ルール（[RFC4271]のセクション6.3）を再度オプション（RFC8955]で指定されていたようにルールは必須ではありません）。そのオリジナルの規則がフロー仕様に適用されていない場合は、いくつかの新しいセキュリティリスクを導入する可能性があります。ルートサーバーを使用したX Xピアリングとしてのスピーカーは、AS_PATH内の最初のものがYである不正なフロー仕様ルートを宣伝することができます.Yは、最適なユニキャストルートのAS_PATHの場合の最初のものです。ルートサーバーがZとしてスピーカーにフロー指定を広告すると、そのスピーカーによって検証されます。このリスクは、フロー指定ルートがルートサーバーピアから受信された場合には不可能です。構成（またはこの文書の範囲を超える他の手段）が、ピアがルートサーバーではないことを示している場合、そのオプションのルールはユニキャストおよび/またはフロー仕様ルートの場合（AS_PATH検証セクションのリビジョンで説明されているように）。それらのアドレスファミリの1つでそれを強制するのが十分です。指示が、ピアがルートサーバーではないか、または決定的な表示がないということである場合、そのオプションの規則は強制されないでください。
A route server itself may be in a good position to enforce the AS_PATH validation rule described in the previous paragraph. If it is known that a route server is not peering with any other route server, it can enforce the AS_PATH validation rule across all its peers.
ルートサーバー自体は、前の段落で説明されているAS_PATH検証規則を強制するための良い位置にある可能性があります。Route Serverが他のRoute Serverを使用してピアリングされていないことがわかっている場合は、AS_PATH検証ルールをそのすべてのピアにわたって適用できます。
BGP updates learned from iBGP peers are considered trusted, so the Traffic Flow Specifications contained in BGP updates are also considered trusted. Therefore, it is not required to validate that the originator of an intra-domain Traffic Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in that Flow Specification. Note that this trustworthiness consideration is not absolute and the new possibility that an iBGP speaker could send a rogue Flow Specification is introduced.
IBGPピアから学んだBGPアップデートは信頼されていると見なされ、BGP更新に含まれているトラフィックフローの仕様も信頼されています。したがって、ドメイン内トラフィックフロー仕様の発信者が、そのフロー仕様に埋め込まれた宛先プレフィックスの最適なユニキャストルートのオリジネータと一致することを検証する必要はありません。この信頼性の考慮事項は絶対的ではなく、IBGPスピーカーが不正なフロー仕様を送信できる新しい可能性が導入されていることに注意してください。
The changes in Section 4.1 don't affect the validation procedures for eBGP-learned routes.
セクション4.1の変更は、EBGP学習経路の検証手順に影響しません。
It's worth mentioning that allowing (or making operationally feasible) Flow Specifications to originate within the Local Domain makes the network overall more secure. Flow Specifications can be originated more readily during attacks and improve the stability and security of the network.
ローカルドメイン内で発信されるように、ネットワークを全体的に安全にしていることを言及する価値がある。フロー仕様は攻撃中により容易に発信され、ネットワークの安定性とセキュリティを改善することができる。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760]ベイツ、T.、Chandra、R.、Katz、D.、およびY.Rekhter、「BGP-4」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<https：// www。rfc-editor.org/info/rfc4760>。
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <https://www.rfc-editor.org/info/rfc5065>.
[RFC5065] Traina、P.、McPherson、D.、およびJ.Scudder、2007年8月、<https：//www.rfc-editor.org/に、RFC 5065、DOI 10.17487 / RFC5065、RFC5065情報/ RFC5065>。
[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, <https://www.rfc-editor.org/info/rfc7947>.
[RFC7947] Jasinska、E.、Hilliard、N.、Raszuk、R.、およびN. Bakker、 "Internet Exchange BGP Route Server"、RFC 7947、DOI 10.17487 / RFC7947、2016年9月、<https：//www.rfc-editor.org/info/rfc7947>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/info/rfc8955>.
[RFC8955] LOIBL、C.、HARES、S.、Raszuk、R.、Mcpherson、D.、およびM. Bacher、「フロー仕様規則の普及」、RFC 8955、DOI 10.17487 / RFC8955、2020年12月2020日、<HTTPS：//www.rfc-editor.org/info/rfc8955>。
[CONFED-SET] Kumari, W., Sriram, K., Hannachi, L., and J. Haas, "Deprecation of AS_SET and AS_CONFED_SET in BGP", Work in Progress, Internet-Draft, draft-ietf-idr-deprecate-as-set-confed-set-05, 12 March 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-05>.
[Confed-Set] Kumari、W.、Sriram、K.、Hannachi、L.、J.HAAS、「BGPのAS_CONFED_SETの非推奨」、進行中の作業、インターネットドラフト、ドラフトIETF-IDR非訴追-as-set-confed-set-05,200月12日、<https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-asset-confed-set-05>。
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, DOI 10.17487/RFC6472, December 2011, <https://www.rfc-editor.org/info/rfc6472>.
[RFC6472] kumari、W.およびK.Sriram、BGP 172、RFC 6472、DOI 10.17487 / RFC6472、2011年12月、<https：//ww.rfc-editor.org/ info / rfc6472>。
Acknowledgements
謝辞
The authors would like to thank Han Nguyen for his direction on this work as well as Waqas Alam, Keyur Patel, Robert Raszuk, Eric Rosen, Shyam Sethuram, Susan Hares, Alvaro Retana, and John Scudder for their review and comments.
著者らは、この作品、Keyur Patel、Robert Raszuk、Eric Rosen、Shyam Sethuram、Susan Hares、Alvaro retana、およびJohn Scudderなどの漢字に感謝します。
Authors' Addresses
著者の住所
James Uttaro AT&T 200 S. Laurel Ave Middletown, NJ 07748 United States of America
James Uttaro AT＆T 200 S. Laurel Ave Middletown、NJ 07748アメリカ合衆国
Email: ju1738@att.com
Juan Alcaide Cisco Research Triangle Park 7100 Kit Creek Road Morrisville, NC 27709 United States of America
Juan Alcaide Cisco Research Triangle Park 7100 Kit Creek Road Morrisville、NC 27709アメリカ合衆国
Email: jalcaide@cisco.com
Clarence Filsfils Cisco
Clarence Filsfilsシスコ
Email: cf@cisco.com
David Smith Cisco 111 Wood Ave South Iselin, NJ 08830 United States of America
David Smith Cisco 111 Wood Ave South Iselin、NJ 08830アメリカ合衆国
Email: djsmith@cisco.com
Pradosh Mohapatra Sproute Networks
Pradosh Mohapatra Sproute Networks
Email: mpradosh@yahoo.com