RFC 8704: 拡張フィージブル-パス・ユニキャスト・リバース・パス・フォワーディング

要旨

本文書では、送信元成り済まし(スプーフィング) (BCP 38を参照)の検出と軽減を目的としたユニキャスト・リバース・パス・フォワーディング(uRPF)技術(RFC 3704を参照)の必要性を確認し、その改善を提案する。厳密な(strict)uRPFは方向性に関して柔軟性に欠け、緩い(loose)uRPFは方向性を考慮せず、現在のフィージブル-パスuRPFは両者のバランスを取ろうとしている(RFC 3704を参照)。しかし、本文書で示すように、既存のフィージブル-パスuRPFは依然として不十分な点がある。本文書では、フィージブル-パスuRPF(RFC 3704)よりも方向性に関して(意味のある方法で)柔軟性の高い、拡張フィージブル-パスuRPF(EFP-uRPF)方式について説明する。提案されているEFP-uRPF方式は、送信元アドレス検証(SAV)における無効な検出に関する誤検知を大幅に削減することを目的としている。したがって、ISPがカスタマへのサービスを中断する可能性について抱える懸念を軽減し、uRPF技術の導入を促進することができる。なお、本文書はRFC 3704を更新するものである。

本文書の位置付け

本文書は、インターネットのベスト・カレント・プラクティスを文書化したものである。

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、<http://www.rfc-editor.org/info/rfc8704>で入手できる

著作権に関する通知

