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

2024/10/02に公開
Security
https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/

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

 本文書の位置付け本インターネット・ドラフトは、BCP78およびBCP 79の規定に完全に準拠して提出されている。
インターネット・ドラフトは、Internet Engineering Task Force (IETF)の作業文書である。他のグループも作業文書をインターネット・ドラフトとして配布する場合がある。現在のインターネット・ドラフトの一覧は、<https://datatracker.ietf.org/drafts/current/>にある。
インターネット・ドラフトは、最長6か月間有効なドラフト文書であり、いつでも更新、置き換え、または他の文書によって廃止される可能性がある。インターネット・ドラフトを参考資料として使用したり、「進行中の作業」以外の理由で引用することは不適切である。
このインターネット・ドラフトの有効期限は2025年3月31日である。

 著作権表示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の自律システム・プロバイダ認可 (ASPA)オブジェクト[ID.ietf-sidrops-aspa-profile]を使用して、広告経路のBGP AS_PATH属性のプロパティを検証する手順を説明する。ASPAベースのAS_PATH検証は、経路漏洩の検出と軽減を提供する。また、偽造オリジンや偽造パス・セグメントによるプレフィックス・ハイジャックに対抗するある程度の保護を提供する(付録B)。これらの新しいASPAベースの手順は、AS間で広告されるBGPアップデートに含まれるAS_PATHの異常を自動的に検出する。
経路漏洩もハイジャックも、ISPの運用に同じような影響を与える。これらは、トラフィックをリダイレクトし、サービス拒否(DoS)、盗聴、遅延の増大、パケット損失を引き起こす可能性がある。しかし、リスクの度合いは、異常の伝播範囲に大きく依存する。例えば、カスタマにのみ伝播する経路漏洩やハイジャックは、ISPのカスタマコーン内でボトルネックを引き起こすかも知れないが、異常がラテラル・ピア(つまり、非トランジット)やトランジット・プロバイダを介して伝播する場合、悪影響は増幅され、世界中で経験する経験することになる。
異常の発信元のサポートがなくても(発信元に悪意がある場合は重要)、トランジット・プロバイダやラテラル・ピアへのBGP異常の伝播を制限する機能は、グローバルなドメイン間ルーティング・システムの堅牢性を大幅に向上させることができる。

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

 3. 用語と略語一覧以下の用語は特別な意味をもって使用されている。
経路が不適格: この用語は[RFC4271]と同じ意味を持つ。つまり、「経路はLoc-RIBにインストールする資格がなく、経路選択の次のフェーズから除外される。」
CAS: カスタマAS ([I-D.ietf-sidrops-aspa-profile]、セクション1)。
PAS: プロバイダAS ([I-D.ietf-sidrops-aspa-profile]、セクション1)。
SPAS: プロバイダAS集合 ([I-D.ietf-sidrops-aspa-profile]、セクション3)。
⚠️ PAS/SPAS/U-PASCASがASPAを複数持つ可能性があることから、以下のようにまとめることができる。
本文書におけるパス検証の目的のために、ASが隣接ASに対して持つことができるピアリング関係は、カスタマ、プロバイダ、ピア、経路サーバ(RS)、RSクライアント、及び複合的(Complex)である。これらのピアリング関係は[RFC9234]で定義されている。複合的関係の特別なケースは、ASが相互にすべて(カスタマ経路と非カスタマ経路の両方)をエクスポートしてもよい(MAY)相互トランジットの関係にある。つまり、カスタマからプロバイダへの関係が各方向に適用される。すべてのピアリング関係はローカルに定義される。
⚠️ RFC 9234における複合的(Complex)の定義
ローカルASがリモートASと複数のピアリング・ロールを持つ場合、そのようなピアリング関係は「複合的(Complex)」と呼ばれる。例えば、ピアリング関係が、あるプレフィックスではProvider-to-Customerで、他のプレフィックスではPeer-to-Peerの場合である[GAO-REXFORD]。


 4. 自律システム・プロバイダ認可 (ASPA)ASPAレコードは、CAS番号にPAS番号セットを結び付け、CASが署名したデジタル署名オブジェクトである[I-D.ietf-sidrops-aspa-profile]。ASPAは、CASがプロバイダAS集合(SPAS)を表明したことを証明し、IPv4とIPv6アドレスファミリー(つまり、AFI=1とAFI=2)、かつユニキャスト転送(SAFI=1)に使われるネットワーク層到達性情報(NLRI)にのみ適用される。
