ID: ASPAオブジェクトに基づくBGP AS_PATH検証

https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/

要旨

本文書は、リソース公開鍵基盤(RPKI)のAutonomous System Provider Authorization (ASPA)オブジェクトを使用して、広告経路のボーダー・ゲートウェイ・プロトコル(BGP) AS_PATH属性を検証する手順を説明する。このタイプのAS_PATH検証は、経路漏洩と異常ASパスの検出と軽減を提供する。また、偽造オリジンや偽造パスセグメントによるプレフィックス・ハイジャックに対抗するある程度の保護も提供する。

本文書の位置付け

本インターネット・ドラフトは、BCP78およびBCP 79の規定に完全に準拠して提出されている。

インターネット・ドラフトは、Internet Engineering Task Force (IETF)の作業文書である。他のグループも作業文書をインターネット・ドラフトとして配布する場合がある。現在のインターネット・ドラフトの一覧は、https://datatracker.ietf.org/drafts/current/ にある。

インターネット・ドラフトは、最長6か月間有効なドラフト文書であり、いつでも更新、置き換え、または他の文書によって廃止される可能性がある。インターネット・ドラフトを参考資料として使用したり、「進行中の作業」以外の理由で引用することは不適切である。

このインターネット・ドラフトの有効期限は2024年9月1日である。

著作権表示

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

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

1. はじめに

最初に設計されたボーダー・ゲートウェイ・プロトコル(BGP)は、プレフィックス(または経路)ハイジャックやBGP経路漏洩に対して脆弱であることが知られている[RFC7908]。既存のBGP拡張機能の中には、この問題を部分的に解決できるものもある。例えば、リソース公開鍵基盤(RPKI)ベースの経路オリジン検証(RPKI-ROV) [RFC6480] [RFC6482] [RFC6811] [RFC9319]は、偶発的な発信元の誤りの検出とフィルタリングに使用できる。[RFC9234]または[ID.ietf-grow-route-leak-detection-mitigation]は、偶発的な経路漏洩の検出と軽減のために使用できる。RPKI-ROVは偶発的なプレフィックス・ハイジャックを防ぐことができるが、悪意のある偽造オリジン・プレフィックス・ハイジャックは依然として発生する可能性がある[RFC9319]。RFC9319には、偽造オリジン・プレフィックス・ハイジャックの攻撃対象領域を縮小するための推奨事項がいくつか含まれている。

本文書は、RPKIのAutonomous System Provider Authorization (ASPA)オブジェクト[ID.ietf-sidrops-aspa-profile]を使用して、広告経路のBGP AS_PATH属性のプロパティを検証する手順を説明する。ASPAベースのAS_PATH検証は、経路漏洩と異常ASパスの検出と軽減を提供する。また、偽造オリジンや偽造パス・セグメントによるプレフィックス・ハイジャックに対抗するある程度の保護を提供する(セクション8)。これらの新しいASPAベースの手順は、カスタマ、ラテラルピア([RFC7908]で定義)、トランジット・プロバイダ、IXP経路サーバ(RS)、RSクライアント、相互トランジットから受信するアナウンス中の異常AS_PATHを自動的に検出する。これらの手順(RPKI-ROVと合わせて)によって提供される保護は、暗号技術に基づいており、多くの偶発的および悪意のある行為に対して効果的である。

ASPAオブジェクトとは、カスタマとプロバイダの関係を暗号で署名して登録したもので、分散データベースに格納される[ID.ietf-sidrops-aspa-profile]。ASPAベースのパス検証は、段階的に導入可能な技術で、限定的な導入でも、アーリーアダプタにメリットを提供する。

この文書で説明する手順は、{AFI, SAFI}の組み合わせ、{AFI 1 (IPv4), SAFI 1}と{AFI 2 (IPv6), SAFI 1}[IANA-AF]を持つBGP経路のみ適用される。SAFI 1は、ユニキャスト転送に使用されるNLRIを表す[IANA-SAF]。

1.1. 異常の伝播

経路漏洩やハイジャックはどちらも、ISPの運用に同じような影響を与える。トラフィックをリダイレクトし、サービス拒否(DoS)、盗聴、遅延の増加、パケット損失を引き起こす可能性がある。しかし、リスクの度合いは、異常の伝播範囲に大きく依存する。例えば、カスタマにのみ伝播される経路漏洩やハイジャックは、特定のISPのカスタマコーン内でボトルネックを引き起こすかも知れないが、異常がラテラル(つまり、非・トランジット)ピアやトランジット・プロバイダを介して伝播したり、トランジット・フリーのネットワークを通じてグローバルに及んだ場合、その悪影響は増幅され、大陸を超えて味合うことになる。

異常の発信元のサポートがなくても(発信元に悪意がある場合は重要)、トランジット・プロバイダやラテラルピアへのBGP異常の伝播を制限する機能は、グローバルなドメイン間ルーティング・システムの堅牢性を大幅に向上させることができる。

1.2. 用語

本文書における「経路は不適格」という用語の使用は、[RFC4271]と同じ意味を持つ。つまり、「経路はLoc-RIBにインストールするのに不適格で、次の経路選択フェーズから除外される」という意味である。

簡潔さのため、本文書では「トランジット・プロバイダ」の代わりに「プロバイダ」という用語がしばしば使われる。それは同じ意味である。

1.3. 要件言語

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

2. BGPロール

この文書では、パス検証目的で、ASがネイバーASに対して持つことができるBGPロールは、カスタマ、プロバイダ、ラテラルピア、ルートサーバ(RS)、RSクライアント、そして相互トランジットである。相互トランジットを除くこれらの関係は[RFC9234]で定義されている。相互トランジットASは、すべて(カスタマの経路とカスタマ以外の経路の両方)を相互にエクスポートしてもよい(MAY)。つまり、互いをカスタマと見なす。相互トランジットASの場合、カスタマとプロバイダの関係は各方向に適用される。

