[要約] RFC 8704は、改良された実現可能なパスのユニキャスト逆経路転送に関する規格です。その目的は、ネットワークのセキュリティを向上させ、不正なトラフィックの送信を防ぐことです。
Internet Engineering Task Force (IETF) K. Sriram
Request for Comments: 8704 D. Montgomery
BCP: 84 USA NIST
Updates: 3704 J. Haas
Category: Best Current Practice Juniper Networks, Inc.
ISSN: 2070-1721 February 2020
Enhanced Feasible-Path Unicast Reverse Path Forwarding
拡張された実行可能パスユニキャストリバースパス転送
Abstract
概要
This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704.
このドキュメントでは、送信元アドレスのスプーフィング（BCP 38を参照）の検出と緩和のためのユニキャストReverse Path Forwarding（uRPF）技術（RFC 3704を参照）の必要性を認識し、改善を提案します。厳密なuRPFは方向性に柔軟性がなく、緩いuRPFは方向性に気付かず、現在の実行可能なパスのuRPFは2つの間のバランスをとろうとします（RFC 3704を参照）。ただし、このドキュメントに示すように、既存の実行可能パスのuRPFにはまだ欠点があります。このドキュメントでは、実行可能パスuRPF（RFC 3704）よりも方向性に関して（意味のある方法で）より柔軟な拡張実行可能パスuRPF（EFP-uRPF）テクニックについて説明します。提案されているEFP-uRPFメソッドは、送信元アドレス検証（SAV）での無効な検出に関する誤検知を大幅に減らすことを目的としています。したがって、顧客へのサービスを中断する可能性についてのISPの懸念を軽減し、uRPF技術の導入を促進することができます。このドキュメントはRFC 3704を更新します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc8704.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8704で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Terminology
1.2. Requirements Language
2. Review of Existing Source Address Validation Techniques
2.1. SAV Using Access Control List
2.2. SAV Using Strict Unicast Reverse Path Forwarding
2.3. SAV Using Feasible-Path Unicast Reverse Path Forwarding
2.4. SAV Using Loose Unicast Reverse Path Forwarding
2.5. SAV Using VRF Table
3. SAV Using Enhanced Feasible-Path uRPF
3.1. Description of the Method
3.1.1. Algorithm A: Enhanced Feasible-Path uRPF
3.2. Operational Recommendations
3.3. A Challenging Scenario
3.4. Algorithm B: Enhanced Feasible-Path uRPF with Additional
Flexibility across Customer Cone
3.5. Augmenting RPF Lists with ROA and IRR Data
3.6. Implementation and Operations Considerations
3.6.1. Impact on FIB Memory Size Requirement
3.6.2. Coping with BGP's Transient Behavior
3.7. Summary of Recommendations
3.7.1. Applicability of the EFP-uRPF Method with Algorithm A
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Authors' Addresses
Source address validation (SAV) refers to the detection and mitigation of source address (SA) spoofing [RFC2827]. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques [RFC3704] for SAV. Strict uRPF is inflexible about directionality (see [RFC3704] for definitions), the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two [RFC3704]. However, as shown in this document, the existing feasible-path uRPF still has shortcomings. Even with the feasible-path uRPF, ISPs are often apprehensive that they may be dropping customers' data packets with legitimate source addresses.
送信元アドレス検証（SAV）は、送信元アドレス（SA）スプーフィングの検出と緩和を指します[RFC2827]。このドキュメントは、SAVのユニキャストReverse Path Forwarding（uRPF）技術[RFC3704]の必要性を識別し、改善を提案します。厳密なuRPFは方向性に柔軟性がなく（定義については[RFC3704]を参照）、緩いuRPFは方向性に気付かず、現在の実行可能パスuRPFは2つの[RFC3704]のバランスをとろうとします。ただし、このドキュメントに示すように、既存の実行可能パスのuRPFにはまだ欠点があります。実現可能なパスのuRPFを使用しても、ISPは、正当な送信元アドレスを持つ顧客のデータパケットをドロップしている可能性があることを懸念しています。
This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that aim to be more flexible (in a meaningful way) about directionality than the feasible-path uRPF. It is based on the principle that if BGP updates for multiple prefixes with the same origin AS were received on different interfaces (at border routers), then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces (presented in Section 3). For some challenging ISP-customer scenarios (see Section 3.3), this document also describes a more relaxed version of the enhanced feasible-path uRPF technique (presented in Section 3.4). Implementation and operations considerations are discussed in Section 3.6.
このドキュメントでは、実行可能パスのuRPFよりも方向性について（意味のある方法で）より柔軟になることを目的とした拡張された実行可能パスのuRPF（EFP-uRPF）テクニックについて説明します。これは、同じ発信元ASを持つ複数のプレフィックスのBGPアップデートが異なるインターフェースで（境界ルーターで）受信された場合、それらのいずれかのプレフィックスに送信元アドレスを持つ着信データパケットが、それらのインターフェースのいずれかで受け入れられるという原則に基づいています（セクション3で提示）。一部の難しいISPのお客様のシナリオ（セクション3.3を参照）については、このドキュメントでは、拡張された実行可能パスuRPF技術（セクション3.4で説明）のよりリラックスしたバージョンについても説明します。実装と運用に関する考慮事項については、セクション3.6で説明します。
Throughout this document, the routes under consideration are assumed to have been vetted based on prefix filtering [RFC7454] and possibly origin validation [RFC6811].
このドキュメント全体を通して、検討中のルートは、プレフィックスフィルタリング[RFC7454]と、場合によっては発信元検証[RFC6811]に基づいて吟味されたと想定されています。
The EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in SAV. They are expected to add greater operational robustness and efficacy to uRPF while minimizing ISPs' concerns about accidental service disruption for their customers. It is expected that this will encourage more deployment of uRPF to help realize its Denial of Service (DoS) and Distributed DoS (DDoS) prevention benefits network wide.
EFP-uRPFメソッドは、SAVでの無効な検出に関する誤検知を大幅に減らすことを目的としています。彼らは、顧客に対する偶発的なサービス中断に関するISPの懸念を最小限に抑えながら、uRPFの運用の堅牢性と効率を向上させることが期待されています。これにより、uRPFのより多くの導入が促進され、サービス拒否（DoS）と分散型DoS（DDoS）防止のメリットをネットワーク全体で実現できるようになることが期待されます。
The Reverse Path Forwarding (RPF) list is the list of permissible source-address prefixes for incoming data packets on a given interface.
リバースパスフォワーディング（RPF）リストは、特定のインターフェイスの着信データパケットに許可される送信元アドレスプレフィックスのリストです。
Peering relationships considered in this document are provider-to-customer (P2C), customer-to-provider (C2P), and peer-to-peer (P2P). Here, "provider" refers to a transit provider. The first two are transit relationships. A peer connected via a P2P link is known as a lateral peer (non-transit).
このドキュメントで検討されているピアリング関係は、プロバイダーからカスタマー（P2C）、カスタマーからプロバイダー（C2P）、およびピアツーピア（P2P）です。ここで、「プロバイダー」はトランジットプロバイダーを指します。最初の2つは通過関係です。 P2Pリンクを介して接続されたピアは、ラテラルピア（非トランジット）と呼ばれます。
AS A's customer cone is A plus all the ASes that can be reached from A following only P2C links [Luckie].
AS Aのカスタマーコーンは、Aに加えて、P2CリンクのみをたどってAから到達できるすべてのASです[ラッキー]。
A stub AS is an AS that does not have any customers or lateral peers. In this document, a single-homed stub AS is one that has a single transit provider and a multihomed stub AS is one that has multiple (two or more) transit providers.
スタブASは、カスタマーまたはラテラルピアを持たないASです。このドキュメントでは、シングルホームのスタブASは単一のトランジットプロバイダーを持つものであり、マルチホームのスタブASは複数（2つ以上）のトランジットプロバイダーを持つものです。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
There are various existing techniques for the mitigation of DoS/DDoS attacks with spoofed addresses [RFC2827] [RFC3704]. SAV is performed in network edge devices, such as border routers, Cable Modem Termination Systems (CMTS) [RFC4036], and Packet Data Network Gateways (PDN-GWs) in mobile networks [Firmin]. Ingress Access Control List (ACL) and uRPF are techniques employed for implementing SAV [RFC2827] [RFC3704] [ISOC].
なりすましアドレスによるDoS / DDoS攻撃を緩和するためのさまざまな既存の技術があります[RFC2827] [RFC3704]。 SAVは、境界ルーター、ケーブルモデムターミネーションシステム（CMTS）[RFC4036]、モバイルネットワークのパケットデータネットワークゲートウェイ（PDN-GW）[フィルミン]などのネットワークエッジデバイスで実行されます。 Ingress Access Control List（ACL）とuRPFは、SAV [RFC2827] [RFC3704] [ISOC]を実装するために使用される技術です。
Ingress/egress ACLs are maintained to list acceptable (or alternatively, unacceptable) prefixes for the source addresses in the incoming/outgoing Internet Protocol (IP) packets. Any packet with a source address that fails the filtering criteria is dropped. The ACLs for the ingress/egress filters need to be maintained to keep them up to date. Updating the ACLs is an operator-driven manual process; hence, it is operationally difficult or infeasible.
入力/出力ACLは、受信/送信インターネットプロトコル（IP）パケット内の送信元アドレスの受け入れ可能な（あるいは、受け入れられない）プレフィックスをリストするために維持されます。フィルタリング基準を満たさない送信元アドレスを持つパケットはすべてドロップされます。入力/出力フィルターのACLは、最新に保つために維持する必要があります。 ACLの更新は、オペレーター主導の手動プロセスです。したがって、運用上困難または実行不可能です。
Typically, the egress ACLs in access aggregation devices (e.g., CMTS, PDN-GW) permit source addresses only from the address spaces (prefixes) that are associated with the interface on which the customer network is connected. Ingress ACLs are typically deployed on border routers and drop ingress packets when the source address is spoofed (e.g., belongs to obviously disallowed prefix blocks, IANA special-purpose prefixes [SPAR-v4][SPAR-v6], provider's own prefixes, etc.).
通常、アクセス集約デバイス（CMTS、PDN-GWなど）の出力ACLは、顧客ネットワークが接続されているインターフェースに関連付けられているアドレススペース（プレフィックス）からの送信元アドレスのみを許可します。入力ACLは通常、境界ルーターに展開され、送信元アドレスが偽装された場合に入力パケットをドロップします（たとえば、明らかに許可されていないプレフィックスブロック、IANA専用プレフィックス[SPAR-v4] [SPAR-v6]、プロバイダー独自のプレフィックスなどに属します）。 ）。
Note: In the figures (scenarios) in this section and the subsequent sections, the following terminology is used:
注：このセクションおよび後続のセクションの図（シナリオ）では、次の用語が使用されています。
* "fails" means drops packets with legitimate source addresses.
* 「失敗」とは、正当な送信元アドレスを持つパケットをドロップすることを意味します。
* "works (but not desirable)" means passes all packets with legitimate source addresses but is oblivious to directionality.
* 「動作する（ただし望ましくない）」とは、正当な送信元アドレスを持つすべてのパケットを通過させるが、方向性には気づかないことを意味します。
* "works best" means passes all packets with legitimate source addresses with no (or minimal) compromise of directionality.
* 「最適に機能する」とは、方向性を損なうことなく（または最小限に）、正当な送信元アドレスを持つすべてのパケットを渡すことを意味します。
* The notation Pi[ASn ASm ...] denotes a BGP update with prefix Pi and an AS_PATH as shown in the square brackets.
* 表記Pi [ASn ASm ...]は、角かっこで示されているように、プレフィックスPiとAS_PATHを持つBGPアップデートを示します。
In the strict uRPF method, an ingress packet at a border router is accepted only if the Forwarding Information Base (FIB) contains a prefix that encompasses the source address and forwarding information for that prefix points back to the interface over which the packet was received. In other words, the reverse path for routing to the source address (if it were used as a destination address) should use the same interface over which the packet was received. It is well known that this method has limitations when networks are multihomed, routes are not symmetrically announced to all transit providers, and there is asymmetric routing of data packets. Asymmetric routing occurs (see Figure 1) when a customer AS announces one prefix (P1) to one transit provider (ISP-a) and a different prefix (P2) to another transit provider (ISP-b) but routes data packets with source addresses in the second prefix (P2) to the first transit provider (ISP-a) or vice versa. Then, data packets with a source address in prefix P2 that are received at AS2 directly from AS1 will get dropped. Further, data packets with a source address in prefix P1 that originate from AS1 and traverse via AS3 to AS2 will also get dropped at AS2.
厳密なuRPF方式では、送信元アドレスを含むプレフィックスが転送情報ベース（FIB）に含まれ、そのプレフィックスの転送情報がパケットの受信に使用されたインターフェイスを指す場合にのみ、境界ルーターでの入力パケットが受け入れられます。つまり、送信元アドレスへのルーティングの逆パス（宛先アドレスとして使用された場合）は、パケットが受信されたのと同じインターフェースを使用する必要があります。ネットワークがマルチホームであり、ルートがすべてのトランジットプロバイダーに対称的に通知されず、データパケットの非対称ルーティングがある場合、この方法には制限があることはよく知られています。非対称ルーティングは、カスタマーASが1つのプレフィックス（P1）を1つのトランジットプロバイダー（ISP-a）にアナウンスし、別のプレフィックス（P2）を別のトランジットプロバイダー（ISP-b）にアナウンスするが、ソースアドレスでデータパケットをルーティングする場合に発生します（図1を参照）。 2番目のプレフィックス（P2）から最初のトランジットプロバイダー（ISP-a）へ、またはその逆。次に、AS1から直接AS2で受信された、プレフィックスP2のソースアドレスを持つデータパケットがドロップされます。さらに、AS1から発信され、AS3を経由してAS2に移動する、プレフィックスP1のソースアドレスを持つデータパケットも、AS2でドロップされます。
+------------+ ---- P1[AS2 AS1] ---> +------------+
| AS2(ISP-a) | <----P2[AS3 AS1] ---- | AS3(ISP-b) |
+------------+ +------------+
/\ /\
\ /
\ /
\ /
P1[AS1]\ /P2[AS1]
\ /
+-----------------------+
| AS1(customer) |
+-----------------------+
P1, P2 (prefixes originated)
Consider data packets received at AS2 (1) from AS1 with a source address (SA) in P2, or (2) from AS3 that originated from AS1 with a SA in P1: * Strict uRPF fails * Feasible-path uRPF fails * Loose uRPF works (but not desirable) * Enhanced feasible-path uRPF works best
AS2で（1）P2に送信元アドレス（SA）を持つAS1から受信したデータパケット、または（2）P1にSAを持つAS1から発信されたデータパケットを考えてみます。動作します（ただし望ましくありません）*拡張された実行可能パスuRPFが最適に動作します
Figure 1: Scenario 1 for Illustration of Efficacy of uRPF Schemes
図1：uRPFスキームの有効性を示すシナリオ1
The feasible-path uRPF technique helps partially overcome the problem identified with the strict uRPF in the multihoming case. The feasible-path uRPF is similar to the strict uRPF, but in addition to inserting the best-path prefix, additional prefixes from alternative announced routes are also included in the RPF list. This method relies on either (a) announcements for the same prefixes (albeit some may be prepended to effect lower preference) propagating to all transit providers performing feasible-path uRPF checks or (b) announcement of an aggregate less-specific prefix to all transit providers while announcing more-specific prefixes (covered by the less-specific prefix) to different transit providers as needed for traffic engineering.
実行可能パスのuRPF技術は、マルチホーミングの場合に厳格なuRPFで識別される問題を部分的に克服するのに役立ちます。実行可能パスのuRPFは、厳密なuRPFに似ていますが、ベストパスプレフィックスの挿入に加えて、代替アナウンスルートからの追加のプレフィックスもRPFリストに含まれています。このメソッドは、（a）実行可能パスのuRPFチェックを実行するすべてのトランジットプロバイダーに伝搬する（a）プレフィックスのプレフィックス（一部は前に追加されて優先順位が低くなる場合があります）への通知、または（b）すべてのトランジットへのより具体的でないプレフィックスのアナウンスに依存します。プロバイダーは、トラフィックエンジニアリングの必要に応じて、より具体的なプレフィックス（具体性の低いプレフィックスでカバーされる）をさまざまな交通機関プロバイダーにアナウンスします。
As an example, in the multihoming scenario (see Scenario 2 in Figure 2), if the customer AS announces routes for both prefixes (P1, P2) to both transit providers (with suitable prepends if needed for traffic engineering), then the feasible-path uRPF method works. It should be mentioned that the feasible-path uRPF works in this scenario only if customer routes are preferred at AS2 and AS3 over a shorter non-customer route. However, the feasible-path uRPF method has limitations as well. One form of limitation naturally occurs when the recommendation (a) or (b) mentioned above regarding propagation of prefixes is not followed.
例として、マルチホーミングシナリオ（図2のシナリオ2を参照）で、カスタマーASが両方のプレフィクス（P1、P2）のルートを両方のトランジットプロバイダーに通知する場合（トラフィックエンジニアリングに必要な場合は適切なプリペンドを使用）、次にパスuRPFメソッドが機能します。実現可能なパスのuRPFがこのシナリオで機能するのは、カスタマールートがAS2およびAS3でより短い非カスタマールートよりも優先される場合のみであることに注意してください。ただし、実行可能パスuRPFメソッドにも制限があります。制限の1つの形式は、プレフィックスの伝播に関する上記の推奨（a）または（b）に従わない場合に自然に発生します。
Another form of limitation can be described as follows. In Scenario 2 (described here, illustrated in Figure 2), it is possible that the second transit provider (ISP-b or AS3) does not propagate the prepended route for prefix P1 to the first transit provider (ISP-a or AS2). This is because AS3's decision policy permits giving priority to a shorter route to prefix P1 via a lateral peer (AS2) over a longer route learned directly from the customer (AS1). In such a scenario, AS3 would not send any route announcement for prefix P1 to AS2 (over the P2P link). Then, a data packet with a source address in prefix P1 that originates from AS1 and traverses via AS3 to AS2 will get dropped at AS2.
別の形式の制限は、次のように説明できます。シナリオ2（ここで説明、図2に示す）では、2番目のトランジットプロバイダー（ISP-bまたはAS3）が、プレフィックスP1の先頭に追加されたルートを最初のトランジットプロバイダー（ISP-aまたはAS2）に伝播しない可能性があります。これは、AS3の決定ポリシーにより、顧客（AS1）から直接学習された長いルートよりも、ラテラルピア（AS2）を介してプレフィックスP1への短いルートを優先することが許可されるためです。このようなシナリオでは、AS3はプレフィックスP1のルートアナウンスメントを（P2Pリンク経由で）AS2に送信しません。次に、AS1から発信され、AS3を経由してAS2に移動する、プレフィックスP1のソースアドレスを持つデータパケットは、AS2でドロップされます。
+------------+ routes for P1, P2 +------------+
| AS2(ISP-a) |<-------------------->| AS3(ISP-b) |
+------------+ (P2P) +------------+
/\ /\
\ /
P1[AS1]\ /P2[AS1]
\ /
P2[AS1 AS1 AS1]\ /P1[AS1 AS1 AS1]
\ /
+-----------------------+
| AS1(customer) |
+-----------------------+
P1, P2 (prefixes originated)
Consider data packets received at AS2 via AS3 that originated from AS1 and have a source address in P1: * Feasible-path uRPF works (if the customer route to P1 is preferred at AS3 over the shorter path) * Feasible-path uRPF fails (if the shorter path to P1 is preferred at AS3 over the customer route) * Loose uRPF works (but not desirable) * Enhanced feasible-path uRPF works best
AS1から発信され、P1に送信元アドレスを持つ、AS3を介してAS2で受信されたデータパケットを考えてみます。 AS1では、カスタマールートよりもP1への短いパスが優先されます）*緩やかなuRPFが機能します（ただし望ましくありません）*拡張された実行可能パスuRPFが最適です
Figure 2: Scenario 2 for Illustration of Efficacy of uRPF Schemes
図2：uRPFスキームの有効性を示すシナリオ2
In the loose uRPF method, an ingress packet at the border router is accepted only if the FIB has one or more prefixes that encompass the source address. That is, a packet is dropped if no route exists in the FIB for the source address. Loose uRPF sacrifices directionality. It only drops packets if the source address is unreachable in the current FIB (e.g., IANA special-purpose prefixes [SPAR-v4][SPAR-v6], unallocated, allocated but currently not routed).
ルーズuRPF方式では、送信元アドレスを含む1つ以上のプレフィックスがFIBにある場合にのみ、境界ルータでの入力パケットが受け入れられます。つまり、送信元アドレスのFIBにルートが存在しない場合、パケットはドロップされます。緩やかなuRPFは方向性を犠牲にします。現在のFIBでソースアドレスに到達できない場合にのみパケットをドロップします（たとえば、IANA特殊目的のプレフィックス[SPAR-v4] [SPAR-v6]、未割り当て、割り当て済みですが、現在ルーティングされていません）。
The Virtual Routing and Forwarding (VRF) technology [RFC4364] [Juniper] allows a router to maintain multiple routing table instances separate from the global Routing Information Base (RIB). External BGP (eBGP) peering sessions send specific routes to be stored in a dedicated VRF table. The uRPF process queries the VRF table (instead of the FIB) for source address validation. A VRF table can be dedicated per eBGP peer and used for uRPF for only that peer, resulting in strict mode operation. For implementing loose uRPF on an interface, the corresponding VRF table would be global, i.e., contains the same routes as in the FIB.
Virtual Routing and Forwarding（VRF）テクノロジー[RFC4364] [Juniper]を使用すると、ルーターは、グローバルルーティング情報ベース（RIB）とは別の複数のルーティングテーブルインスタンスを維持できます。外部BGP（eBGP）ピアリングセッションは、専用VRFテーブルに格納される特定のルートを送信します。 uRPFプロセスは、送信元アドレスの検証のために（FIBではなく）VRFテーブルを照会します。 VRFテーブルはeBGPピアごとに専用にでき、そのピアのみのuRPFに使用できるため、ストリクトモードで動作します。インターフェイスにルーズなuRPFを実装する場合、対応するVRFテーブルはグローバルになります。つまり、FIBと同じルートが含まれます。
The enhanced feasible-path uRPF (EFP-uRPF) method adds greater operational robustness and efficacy to existing uRPF methods discussed in Section 2. That is because it avoids dropping legitimate data packets and compromising directionality. The method is based on the principle that if BGP updates for multiple prefixes with the same origin AS were received on different interfaces (at border routers), then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces. The EFP-uRPF method can be best explained with an example, as follows:
拡張された実行可能パスuRPF（EFP-uRPF）メソッドは、セクション2で説明した既存のuRPFメソッドに操作上の堅牢性と効率を追加します。これは、正当なデータパケットのドロップと方向性の低下を回避するためです。この方法は、同じ起点ASを持つ複数のプレフィックスのBGP更新が異なるインターフェイス（境界ルーターで）で受信された場合、それらのいずれかのプレフィックスに送信元アドレスを持つ着信データパケットが、それらのいずれかのインターフェイスで受け入れられるという原則に基づいています。 。 EFP-uRPFメソッドは、次のように例を使用して説明するのが最適です。
Let us say, in its Adj-RIBs-In [RFC4271], a border router of ISP-A has the set of prefixes {Q1, Q2, Q3}, each of which has AS-x as its origin and AS-x is in ISP-A's customer cone. In this set, the border router received the route for prefix Q1 over a customer-facing interface while it learned the routes for prefixes Q2 and Q3 from a lateral peer and an upstream transit provider, respectively. In this example scenario, the enhanced feasible-path uRPF method requires Q1, Q2, and Q3 be included in the RPF list for the customer interface under consideration.
Adj-RIBs-In [RFC4271]で、ISP-Aの境界ルータにプレフィックスのセット{Q1、Q2、Q3}があり、それぞれにAS-xがあり、AS-xがISP-Aの顧客コーン。このセットでは、ボーダールーターはプレフィックスQ1のルートを顧客向けのインターフェイスを介して受信し、プレフィックスQ2およびQ3のルートをラテラルピアおよびアップストリームトランジットプロバイダーからそれぞれ学習しました。このシナリオ例では、拡張された実行可能パスuRPFメソッドでは、検討中のカスタマーインターフェイスのRPFリストにQ1、Q2、およびQ3が含まれている必要があります。
Thus, the EFP-uRPF method gathers feasible paths for customer interfaces in a more precise way (as compared to the feasible-path uRPF) so that all legitimate packets are accepted while the directionality property is not compromised.
したがって、EFP-uRPFメソッドは、（実行可能パスuRPFと比較して）より正確な方法でカスタマーインターフェイスの実行可能パスを収集するため、方向性プロパティが損なわれることなくすべての正当なパケットが受け入れられます。
The above-described EFP-uRPF method is recommended to be applied on customer interfaces. It can also be extended to create the RPF lists for lateral peer interfaces. That is, the EFP-uRPF method can be applied (and loose uRPF avoided) on lateral peer interfaces. That will help to avoid compromising directionality for lateral peer interfaces (which is inevitable with loose uRPF; see Section 2.4).
上記のEFP-uRPF方式は、カスタマーインターフェイスに適用することをお勧めします。これを拡張して、ラテラルピアインターフェイスのRPFリストを作成することもできます。つまり、EFP-uRPF方式をラテラルピアインターフェイスに適用できます（緩いuRPFを回避できます）。これは、ラテラルピアインターフェイスの方向性を損なうのを防ぐのに役立ちます（これは緩いuRPFでは避けられません。2.4を参照してください）。
Looking back at Scenarios 1 and 2 (Figures 1 and 2), the EFP-uRPF method works better than the other uRPF methods. Scenario 3 (Figure 3) further illustrates the enhanced feasible-path uRPF method with a more concrete example. In this scenario, the focus is on operation of the EFP-uRPF at ISP4 (AS4). ISP4 learns a route for prefix P1 via a C2P interface from customer ISP2 (AS2). This route for P1 has origin AS1. ISP4 also learns a route for P2 via another C2P interface from customer ISP3 (AS3). Additionally, AS4 learns a route for P3 via a lateral P2P interface from ISP5 (AS5). Routes for all three prefixes have the same origin AS (i.e., AS1). Using the enhanced feasible-path uRPF scheme and given the commonality of the origin AS across the routes for P1, P2, and P3, AS4 includes all of these prefixes in the RPF list for the customer interfaces (from AS2 and AS3).
シナリオ1と2（図1と2）を振り返ると、EFP-uRPFメソッドは他のuRPFメソッドよりもうまく機能します。シナリオ3（図3）は、より具体的な例を使用して、拡張された実行可能パスuRPFメソッドをさらに示しています。このシナリオでは、ISP4（AS4）でのEFP-uRPFの操作に焦点が当てられています。 ISP4は、顧客ISP2（AS2）からのC2Pインターフェイスを介して、プレフィックスP1のルートを学習します。 P1のこのルートには、発信元AS1があります。 ISP4は、顧客ISP3（AS3）からの別のC2Pインターフェースを介してP2のルートも学習します。さらに、AS4は、ISP5（AS5）からのラテラルP2Pインターフェイスを介してP3のルートを学習します。 3つのプレフィックスすべてのルートは、同じ起点AS（つまり、AS1）を持っています。拡張された実行可能パスuRPFスキームを使用し、P1、P2、およびP3のルート全体でオリジンASの共通性が与えられた場合、AS4は、これらのプレフィックスのすべてをカスタマーインターフェイスのRPFリストに含めます（AS2およびAS3から）。
+----------+ P3[AS5 AS1] +------------+
| AS4(ISP4)|<---------------| AS5(ISP5) |
+----------+ (P2P) +------------+
/\ /\ /\
/ \ /
P1[AS2 AS1]/ \P2[AS3 AS1] /
(C2P)/ \(C2P) /
/ \ /
+----------+ +----------+ /
| AS2(ISP2)| | AS3(ISP3)| /
+----------+ +----------+ /
/\ /\ /
\ / /
P1[AS1]\ /P2[AS1] /P3[AS1]
(C2P)\ /(C2P) /(C2P)
\ / /
+----------------+ /
| AS1(customer) |/
+----------------+
P1, P2, P3 (prefixes originated)
Consider that data packets (sourced from AS1) may be received at AS4 with a source address in P1, P2, or P3 via any of the neighbors (AS2, AS3, AS5): * Feasible-path uRPF fails * Loose uRPF works (but not desirable) * Enhanced feasible-path uRPF works best
AS1から送信されたデータパケットが、ネイバー（AS2、AS3、AS5）のいずれかを経由して、P1、P2、またはP3のソースアドレスとともにAS4で受信される可能性があることを考慮してください。望ましくない）*拡張実行可能パスuRPFが最適に機能する
Figure 3: Scenario 3 for Illustration of Efficacy of uRPF Schemes
図3：uRPFスキームの有効性を示すシナリオ3
The underlying algorithm in the solution method described above (Section 3.1) can be specified as follows (to be implemented in a transit AS):
上記（3.1節）で説明した解法の基礎となるアルゴリズムは、次のように指定できます（トランジットASに実装する）。
1. Create the set of unique origin ASes considering only the routes in the Adj-RIBs-In of customer interfaces. Call it Set A = {AS1, AS2, ..., ASn}.
1. カスタマーインターフェイスのAdj-RIBs-Inのルートのみを考慮して、一意の発信元ASのセットを作成します。それをSet A = {AS1、AS2、...、ASn}と呼びます。
2. Considering all routes in Adj-RIBs-In for all interfaces (customer, lateral peer, and transit provider), form the set of unique prefixes that have a common origin AS1. Call it Set X1.
2. すべてのインターフェイス（顧客、ラテラルピア、および中継プロバイダー）のAdj-RIBs-Inのすべてのルートを考慮して、共通の発信元AS1を持つ一意のプレフィックスのセットを形成します。セットX1と呼びます。
3. Include Set X1 in the RPF list on all customer interfaces on which one or more of the prefixes in Set X1 were received.
3. セットX1の1つ以上のプレフィックスが受信されたすべてのカスタマーインターフェイスのRPFリストにセットX1を含めます。
4. Repeat Steps 2 and 3 for each of the remaining ASes in Set A (i.e., for ASi, where i = 2, ..., n).
4. セットAの残りのASごとに手順2と3を繰り返します（つまり、ASiの場合、i = 2、...、n）。
The above algorithm can also be extended to apply the EFP-uRPF method to lateral peer interfaces. However, it is left up to the operator to decide whether they should apply the EFP-uRPF or loose uRPF method on lateral peer interfaces. The loose uRPF method is recommended to be applied on transit provider interfaces.
上記のアルゴリズムを拡張して、EFP-uRPFメソッドをラテラルピアインターフェイスに適用することもできます。ただし、ラテラルピアインターフェイスにEFP-uRPFまたはルーズuRPFのどちらの方法を適用するかは、オペレーターの判断に任されています。緩やかなuRPFメソッドは、トランジットプロバイダーインターフェイスに適用することをお勧めします。
The following operational recommendations will make the operation of the enhanced feasible-path uRPF robust:
次の運用上の推奨事項により、拡張実現可能パスuRPFの運用が堅牢になります。
For multihomed stub AS:
マルチホームスタブASの場合：
* A multihomed stub AS should announce at least one of the prefixes it originates to each of its transit provider ASes. (It is understood that a single-homed stub AS would announce all prefixes it originates to its sole transit provider AS.)
* マルチホームのスタブASは、発信元のプレフィックスの少なくとも1つを各トランジットプロバイダーASに通知する必要があります。 （シングルホームスタブASは、発信元のすべてのプレフィックスをその唯一のトランジットプロバイダーASにアナウンスすることが理解されています。）
For non-stub AS:
非スタブASの場合：
* A non-stub AS should also announce at least one of the prefixes it originates to each of its transit provider ASes.
* 非スタブASは、発信トランジットASのそれぞれに発信するプレフィックスの少なくとも1つもアナウンスする必要があります。
* Additionally, from the routes it has learned from customers, a non-stub AS SHOULD announce at least one route per origin AS to each of its transit provider ASes.
* さらに、非スタブASは、顧客から学習したルートから、起点ASごとに少なくとも1つのルートを各トランジットプロバイダーASに通知する必要があります（SHOULD）。
It should be observed that in the absence of ASes adhering to above recommendations, the following example scenario, which poses a challenge for the enhanced feasible-path uRPF (as well as for traditional feasible-path uRPF), may be constructed. In the scenario illustrated in Figure 4, since routes for neither P1 nor P2 are propagated on the AS2-AS4 interface (due to the presence of NO_EXPORT Community), the enhanced feasible-path uRPF at AS4 will reject data packets received on that interface with source addresses in P1 or P2. (For a little more complex example scenario, see slide #10 in [Sriram-URPF].)
上記の推奨事項に準拠したASがない場合、拡張された実行可能パスuRPF（および従来の実行可能パスuRPF）に課題をもたらす次のシナリオ例が構築される可能性があることに注意してください。図4に示すシナリオでは、P1とP2のどちらのルートもAS2-AS4インターフェースで伝搬されないため（NO_EXPORTコミュニティが存在するため）、AS4の拡張された実行可能パスuRPFは、そのインターフェースで受信されたデータパケットを拒否します。 P1またはP2の送信元アドレス。 （もう少し複雑な例のシナリオについては、[Sriram-URPF]のスライド＃10を参照してください。）
+----------+
| AS4(ISP4)|
+----------+
/\ /\
/ \ P1[AS3 AS1]
P1 and P2 not / \ P2[AS3 AS1]
propagated / \ (C2P)
(C2P) / \
+----------+ +----------+
| AS2(ISP2)| | AS3(ISP3)|
+----------+ +----------+
/\ /\
\ / P1[AS1]
P1[AS1] NO_EXPORT \ / P2[AS1]
P2[AS1] NO_EXPORT \ / (C2P)
(C2P) \ /
+----------------+
| AS1(customer) |
+----------------+
P1, P2 (prefixes originated)
Consider that data packets (sourced from AS1) may be received at AS4 with a source address in P1 or P2 via AS2: * Feasible-path uRPF fails * Loose uRPF works (but not desirable) * Enhanced feasible-path uRPF with Algorithm A fails * Enhanced feasible-path uRPF with Algorithm B works best
AS2経由でP1またはP2のソースアドレスを持つデータパケット（AS1からソース）がAS4で受信される可能性があることを考慮してください。*実行可能パスuRPFが失敗します。 *アルゴリズムBによる拡張された実行可能パスuRPFが最もよく機能する
Figure 4: Illustration of a Challenging Scenario
図4：困難なシナリオの図
3.4. Algorithm B: Enhanced Feasible-Path uRPF with Additional Flexibility across Customer Cone
3.4. アルゴリズムB：カスタマーコーン全体の柔軟性を向上させた拡張可能なパスuRPF
Adding further flexibility to the enhanced feasible-path uRPF method can help address the potential limitation identified above using the scenario in Figure 4 (Section 3.3). In the following, "route" refers to a route currently existing in the Adj-RIBs-In. Including the additional degree of flexibility, the modified algorithm called Algorithm B (implemented in a transit AS) can be described as follows:
拡張された実行可能パスuRPFメソッドにさらに柔軟性を追加すると、図4（セクション3.3）のシナリオを使用して、上記で特定された潜在的な制限に対処できます。以下の「ルート」とは、Adj-RIBs-Inに現在存在するルートを指します。追加の柔軟性を含め、アルゴリズムBと呼ばれる変更されたアルゴリズム（トランジットASで実装）は次のように説明できます。
1. Create the set of all directly connected customer interfaces. Call it Set I = {I1, I2, ..., Ik}.
1. 直接接続されているすべてのカスタマーインターフェイスのセットを作成します。それをSet I = {I1、I2、...、Ik}と呼びます。
2. Create the set of all unique prefixes for which routes exist in Adj-RIBs-In for the interfaces in Set I. Call it Set P = {P1, P2, ..., Pm}.
2. セットIのインターフェイスのAdj-RIBs-Inにルートが存在するすべての一意のプレフィックスのセットを作成します。これをSet P = {P1、P2、...、Pm}と呼びます。
3. Create the set of all unique origin ASes seen in the routes that exist in Adj-RIBs-In for the interfaces in Set I. Call it Set A = {AS1, AS2, ..., ASn}.
3. セットIのインターフェースのAdj-RIBs-Inに存在するルートにあるすべての一意の起点ASのセットを作成します。これをSet A = {AS1、AS2、...、ASn}と呼びます。
4. Create the set of all unique prefixes for which routes exist in Adj-RIBs-In of all lateral peer and transit provider interfaces such that each of the routes has its origin AS belonging in Set A. Call it Set Q = {Q1, Q2, ..., Qj}.
4. すべてのラテラルピアおよび中継プロバイダーインターフェイスのAdj-RIBs-Inにルートが存在するすべての一意のプレフィックスのセットを作成します。これにより、ルートのそれぞれがセットAに属している発信元ASを持ちます。これをセットQ = {Q1、Q2、 ...、Qj}。
5. Then, Set Z = Union(P,Q) is the RPF list that is applied for every customer interface in Set I.
5. 次に、セットZ = Union（P、Q）は、セットIのすべてのカスタマーインターフェイスに適用されるRPFリストです。
When Algorithm B (which is more flexible than Algorithm A) is employed on customer interfaces, the type of limitation identified in Figure 4 (Section 3.3) is overcome and the method works. The directionality property is minimally compromised, but the proposed EFP-uRPF method with Algorithm B is still a much better choice (for the scenario under consideration) than applying the loose uRPF method, which is oblivious to directionality.
アルゴリズムB（アルゴリズムAよりも柔軟）が顧客のインターフェースで採用されている場合、図4（セクション3.3）で特定されたタイプの制限は克服され、メソッドは機能します。方向性のプロパティへの影響は最小限に抑えられていますが、提案されているアルゴリズムBのEFP-uRPF方法は、方向性に気付かれないルーズuRPF方法を適用するよりも（検討中のシナリオでは）はるかに優れた選択肢です。
So, applying the EFP-uRPF method with Algorithm B is recommended on customer interfaces for the challenging scenarios, such as those described in Section 3.3.
したがって、セクション3.3で説明されているような困難なシナリオでは、アルゴリズムBを使用してEFP-uRPFメソッドを適用することを顧客インターフェイスに推奨します。
It is worth emphasizing that an indirect part of the proposal in this document is that RPF filters may be augmented from secondary sources. Hence, the construction of RPF lists using a method proposed in this document (Algorithm A or B) can be augmented with data from Route Origin Authorization (ROA) [RFC6482], as well as Internet Routing Registry (IRR) data. Special care should be exercised when using IRR data because it is not always accurate or trusted. In the EFP-uRPF method with Algorithm A (see Section 3.1.1), if a ROA includes prefix Pi and ASj, then augment the RPF list of each customer interface on which at least one route with origin ASj was received with prefix Pi. In the EFP-uRPF method with Algorithm B, if ASj belongs in Set A (see Step #3 Section 3.4) and if a ROA includes prefix Pi and ASj, then augment the RPF list Z in Step 5 of Algorithm B with prefix Pi. Similar procedures can be followed with reliable IRR data as well. This will help make the RPF lists more robust about source addresses that may be legitimately used by customers of the ISP.
このドキュメントの提案の間接的な部分は、RPFフィルターが二次ソースから拡張される可能性があるということを強調する価値があります。したがって、このドキュメントで提案されている方法（アルゴリズムAまたはB）を使用したRPFリストの構築は、Route Origin Authorization（ROA）[RFC6482]からのデータとインターネットルーティングレジストリ（IRR）データで補強できます。 IRRデータは常に正確または信頼できるとは限らないため、IRRデータを使用するときは特別な注意が必要です。アルゴリズムAを使用するEFP-uRPFメソッド（セクション3.1.1を参照）で、ROAに接頭辞PiおよびASjが含まれている場合、元のASjを持つ少なくとも1つのルートが接頭辞Piで受信された各カスタマーインターフェイスのRPFリストを拡張します。アルゴリズムBを使用するEFP-uRPFメソッドで、ASjがセットAに属している場合（ステップ＃3セクション3.4を参照）、ROAにプレフィックスPiとASjが含まれている場合は、アルゴリズムBのステップ5でRPFリストZにプレフィックスPiを追加します。同様の手順は、信頼性の高いIRRデータでも追跡できます。これは、ISPの顧客が合法的に使用する可能性のあるソースアドレスに関するRPFリストをより堅牢にするのに役立ちます。
The existing RPF checks in edge routers take advantage of existing line card implementations to perform the RPF functions. For implementation of the enhanced feasible-path uRPF, the general necessary feature would be to extend the line cards to take arbitrary RPF lists that are not necessarily the same as the existing FIB contents. In the algorithms (Sections 3.1.1 and 3.4) described here, the RPF lists are constructed by applying a set of rules to all received BGP routes (not just those selected as best path and installed in the FIB). The concept of uRPF querying an RPF list (instead of the FIB) is similar to uRPF querying a VRF table (see Section 2.5).
エッジルータの既存のRPFチェックは、既存のラインカード実装を利用してRPF機能を実行します。拡張された実行可能パスuRPFの実装の場合、一般的に必要な機能は、ラインカードを拡張して、必ずしも既存のFIBの内容と同じではない任意のRPFリストを取得することです。ここで説明するアルゴリズム（セクション3.1.1および3.4）では、RPFリストは、受信したすべてのBGPルート（ベストパスとして選択され、FIBにインストールされているものだけではない）に一連のルールを適用することによって構築されます。 uRPFが（FIBの代わりに）RPFリストを照会する概念は、VRPテーブルを照会するuRPFに似ています（2.5項を参照）。
The techniques described in this document require that there should be additional memory (i.e., ternary content-addressable memory (TCAM)) available to store the RPF lists in line cards. For an ISP's AS, the RPF list size for each line card will roughly equal the total number of originated prefixes from ASes in its customer cone (assuming Algorithm B in Section 3.4 is used). (Note: EFP-uRPF with Algorithm A (see Section 3.1.1) requires much less memory than EFP-uRPF with Algorithm B.)
このドキュメントで説明されている手法では、RPFリストをラインカードに格納するために使用できる追加のメモリ（つまり、3値連想メモリ（TCAM））が必要です。 ISPのASの場合、各ラインカードのRPFリストサイズは、カスタマーコーン内のASからの発信プレフィックスの総数とほぼ同じです（セクション3.4のアルゴリズムBが使用されていると想定）。 （注：アルゴリズムAを使用したEFP-uRPF（セクション3.1.1を参照）は、アルゴリズムBを使用したEFP-uRPFよりも必要なメモリがはるかに少なくなります。）
The following table shows the measured customer cone sizes in number of prefixes originated (from all ASes in the customer cone) for various types of ISPs [Sriram-RIPE63]:
次の表は、さまざまなタイプのISP [Sriram-RIPE63]について、（カスタマーコーンのすべてのASから）生成されたプレフィックスの数で測定されたカスタマーコーンサイズを示しています。
+------------+---------------------------------------+
| Type of | Measured Customer Cone Size in # |
| ISP | Prefixes (in turn this is an estimate |
| | for RPF list size on the line card) |
+============+=======================================+
| Very Large | 32393 |
| Global ISP | |
| #1 | |
+------------+---------------------------------------+
| Very Large | 29528 |
| Global ISP | |
| #2 | |
+------------+---------------------------------------+
| Large | 20038 |
| Global ISP | |
+------------+---------------------------------------+
| Mid-size | 8661 |
| Global ISP | |
+------------+---------------------------------------+
| Regional | 1101 |
| ISP (in | |
| Asia) | |
+------------+---------------------------------------+
Table 1: Customer Cone Sizes (# Prefixes) for Various Types of ISPs
表1：さまざまなタイプのISPのカスタマーコーンサイズ（＃プレフィックス）
For some super large global ISPs that are at the core of the Internet, the customer cone size (# prefixes) can be as high as a few hundred thousand [CAIDA], but uRPF is most effective when deployed at ASes at the edges of the Internet where the customer cone sizes are smaller, as shown in Table 1.
インターネットのコアにあるいくつかの超大規模なグローバルISPの場合、顧客のコーンサイズ（＃プレフィックス）は数十万[CAIDA]まで高くなることがありますが、uRPFは、表1に示すように、顧客のコーンサイズが小さいインターネット。
A very large global ISP's router line card is likely to have a FIB size large enough to accommodate 2 million routes [Cisco1]. Similarly, the line cards in routers corresponding to a large global ISP, a midsize global ISP, and a regional ISP are likely to have FIB sizes large enough to accommodate about 1 million, 0.5 million, and 100k routes, respectively [Cisco2]. Comparing these FIB size numbers with the corresponding RPF list size numbers in Table 1, it can be surmised that the conservatively estimated RPF list size is only a small fraction of the anticipated FIB memory size under relevant ISP scenarios. What is meant here by relevant ISP scenarios is that only smaller ISPs (and possibly some midsize and regional ISPs) are expected to implement the proposed EFP-uRPF method since it is most effective closer to the edges of the Internet.
非常に大規模なグローバルISPのルーターラインカードは、200万のルートを収容するのに十分な大きさのFIBサイズを持つ可能性があります[Cisco1]。同様に、大規模なグローバルISP、中規模のグローバルISP、およびリージョナルISPに対応するルーターのラインカードは、それぞれ約100万、50万、10万のルートに対応できる十分な大きさのFIBサイズを持つ可能性があります[Cisco2]。これらのFIBサイズの数値を表1の対応するRPFリストサイズの数値と比較すると、控えめに見積もられたRPFリストサイズは、関連するISPシナリオで予想されるFIBメモリサイズのごく一部にすぎないと推測できます。ここで関連するISPシナリオが意味することは、提案されたEFP-uRPF方式を実装することが期待されるのは、小規模なISP（およびおそらく中規模および地域のISP）のみであり、インターネットの端に近いほど効果的であるためです。
BGP routing announcements can exhibit transient behavior. Routes may be withdrawn temporarily and then reannounced due to transient conditions, such as BGP session reset or link failure recovery. To cope with this, hysteresis should be introduced in the maintenance of the RPF lists. Deleting entries from the RPF lists SHOULD be delayed by a predetermined amount (the value based on operational experience) when responding to route withdrawals. This should help suppress the effects due to the transients in BGP.
BGPルーティングアナウンスは一時的な動作を示すことがあります。ルートは一時的に撤回され、BGPセッションのリセットやリンク障害の回復などの一時的な状態が原因で再アナウンスされる場合があります。これに対処するには、RPFリストのメンテナンスにヒステリシスを導入する必要があります。 RPFリストからのエントリの削除は、ルートの撤回に応答する際に、所定の量（運用経験に基づく値）だけ遅延する必要があります（SHOULD）。これは、BGPの過渡現象による影響を抑えるのに役立ちます。
Depending on the scenario, an ISP or enterprise AS operator should follow one of the following recommendations concerning uRPF/SAV:
シナリオに応じて、ISPまたはエンタープライズASオペレーターは、uRPF / SAVに関する次の推奨事項のいずれかに従う必要があります。
1. For directly connected networks, i.e., subnets directly connected to the AS, the AS under consideration SHOULD perform ACL-based SAV.
1. 直接接続されたネットワーク、つまりASに直接接続されたサブネットの場合、検討中のASはACLベースのSAVを実行する必要があります（SHOULD）。
2. For a directly connected single-homed stub AS (customer), the AS under consideration SHOULD perform SAV based on the strict uRPF method.
2. 直接接続されたシングルホームスタブAS（顧客）の場合、検討中のASは、厳密なuRPFメソッドに基づいてSAVを実行する必要があります（SHOULD）。
3. For all other scenarios:
3. 他のすべてのシナリオの場合：
* The EFP-uRPF method with Algorithm B (see Section 3.4) SHOULD be applied on customer interfaces.
* アルゴリズムB（セクション3.4を参照）を使用するEFP-uRPFメソッドは、カスタマーインターフェイスに適用する必要があります（SHOULD）。
* The loose uRPF method SHOULD be applied on lateral peer and transit provider interfaces.
* ルーズuRPFメソッドは、ラテラルピアおよびトランジットプロバイダーインターフェイスに適用する必要があります（SHOULD）。
It is also recommended that prefixes from registered ROAs and IRR route objects that include ASes in an ISP's customer cone SHOULD be used to augment the pertaining RPF lists (see Section 3.5 for details).
また、ISPのカスタマーコーンにASを含む登録済みROAおよびIRRルートオブジェクトのプレフィックスを使用して、関連するRPFリストを拡張することをお勧めします（詳細については、セクション3.5を参照）。
The EFP-uRPF method with Algorithm A is not mentioned in the above set of recommendations. It is an alternative to EFP-uRPF with Algorithm B and can be used in limited circumstances. The EFP-uRPF method with Algorithm A is expected to work fine if an ISP deploying it has only multihomed stub customers. It is trivially equivalent to strict uRPF if an ISP deploys it for a single-homed stub customer. More generally, it is also expected to work fine when there is absence of limitations, such as those described in Section 3.3. However, caution is required for use of EFP-uRPF with Algorithm A because even if the limitations are not expected at the time of deployment, the vulnerability to change in conditions exists. It may be difficult for an ISP to know or track the extent of use of NO_EXPORT (see Section 3.3) on routes within its customer cone. If an ISP decides to use EFP-uRPF with Algorithm A, it should make its direct customers aware of the operational recommendations in Section 3.2. This means that the ISP notifies direct customers that at least one prefix originated by each AS in the direct customer's customer cone must propagate to the ISP.
アルゴリズムAを使用するEFP-uRPFメソッドは、上記の一連の推奨事項には記載されていません。アルゴリズムBを備えたEFP-uRPFの代替であり、限られた状況で使用できます。アルゴリズムAを使用するEFP-uRPFメソッドは、それを展開するISPにマルチホームのスタブ顧客しかいない場合、正常に機能すると予想されます。 ISPがシングルホームのスタブカスタマーに展開する場合、これは厳密なuRPFと同等です。より一般的には、セクション3.3で説明されているような制限がない場合にも正常に機能することが期待されます。ただし、EFP-uRPFをアルゴリズムAで使用する場合は、展開時に制限が想定されていなくても、条件が変化する脆弱性が存在するため、注意が必要です。 ISPが、顧客コーン内のルートでのNO_EXPORT（セクション3.3を参照）の使用範囲を把握または追跡することは困難な場合があります。 ISPがアルゴリズムAでEFP-uRPFを使用することを決定した場合、それは、直接顧客にセクション3.2の運用上の推奨事項を認識させる必要があります。これは、ISPがダイレクトカスタマーに、ダイレクトカスタマーのカスタマーコーン内の各ASから発信された少なくとも1つのプレフィックスをISPに伝播する必要があることを通知することを意味します。
On a lateral peer interface, an ISP may choose to apply the EFP-uRPF method with Algorithm A (with appropriate modification of the algorithm). This is because stricter forms of uRPF (than the loose uRPF) may be considered applicable by some ISPs on interfaces with lateral peers.
ラテラルピアインターフェイスでは、ISPはEFP-uRPFメソッドをアルゴリズムA（アルゴリズムを適切に変更）で適用することを選択できます。これは、（緩いuRPFよりも）より厳密な形式のuRPFが、ラテラルピアとのインターフェイス上の一部のISPによって適用可能であると見なされるためです。
The security considerations in BCP 38 [RFC2827] and RFC 3704 [RFC3704] apply for this document as well. In addition, if considering using the EFP-uRPF method with Algorithm A, an ISP or AS operator should be aware of the applicability considerations and potential vulnerabilities discussed in Section 3.7.1.
BCP 38 [RFC2827]およびRFC 3704 [RFC3704]のセキュリティに関する考慮事項は、このドキュメントにも適用されます。さらに、アルゴリズムAでEFP-uRPFメソッドの使用を検討する場合、ISPまたはASオペレーターは、セクション3.7.1で説明されている適用性の考慮事項と潜在的な脆弱性に注意する必要があります。
In augmenting RPF lists with ROA (and possibly reliable IRR) information (see Section 3.5), a trade-off is made in favor of reducing false positives (regarding invalid detection in SAV) at the expense of another slight risk. The other risk being that a malicious actor at another AS in the neighborhood within the customer cone might take advantage (of the augmented prefix) to some extent. This risk also exists even with normal announced prefixes (i.e., without ROA augmentation) for any uRPF method other than the strict uRPF. However, the risk is mitigated if the transit provider of the other AS in question is performing SAV.
ROA（および場合によっては信頼できるIRR）情報（セクション3.5を参照）を使用してRPFリストを拡張する際に、別のわずかなリスクを犠牲にして（SAVでの無効な検出に関する）誤検知を減らすことを優先します。もう1つのリスクは、カスタマーコーン内の近隣にある別のASの悪意のある俳優が（拡張されたプレフィックスの）ある程度利用する可能性があることです。このリスクは、厳密なuRPF以外のuRPFメソッドの通常のアナウンスされたプレフィックス（つまり、ROA拡張なし）でも存在します。ただし、問題のある他のASのトランジットプロバイダーがSAVを実行している場合、リスクは軽減されます。
Though not within the scope of this document, security hardening of routers and other supporting systems (e.g., Resource PKI (RPKI) and ROA management systems) against compromise is extremely important. The compromise of those systems can affect the operation and performance of the SAV methods described in this document.
このドキュメントの範囲外ではありますが、ルーターやその他のサポートシステム（Resource PKI（RPKI）やROA管理システムなど）のセキュリティに対するセキュリティの強化は、非常に重要です。これらのシステムの妥協は、このドキュメントで説明されているSAVメソッドの操作とパフォーマンスに影響を与える可能性があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[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。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IPソースアドレススプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<https：// www .rfc-editor.org / info / rfc2827>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC3704]ベイカー、F。およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、DOI 10.17487 / RFC3704、2004年3月、<https://www.rfc-editor.org/info/rfc3704 >。
[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] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<https://www.rfc-editor.org/info/rfc4271>。
[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>。
[CAIDA] CAIDA, "Information for AS 174 (COGENT-174)", October 2019, <https://spoofer.caida.org/as.php?asn=174>.
[CAIDA] CAIDA、「AS 174（COGENT-174）の情報」、2019年10月、<https://spoofer.caida.org/as.php?asn=174>。
[Cisco1] Cisco, "Internet Routing Table Growth Causes %ROUTING-FIB-4-RSRC_LOW Message on Trident-Based Line Cards", January 2014, <https://www.cisco.com/c/en/us/support/docs/routers/ asr-9000-series-aggregation-services-routers/116999- problem-line-card-00.html>.
[Cisco1] Cisco、「インターネットルーティングテーブルの増加によりTridentベースのラインカードで％ROUTING-FIB-4-RSRC_LOWメッセージが発生する」、2014年1月、<https://www.cisco.com/c/en/us/support/ docs / routers / asr-9000-series-aggregation-services-routers / 116999- problem-line-card-00.html>。
[Cisco2] Cisco, "Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide, Release 5.x (Chapter 15: 'Managing the Unicast RIB and FIB')", March 2018, <https://www.cisco.com/c/en/us/td/docs/switches/ datacenter/sw/5_x/nx-os/unicast/configuration/guide/l3_cli_nxos/ l3_NewChange.html>.
[Cisco2] Cisco、「Cisco Nexus 7000シリーズNX-OSユニキャストルーティングコンフィギュレーションガイド、リリース5.x（第15章：「ユニキャストRIBおよびFIBの管理」）」、2018年3月、<https://www.cisco.com / c / en / us / td / docs / switches / datacenter / sw / 5_x / nx-os / unicast / configuration / guide / l3_cli_nxos / l3_NewChange.html>。
[Firmin] Firmin, F., "The Evolved Packet Core", <https://www.3gpp.org/technologies/keywords-acronyms/100- the-evolved-packet-core>.
[Firmin] Firmin、F。、「The Evolved Packet Core」、<https://www.3gpp.org/technologies/keywords-acronyms/100- the-evolved-packet-core>。
[ISOC] Internet Society, "Addressing the challenge of IP spoofing", September 2015, <https://www.internetsociety.org/resources/doc/2015/ addressing-the-challenge-of-ip-spoofing/>.
[ISOC]インターネット協会、「IPスプーフィングの課題への対処」、2015年9月、<https://www.internetsociety.org/resources/doc/2015/addressing-the-challenge-of-ip-spoofing/>。
[Juniper] Juniper Networks, "Creating Unique VPN Routes Using VRF Tables", May 2019, <https://www.juniper.net/documentation/en_US/junos/topics/ topic-map/l3-vpns-routes-vrf-tables.html#id-understanding-virtual-routing-and-forwarding-tables>.
[ジュニパー]ジュニパーネットワークス、「VRFテーブルを使用した固有のVPNルートの作成」、2019年5月、<https://www.juniper.net/documentation/en_US/junos/topics/topic-map/l3-vpns-routes-vrf- tables.html＃id-understanding-virtual-routing-and-forwarding-tables>。
[Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and kc. claffy, "AS Relationships, customer cones, and validation", In Proceedings of the 2013 Internet Measurement Conference, DOI 10.1145/2504730.2504735, October 2013, <https://dl.acm.org/doi/10.1145/2504730.2504735>.
[ラッキー]ラッキー、M。、ハッファーカー、B。、ダムデア、A。、ジョッツァス、V.、kc。 claffy、「AS関係、顧客コーン、および検証」、2013年インターネット測定会議の議事録、DOI 10.1145 / 2504730.2504735、2013年10月、<https://dl.acm.org/doi/10.1145/2504730.2504735>。
[RFC4036] Sawyer, W., "Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management", RFC 4036, DOI 10.17487/RFC4036, April 2005, <https://www.rfc-editor.org/info/rfc4036>.
[RFC4036] Sawyer、W。、「加入者管理用のデータオーバーケーブルサービスインターフェイス仕様（DOCSIS）ケーブルモデムターミネーションシステムの管理情報ベース」、RFC 4036、DOI 10.17487 / RFC4036、2005年4月、<https：//www.rfc -editor.org/info/rfc4036>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https://www.rfc-editor.org/info / rfc4364>。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.
[RFC6482] Lepinski、M.、Kent、S.、D。Kong、「A Route for Route Origin Authorizations（ROAs）」、RFC 6482、DOI 10.17487 / RFC6482、2012年2月、<https：//www.rfc- editor.org/info/rfc6482>。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.
[RFC6811] Mohapatra、P.、Scudder、J.、Ward、D.、Bush、R。、およびR. Austein、「BGP Prefix Origin Validation」、RFC 6811、DOI 10.17487 / RFC6811、2013年1月、<https：/ /www.rfc-editor.org/info/rfc6811>。
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <https://www.rfc-editor.org/info/rfc7454>.
[RFC7454] Durand、J.、Pepelnjak、I。、およびG. Doering、「BGP Operations and Security」、BCP 194、RFC 7454、DOI 10.17487 / RFC7454、2015年2月、<https：//www.rfc-editor。 org / info / rfc7454>。
[SPAR-v4] IANA, "IANA IPv4 Special-Purpose Address Registry", <https://www.iana.org/assignments/iana-ipv4-special-registry/>.
[SPAR-v4] IANA、「IANA IPv4 Special-Purpose Address Registry」、<https://www.iana.org/assignments/iana-ipv4-special-registry/>。
[SPAR-v6] IANA, "IANA IPv6 Special-Purpose Address Registry", <https://www.iana.org/assignments/iana-ipv6-special-registry/>.
[SPAR-v6] IANA、「IANA IPv6 Special-Purpose Address Registry」、<https://www.iana.org/assignments/iana-ipv6-special-registry/>。
[Sriram-RIPE63] Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on a Router", Presented at RIPE 63 and at the SIDR WG meeting at IETF 83, March 2012, <http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf>.
[Sriram-RIPE63] Sriram、K。およびR. Bush、「Estimating CPU Cost of a BGPSEC on a Router」、RIPE 63およびSIDR WGミーティング、IETF 83、2012年3月、<http：//www.ietf .org / proceedings / 83 / slides / slides-83-sidr-7.pdf>。
[Sriram-URPF] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Filtering", Presented at the OPSEC WG meeting at IETF 101, March 2018, <https://datatracker.ietf.org/meeting/101/materials/ slides-101-opsec-draft-sriram-opsec-urpf-improvements-00>.
[Sriram-URPF] Sriram、K.、Montgomery、D。、およびJ. Haas、「Enhanced Feasible-Path Unicast Reverse Path Filtering」、IESEC 101でのOPSEC WGミーティングで発表、2018年3月、<https：// datatracker .ietf.org / meeting / 101 / materials / slides-101-opsec-draft-sriram-opsec-urpf-improvements-00>。
Acknowledgements
謝辞
The authors would like to thank Sandy Murphy, Alvaro Retana, Job Snijders, Marco Marzetti, Marco d'Itri, Nick Hilliard, Gert Doering, Fred Baker, Igor Gashinsky, Igor Lubashev, Andrei Robachevsky, Barry Greene, Amir Herzberg, Ruediger Volk, Jared Mauch, Oliver Borchert, Mehmet Adalier, and Joel Jaeggli for comments and suggestions. The comments and suggestions received from the IESG reviewers are also much appreciated.
著者は、サンディ・マーフィー、アルバロ・レタナ、ジョブ・スナイダース、マルコ・マルゼッティ、マルコ・ディトリ、ニック・ヒリアード、ガート・ドエリング、フレッド・ベイカー、イゴール・ガシンスキー、イゴール・ルバシェフ、アンドレイ・ロバチェフスキー、バリー・グリーン、アミール・ヘルツバーグ、ルーディガー・ボルクに感謝しますコメントと提案については、Jared Mauch、Oliver Borchert、Mehmet Adalier、およびJoel Jaeggli。 IESGレビュアーから寄せられたコメントや提案も大歓迎です。
Authors' Addresses
著者のアドレス
Kotikalapudi Sriram USA National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899 United States of America
Kotikalapudi Sriram USA National Institute of Standards and Technology 100 Bureau Drive Gaithersburg、MD 20899アメリカ合衆国
Email: ksriram@nist.gov
Doug Montgomery USA National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899 United States of America
ダグモンゴメリーアメリカ国立標準技術研究所100ビューロードライブゲイザースバーグ、MD 20899アメリカ合衆国
Email: dougm@nist.gov
Jeffrey Haas Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Jeffrey Haas Juniper Networks、Inc. 1133 Innovation Way Sunnyvale、CA 94089アメリカ合衆国
Email: jhaas@juniper.net