(AS x, {AS y1, AS y2, ...})という表記法は、AS xという名前のCASのASPAオブジェクトを表すために使用される[I-D.ietf-sidrops-aspa-notation]。この表記法では、カンマで区切られた集合{AS y1, AS y2, ...}が、CAS(AS x)のプロバイダAS集合(SPAS)を表す。CASは、そのプロバイダASをすべて記載した1つのASPAを登録することが求められる(セクション5参照)。CASが暗号的に有効な1つのASPAを持つ場合、CASのユニオンSPAS(U-SPAS)はSPASと等しい。CASが暗号的に有効な複数のASPAを持つ場合、CASのU-SPASは、これらのASPAのすべてのSPASに記載されているASの和集合となる。
⚠️ ASPAの表記法について上記ASPAの表記法を図に表すと次のようになる。
AS iはRPKIのASPAオブジェクトに署名し、AS j、AS k、AS mがトランジット・プロバイダであることを証明する。
ASPAはRPKIリポジトリに登録/保管される。
ところで、本ドラフトで引用されているIETFドラフト「draft-ietf-sidrops-aspa-notation-00」に記載されている表記方法は、
AS x => AS y1, AS y2, ...
である。ただし、このドラフトは期限切れとなっており、上記表記法で更新されるのか??

 5. ASPA登録の推奨事項(ASPA)準拠ASまたは経路サーバAS (RS AS)は、ASPAを持たなければならない(MUST)。ASは複数のASPAを持ってはならない(SHOULD NOT)。ASは、そのSPASに、自身がRSクライアントとなっているすべてのプロバイダASと非透過RS ASの和集合を記載しなければならない(MUST)。ASは、プロバイダASがIPv4のみ、IPv6のみ、またはその両方の接続性を提供しているかどうかに関わらず、SPASにプロバイダASを含めなければならない(MUST)。
⚠️非透過RSを含むASPA
一方、透過RSの場合は、経路交換をしている相手(AS1であればAS2)とはラテラルピアとなるため、ASPAには登録しない。
プロバイダASとして、AS 0のみを示すASPAオブジェクトは、AS0 ASPAと呼ばれる。非透過経路サーバAS(RS AS)とは、AS_PATHにそのAS番号を含むASをいう。AS0 ASPAとして登録することは、登録するASがトランジット・プロバイダを持たず、非透過RS ASのRSクライアントでもないことの表明である。この表明が真である場合、ASはAS0 ASPAを登録しなければならない(MUST)。
⚠️ AS0 ASPAAS0 ASPAは、Tier-1やRS ASがあたる。例えば、AS 1000を持つTier-1があったとする。そのASPAは次のようになる。
1000, {0}
ASPAに準拠したASは、シングルASPAオブジェクトを登録する必要がある(SHOULD)。ASに対してシングルASPAレコードを登録することで、ASPA更新時にプレフィックス伝播に影響を与える可能性のある競合状態を防ぐべきである。ASPAレコードのホスティングを提供するソフトウェアは、この慣行の徹底を支援する必要がある(SHOULD)。
ASには、DDoS攻撃が発生した場合など、特定の状況で利用するプロバイダを持つかもしれない。ASPAの配布と経路伝播の間に競合状態が発生しないよう、そのようなプロバイダをあらかじめASPAに追加しておくことが推奨される(RECOMMENDED)。
異なる証明機関(CA)レジストリ間の移行プロセス中、ASPAレコードは関連するすべてのレジストリで同一に保つ必要がある(SHOULD)。
通常、U-SPAS(セクション4参照)はAS 0や他のプロバイダASの両方を含むことを想定していないが、AS 0が予期せず存在しても、ASパス検証手順(セクション6、セクション7参照)には影響しない。
複合的な関係の場合(セクション3)、受信または送信されたプレフィックスの一部に対して、ネイバーがプロバイダの役割を果たす場合、ASはそのSPASにネイバーASを含めなければならない(MUST)。相互トランジット・ペアの2つのASはそれぞれは、そのSPASに相手ASを含むASPAを登録しなければならない(MUST)。
ASコンフェデレーションの境界にあるASは、CASとしてコンフェデレーションのグローバルAS番号(ASN)を使用して、ASPAを登録しなければならない(MUST)。

 6. プロバイダ認可関数前提として、AS xとAS yが2つのユニークなASを表すものとする。プロバイダ認可関数 authorized(AS x, AS y)は、ASNの順序対(AS x, AS y)が、AS xのU-SPASを通じて、AS yがAS xの認可済みプロバイダという特性を持つかどうかを照合する。「Provider+」という用語から分かるとおり、この関数はAS yがプロバイダ、非透過RS、あるいは相互トランジット・ネイバーの役割を持つことを示す関数でもある。この関数は以下のように規定できる。


図1: プロバイダ認可関数
「No Attestation」(証明なし)という結果は、CASのASPAが取得できないか、CASのASPAが暗号的に有効でない場合にのみ返される。プロバイダ認可関数は、セクション7.2及びセクション7.3で説明するASPAベースのAS_PATH検証アルゴリズムで使用される。
⚠️ 図1のコメントプロバイダ認可関数は、ASPAの原理を説明するためのもので実装方法を説明しているわけではない。
slides-interim-2024-sidrops-01-sessa-update-on-the-aspa-verification-00

 7. AS_PATHの検証この文書で説明する手順は、4オクテットAS番号に対応するBGPスピーカー[RFC6793]にのみ適用される。このようなBGPスピーカーがUPDATEでAS_PATH属性とAS4_PATH属性の両方を受信した場合、検証手順は再構築されたASパスに適用される([RFC6793]のセクション4.2.3 )。したがって、この文書では、AS_PATHという用語は、通常のAS_PATH [RFC4271]と再構築されたASパスを指すために使用する。