すべてのロールはローカルに設定され、ASPAオブジェクトの登録(セクション3、セクション4)および/またはパス検証(セクション6)に使用される。BGP OPENメッセージのローカルBGPロールのアナウンス手順と、[RFC9234]で規定されているネイバー・ロールのクロスチェック(照合)手順が推奨される(RECOMMENDED)。このロールは[RFC9234]で規定されていないため、これらの手順は相互トランジット・ロールのクロスチェックには適用されない。

3. Autonomous System Provider Authorization

ASPAレコードは、プロバイダのAS番号一式をカスタマAS(CAS)番号に結び付けるデジタル署名されたオブジェクトであり、(BGPアナウンスの観点から)CASが署名する[ID.ietf -sidrops-aspa-profile]。ASPAは、CASがプロバイダAS一式(SPAS)を表明したことを証明し、IPv4とIPv6アドレスファミリー(つまり、AFI=1とAFI=2)、かつユニキャスト転送(SAFI=1)に使われるNetwork Layer Reachability Information (NLRI)にのみ適用される。プロバイダASの定義は、ASPAプロファイル・オブジェクト文書[ID.ietf-sidrops-aspa-profile]のセクション1 に記載されている。プロバイダASの役割は、CASの経路アナウンスをさらに先へ、すなわちプロバイダの上流プロバイダ、ラテラルピア、あるいはカスタマに伝播することにある。もう1つの役割は、アウトバウンド(カスタマからインターネット)・データ・トラフィックの接続をCASに提供することにある。

(AS x, {AS y1, AS y2, ...})という表記は、AS xを意味するCASのASPAオブジェクトを表すために使用される。この表記では、集合{AS y1, AS y2, ...}は、CAS(AS x)のプロバイダAS(SPAS)一式を表す。CASは、そのすべてのプロバイダASを列挙した一つのASPAを登録することが求められる(セクション4参照)。CASが1つのASPAを持つ場合、CASのSPASはそのASPAに列挙されているプロバイダAS一式である。CASが複数のASPAを持つ場合、SPASはCASのすべてのASPAに列挙されているプロバイダAS一式である。

Verified ASPA Payload(VAP)は、暗号的に検証された(すなわち、X.509有効 [RFC3779] [RFC5280]) ASPAオブジェクトのペイロードを指す。本文書で説明するASパス検証の手順(セクション5、セクション6)において、VAP-SPASは、考慮に入れるCASのVAPから派生したプロバイダAS一式を指す。

4. ASPA登録の推奨事項

プロバイダASとして、AS 0のみを示すASPAオブジェクトは、AS0 ASPAと呼ばれる。非・透過型ルートサーバAS(RS AS)とは、AS_PATHにそのAS番号を含むASをいう。AS0 ASPAの登録は、登録するASがトランジット・プロバイダを持たず、非・透過型RS ASのRSクライアントでもないことのステートメントである。このステートメントが真である場合、ASはAS 0 ASPAを登録しなければならない(MUST)。

通常、CASのプロバイダASは、アドレスファミリーの組み合わせ、{AFI 1 (IPv4), SAFI 1}と{AFI 2 (IPv6), SAFI 1}に適合する。これに対する例外は稀だと想定される。いずれの場合も、CASは上記のアドレスファミリーの組み合わせに適用されるすべてのプロバイダASの集合をSPASに列挙しなければならず(MUST)、RSクライアントである非・透過型RS ASも含めなければならない(MUST)。本文書で説明するASパス検証の手順(セクション5、セクション6)では、SPASは常に{AFI 1 (IPv4), SAFI 1}と{AFI 2 (IPv6), SAFI 1}に一律に適用されるものと見なされる。

ルートサーバAS(RS AS)を含む準拠ASはASPAを持たなければならない(MUST)。ASは複数のASPAを持たないほうがよい(SHOULD NOT)。RS ASはAS 0 ASPAを登録する必要がある(SHOULD)。

セクション3で述べたように、VAPに含まれるプロバイダAS一式は、ASPAを登録するASのVAP-SPASと呼ばれる。通常、VAP-SPASにはAS 0と他のプロバイダASの両方が含まれることは想定されていないが、AS 0が存在しても、ASパス検証手順に影響しない(セクション5、セクション6参照)。

相互トランジット・ペアの2つのASはそれぞれ、SPASに相手ASを含むASPAを登録しなければならない(MUST)。ペアのASの1つがこの登録を行い、もう一方のASが登録を行わない場合、そのペアを含む経路に対するASパス検証結果が不正確になるリスクが高まる。

ASコンフェデレーションの境界にあるASは、コンフェデレーションのグローバルASNをCASとして使用し、ASPAを登録しなければならない(MUST)。

前述したように、準拠ASは、非・透過型RS ASを含むすべてのプロバイダASを持つ1つのASPAオブジェクトを保持する必要がある。このような慣行は、プレフィックスの伝播に影響を与える可能性のある、ASPAの更新中の競合状態を防ぐのに役立つ。ASPAレコードのホスティングを提供するソフトウェアは、この慣行をサポートする必要がある(SHOULD)。異なる認証局(CA)レジストリ間の移行プロセス中、ASPAレコードは関連するすべてのレジストリで同一に保たれる必要がある(SHOULD)。

⚠️RSを含むASPA

5. ホップチェック関数

AS(i)とAS(j)がそれぞれAS_PATH 内の隣接する一意のASを表すとすると、(AS(i), AS(j))はASホップを表す。ホップチェック関数hop(AS(i), AS(j))は、ASNの順序対(ordered pair)、(AS(i), AS(j))において、AS(j)がAS(i)のVAP-SPASによるAS(i)の認証済みプロバイダというプロパティを持っているかどうかをチェックする。VAP-SPASテーブルは、(1) 指定されたCAS = AS(i)にエントリがある(つまり、SPASが列挙されている)か、または (2) (AS(i), AS(j))タプルについて、AS(j)がCAS = AS(i)に関連付けられたプロバイダとしてVAP-SPASに列挙されているかをチェックできるよう整理されていると仮定する。SPASに含まれるプロバイダのAS IDは、プロバイダ、非・透過型RS、または相互トランジット・ネイバーに対応する。非・透過型RSは、事実上、そのRSクライアントのプロバイダである。相互トランジット・ネイバーは、お互いをプロバイダと見なす(セクション4参照)。ホップチェック関数の定義における「Provider+」という用語は、プロバイダ、非・透過型RS、相互トランジット・ネイバーの3つの可能性をすべて包含することを意味している。この関数は以下のように規定する。