Copyright (c) 2020 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(<https://trustee.ietf.org/license-info>)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

送信元アドレス検証(SAV)とは、送信元アドレス(SA)の成り済ましの検出と軽減を指す[RFC2827]。本文書では、SAV用のユニキャスト・リバース・パス・フォワーディング(uRPF) 技術[RFC3704]の必要性を明確にし、その改善を提案する。厳密なuRPFは方向性に関して柔軟性がなく(定義については[RFC3704]を参照)、緩いuRPFは方向性を意識せず、現在のフィージブル-パスuRPFはこれら2つのバランスを取ろうとしている[RFC3704]。しかし、本文書で示しているように、既存のフィージブル-パスuRPFは依然として不十分な点がある。フィージブル-パスuRPFを使用しても、ISPは正当な送信元アドレスを持つカスタマのデータ・パケットを破棄してしまうのではないかと懸念することが多い。

本文書では、方向性に関して、フィージブル-パスuRPFよりも柔軟性(意味のある方法で)高めることを目的とした拡張フィージブル-パスuRPF(EFP-uRPF)技術について説明する。これは、同じオリジンASを持つ複数のプレフィックスに対するBGPアップデートが異なるインタフェース(ボーダー・ルータ)で受信した場合、それらのプレフィックスのいずれかの送信元アドレスを持つ受信データ・パケットは、それらのインタフェースのいずれかで受け入れなければならないという原則に基づいている(セクション3で説明)。いくつかの困難なISP-カスタマのシナリオ(セクション3.3を参照)については、本文書では、拡張フィージブル-パスuRPF技術(セクション3.4で提示)をさらに緩やかにしたバージョンについても説明する。実装と運用に関する考慮事項については、セクション3.6で説明する。

本文書全体を通して、検討対象の経路はプレフィックス・フィルタリング[RFC7454]と、場合によってはオリジン検証[RFC6811]に基づいて検証済みという前提である。

EFP-uRPF手法は、SAVの無効検出に関する誤検出を大幅に減らすことを目的としている。これにより、ISPがカスタマに対する偶発的なサービス中断という懸念を最小限に抑えつつ、uRPFの運用上の堅牢性と有効性が向上することが期待される。そして、ネットワーク全体でサービス拒否(DoS)や分散型DoS(DDoS)防止が実現できるため、uRPFの導入が促進されることが期待される。

1.1. 用語

リバース・パス・フォワーディング(RPF)リストは、あるインタフェースで受信したデータ・パケットの許可される送信元アドレスのプレフィックス・リストである。

本文書で検討するピアリング関係は、provider-to-customer (P2C)、customer-to-provider (C2P)、peer-to-peer (P2P)である。ここで、「プロバイダ」とはトランジット・プロバイダを指す。最初の2つはトランジット関係にある。P2Pリンク経由で接続したピアは、ラテラル・ピア(非トランジット)と呼ぶ。

AS Aのカスタマ・コーンとは、AとはP2Cリンクのみで接続され、Aから到達できるすべてのASのことである[Luckie]。

カスタマ・コーン

カスタマ・コーンとは、自身の顧客経路のみを通って辿り着くすべてのASをいう。図のAのカスタマコーンはA、B、C、D、E、Fであり、Bのカスタマ・コーンはB、D、Eであり、Cのカスタマ・コーンはC、E、Fである。

スタブASとは、カスタマやラテラル・ピアを持たないASをいう。本文書では、シングルホームのスタブASは、一つのトランジット・プロバイダを持つASを指し、マルチホーム・スタブASは複数(2つ以上)のトランジット・プロバイダを持つASを指す。

1.2. 要件言語

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

2. 既存の送信元アドレス検証技術のレビュー

成り済ましアドレスによるDoS/DDoS攻撃を軽減するために、様々な既存の技術がある[RFC2827] [RFC3704]。SAVは、ボーダー・ルータ、ケーブルモデム終端システム(CMTS)[RFC4036]、モバイル・ネットワークのパケット・データ・ネットワーク・ゲートウェイ(PDN-GW)[Firmin]などのネットワーク・エッジ・デバイスで実行される。イングレス・アクセス制御リスト(ACL)とuRPFは、SAVを実装するための技術である[RFC2827] [RFC3704] [ISOC]。

2.1. アクセス制御リストを使用したSAV

イングレス/エグレスACLは、着信/発信インターネット・プロトコル(IP)パケットの送信元アドレスに対して、許容できる(あるいは許容できない)プレフィックスをリストアップするためにメンテナンスする。フィルタリング基準を満たさない送信元アドレスを持つパケットはすべて破棄する。イングレス/エグレス・フィルタのACLは、常に最新の状態に保つためにメンテナンスが必要である。ACLの更新は、オペレータ主導の手動プロセスであるため、運用上困難または実行不可能である。

通常、アクセス集約デバイス(CMTS、PDN-GWなど)のエグレスACLは、カスタマ・ネットワークが接続されているインタフェースに関連付けられたアドレス空間(プレフィックス)からの送信元アドレスのみを許可する。イングレスACLは通常、ボーダー・ルータに配備され、送信元アドレスが成り済まされている場合(明らかに許可されていないプレフィックス・ブロック、IANA特殊用途プレフィックス[SPAR-v4] [SPAR-v6]、プロバイダ独自のプレフィックスなどに属している場合など)はイングレス・パケットを破棄する。

2.2. 厳密なユニキャスト・リバース・パス・フォワーディングを使用するSAV

注記: このセクションおよび以降のセクションの図(シナリオ)では、以下の用語を使用する:

• 「失敗」とは、正当な送信元アドレスを持つパケットを破棄することを意味する。
• 「動作する(しかし、望ましくない)」とは、正当な送信元アドレスを持つすべてのパケットを通過させるが、方向性を認識しないことを意味する。
• 「最適に動作する」とは、方向性をまったく(または最小限に抑えて)妥協することなく、正当な送信元アドレスを持つすべてのパケットを通過させることを意味する。
• Pi[ASn ASm ...]という表記は、プレフィックスPiと角括弧で囲まれたAS_PATHを持つBGPアップデートを表す。

厳密なuRPF方式では、フォワーディング情報ベース(FIB)が送信元アドレスを包含するプレフィックスを含み、そのプレフィックスに対するフォワーディング情報がパケットを受信したインタフェースを指す場合にのみ、ボーダー・ルータでのイングレス・パケットが受け入れられる。言い換えれば、送信元アドレスが宛先アドレスとして使用された場合のルーティングのためのリバース・パスは、パケットを受信したのと同じインタフェースを使用する必要がある。ネットワークがマルチホームで、経路がすべてのトランジット・プロバイダに対称的にアナウンスされず、データ・パケットの非対称ルーティングがある場合、この方式には限界があることはよく知られている。非対称ルーティングが発生するのは(図1を参照)、カスタマASがトランジット・プロバイダ(ISP-a)にプレフィックス(P1)をアナウンスし、別のトランジット・プロバイダ(ISP-b)には別のプレフィックス (P2)をアナウンスしている。そこで、2番目のプレフィックス(P2)の中に送信元アドレスを持つデータ・パケットをトランジット・プロバイダ(ISP-a)に、またはその逆にルーティングする場合に発生する。すると、AS1から直接AS2で受信したプレフィックスP2に送信元アドレスを持つデータ・パケットは破棄されてしまう。さらに、プレフィックスP1に送信元アドレスを持つデータ・パケットで、AS1から発信され、AS3を経由してAS2に到達したものも、AS2で破棄される。

図1: uRPFスキームの有効性を説明するシナリオ1

2.3. フィージブル-パス・ユニキャスト・リバース・パス・フォワーディングを使用したSAV

フィージブル-パスuRPF技術は、マルチホーミングの場合に、厳密なuRPFで明らかになった問題を部分的に克服するのに役立つ。フィージブル-パスuRPFは厳密なuRPFと似ているが、ベストパスのプレフィックスを挿入することに加えて、アナウンスされた代替経路のプレフィックスもRPFリストに追加する。この方法は、(a) 同じプレフィックスに対するアナウンス(優先度を下げるためにプレフィックスがいくつか追加される場合がある)が、すべてのトランジット・プロバイダに伝播し、フィージブル-パスuRPFチェックを実行する、(b) すべてのトランジット・プロバイダに対して、集約されたレス・スペシフィックなプレフィックスをアナウンスし、トラフィック・エンジニアリングの必要性に応じて、モア・スペシフィックなプレフィックス(レス・スペシフィックなプレフィックスでカバーされる)をさまざまなトランジット・プロバイダにアナウンスするかのいずれかを利用する。

例として、マルチホームのシナリオ(図2のシナリオ2を参照)では、カスタマASが両プレフィックス(P1、P2)の経路を両方のトランジット・プロバイダにアナウンスする場合(トラフィック・エンジニアリングに必要な場合は適切なプレフィックスを追加)、フィージブル-パスuRPF方式が機能する。このシナリオでフィージブル-パスuRPFが機能するのは、AS2とAS3においてカスタマ経路が、より短い非カスタマ経路よりも優先される場合のみであることに留意する。しかし、フィージブル-パスuRPF方式にも限界がある。限界の一つは、プレフィックスの伝播に関する前述の推奨事項(a)または(b)に従わない場合に当然のことながら存在する。

別の形の限界は、以下のように説明できる。シナリオ2(図2図示、ここで説明)では、2番目のトランジット・プロバイダ(ISP-bまたはAS3)がプレフィックスP1の先頭に追加された経路を最初のトランジット・プロバイダ(ISP-aまたはAS2)に伝播しない可能性がある。これは、AS3の決定ポリシーにより、カスタマ(AS1)から直接学習した長い経路よりも、ラテラル・ピア(AS2) を経由したプレフィックスP1への短い経路を優先することを許可しているためである。このようなシナリオでは、AS3はプレフィックスP1の経路アナウンスをAS2に送信しない(P2Pリンク経由)。すると、AS1から発信され、AS3経由でAS2に渡されるプレフィックスP1の送信元アドレスを持つデータ・パケットは、AS2で破棄されることになる。

図2: uRPFスキームの有効性を示すシナリオ2

2.4. 緩いユニキャスト・リバース・パス・フォワーディングを使用したSAV

緩いuRPF方式では、ボーダー・ルータでのイングレス・パケットは、FIBに送信元アドレスを含む1つ以上のプレフィックスがある場合にのみ受け入れられる。つまり、送信元アドレスの経路がFIBに存在しない場合、パケットを破棄する。緩いuRPFは方向性を犠牲にする。送信元アドレスが現在のFIBで到達不能な場合(例: IANAの特殊目的プレフィックス[SPAR-v4] [SPAR-v6]、未割り当て、割り当て済みだが現在ルーティングされていない)にのみパケットを破棄する。

2.5. VRFテーブルを使用したSAV

仮想ルーティングおよびフォワーディング(VRF)技術[RFC4364] [Juniper]により、ルータはグローバルなルーティング情報ベース(RIB)とは別に、複数のルーティング・テーブル・インスタンスを保持することができる。外部BGP(eBGP)ピアリング・セッションは、専用のVRFテーブルに格納する特定の経路を送信する。uRPFプロセスは、送信元アドレスの検証のために、(FIBではなく)VRFテーブルを照会する。VRFテーブルはeBGPピアごとに専用化し、そのピアだけのuRPFを使用することで、厳密なモードでの動作になる。インタフェースに緩いuRPFを実装する場合、対応するVRFテーブルはグローバルなもの、つまり、FIBと同じ経路を含むものになる。

3. 拡張フィージブル-パスuRPFを使用したSAV

3.1. 方式の説明

拡張フィージブル-パスuRPF(EFP-uRPF)方式は、セクション2で説明した既存のuRPF方式に、運用上の堅牢性と有効性を追加する。これは、正当なデータ・パケットの破棄や方向性の妥協を避けるためである。この方式は、同じオリジンASを持つ複数のプレフィックスのBGPアップデートが異なるインタフェース(ボーダー・ルータ)で受信した場合、それらのプレフィックスのいずれかの送信元アドレスを持つ着信データ・パケットは、そのインタフェースのいずれかで受け入れられなければならないという原則に基づいている。EFP-uRPF方式は、次の例で説明するのが最も分かりやすい。

例えば、Adj-RIBs-In[RFC4271]において、ISP-Aのボーダー・ルータがプレフィックス・セットQ1, Q2, Q3を持っており、それぞれのプレフィックスはAS-xをオリジンとし、AS-xはISP-Aのカスタマ・コーン内にあるとする。このプレフィックス・セットの中で、ボーダー・ルータはプレフィックスQ1の経路をカスタマ向けインタフェース経由で受信し、プレフィックスQ2とQ3の経路をそれぞれラテラル・ピアと上流のトランジット・プロバイダから学習した。この例のシナリオでは、拡張フィージブル-パスuRPF方式は、Q1、Q2、Q3が検討中のカスタマ向けインタフェースのRPFリストに含む必要がある。

したがって、EFP-uRPF方式は、フィージブル-パスuRPF方式と比較して、よりきめ細かな方法でカスタマ向けインタフェースのフィージブル-パスを収集するため、方向性プロパティが損なわれることなくすべての正当なパケットが受け入れられる。

上述のEFP-uRPF方式は、カスタマ向けインタフェースに適用することが推奨される。また、ラテラル・ピアのインタフェースのRPFリストを作成するように拡張することもできる。つまり、EFP-uRPF方式をラテラル・ピア向けインタフェースに適用(そして、緩いuRPFを回避)できる。これにより、ラテラル・ピア向けインタフェースの方向性が損なわれるのを防ぐことができる(これは緩いuRPFでは避けられない。セクション2.4を参照)。

シナリオ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はこれらのプレフィックスすべてをカスタマ向けインタフェース(AS2とAS3から)のRPFリストに含める。

図3: uRPFスキームの有効性を示すシナリオ3

3.1.1. アルゴリズムA: 拡張実行可能パスuRPF

上で説明した解決方法(セクション3.1)の基礎となるアルゴリズムは、以下のように規定できる(トランジットASで実装する):

1. カスタマ・インタフェースのAdj-RIBs-Inの経路のみを考慮して、ユニークなオリジンASセットを作成する。これをSet A = AS1, AS2, ..., ASnと呼ぶ。
2. すべてのインタフェース(カスタマ、ラテラル・ピア、トランジット・プロバイダ)のAdj-RIBs-Inにあるすべての経路を考慮し、共通のオリジンAS1を持つユニークなプレフィックス・セットを形成する。これをSet X1と呼ぶ。
3. Set X1に含まれる1つ以上のプレフィックスを受信しているすべてのカスタマ・インタフェースのRPFリストにSet X1を含める。
4. Set Aの残りの各ASに対して、手順2と3を繰り返す(つまり、ASiの場合、i = 2, ..., n)

上記のアルゴリズムは、ラテラル・ピアのインタフェースにEFP-uRPF方式を適用するように拡張することもできる。ただし、ラテラル・ピアのインタフェースにEFP-uRPF方式と緩いuRPF方式のどちらを適用するかは、オペレータの判断に委ねられている。トランジット・プロバイダのインタフェースには、緩いuRPF方式の適用が推奨される。

3.2. 運用に関する推奨事項

以下の運用上の推奨事項は、拡張フィージブル-パスuRPFの運用を堅牢にする。

マルチホームスタブASの場合:

• マルチホーム・スタブASは、そのトランジット・プロバイダASのそれぞれに発信した、少なくとも1つのプレフィックスをアナウンスしなければならない。(シングルホームのスタブASは、その唯一のトランジット・プロバイダASに発信するすべてのプレフィックスをアナウンスすると理解される。)

非スタブASの場合:

• 非スタブASは、各トランジット・プロバイダASに対して、少なくとも1つのプレフィックスをアナウンスする必要がある。
• さらに、顧客から学習した経路から、非スタブASは各トランジット・プロバイダASに対して、オリジンAS ごとに少なくとも1つの経路をアナウンスする必要がある(SHOULD)。

3.3. 困難なシナリオ

上記の推奨事項を順守するASが存在しない場合、拡張フィージブル-パスuRPF(従来のフィージブル-パスuRPF)にとって課題となる以下のシナリオ例が構築される可能性があることに留意する。図4に示すシナリオでは、AS2-AS4インタフェース上ではP1もP2も経路が伝播されないため(NO_EXPORTコミュニティが存在するため)、AS4の拡張フィージブル-パスuRPFは、そのインタフェースで受信したP1またはP2の送信元アドレスを持つデータ・パケットを拒否する。(もう少し複雑なシナリオ例については、[Sriram-URPF]のスライド#10を参照のこと。)

図4: 困難なシナリオの図解

3.4.アルゴリズムB: カスタマ・コーンにまたがる柔軟性を追加した拡張フィージブル-パスuRPF

拡張フィージブル-パスuRPF方式にさらなる柔軟性を追加することで、図4(セクション3.3)のシナリオを使用して、上記で特定した潜在的な限界に対処することができる。以下では、「経路」は、Adj-RIBs-Inに現在存在する経路を指す。追加の柔軟性を含めると、アルゴリズムB(トランジットASで実装)と呼ばれる修正アルゴリズムは、以下のように説明できる。

1. 直接接続されているすべてのカスタマ・インタフェース・セットを作成する。これをSet I = I1, I2, ..., Ikと呼ぶ。
2. セットIに含まれるインタフェースのAdj-RIBs-Inに経路が存在するユニークなプレフィックス・セットを作成する。これをセットP = P1、P2、...、Pmと呼ぶ。
3. セットIのインタフェースのAdj-RIBs-Inに存在する経路に見られる、すべてのユニークなオリジンASセットを作成する。これをセットA = AS1、AS2、...、ASnと呼ぶ。
4. すべてのラテラル・ピアおよびトランジット・プロバイダのインタフェースのAdj-RIBs-Inに存在するすべてのユニークなプレフィックス・セットを作成し、各経路のオリジンASがセットAに属するようにする。これをセットQ = Q1、Q2、...、Qjと呼ぶ。
5. そして、セットZ = Union(P,Q)は、セットIのすべてのカスタマ・インタフェースに適用されるRPFリストである。

カスタマ・インタフェースにアルゴリズムB(アルゴリズムA よりも柔軟性が高い)を適用すると、図4(セクション3.3)で特定された限界のタイプが克服され、この方法が機能する。方向性特性は最小限に妥協することになるが、方向性を無視する緩いuRPF方式を適用するよりも、アルゴリズムBを使用した提案されたEFP-uRPF方式の方が(検討中のシナリオの場合)、はるかに優れた選択肢である。

したがって、セクション3.3で説明しているような困難なシナリオのカスタマ・インタフェースにアルゴリズムBを使用したEFP-uRPF方式の適用を推奨する。

3.5. ROAとIRRデータによるRPFリストの補強

この文書における提案の副次的な部分は、RPFフィルタが二次ソースから拡張できる可能性があることを強調しておく。したがって、この文書で提案する方法(アルゴリズムAまたはB)を使用したRPFリストの作成は、経路オリジン認証(ROA)[RFC6482]のデータやインターネット・ルーティング・レジストリ(IRR)データも拡張に利用できる。IRRデータは必ずしも正確または信頼できるとは限らないため、IRRデータを使用する際には特別な注意が必要である。アルゴリズムAを使用したEFP-uRPF方式(セクション3.1.1を参照)では、ROAがプレフィックスPiとASjを含む場合、オリジンASjをプレフィックスPiとする経路を少なくとも1つ受信した各マスタマ・インタフェースのRPFリストを補強する。アルゴリズムBを使用したEFP-uRPF方式では、ASjがセットAに属し(セクション3.4のステップ#3を参照)、ROAがプレフィックスPiとASjを含む場合、アルゴリズムBのステップ5のRPFリストZにプレフィックスPiを補強する。信頼性の高いIRRデータでも同様の手順を行うことができる。これにより、ISPのカスタマが正当に使用する可能性のある送信元アドレスについて、RPFリストをより堅牢にするのに役立つ。

3.6. 実装と運用に関する考慮事項

3.6.1. FIBのメモリサイズ要件への影響

エッジ・ルータにおける既存のRPFチェックは、ラインカードの実装を利用してRPF機能を実行する。拡張フィージブル-パスuRPFの実装では、一般的に必要な機能は、既存のFIBの内容と必ずしも同じではない任意のRPFリストを取得できるよう、ラインカードを拡張することである。ここで説明するアルゴリズム(セクション3.1.1と3.4)では、RPFリストは受信したすべてのBGP経路(最適パスとして選択され、FIBにインストールされたものだけでない)にルール・セットを適用することで構築する。 (FIBの代わりに)RPFリストを照会するuRPFという概念は、VRFテーブルを照会するというuRPFと似ている(セクション2.5を参照)。

本文書で説明する手法では、ラインカードにRPFリストを格納するために追加のメモリ(つまり、三値連想メモリ(TCAM))が必要である。ISPのASの場合、各ラインカードのRPFリストのサイズは、そのカスタマ・コーン内のASからの発信プレフィックスの合計数とほぼ等しくなる(セクション3.4のアルゴリズムBが使用されていると仮定)。(注: アルゴリズムAを使用したEFP-uRPF(セクション3.1.1を参照)は、アルゴリズムBを使用したEFP-uRPFよりも必要なメモリが大幅に少なくなる。)

次の表は、さまざまな種類のISPについて、カスタマ・コーン内のすべてのASから発信されたプレフィックスの数で測定されたカスタマ・コーンのサイズを示している[Sriram-RIPE63]。

ISPの種類	測定されたカスタマ・コーンのサイズ(プレフィックス数) (これは、ラインカード上のRPFリストのサイズの推定値)
非常に大規模なグローバルISP#1	32393
非常に大規模なグローバルISP#2	29528
大手グローバルISP	20038
中規模グローバルISP	8661
地域ISP(アジア)	1101

表1: さまざまなタイプの ISPの顧客コーン・サイズ (プレフィックス数)

インターネットの中核をなす超大規模グローバルISPは、カスタマ・コーンのサイズ(プレフィックス数)が数十万にも達する[CAIDA]。しかし、uRPFは、表1に示すように、カスタマ・コーンのサイズが小さいインターネットのエッジに位置するASに導入するのが最も効果的である。

非常に大規模なグローバルISPのルータのラインカードは、200万の経路を収容できるほどのFIBサイズを持つ可能性が高い[Cisco1]。同様に、大規模なグローバルISP、中規模グローバルISP、地域ISPに対応するルータのラインカードは、それぞれ約100万、50万、10万経路を収容するのに十分なFIBサイズを持つ可能性が高い[Cisco2]。これらのFIBサイズ数値を表1の対応するRPFリストのサイズ数値と比較すると、控えめに見積もったRPFリストのサイズは、関連するISPシナリオの下で予想されるFIBメモリサイズのほんの一部にすぎないと推測できる。ここで関連するISPシナリオが意味するのは、提案するEFP-uRPF方式はインターネットのエッジに近いほど効果的であるため、小規模ISP(そして、おそらく一部の中規模および地域ISP)のみがこの方式を実装することが予想されるということである。

3.6.2. BGPの一時的な動作への対処

BGPルーティングのアナウンスは、一時的な動作を示すことがある。BGPセッションのリセットやリンク障害の回復などの過渡的な状況により、経路が一時的に撤回され、その後再びアナウンスされることがある。これに対処するには、RPFリストのメンテナンスにヒステリシス(履歴効果)を導入する必要がある。経路の撤回に対応する際、RPFリストのエントリ削除は、事前に決定された量(運用経験に基づく値)だけ遅延させるべきである(SHOULD)。これにより、BGPの一時的状況による影響を抑えることができるはずである。

3.7. 推奨事項の要約

シナリオに応じて、ISPやエンタープライズASオペレータは、uRPF/SAVに関する以下のいずれかの推奨事項に従うべきである。

1. 直接接続されたネットワーク、つまりASに直接接続されたサブネットの場合、検討中のASはACLベースのSAVを実行すべきである(SHOULD)。

2. 直接接続されたシングルホームのスタブAS(カスタマ)の場合、検討中のASは厳密なuRPF方式に基づいてSAVを実行すべきである(SHOULD)。

3. その他のシナリオの場合:

   • アルゴリズムBを使用したEFP-uRPF方式(セクション3.4を参照)をカスタマ・インタフェースに適用すべきである(SHOULD)。
   • 緩いuRPF方式は、ラテラル・ピアおよびトランジット・プロバイダのインタフェースに適用すべきである(SHOULD)。

また、ISPのカスタマ・コーン内のASを含む登録済みROAとIRR経路オブジェクトのプレフィックスを使用して、関連するRPFリストを補強することも推奨される(詳細についてはセクション3.5を参照)。

3.7.1. アルゴリズムAによるEFP-uRPF法の適用性

アルゴリズムAを使用したEFP-uRPF方式は、上記の推奨事項では言及されていない。これは、アルゴリズムBを使用したEFP-uRPFの代替方式であり、限られた状況で使用できる。アルゴリズムAを使用したEFP-uRPF方式は、それを導入するISPがマルチホームのスタブ・カスタマのみであれば、正常に動作すると予想される。ISPがシングルホームのスタブ・カスタマ向けにそれを導入する場合は、厳密なuRPFと同等である。より一般的には、セクション3.3で説明されているような限界がない場合にも、正常に動作することが予想される。しかし、導入時に限界が予想されなくても、状況の変化に対する脆弱性が存在するため、アルゴリズムAを使用した EFP-uRPFの使用には注意が必要である。ISPがカスタマ・コーン内の経路でNO_EXPORT (セクション3.3を参照)の使用範囲を把握または追跡することは難しいかも知れない。ISPがアルゴリズムAでEFP-uRPFを使用することを決定した場合、直接のカスタマにセクション3.2の運用上の推奨事項を知らせる必要がある。これは、直接のカスタマのカスタマ・コーン内の各ASが発信した少なくとも1つのプレフィックスがISPに伝播しなければならないことを通知することを意味する。

ISPは、ラテラル・ピアのインタフェースにおいて、アルゴリズムA(アルゴリズムを適切に変更)を使用したEFP-uRPF方式を適用することを選択できる。これは、一部のISPでは、ラテラル・ピアのインタフェースにおいて、より厳密なuRPF(緩いuRPFよりも)を適用できると考えられるためである。

4. セキュリティに関する考慮事項

BCP 38[RFC2827]およびRFC 3704[RFC3704]のセキュリティに関する考慮事項は、本文書にも適用される。さらに、アルゴリズムAでEFP-uRPF方式の使用を検討している場合、ISPまたはASオペレータは、3.7.1で説明した適用可能性の考慮事項と潜在的な脆弱性に留意する必要がある。

RPFリストをROA(およびおそらく信頼性の高いIRR)情報で補強する場合(セクション3.5を参照)、別のわずかなリスクを犠牲にして、誤検知(SAVの無効な検出に関して)を減らすというトレードオフが行われる。もう1つのリスクは、カスタマ・コーン内の近隣にある別のASにいる悪意あるアクターが、(補強されたプレフィックスを) ある程度利用するかも知れないということである。このリスクは、厳密なuRPF以外のuRPF方式では、通常のアナウンスされたプレフィックス(つまり、ROA補強なし)でも存在する。ただし、当該ASのトランジット・プロバイダがSAVを実行している場合には、このリスクは軽減される。

本文書の範囲外だが、ルータや他のサポート・システム(リソースPKI(RPKI)やROA管理システムなど)のセキュリティ侵害に対して強化することは非常に重要である。これらのシステムのセキュリティ侵害は、本文書で説明するSAV方法の動作と性能に影響を与える可能性がある。

5. IANAに関する考慮事項

本文書にはIANAアクションはない。

6. 参考文献

6.1. 引用規格

[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>.

[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>.

[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>.

[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>.

[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>.

6.2. 参考規格

[CAIDA] CAIDA, "Information for AS 174 (COGENT-174)", October 2019, <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>.

[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>.

[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/>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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/>.

[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-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>.

謝辞

サンディ・マーフィー、アルバロ・レタナ、ジョブ・スナイデルス、マルコ・マルツェッティ、マルコ・ディトリ、ニック・ヒリヤード、ゲルト・ドーリング、フレッド・ベイカー、イーゴリ・ガシンスキー、イゴール・ルバシェフ、アンドレイ・ロバチェフスキー、バリー・グリーン、アミール・ハーズバーグ、ルディガー・ヴォルク、ジャレッド・マウチ、オリバー・ボルヒャート、メフメット・アダリエ、ジョエル・ジェグリのコメントと提案に感謝する。IESGの査読者からのコメントと提案にも大いに感謝する。

著者のアドレス

コティカラプディ・スリラム
米国国立標準技術研究所
100 Bureau Drive
Gaithersburg, MD 20899
アメリカ合衆国
メールアドレス: <[e-mail]>

ダグ・モンゴメリー
米国国立標準技術研究所
100 Bureau Drive
Gaithersburg, MD 20899
アメリカ合衆国
メールアドレス: <[e-mail]>

ジェフリー・ハース
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089
アメリカ合衆国
メールアドレス: <[e-mail]>

更新履歴

• 2024.9.1