⚠️ ASパスの再構築について再構築は、4オクテットの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 検証手順 (セクション7.2節及びセクション7.3) において、AS_SET を含む経路は無効と評価される。無効なAS_PATHを持つ経路の処理方法については、セクション7.4を参照のこと。
⚠️ Treat-as-withdrawTreat-as-withdrawとは、UPDATEメッセージの処理でエラーが発生した場合、BGPセッションをクローズするのではなく、エラーとなったUPDATEメッセージに含まれる経路を撤回(withdraw)扱いにすることをいう。

 7.1. 動作原理{AS(N), AS(N-1),..., AS(2), AS(1)}というシーケンスが、AS_PATHを一意のASNで表し、AS(1)がオリジンAS、AS(N)が直近に追加されたASで、受信/検証ASのネイバーだとする。Nは受信したAS_PATHのユニークなASの長さである。AS(N+1)は受信/検証ASとする。


図2 :上り傾斜と下り傾斜の図
⚠️ ASパスのプリペンドについてASの繰り返し(ASプリペンド)は、1つのASとしてカウントする。したがって、ASパスはユニークなASNシーケンスとなる。
AS_PATH: {1, 2, 2, 2, 2, 2, 3, 4, 5} → {1, 2, 3, 4, 5}
AS_PATHは一般に、上り傾斜(AS(1)を起点とする右側)と下り傾斜(AS(N)を起点とする左側)の両方を持つ。上り傾斜はAS(1)から始まり、AS(i)からAS(i+1)へ各ホップはカスタマとプロバイダのピアリング関係を表す。下り傾斜はAS(N)からAS(L)へ逆方向に続く。下り傾斜では、AS(j)からAS(j-1)の各ペアはカスタマとプロバイダのピアリング関係を表す。上り傾斜と下り傾斜の頂点間にホップがないか、または1ホップしかない場合、そのAS_PATHは有効である(バレー・フリー)。
⚠️ 図2と上記の解釈Tier-1について
ASパスの頂点に位置するのはTier-1のような上流を持たないASで、このようなASはすべての経路を持つため、頂点が2ホップ以上の「A-B-C」のようなパスになることは考えられない。
そもそも、インターネットにおけるTier-1ネットワークとは、インターネットのバックボーンを構成する最上位のネットワーク・プロバイダをいう。具体的には、他のネットワークに対してトランジットを購入することなく、他のTier-1ネットワークとピアリング(相互接続)することで、インターネット全体にアクセスできるネットワークを指す。そもそも、Tier-1ネットワークの認定は、特定の公式認定機関があるわけではなく、業界の専門家やネットワーク・エンジニアによるコンセンサス、相互接続パターン、ピアリング・ポリシー、ネットワーク・トポロジーの分析などによって、どのネットワークがTier-1であるかが認識されている。具体的には、以下のような条件を満たしているかどうかによってTier-1ネットワークと見なされている。
相互接続の範囲が広い: 他のTier-1ネットワークとピアリングしており、全世界にわたるインターネット・トラフィックを取り扱うことができる。
トランジットの購入が不要: 他のTier-1ネットワークと対等にピアリングしているため、他のネットワークからインターネット接続を購入する必要がない。
高い信頼性とパフォーマンス: インターネットの基幹を支えているため、非常に高い信頼性とパフォーマンスを持つ。
ウィキペディアに掲載されているTier-1ネットワークは下表の通り。これらのプロバイダは大規模なインフラを持ち、世界中のネットワークに接続している。


プロバイダ名
HQ
ASN


AT&T
米国
7018

ドイツ・テレコム
ドイツ
3320

GTTコミュニケーションズ
米国
3257

リバティ・グローバル
オランダ
6830

ルーメン・テクノロジーズ
米国
3356

NTTコミュニケーションズ
日本
2914

Orange
フランス
5511

PCCW
香港
3491

タタ・コミュニケーションズ
インド
6453

テレコム・イタリア
イタリア
6762

Arelion
スウェーデン
1299

Telxius
スペイン
12956

Verizon
米国
701

Zayo
米国
6461

Tier-1はASPA AS 0と登録するか、ASPAを持たないと考えていいだろう。