図1: ホップチェック関数

明確化のために言うと、この関数はAS(j)がAS(i)のVAP-SPASに含まれているかどうかをチェックする際、プロバイダ、非・透過型RS、相互トランジット・ネイバーを区別する必要はない。

「No Attestation」という結果は、CAS = AS(i)がVAP-SPASテーブルにエントリがない場合にのみ返される。これは、CASがASPAに登録されていないか、そのASPAが暗号的に有効ではない場合に発生する。ホップチェック関数は、セクション6.1およびセクション6.2で説明するASPAベースのAS_PATH検証アルゴリズムで使用する。

6. AS_PATHの検証

この文書で説明する手順は、4オクテットAS番号に対応するBGPスピーカー[RFC6793]にのみ適用される。このようなBGPスピーカーがUPDATEでAS_PATH属性とAS4_PATH属性の両方を受信した場合、手順は再構築されたASパスに適用される([RFC6793]のセクション4.2.3 )。したがって、この文書では、AS_PATHという用語は、通常のAS_PATH [RFC4271]と再構築されたASパスを指すために使用する。

攻撃者が意図的に経路漏洩を発生させようとする場合、AS_PATHからASを取り除こうとするかも知れない。それを部分的に防ぐには、AS_PATHに直近追加されたASとBGPネイバーのASNとの一致をチェックする必要がある。このチェックは、[RFC4271]のセクション6.3の規定に従って実行しなければならない(MUST)。チェックが失敗した場合、AS_PATHは不正なAS_PATHとみなされ、UPDATEはエラーとみなされる([RFC4271]のセクション6.3)。透過型RSの場合も適切に対処しなければならない(例えば、ネイバーASNのチェックを停止するなど)。AS_PATHが空(長さゼロ)の場合もチェックは失敗し、そのようなUPDATEもエラーとみなされる。

[ID.ietf-idr-deprecate-as-set-confed-set]は、AS_PATHにAS_SETが含まれる経路に対して、「Treat-as-withdraw」エラー処理[RFC7606]を適用する必要がある(SHOULD)と規定している。現行文書では、AS_PATH 検証手順 ( 6.1 節および6.2 節) において、AS_SET を含む経路は無効と評価される。無効なAS_PATHを持つ経路の処理方法については、セクション7を参照のこと。

⚠️ Treat-as-withdraw

Treat-as-withdrawとは、UPDATEメッセージの処理でエラーが発生した場合、BGPセッションをクローズするのではなく、エラーとなったUPDATEメッセージに含まれる経路を撤回(withdraw)扱いにすることをいう。

以下のセクション 6.1と6.2では、「アップストリームパス」および「ダウンストリームパス」という用語が、一般的に、それぞれ上流方向(カスタマまたはラテラルピアから) および下流方向 (プロバイダまたは相互トランジットピアから)で受信したASパスを指す。RSから経路を受信するRSクライアントは、アップストリームパスのアルゴリズムが適用される特別なケースである(セクション6.1)。

6.1. アップストリームパスのアルゴリズム

ここで説明するアップストリーム検証アルゴリズムは、経路をカスタマまたはラテラルピアから受信した場合、またはRSがRSクライアントから受信した場合、またはRSクライアントがRSから受信した場合に適用される。これらすべてのケースにおいて、受信/検証するeBGPルータは、AS_PATHがオリジンASからネイバーAS(直近追加された)への連続したcustomer-to-providerホップのみで構成されることを期待する。

⚠️ コメント

アップストリーム検証は、トランジット・プロバイダ、ラテラルピア、RS(ローカルASがRSクライアントの役割を持つ)、またはRSクライアント(ローカルASがRSの役割を持つ)で実行される。

ここで、アップストリーム検証アルゴリズムの基本原理を説明する。{AS(N), AS(N-1),..., AS(2), AS(1)}のシーケンスが一意のASNに関するAS_PATHを表すものとする。ここで、AS(1)はオリジンASで、AS(N)は最後に追加されたASで、受信/検証中のASのネイバーASである。AS_PATHが有効であるためには、このシーケンスのAS(i-1)からAS(i)への各ホップについて、ホップチェック関数hop(AS(i-1), AS(i))が「Provider+」(セクション5)に等しくなければならない。これらのホップのうち少なくとも1つでも、ホップチェック関数が「Not Provider+」である場合、AS_PATHは無効とみなされる。AS_PATHの検証結果が(上記の原則に従って)有効でも無効でもない場合、不明として評価する。

⚠️ アップストリームパス

右はバレーフリー違反の可能性がある。

アップストリームパスの検証手順は以下のように規定する。

1. AS_PATHにAS_SETがある場合、手順は「無効」という結果で停止する。

2. AS_PATHのAS_SEQUENCEのプリペンドを折り畳む(つまり、一意のAS番号だけを保持する)。結果として得られる順序付きシーケンスを{AS(N), AS(N-1), ..., AS(2), AS(1)}で表す。ここで、AS(1)は最初に追加された(つまり、オリジン)ASで、AS(N)は最後に追加されたASであり、受信/検証中ASのネイバーである。

3. N = 1の場合、手順は「有効」という結果で停止する。それ以外は、続行する。

4. このステップでは、N ≥ 2である。2 ≤ i ≤ Nのような i があり、hop(AS(i-1), AS(i)) = "Not Provider+"の場合、手順は「無効」という結果で停止する。それ以外は、続行する。

5. 2 ≤ i ≤ Nであり、hop(AS(i-1), AS(i)) = "No Attestation"であるような i が存在する場合、手順は「不明」という結果で停止する。それ以外は、手続き「有効」という結果で停止する。

⚠️ アップストリームパス検証例

アップストリームパスは、プロバイダ側のASパス検証に使われるものなので、ランプを考慮する必要はない。

6.2. ダウンストリームパスのアルゴリズム