図2について
便宜上、ASパス長が8のネットワークを考える。ルータはプロバイダ認可関数とASPAを使って各ホップを検証していく。全てのASはASPAを持っていると仮定する。
AS_PATH = {8, 7, 6, 5, 4, 3, 2, 1}
で、ASPA的には、
ASPA: (1,2), (2,3), (3,4), (4,0), (5,0), (6,5), (7,6), (8,7)
となる。AS_PATHからは、どこからどこまでが上り/下り傾斜かは分からない。
authorized(1, 2) = P
authorized(2, 3) = P
authorized(3, 4) = P
authorized(4, 5) = nP ---> ４が上り境界になる
authorized(8, 7) = P
authorized(7, 6) = P
authorized(6, 5) = P
authorized(5, 4) = nP ---> 5が下り境界になる
このように、プロバイダ認可関数から傾斜が分かる。
上り傾斜と下り傾斜の長さの合計がN未満の場合、無効である。プレフィックスが漏洩したか、そのAS_PATHが不正である。
⚠️ 上記の解釈いきなり、「上り傾斜と下り傾斜の長さの合計がN未満の場合、無効である」と書かれると、何も説明がないため、チンプンカンプンである。まず、長さとはASパス長のことなので、通過するASの数である(RFC 4271、セクション5.1.2)。
下図のような例を考える。
左側は、トランジットASを通過してバレーフリーのネットワークになっている。この場合、上り傾斜部分の通過ASは4、下り傾斜部分の通過ASは4となり、ASパス長は4+4で合計8となり、全体のASパス長と一致する。
ところが、右側は途中でC2Pの関係が崩れている部分が入っており、バレーフリー違反になっている(RFC 7908)。この場合、上り傾斜部分の通過ASは4、下り傾斜部分の通過ASは2となり、ASパス長は4+2で合計6となり、全体のASパス長と一致しない。そのため、バレーフリー違反と想定でき、経路操作が途中で起きている可能性があるため、このASパスは無効と考える。
すなわち、上り/下り傾斜の合計がN未満であれば、何らかのバレーフリー違反があり、不正と考えられる。
ASPAは、AS yがAS xの認可されたプロバイダかどうかを確認するために使用できる。したがって、プロバイダ認可関数は、上り傾斜と下り傾斜の境界を測定するために使用できる。プロバイダ認可関数の「Not Provider+」という結果は、傾斜長の上界の計算に使用でき、「No Attestation」という結果は、傾斜長の下界の計算に使用できる。以下は正式な定義である。
⚠️ 上記の解釈分かりやすい例で説明した方がいいだろう。一般的にインターネット通信は発信元ASから、上位トランジットASを経由して、宛先ASに向かう。発信元から上位に向かうパスを上り傾斜、上位から宛先に向かうパスを下り傾斜と呼んでいる。発信元から宛先までのパス上の全てのASがASPAをサポートしていれば、前述のとおりプロバイダ認可関数を使って、上り傾斜、下り傾斜を知ることができる。
ところが、全てのASがASPAをサポートしているわけではない。当然、ASPAをサポートしていても、パス上のASがU-SPASに存在しないケース、そもそもASPAをサポートしていないケースも考えられる。例えば、上図の例で言えば、(3,0)と(5,4)の部分が不明と考えると、(3,0)の部分は(3,4)かもしれない。その場合、上り傾斜は1-2-3-4になるし(最大上り傾斜: max_up_ramp)、(3,0)のままであれば、上り傾斜は1-2-3となる(最小上り傾斜: min_up_ramp)。すなわち、認可関数の結果がnPかどうかで分かる。下り傾斜の場合を同様に考えれば、最大下り傾斜(max_down_ramp)は6-5-4になり、最小下り傾斜(min_down_ramp)は6-5となる。すなわち、nAかどうかで分かる。
最大上り傾斜の長さをIとする。ここで、Iは、authorized(A(I), A(I+1))が「Not Provider+"」を返す最小インデックス(位置)である。このようなIがない場合、最大上り傾斜長はAS_PATH長Nに等しくなる。このパラメータはmax_up_rampと定義する。上り傾斜長の最小値は、Iとして決定できる。ここで、Iは、authorized(A(I), A(I+1))が「No Attestation」または「Not Provider+」を返す最小のインデックスである。このようなIがない場合、AS_PATHは「Provider+」ペアのみで構成されるので、最小上り傾斜長はAS_PATH長Nに等しくなる。このパラメータはmin_up_rampとして定義する。
同様に、最大下り傾斜長は、N-J+1として決定することができる。ここで、Jはauthorized(A(J), A(J-1))が「Not Provider+」を返す最大インデックスである。そのようなJがない場合、最大下り傾斜長はAS_PATH長Nに等しく設定される。このパラメータはmax_down_rampと定義する。最小下り傾斜長はN-J+1として決定できる。ここで、Jはauthorized(A(J), A(J-1))が「No Attestation」または「Not Provider+」を返す最大インデックス(位置)である。そのようなJがない場合、最小下り傾斜長はAS_PATH長Nと等しくなる。このパラメータはmin_down_rampとして定義する。
max_up_ramとmax_down_rampの和がN未満の場合、ASパスは無効である。一方、min_up_ramとmin_down_rampの和がN未満の場合、完全なASパス検証を行うのに十分な情報が得られず、結果は不明(Unknown)に設定される。それ以外の場合、ASパスは有効である。
⚠️ 上り/下り傾斜の境界についての解釈上記の説明は分かりにくい。
「このようなIがない場合、最大上り傾斜長はAS_PATH長Nに等しく設定される」とは、逆説的な説明をしている。max_up_ramp=Iとすると、nPを返さなければ、パス全体が上り傾斜と考えられる。すなわち、宛先ASは上位プロバイダと考えられる。下りも上りと同じ原理で考えられる。
そもそも、上り/下り傾斜の境界というのは、関数の結果がProvider+ではなくなったASである。上り傾斜の場合、境界の先はトランジットAS(例えば、Tier-1)やRSの可能性が高いと考えられる。下り傾斜の場合も同様である。
ところが、前のコメントでも説明したように、展開途中では全てのASがASPAが登録しているとは限らない。そのため、次のパスが不明的な扱いとなる(No Attestation)ケースも考えられ、その場合の傾斜は最小と扱っている。これは、途中のパスがASPA的に不明であっても、無効なASパスを判別することができるためである。
ここで、先ほどの例で考えてみる。

max_up_ramp + max_down_ramp < Nは無効

min_up_ramp + min_down_ramp < Nは不明
となる。
以下は、受信ASとその隣接AS間のピアリング関係に応じたパス検証の正式な手順である。これらの手順では、AS_PATH AS(N), AS(N-1), ..., AS(2), AS(1)の圧縮シーケンス表現と、上記で定義されたパラメータmax_up_ramp、min_up_ramp、max_down_ramp、min_up_ramp を使用する。
⚠️ まとめると
ASPAは部分展開が可能で、アップストリーム/ダウンストリーム・パス、(上り/下り)傾斜を混同しないこと。アップストリーム/ダウンストリームはオリジンASから受信ASまでのBGP UPDATEの流れ、傾斜は各ホップがASPA的に有効(カスタマ→プロバイダ)であるASパスを言う。
上りの傾斜は、オリジンあるいは近いASから上り方向のホップがProvider+である。上りのホップがNot ProviderやNo Attestationになった時点で、上り方向ではなくなったと解釈し、その前のASが頂点ということになる。
下り傾斜は、下りの方向なので終点から逆方向にauthorized関数を実行する(ASPA的には逆方向になることに注意)。結局、上り方向にASPA関数を評価することとなり、上り傾斜同様、上りのホップがNot ProviderやNo Attestationになった時点で、上り方向ではなくなったと解釈、そのASが下り傾斜の頂点となる。


 7.2. アップストリーム・パスのアルゴリズムここで説明するアップストリーム検証アルゴリズムは、経路をカスタマまたはピアから受信した場合、またはRSがRSクライアントから受信した場合、またはRSクライアントがRSから受信した場合に適用される。これらすべての場合において、受信/検証するeBGPルータは、AS_PATHが上り傾斜のみ(下り傾斜なし)で有効であることを想定する。したがって、max_down_rampとmin_down_rampは0になる。
アップストリーム・パス検証手順は以下のように規定されている。
AS_PATHが空の場合、「無効」という結果で停止する。
受信ASがRSクライアントではなく、AS_PATHに最後に追加されたASが隣接ASと一致しない場合、「無効」という結果で停止する。
AS_PATHにAS_SETがある場合、「無効」という結果で停止する。

max_up_ramp < Nの場合、「無効」という結果で停止する。

min_up_ramp < Nの場合、「不明」という結果で停止する。
それ以外の場合、結果「有効」という結果で停止する。
⚠️ 上記の解釈ここでは、今まで説明してきた逆V字の構成ではなく、上り傾斜のみのパスである。「上り/下り傾斜の境界についての解釈」で説明した解釈を適用すると、max_down_rampが0なので、max_up_rampがNより小さければ無効となる。min_down_rampも0なので、min_up_rampがNより小さければ不明となる。

 7.3. ダウンストリーム・パスのアルゴリズムここで説明するダウンストリーム検証アルゴリズムは、プロバイダから経路を受信したときに適用される。
AS_PATHが空の場合、「無効」という結果で停止する。
AS_PATHに最後に追加されたASが隣接ASと一致しない場合、「無効」という結果で停止する。
AS_PATHにAS_SETがある場合、「無効」という結果で停止する。

max_up_ramp + max_down_ramp < Nの場合、「無効」という結果で停止する。

min_up_ramp + min_down_ramp < Nの場合、「不明」という結果で停止する。
それ以外の場合、「有効」という結果で停止する。
⚠️ 上記の解釈「上り/下り傾斜の境界についての解釈」で説明した解釈の通り。

 7.4. 軽減ポリシーASPAを使用したAS_PATH検証に基づく軽減ポリシーの具体的な構成は、ネットワーク・オペレータの裁量に委ねられる。ただし、以下の緩和ポリシーを強く推奨する。
無効: AS_PATHが無効だと判断した場合、その経路は経路選択に不適格とみなされるが(セクション3を参照)、将来の再評価に備えてAdj-RIB-Inに保持しなければならない(MUST)([RFC9324]を参照)。
有効または不明: 経路が不明と評価された場合(ASPAベースのAS_PATH検証を使用)、有効と評価された経路と同じ優先レベルで処理する必要がある(SHOULD)。

 8. 導入の推奨事項このセクションでは、実践的な展開の推奨事項について説明する。

 8.1. 検証手順の適用本文書で説明する検証手順は、AFI, SAFIの組み合わせ AFI 1 (IPv4), SAFI 1及びAFI 2 (IPv6), SAFI 1を持つBGP経路に適用しなければならない(MUST) [IANA-AF] [IANA-SAF]。この手順は、デフォルトで他のアドレス・ファミリーに適用してはならない(MUST NOT)。