ここで説明するダウンストリーム検証アルゴリズムは、トランジット・プロバイダまたは相互トランジット・ネイバーから経路を受信したときに適用される。セクション4で説明したように、送信側相互トランジットASは、受信側相互トランジットASに対して、プロバイダがカスタマに対して行うのと同様の動作をする。

必須ではないが、読者はここで説明するアルゴリズムをより明確に理解するため、[sriram1]の図と形式的証明を参照するといい。

ここでも (セクション6.1と同様)、AS_PATHを簡略化し、一意のASNの順序付きシーケンスを{AS(N), AS(N-1),...,AS(2), AS(1)}として表す。

1 <= N <= 2の場合、AS_PATHは自明のことながら有効である。

以下のセクション 6.2.1では、AS_PATHに3つ以上の一意のASN(N >= 3)が含まれていることを前提としている。

⚠️ ダウンストリームパス

6.2.1. ダウンストリームパス検証における無効、有効、不明の判定の原則 (N >= 3の場合)

無効なAS_PATHの判定:

前述の順序付けシーケンスを考慮すると、(1) u <= v、(2) hop(AS(u-1), AS(u)) = "Not Provider+"、(3) hop(AS(v+1), AS(v)) = "Not Provider+"となるようなインデックスuとvが存在する場合、AS_PATHは無効である。

⚠️ ダウンストリームパス検証

AS_PATH={N,.., 3, 2, 1}

hop(AS5, AS4) = "Not Provider+"

hop(AS7, AS6) = "Not Provider+"

------------

有効なAS_PATHの判定:

図2に示すように、AS_PATH内のASはシーケンス表現{AS(N), AS(N-1),..., AS(2), AS(1)}と同じ物理的(位置的)順序、つまり、AS(N)が左端で、AS(1)が右端と仮定する。

図2 :上りランプと下りランプの図

図2を見ると、UPDATEはプロバイダまたは相互トランジット・ネイバーから受信する(つまり、AS(N)は受信の役割を担う)。AS_PATHには、上りランプ(AS(1)をオリジンとする右側)と下りランプ (AS(N)をオリジンとする左側)の両方がある。ランプは、連続するcustomer-to-providerホップで構成されるASシーケンスとして表される。上りランプはAS(1)から始まり、その中の各ASホップ(AS(i), AS(i+1))は、i = 1, 2,... , K-1に対して、hop(AS(i), AS(i+1)) = "Provider+"という特性を持つ。そのようなKが存在しない場合、Kは1に設定される。hop(AS(K), AS(K+1)) = "Not Provider+"または"No Attestation"であるため、上りランプはAS(K)で終了する(頂点に達する)。下りランプはAS(N)からAS(L)へ逆方向に実行する。その中の各ASホップ(AS(j), AS(j-1))は、j = N, N-1,... , L+1に対して、hop(AS(j), AS(j-1))="Provider+"という特性を持つ。そのようなLが存在しない場合、LはNに設定される。 hop(AS(L), AS(L-1)) = "Not Provider+"または"No Attestation"であるため、下りランプはAS(L)で終了する。したがって、下りランプの頂点はAS(L)となる。

⚠️ コメント

• ASPAは部分展開が可能で、アップストリーム/ダウンストリームパス、(上り/下り)ランプを混同しないこと。アップストリーム/ダウンストリームはオリジンASから受信ASまでのBGP UPDATEの流れ、ランプは各ホップがASPA的に有効(カスタマ→プロバイダ)であるASパスを言う。
• 上りのランプは、オリジンあるいは近いASから上り方向のホップがProvider+である。上りのホップがNot ProviderやNo Attestationになった時点で、上り方向ではなくなったと解釈し、その前のASが頂点ということになる。
• 下りランプは、下りの方向なので終点から逆方向にhop関数を実行する(ASPA的には逆方向になることに注意)。結局、上り方向にhop関数を評価することとなり、上りランプ同様、上りのホップがNot ProviderやNo Attestationになった時点で、上り方向ではなくなったと解釈、そのASが下りランプの頂点となる。

AS_PATH内のAS全体が上りランプの場合 (つまり、K = N)、AS_PATHは明らかに有効である。同様に、AS_PATH内のAS全体が下りランプの場合(つまり、L = 1)、そのAS_PATHも有効である。しかし、K < N かつ L > 1 の AS_PATH に上りと下りランプが存在する場合、 L - K <= 1 の場合に限り、AS_PATHは有効となる。KがLより大きい可能性があることに注意すること(つまり、L - Kが負の値を持つ)。その場合、上りランプと下りランプがオーバーラップしていることを意味し、AS_PATH内の隣接AS間で相互トランジットの関係がある(つまり、お互いをそれぞれの SPASに含む)場合に起こり得る(セクション4参照)。L - K = 0の場合、上りランプと下りランプの頂点が同じASであることを意味する。L - K = 1の場合、頂点が隣接するASにあることを意味する。まとめると、AS_PATHは、L - K が 0または1、あるいは負の値の場合に有効である。

⚠️ ダウンストリームパス検証例

• K=Nは、アップストリームパスと思われる。
• L=1は、トランジット・プロバイダやRSから発信された経路のASパスと思われる。
• K < Nは上りランプの頂点から先が存在する、L > 1は下りランプの頂点から先が存在することを意味し、すなわち上りランプと下りランプが存在するASパスである。
• L - K = 0は、それぞれのランプの頂点(LとK)が同じASである。
• L - K = 1は、頂点が隣接ASである。
• L - Kが負の場合、上りランプと下りランプがオーバーラップしている。

------------

不明なAS_PATH の決定:

L - K >= 2の場合、AS_PATHは無効 (経路漏洩)または不明のどちらかである([sriram1]の図と証明を参照)。しかし、L - K >= 2で、このセクションで前述したプロセスで無効な結果が見つからなかった場合、AS_PATH は不明と判定される。

⚠️ コメント

L - K >= 2の場合、実際にはAS(K), AS(K+1),...., AS(L-1), AS(L)という部分パスと同じことである。部分パスは必ず無効か不明になる。そして、前述のu<vであるような、uとvが存在する場合は無効になる。

6.2.2. ダウンストリームパス検証の正式な手順

ダウンストリームパス検証手順は正式には次のように規定する。

1. AS_PATHにAS_SETがある場合、手順は「無効」という結果で停止する。

2. AS_PATH内のAS_SEQUENCEのプリペンドを折り畳む(つまり、一意のAS番号だけを保持する)。結果として得られた順序付きシーケンスを{AS(N), AS(N-1), ..., AS(2), AS(1)}で表す。ここで、AS(1)は最初に追加された(つまり、オリジン)ASで、AS(N)は最後に追加されたASであり、受信/検証ASのネイバーである。

3. 1 ≤ N ≤ 2の場合、手順は「有効」という結果で停止する。それ以外は続行する。

4. この段階では、N ≥ 3である。上記順序付けシーケンスを前提として、hop(AS(u-1), AS(u)) = "Not Provider+"となるuの最低値(2 ≤ u ≤ N)を求める。それをu_minと呼ぶ。そのような u_min が存在しない場合は、u_min = N+1とする。hop(AS(v+1), AS(v)) = "Not Provider+"となるvの最高値(N-1 ≥ v ≥ 1)を見つける。これをv_maxと呼ぶ。そのようなv_maxが存在しない場合は、v_max = 0とする。u_min ≤ v_maxの場合、手順は「無効」という結果で停止する。それ以外は続行する。

   ⚠️ コメント

   

5. 上りランプ: 2 ≤ i ≤ Nの場合、2 ≤ i ≤ Kの範囲内の各 i に対して hop(AS(i-1), AS(i)) = "Provider+"となる最大の Kを決定する。最大のKが存在しない場合は、K = 1とする。

6. 下りランプ: N-1 ≥ j ≥ 1の場合、N-1 ≥ j ≥ Lの範囲内の各 j に対してhop(AS(j+1), AS(j)) = "Provider+"となる最小の Lを決定する。最小のLが存在しない場合は、L = Nとする。

7. L-K ≤ 1の場合、手順は「有効」という結果で停止する。それ以外の場合は、手順は「不明」という結果で停止する。

上記の手順は、ステップ 4、5、6 の計算を同時に行うことができる。

⚠️ OpenBGPD

https://github.com/openbgpd-portable/openbgpd-openbsd/blob/master/src/usr.sbin/bgpd/rde_aspa.c

7. AS_PATHの検証と異常軽減に関する推奨事項

このセクションでは、eBGPルータのAS_PATH検証と異常軽減の推奨事項について説明する。この推奨事項は、外部ASに面するASコンフェデレーションの境界にある eBGP ルーターを含む、eBGPルータ全般に適用される。ただし、本文書のASPAベースのAS_PATH検証手順は、コンフェデレーション内部のeBGPリンクで使用することは推奨されない(NOT RECOMMENDED)。

この文書に記述されている検証手順は、{AFI, SAFI}の組み合わせ{AFI 1 (IPv4), SAFI 1}と{AFI 2 (IPv6), SAFI 1}[IANA-AF]を持つBGP経路に適用しなければならない(MUST) 。この手順をデフォルトで他のアドレスファミリーに適用してはならない[MUST NOT]。

7.1. 入口のeBGPルータでの検証と軽減

検証: 本仕様に準拠した実装は、セクション6.1およびセクション6.2で説明するとおり、AS_PATH 検証手順(段階的リスト)を正確に実装する必要はないが、これらの手順から生じる外的振る舞いと同等の機能を提供しなければならない(MUST)。言い換えれば、特定の実装で使用されるアルゴリズムは、例えば計算効率で異なるかも知れないが、AS_PATHの検証結果は、セクション6.1と6.2に記載されている手順によって得られる結果と同一でなければならない(MUST)。

軽減策: ここでは、導入された軽減ポリシーがネットワークオペレータの裁量によって設定されることを理解した上で、軽減策の推奨事項を規定する。AS_PATHが無効と判断された場合、その経路は経路選択に不適格(セクション1.2を参照)とみなす必要があり(SHOULD)、将来の再評価に備えてAdj-RIB-Inに保持しなければならない(MUST)([RFC9324]参照)。また、無効なAS_PATHを持つ経路についても、無効状態の原因を監視と診断の目的でログに記録する必要がある(SHOULD)。無効状態の原因は、ホップチェック関数によって「Not Provider+」と評価されたASホップをリスト形式にできる。不明なAS_PATHを持つ経路については、監視と診断の目的で不明状態の原因をログに記録する必要がある(SHOULD)。不明状態の原因は、ホップチェック関数によって「No Attestation」または「Not Provider+」と評価されたASホップをリスト形式にできる。

7.2. Only to Customer (OTC)属性

ASPAベースのAS_PATH検証方法(セクション7.1)は、AS_PATHにリストされている先行ASが引き起こした経路漏洩を検出して軽減するが、ローカルASで発生する経路漏洩を防ぐ機能は欠けている。そのギャップが埋めるのが、Only to Customer (OTC)属性[RFC9234]である。[RFC9234]で規定されているOTC属性を利用する手順は、本文書で説明する手順を補完するものである。ASPAベースのAS_PATH検証に加えて、これらの手順の実装が推奨される。

⚠️ コメント

1. v15では、「出口eBGPルータでの検証と軽減」というセクションがあったが、v16では削除されている。その理由は、不必要な複雑さを避けることにある。https://datatracker.ietf.org/meeting/117/materials/slides-117-sidrops-aspa-draft-update

   OTC属性は、ローカルASで発生する経路漏洩を十分に防ぐのに役立つ。

2. IBGPではASPA検証を行わない。その理由は、出口eBGPでASPAパス検証を行い、無効なASパスを拒否すれば十分だからだ。ASは、すべての境界ルータでRPKIデータの一貫したビューを維持することが期待される。ただし、IBGPでASPA検証が全く不要というわけではなく、RRなどではセキュリティを高めることができるという意見もある。IBGPのASPA検証は今後、検討される可能性がある。

3. 7.2にOTC属性(上記)を追加している。