ASPAベースのAS_PATH検証の手順は、イングレス側のエッジ・ルータでの実装を意図している。これには、外部ASに面するASコンフェデレーションの境界上のエッジ・ルータも含まれる。ただし、この手順は、内部BGP(iBGP)セッションまたはASコンフェデレーション内部の eBGPセッションで使用することを推奨しない。

 8.2. BGPロール[RFC9234]で規定されているBGP OPENメッセージのBGPロール構成パラメータとそのクロスチェックを推奨する(RECOMMENDED)。設定されたBGPロールは、前述のASパス検証手順を自動化するために使用する必要がある(SHOULD)。これにより、アップストリーム手順とダウンストリーム手順のどちらを適用すべきかを区別するのに役立つ。BGPロールの自動クロスチェック[RFC9234]は、ASPAのより正確で効果的な展開を促進するはずである。

 8.3. 複合的ピアリング関係複数のeBGPセッションを持つ複合的なピアリング関係を、通常のピアリング関係を持つeBGPセッションに分離できる場合、受信/検証ASは、そのピアリング関係のタイプに基づいて、通常のセッションごとにアルゴリズム(セクション7.2またはセクション7.3に従う)を選択する必要がある(SHOULD)。
複合的なピアリング関係を分離できない場合(つまり、複合的なBGP関係が1つのBGPセッション内で発生する場合)、オペレータはプレフィックスのピアリング関係に対応するプレフィックスごとにポリシーを設定することで、同等の結果を得たいと考えるかもしれない。このオプションが実行できない場合、オペレータはセクション7.3を適用してもよい(MAY)。

 8.4. ログ記録無効なAS_PATHを持ついかなる経路についても、監視と診断の目的で無効状態の原因をログに記録する必要がある(SHOULD)。無効状態の原因は、プロバイダ認可機能によって「Not Provider+」と評価されたASホップをリストアップする形で記録できる。ただし、ログを記録するルータは、経路漏洩の原因となったASを必ずしも特定できるわけではない。

 9. セキュリティに関する考慮事項
 9.1. IPv4とIPv6の接続性の不整合U-SPASには、IPv4とIPv6の両ユニキャスト接続用のCASのプロバイダの和集合が含まれている。このデザイン上の選択は結果として、カスタマとプロバイダの関係が一方のアドレス・ファミリーには存在するが、もう一方のアドレス・ファミリーには存在しない場合、後者のAFIのAS_PATH検証結果が、前者のAFIの検証結果と同様に許容されることを意味する。これは、ASPAの登録プロセスと検証プロセスの両方が簡素化され、誤検知の結果(例えば、不注意による無効評価)を発生させないため、妥当な妥協策と考えられる。

 9.2. 信頼できるポイントとしてのプロバイダアップストリーム・プロバイダは信頼できるポイントになるため、理論上は、偽造されたオリジンや偽造されたパス・セグメント、あるいは操作されたAS_PATHを持つ経路を持つハイジャックされたプレフィックスのインスタンスを伝播できるかもしれず、そのような攻撃はカスタマや上位プロバイダによって検出されない可能性がある。
そのような攻撃が起こるかも知れないが、現実的なシナリオではないようだ。通常、カスタマとトランジット・プロバイダはサービス契約を結んでいるはずで、ポリシー違反(上記のような)には法的結果が伴うか、カスタマはそのようなプロバイダとの関係を断ち切り、対応するASPAレコードを削除すればよい。

 9.3. AS_PATHプリペンドの操作ASPAの検証手順では、ASパス内のAS番号の繰り返しの削除(または追加)を検出できない。しかし、この攻撃自体はASPAの経路漏洩検出機能には影響しない。

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

 10. 他のテクノロジとの比較
 10.1 BGPsecBGPsec [RFC8205]は、BGP UPDATEメッセージに暗号署名を含めることで、AS_PATH検証の問題を解決するために設計された。これは、不正なパス変更に対する保護を提供し、BGPsec_PATH属性に示されたパスをBGPsec UPDATEが通過したことを保証する。しかし、経路漏洩(バレーフリー違反)は検出できない。したがって、BGPsecとASPAは補完的なテクノロジーである。

 10.2. PeerlockPeerlockメカニズム[Peerlock] [Flexsealing]は、本文書で説明するAPSAベースの経路漏洩保護メカニズムと同様の目的を持つ。これは、大手インターネット通信事業者が、経路漏洩からお互いに保護するために一般的に導入されている。Peerlockは、オペレータが体系化されていないプロバイダ認可(Provider Authorizations)のやり取りを、帯域外手段を通じて多対多で調整する面倒な手動プロセスに依存している。一方、ASPAがRPKIを使用することで、自動化された、スケーラブルでユビキタスな展開が可能になり、より広範囲のネットワーク事業者が保護メカニズムを利用できるようになる。