8. ASPAベースのパス検証の特性

ASPAベースのパス検証手順は、カスタマ、ラテラルピア、トランジット・プロバイダ、RS、RSクライアント、相互トランジットから受信した経路をチェックできる。これらの手順をBGPロールとOTC属性[RFC9234]とRPKI-ROV[RFC6811] [RFC9319]を組み合わせることで、通常のプレフィックス・ハイジャック、経路漏洩、発信元が偽造あるいはパスセグメントが偽造されたプレフィックス・ハイジャックの多くを検出し、フィルタリングするための完全に自動化されたソリューションを提供できる(以下の特性3を参照)。

イングレスeBGPルータにおけるASPAベースのパス検証(セクション6、セクション7.1)には、以下のプロパティ(検出能力)がある:

プロパティ1: AS AとAS Bは、ASPA(登録とパス検証)を実行するインターネット上の任意の2つのASとし、他のASのASPA展開状況については仮定しないものとする。AS Aからカスタマまたはラテラルピアに伝播された経路を考える。この経路はその後、カスタマまたはラテラルピアの境界で、AS Bが受信する前に、ASパス内の加害ASが漏洩する。AS BにおけるASPAベースのパス検証は、漏洩の原因となったASを特定できないかも知れないが、常にこのような経路漏洩を検出する。このアサーションは、送信側AS A(または受信側AS B)がRS ASであり、AS Aが送信した(またはAS Bから受信した)ネイバーASがRSクライアントの場合にも当てはまる。

⚠️ コメント

プロパティ2: ここでも、AS AとAS BをASPA(登録とパス検証)を実行するインターネット上の任意の2つのASとし、他のASのASPA展開状況については仮定しないものとする。カスタマまたはラテラルピアの境界で、AS Bが受信した経路が、AS Aを偽造オリジンとする偽造オリジン・プレフィックス・ハイジャックである場合を考える。AS BでのASPAベースのパス検証は、常にこのような偽造オリジンのプレフィックス・ハイジャックを検出する。

⚠️ コメント

プロパティ3: これは、上記の特性2を、偽造パスセグメントによるプレフィックス・ハイジャックの場合に拡張したものである。このようなハイジャックとは、オリジンASから始まるASパスにおいて、連続する複数のASを偽造することを指す。ここでも、AS AとAS BをASPA(登録とパス検証)を実行しているインターネット上の任意の2つのASとする。AS AのプロバイダであるAS PとAS QもASPAを登録しているとする。インターネット上の他のASのASPA展開状況については仮定しない。カスタマまたはラテラルピアの境界で、AS Bが受信した経路が偽造パスセグメント{AS P, AS A}または{AS Q, AS A}を持つプレフィックス・ハイジャックである場合を考える。つまり、ハイジャッカーは、経路アナウンスの先頭にこのパスセグメントを付加する。AS BのASPAベースのパス検証は、このような偽造パスセグメント・プレフィックス・ハイジャックを常に検出する。ハイジャッカーが成功する(AS Bに検出されない)チャンスを得るためには、AS P(またはAS Q)のプロバイダASを含む3つのASを使った偽造パスセグメントを使用する可能性がある。しかし、AS PとAS QのプロバイダもASPAを登録していれば、それさえも阻止(検出)することができる。AS Bによる検出を回避するためには、より長い偽造パスセグメントを使用しなければならないため、経路選択においてハイジャックされた経路が対応する正当な経路と競合する能力が低下する。

⚠️ コメント