ルータコードに実装されたASPAメカニズムは(PeerlockのAS_PATH正規表現とは対照的)、トランジット・プロバイダやIX経路サーバから伝播された異常を検出する方法も提供する。ASPAは、既存のPeerlockを置き換える完全なソリューションとなることを意図している。
⚠️ PeerlockについてPeerlockとは、保護対象ASからの経路を受信する接続点を、経路フィルタリングで制限することで、経路漏洩等の影響を軽減する手法で、ジョブ・スナイデルがNTT在籍時に推進した。例えば、下記のような構成であれば、接続点は3点あり、AS Bとの直接接続及びAS Aの上流AS経由(AS C)を許可し、他のすべてのBGP接続(AS YやAS Zからの受信)で、AS_AをAS_PATHに含む経路をフィルタリングする。AS Pathフィルタリングは新しいものではないが、PeerlockではAS-Pathフィルタと書面によるピアリング契約を行う。
Peerlockの変形であるPeerlock Liteは、特に大規模プロバイダに適用されるもので、Tier-1プロバイダがトランジットを購入しないことから、Tier-1 ASN間に非Tier-1 ASNがあってはならないという前提に基づく。もし、それが起こった場合に経路漏洩が発生したことになる。例えば、下記の場合、AS23456がAS1299への経路を漏洩した疑いがある。


https://bgp.tools/kb/peerlock
Peerlock Liteのポリシーは、カスタマから受信したプレフィックスのAS_PATHに、これらの大規模プロバイダ(Tier-1)ASNが含まれているものを拒否することで対応する(下はCiscoのACL例)。
ip as-path access-list 99 permit \
        _(209|701|1299|2828|2914\
        |3257|3320|3356|3491|5511\
        |6453|6461|6762|6830|7018\
        |12956)_

route-map ebgp-customer-in deny 1
   match as-path 99


https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf

 10.3. Only to Customer(OTC)属性ASPAベースのAS_PATH検証方法(セクション7、セクション7.4)は、AS_PATHに記載されている先行ASによって作成された経路漏洩を検出し、軽減する一方で、ローカルASがその隣接ASへの経路漏洩を開始するのを防ぐ機能を欠いている。ASPA検証はまた、AS_PATHに複合的な関係が存在する場合、経路漏洩を検出できない可能性もある。Only to Customer(OTC)属性を使用すると、そのギャップを埋めることができる(セクション5、[RFC9234]を参照)。ASPAベースのAS_PATH検証を補完するために、OTC属性を使用する手順の実装が推奨される(RECOMMENDED)。

 11. IANA に関する考慮事項本文書はIANAへの依頼を含まない。

 12. 実装状況このセクションは、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クライアントに関連するドラフト仕様の最新の変更を採り入れるには、いくつかの追加作業が必要である。
BIRDインターネット・ルーティング・デーモン[BIRD]におけるASPAベースのASパス検証の実装は、カテリーナ・クベコワとマリア・マテイカによるサイド・ブランチ(ブランチmq-aspa)で提供されている。RTR v2の完成後にリリースされる予定である。

 13. 参考文献
 13.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-18, 25 June 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-18>.