プロパティ4: AS A、AS B、AS Cを、ASPA(登録およびパス検証)を実行するインターネット上の任意の3つのASとする。AS Aから任意の方向(つまり、セクション2で説明したBGPのいずれかのロールを持つネイバーAS)に伝播された経路を考える。その経路が任意の方向からAS Bで受信され、経路漏洩と検出されたとする(AS AからAS BへのASパス内で、ASPAを実行する十分なASがあるため、検出が容易になる。AS Bのローカルポリシーは、経路のLOCAL_PREF [RFC4271]を下げるだけだと仮定する。AS Bによって選択され転送されたこのような経路が、その後AS Cで受信されたとする。AS BからAS Cまでに介在するパス内のASのASPA準拠については仮定しない。AS CのASPAベースのパス検証では、そのような受信経路がどの方向(ピアの種類)から受信されたかにに関係なく、常に漏洩として検出する。

⚠️ コメント

上記のプロパティの説明では、「カスタマ」という用語を「RSクライアント」に置き換えることができる。

上記のプロパティ#1から導かれる所見は、2つのISP ASのいずれかがASPAを登録し、検出および軽減手順を実装した場合、そのうちの一方から受信し、共通のカスタマAS(ASPAに準拠しているかどうかに関係なく)からもう一方に漏洩した経路は、自動的に検出され、軽減される。事実上、ほとんどの主要なISPが準拠していれば、インターネットにおける経路漏洩の伝播は厳しく制限される。

上記のプロパティは、ASPAベースのパス検証はアーリーアダプタにとって大きなメリットがあることを示している。一部の形式の悪意のあるASパス操作に関するこの方法の限界については、セクション12で説明する。

9. 運用上の考慮事項

9.1. 4バイトAS番号の要件

本文書で規定する手順は、AS_PATHで4バイトのASNをサポートするBGP実装とのみ互換性がある。レガシーなBGPルータはまれで、RPKIとの統合をサポートしている可能性は低いため、この制限は運用に実質的な影響を与えることはない。

9.2. ASPAの正しさ

ASPA発行者は、ASPAベースのASパス検証の影響を認識する必要がある。ネットワーク・オペレータは、ASPAオブジェクトを正確かつ最新の状態に保つ必要がある。さもなければ、例えば、プロバイダASがASPAのプロバイダAS一式(SPAS)から除外されている場合、(ASPA内の)CASとそのプロバイダASを含む経路は、経路漏洩として誤ってラベル付けされ、経路選択で不適格とみなされる可能性がある(セクション7.1参照)。

9.3. メイク・ビフォア・ブレーク

ASPA発行者は、ASPA登録の更新時にメイク・ビフォア・ブレイク原則を適用する必要がある(SHOULD)。例えば、SPASに新しいプロバイダASを追加する際、新しいASPAが以前作成したASPAを置き換える場合、新しいASPAはグローバルRPKIシステムを通じてリライング・パーティー(RP)に伝播される十分な時間が経過した場合にのみ、後者を廃止する必要がある(SHOULD)。

⚠️ メイク・ビフォア・ブレイク

メイク・ビフォア・ブレークとは、電気や電子機器の分野でよく使われる用語の一つで、ある回路や接続が切り替えられる際に、新しい接続が確立されてから古い接続を切断することで、中断や断絶が最小限になるという原則。

9.4. DoS/DDoS軽減サービス・プロバイダ

ASは、そのASが発信するプレフィックスに含まれるIPアドレスを持つサーバを標的とするサービス拒否(DoS)/分散DoS(DDoS)攻撃から保護するため、軽減サービス・プロバイダ(MSP)を利用する可能性がある。このようなASは、そのASPAのSPASにMSPのASを含めてもよい(MAY)。このようなASPAを導入すると、攻撃が発生した場合、AS (MSPのカスタマ)は、軽減目的でMore-Specificプレフィックスを(BGP セッション経由で)MSPのASにアナウンスすることができ、そのようなアナウンスはASPAベースのパス検証をパスすることができる。アナウンスもRPKI-ROVをパスできるよう、適切なROAが事前に登録されていることが前提である。

10. 他の技術との比較

10.1. BGPsec

BGPsec [RFC8205]は、BGP UPDATEメッセージに暗号署名を含めることで、AS_PATH検証の問題を解決するために設計された。これは、不正なパス変更に対する保護を提供し、BGPsec UPDATEが実際にBGPsec_PATH属性に示されたパスを通過したことを保証する。しかし、経路漏洩(バレーフリー違反)は検出できない。これに対して、本文書で説明するASPAベースのパス検証は、ASパスがあり得ないかどうかを検出し、経路漏洩(悪意のあるケースを含む)と偽造オリジン・ハイジャックを検出することに重点を置いている。

BGPsecとASPAは補完的なテクノロジーである。

10.2. Peerlock

Peerlockメカニズム[Peerlock] [Flexsealing]は、本文書で説明するAPSAベースの経路漏洩保護メカニズムと同様の目的を持つ。これは、大手インターネット通信事業者が、経路漏洩からお互いに保護するために一般的に導入されている。Peerlockは、オペレーターが体系化されていないProvider Authorizationsの配布を帯域外手段を通じて多対多で調整する面倒な手動プロセスに依存している。一方、ASPAがRPKIを使用することで、自動化された、スケーラブルでユビキタスな展開が可能になり、より広範囲のネットワーク事業者が保護メカニズムを利用できるようになる。

ルータコードに実装されたASPAメカニズムは(PeerlockのAS_PATH正規表現とは対照的)、トランジット・プロバイダやIXルートサーバから伝播された異常を検出する方法も提供する。ASPAは、既存のPeerlockを置き換える完全なソリューションであることを意図している。

11. IANA に関する考慮事項

本文書はIANAへの依頼を含まない。

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

ASPAベースのメカニズムは、経路に影響を与えるミスや悪意のあるアクティビティの大部分を検出し、軽減することができるが、特にトランジット・プロバイダから受信した経路の場合、一部の悪意のあるパス変更を検出できない可能性がある。

アップストリーム・プロバイダは信頼されるポイントになるため、理論的には、偽造オリジンや偽造パスセグメントを持つハイジャックされたプレフィックスや、AS_PATHが操作された経路を伝播することができ、そのような攻撃をカスタマは検出できないかも知れない。これはいくつかの例で説明できる。図3では、通常、左下に位置する受信/検証ASはAS_PATH{AS(5), AS(4), AS(3), AS(2), AS(1)}を持つ経路を受信する。図に示されているすべてのASPAを考えると、これは有効である(セクション6.2)。しかし、検証ASへのトランジット・プロバイダであるAS(5)が悪意を持って行動し、{AS(5), AS(3), AS(2), AS(1)}や{AS(5), AS(2), AS(1)}のように、AS_PATHを短縮して経路を送信した場合、そのようなパス操作は検出できない(つまり、そのAS_PATHは有効であると見なされる)。また、AS(5)がAS_PATH {AS(5), AS(1)}を挿入することで、偽造オリジン・ハイジャックを実行したとしても検出できない。

図3 :検出できないAS_PATHの操作について説明図

上記の例のような攻撃が発生する可能性はあるが、現実的なシナリオではないように思われる。通常、カスタマとそのトランジット・プロバイダは契約を結んでおり、(上記のような)ポリシー違反は法的責任を負うか、そうでない場合でも、カスタマはそのようなプロバイダとの関係を破棄し、対応するASPAレコードを削除するだけで済む。

ASPA方式の主要な特性や長所をセクション8で説明した。もし、あらゆる種類のパス操作攻撃を検出することが目的であれば、BGPsec [RFC8205]をASPA方式を補完する形で導入する必要がある。現在のBGPsecには経路漏洩を検出する機能が欠けていることに注意する。

13. 実装状況

このセクションは、RFCとして公開する前に削除すること。

このセクションは、このインターネットドラフトが掲載された時点で、この仕様で定義されているプロトコルの既知の実装の状況を記録する。このセクションをここに含めることは、 [RFC7942]で説明されているプロセスに従う。このセクションの実装の説明は、IETFがドラフトをRFCに進める際の決定プロセスを支援することを目的としている。ここに個々の実装を記載することは、IETFによる承認を意味するものではないことに注意する。さらに、ここで紹介されている情報は、IETFの寄稿者から提供された情報を検証するための労力は一切かけられていない。これは、利用可能な実装やその機能のカタログを意図したものではなく、そう解釈してはならない。読者は、他の実装が存在するかも知れないことに注意すること。

[RFC7942]によると、「これによって、レビュー担当者や作業グループは、実行中のコードの利点を持つ文書に適切な配慮をすることができる。これは、実装されたプロトコルをより成熟させた、貴重な実験とフィードバックの証拠として役立つ可能性がある。この情報をどのように使うかは、各作業グループの自由である。」

• Cで書かれたBGP実装OpenBGPD [bgpd] (バージョン7.8以降)は、クラウディオ・ジェーカー、テオ・ビューラー、ジョブ・スナイダースによって提供された。
• 実装NIST-BGP-SRx [BGP-SRx]は、検証エンジン(BGP-SRx)とQuaggaベースのBGPルータ(Quagga-SRx)を提供するソフトウェア・スイートである。ASPAベースのパス検証をテストするためのユニット・テスト・ケースも含まれている。これは、米国NISTのオリヴァー・ボルヒェルト、リ・ギュファン、および彼らの同僚によって提供された。IXP RS ASとRSクライアントに関連するドラフト仕様の最新の変更を採り入れるには、いくつかの追加作業が必要である。

14. 参考文献

14.1. 引用規格

[I-D.ietf-sidrops-aspa-profile] Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley, R., and B. Maddison, "A Profile for Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-profile-17, 7 November 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-17>.

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

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

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.

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

[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <https://www.rfc-editor.org/info/rfc6793>.

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

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.

[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 2016, <https://www.rfc-editor.org/info/rfc7908>.

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

[RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)", RFC 8481, DOI 10.17487/RFC8481, September 2018, <https://www.rfc-editor.org/info/rfc8481>.

[RFC8893] Bush, R., Volk, R., and J. Heitz, "Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export", RFC 8893, DOI 10.17487/RFC8893, September 2020, <https://www.rfc-editor.org/info/rfc8893>.

[RFC9234] Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. Sriram, "Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages", RFC 9234, DOI 10.17487/RFC9234, May 2022, <https://www.rfc-editor.org/info/rfc9234>.

[RFC9324] Bush, R., Patel, K., Smith, P., and M. Tinka, "Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh", RFC 9324, DOI 10.17487/RFC9324, December 2022, <https://www.rfc-editor.org/info/rfc9324>.

14.2. 参考規格

[BGP-SRx] NIST, "BGP Secure Routing Extension (BGP-SRx) Software Suite", NIST Open-Source Software , <https://www.nist.gov/services-resources/software/bgp-secure-routing-extension-bgp-srx-software-suite>.

[bgpd] Jeker, C., "OpenBGPD", <http://www.openbgpd.org/>.

[Flexsealing] McDaniel, T., Smith, J., and M. Schuchard, "Flexsealing BGP Against Route Leaks: Peerlock Active Measurement and Analysis", November 2020, <https://arxiv.org/pdf/2006.06576.pdf>.

[I-D.ietf-grow-route-leak-detection-mitigation] Sriram, K. and A. Azimov, "Methods for Detection and Mitigation of BGP Route Leaks", Work in Progress, Internet-Draft, draft-ietf-grow-route-leak-detection-mitigation-10, 8 January 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-10>.

[I-D.ietf-idr-deprecate-as-set-confed-set] Kumari, W. A., 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-12, 10 January 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-12>.

[IANA-AF] IANA, "Address Family Numbers", <https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml>.

[IANA-SAF] IANA, "Subsequent Address Family Identifiers (SAFI) Parameters", <https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml>.

[Peerlock] Snijders, J., "Peerlock", June 2016, <https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf>.

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>.

[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.

[RFC9319] Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B. Maddison, "The Use of maxLength in the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 9319, DOI 10.17487/RFC9319, October 2022, <https://www.rfc-editor.org/info/rfc9319>.

[sriram1] Sriram, K. and J. Heitz, "On the Accuracy of Algorithms for ASPA Based Route Leak Detection", IETF SIDROPS Meeting, Proceedings of the IETF 110, March 2021, <https://datatracker.ietf.org/meeting/110/materials/slides-110-sidrops-sriram-aspa-alg-accuracy-01>.

付録A. 謝辞

著者らは、ジェイコブ・ハイツ、アミール・ハーズバーグ、イゴール・ルバシェフ、ベン・マディソン、ラス・ハウズリー、ジェフ・ハース、ナン・ゲン、ニック・ヒリアード、シュンワン・チュアン、ヤンヤン・ワン、マーティン・ホフマン、ジェイ・ボルケンハーゲン、アムリーシュ・フォーカー、アフターブ・シッディーキー、ダイ・ジビンに感謝する。ダグ・モンゴメリー、リッチ・コンプトン、アンドレイ・ロバチェフスキー、イリイチ・ヴァン・ベイナムには、パス検証手順や本文書に関するコメント、提案、考察を提供してもらった。この文書の手順の実装と検証については、クラウディオ・ジェーカーとテオ・ビューラー[bgpd]、リ・ギュファンとオリヴァー・ボルヒェルト[BGP-SRx]に感謝する。

貢献者

以下の人々はこの文書に多大な貢献をし、共著者とみなさるべきである。

    クラウディオ・ジェーカー
    OpenBSD
    メール: [e-mail]

著者のアドレス

アレクサンダー・アジモフ
ヤンデックス
Ulitsa Lva Tolstogo 16
Moscow
119021
ロシア連邦
メール: [e-mail]

ユージン・ボゴマゾフ
Qrator Labs
1-y Magistralnyy tupik 5A
Moscow
123290
ロシア連邦
メール: [e-mail]

ランディ・ブッシュ
インターネットイニシアティブ & アーカス
5147 Crystal Springs
Bainbridge Island, Washington 98110
アメリカ合衆国
メール: [e-mail]

キーア・パテル
アーカス
2077 Gateway Place
Suite #400
San Jose, CA 95119
アメリカ合衆国
メール: [e-mail]

ジョブ・スナイダース
Fastly
アムステルダム
オランダ
メール: [e-mail]

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

更新履歴

• 2024.1.21: draft-ietf-sidrops-aspa-verification-16
• 2024.1.25
• 2024.2.1
• 2024.3.1: draft-ietf-sidrops-aspa-verification-17、期限延長のみ
• 2024.7.10: 図1の変更、draft-ietf-sidrops-aspa-verification-18の準備