[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>.
[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>.

 13.2. 参考規格[BGP-SRx] Lee, K. and O. Borchert, et al., "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/>.
[BIRD]  Kubecova, K. and M. Matejka, "BIRD Internet Routing Daemon; branch mq-aspa", CZ.NIC BIRD Open-Source Software , <https://bird.nic.cz/en/>.
[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-11, 26 August 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-11>.
[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-16, 27 August 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-16>.
[I-D.ietf-sidrops-aspa-notation]  Bruijnzeels, T., Borchert, O., Ma, D., and T. de Kock, "Human Readable ASPA Notation", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-notation-00, 9 January 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-notation-00>.
[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>.
[nanog-aspa]  Sriram, K., "ASPA-based BGP AS_PATH Verification and Route Leaks Solution", NANOG-89, North American Network Operator Group Meeting, Slides/video archives from NANOG, October 2023, <https://storage.googleapis.com/site-media-prod/meetings/NANOG89/4809/20231017_Sriram_Aspa-Based_Bgp_As_Path_v1.pdf> (slides) <https://www.youtube.com/watch?v=GdVnZGd7jMo> (video).
[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>.

 付録A. 謝辞著者らは、パス検証手順または文書内のテキストに関するコメント、提案、および議論を提供してくれた クラウディオ・イェカー、ジェイコブ・ハイツ、アミール・ハーズバーグ、イゴール・ルバシェフ、ベン・マディソン、ラス・ハウズリー、ジェフ・ハース、ナン・ゲン、ニック・ヒリアード、シュンワン・チュアン、ヤンヤン・ワン、マーティン・ホフマン、ジェイ・ボルケンハーゲン、アムリーシュ・フォーカー、アフターブ・シッディーキー、ダイ・ジビン、ダグ・モンゴメリー、パドマ・クリシュナスワミ、リッチ・コンプトン、アンドレイ・ロバチェフスキー、ルディガー・ヴォルク、イルジッチュ・ファン・ベイヌム、タッシロ・タンネベルガー、マティアス・ヴァエリッシュ、モリッツ・シュルツ、カール・ザイファートの各氏に感謝する。本文書の手順の実装とテストに対して、クラウディオ・イェカーとテオ・ビューラー [bgpd]、リー・キーファンとオリバー・ボルヒャート [BGP-SRx]、カテリーナ・クベコワとマリア・マテイカ [BIRD] に感謝する。

 付録B. 特性と早期導入のメリットASPA方式は、以下に記載する特性(異常検出機能など)を持つ。部分的な展開シナリオと早期導入のメリットが考慮されている。特性1の場合、攻撃は経路漏洩が関係するが、ASパスからASPAレコードを持つAS 悪意を持って削除することはないと想定する。
特性1(経路漏洩検出): AS AとAS Bを、ASPA(登録とパス検証)を行なっているインターネット上の任意の2つのASとし、他のASのASPA展開状況は想定しない。AS Aからカスタマまたはラテラル・ピアに伝播された経路を考える。その後、経路はカスタマまたはラテラル・ピアのインタフェース上のAS Bが受信する前に、ASパス内の違反ASが漏洩したとする。AS BにおけるASPAベースのパス検証は、漏洩を起こしたASを特定できないかも知れないが、常にこのような経路漏洩を検出する。
⚠️ 上記解釈
特性1の帰結: 上記の特性#1から導かれる知見は、2つのISP ASがASPAを登録し、検出と軽減手順を実装すると、そのASの1つから受信され、重複するカスタマ・コーン内のAS(ASPAに準拠しているかどうかに関係なく)によって他方に漏洩された経路は、自動的に検出され、軽減されるということである。事実上、ほとんどの主要ISPが準拠すれば、インターネットにおける経路漏洩の伝播は厳しく制限されることになる。
特性2(偽造オリジン・プレフィックス・ハイジャックの検出): ここでも、AS AとAS BをASPA(登録とパス検証)を行なっているインターネット上の任意の2つのASとし、他のASのASPA展開状況は想定しない。カスタマまたはラテラル・ピアのインタフェース上のAS Bで受信した経路が、AS Aを偽造オリジンとする偽造オリジン・プレフィックス・ハイジャックであると考える。問題のAS XはAS AのASPAに含まれていないと想定する。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 Xは、このパス・セグメントをその(AS Xの)経路アナウンスの先頭に付加する。AS XがAS PまたはAS QのASPAに含まれていないものとする。AS BのASPAベースのパス検証は、このような偽造パス・セグメントのプレフィックス・ハイジャックを常に検出する。ハイジャックが成功する可能性(AS Bに検出されないままになる可能性)を高めるためには、ハイジャッカーは、AS P(またはAS Q)のプロバイダASを含む3つのASを含む偽造パス・セグメントを使うかも知れない。しかし、AS PとAS QのプロバイダもASPAを登録すれば、それさえも阻止(検出)することができる。AS AからそのTier 1までの連続するC2Pホップ内のすべてのASが ASPA登録をしていれば、(どのような偽造パス・セグメントの長さであっても)、検討中の偽造パス・セグメント・ハイジャックは完全に防ぐことができる。
⚠️ 上記解釈
以上の特性から、ASPAベースのパス検証が早期導入者に大きなメリットをもたらすことを示している。悪意のあるASパス操作のいくつかの形式に関するこの手法の限界については、セクション9で説明している。

 著者のアドレスアレクサンダー・アジモフ

ヤンデックス

Ulitsa Lva Tolstogo 16

Moscow

119021

ロシア連邦

メール: a.e.azimov@gmail.com
ユージン・ボゴマゾフ

Qrator Labs

1-y Magistralnyy tupik 5A

Moscow

123290

ロシア連邦

メール: eb@qrator.net
ランディ・ブッシュ

インターネットイニシアティブ & アーカス

5147 Crystal Springs

Bainbridge Island, Washington 98110

アメリカ合衆国

メール: randy@psg.com
キーア・パテル

アーカス

2077 Gateway Place

Suite #400

San Jose, CA 95119

アメリカ合衆国

メール: keyur@arrcus.com
ジョブ・スナイダース

Fastly

アムステルダム

オランダ

メール: job@fastly.com
コティカラプディ・スリラム

米国国立標準技術研究所

100 Bureau Drive

Gaithersburg, MD 20899

アメリカ合衆国

メール: ksriram@nist.gov

 更新履歴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.8.9: draft-ietf-sidrops-aspa-verification-18
2024.10.2: draft-ietf-sidrops-aspa-verification-19、セクション9.1
プロバイダ名	HQ	ASN
AT&T	米国	7018
ドイツ・テレコム	ドイツ	3320
GTTコミュニケーションズ	米国	3257
リバティ・グローバル	オランダ	6830
ルーメン・テクノロジーズ	米国	3356
NTTコミュニケーションズ	日本	2914
Orange	フランス	5511
PCCW	香港	3491
タタ・コミュニケーションズ	インド	6453
テレコム・イタリア	イタリア	6762
Arelion	スウェーデン	1299
Telxius	スペイン	12956
Verizon	米国	701
Zayo	米国	6461