網際網路流量依賴邊界閘道通訊協定 (BGP) 在網路之間找到路徑。然而，由於設定錯誤或惡意行為，這些流量有時會被誤導。當流量被路由經過原本不應經過的網路時，便稱為路由洩漏。我們已在部落格中多次探討 BGP 路由洩漏及其對網際網路路由的影響，並數次提及未來有望在 BGP 中實現路徑驗證的可能性。
雖然網路社群在驗證網際網路流量的最終目的地方面取得了重大進展，但確保其實際傳輸路徑的安全，仍然是維護可靠網際網路的關鍵挑戰。為了解決這個問題，業界正在採用名為 ASPA（自發系統提供者授權）的新加密標準，旨在驗證網路流量的完整路徑，以防止路由洩漏。
為了協助社群追蹤此標準的推廣情況，Cloudflare Radar 引入了全新的 ASPA 部署監控功能。此檢視畫面讓使用者能夠觀察 ASPA 在五大區域網際網路註冊機構 (RIR) 中隨時間變化的採用趨勢，並在自發系統 (AS) 層級檢視 ASPA 記錄及其隨時間的變更。
要理解 ASPA 的運作方式，先瞭解當前網際網路如何保護流量目的地會有所幫助。
現今，網路使用名為 RPKI（資源公開金鑰基礎架構）的安全基礎架構系統，該系統在過去幾年部署量顯著成長。在 RPKI 中，網路發布稱為 ROA（路由來源授權）的特定加密記錄。ROA 就像一張可驗證的數位身分證，用以確認某個自發系統 (AS) 已被正式授權可宣告特定的 IP 位址。這解決了「來源劫持」問題，即一個網路試圖冒充另一個網路的情況。
ASPA（自發系統提供者授權）正是建立在這個基礎之上。ROA 驗證的是目的地，而 ASPA 驗證的是旅程本身。
當資料在網際網路中傳輸時，它會持續記錄所經過的每一個網路。在 BGP 中，這份記錄被稱為 AS_PATH（自發系統路徑）。ASPA 提供了一種方式，讓網路可以在 RPKI 系統內正式發布一份經過授權的上游提供者清單。這使得任何接收端網路可以查看 AS_PATH，檢查相關的 ASPA 記錄，並驗證流量是否只通過了經過核准的網路鏈。
簡言之，ROA 確保流量到達正確的目的地，而 ASPA 則確保流量是沿著預期且經授權的路徑到達目的地。讓我們來看看路徑評估在實務上是如何運作的。
ASPA 是如何知道某條路由是「繞路」的呢？它倚賴的是網際網路的階層結構。
在一個健康的網際網路路由拓撲中（例如「無谷底」路由，valley-free routing），流量通常遵循固定的傳輸模式：從「客戶」往上傳送至大型提供者（如主要 ISP），可能再橫向連接到另一個大型提供者，然後「向下」流向目的地。您可以將其想像成一座「山峰」的形狀：
上坡段 (The Up-Ramp)：流量從用戶端開始，一路「向上」經過規模越來越大的提供者 (ISP)，ISP 會付費給其他 ISP 以轉送流量。
山頂 (The Apex)：流量抵達網際網路骨幹的最高層，並可能橫跨一個對等連結。
下坡段 (The Down-Ramp)：然後流量「向下」經過各個提供者，最終到達目的地用戶端。
這種結構可視為「無谷底」路由的示意圖：路由從客戶往上傳至一個提供者，可選擇經一個對等連結，再往下傳至目的地客戶。
在此模型中，「路由洩漏」就像是山谷般的凹陷。其中一種洩漏類型是，當流量流向某個客戶，然後意外地嘗試向上返回到另一個提供者時發生的。
這種「先下後上」的移動是不可取的，因為客戶網路並未被設計用來在兩個較大的網路提供者之間轉送流量，也不具備這樣的能力。
ASPA 為網路營運商提供了一種加密方式，用以宣告其經授權的提供者，從而使接收端網路能夠驗證 AS 路徑是否符合預期的結構。
ASPA 透過檢查路由傳播兩端的「關係鏈」來驗證 AS 路徑：
如果「上坡」路徑與「下坡」路徑能夠重疊或在山頂交會，則該路由被視為有效。山峰形狀保持完整。
然而，如果這兩段有效路徑未能交會，即中間存在一個缺少授權或授權無效的缺口，ASPA 便會將此類路徑標記為有問題。這個缺口就代表了「山谷」或洩漏點。
我們來看看一個場景：網路 (AS65539) 從客戶 (AS65538) 接收到一條錯誤的路由。
這位客戶 (AS65538) 試圖將從一個提供者 (AS65537) 收到的流量，「向上」傳給另一個提供者 (AS65538)，扮演提供者之間的橋樑角色。這是典型的路由洩漏行為。現在，讓我們逐步進行 ASPA 驗證。
檢查上坡段：原始來源 (AS65536) 授權了它的提供者。（檢查通過）
檢查下坡段：我們從目的地（AS65539）開始反向查看。我們看到了客戶 (AS65538)。
出現不符：上坡段結束於 AS65537，而下坡段結束於 AS65538。這兩段路徑未能連接。
由於「上坡」路徑和「下坡」路徑無法連接，系統便會將此路由標記為 ASPA 無效。必須進行此路徑驗證的原因是，如果在 RPKI 中沒有簽署的 ASPA 物件，我們就無法得知哪些網路被授權向誰通告哪些首碼。透過為每個 AS 簽署一份提供者網路清單，我們就能知道哪些網路應該能夠橫向或向上游傳播首碼。
ASPA 可以有效防禦偽造來源劫持，在這種攻擊中，攻擊者透過假扮並宣告一條通往真實來源首碼的 BGP 路徑，來繞過路由來源驗證 (ROV)。雖然來源 AS 保持正確，但劫持者與受害者之間的關係是偽造的。
ASPA 允許受害者網路以密碼學方式宣告其實際的授權提供者，從而揭露此種欺騙行為；由於劫持者不在該授權清單上，該路徑將被視為無效而遭到拒絕，從而有效防止惡意重新導向。
然而，ASPA 並不能完全防護偽造來源劫持。至少有一種情況下，即便有 ASPA 驗證，仍無法完全防止針對網路的此類攻擊。例如：當某個提供者對其客戶偽造路徑通告時，ASPA 便無法察覺。
基本上，提供者可以「偽造」與另一個 AS 的對等互連連結，以利用較短的 AS_PATH 長度來吸引來自客戶的流量，即使實際上並不存在這樣的對等互連連結。ASPA 並不能防止提供者的此種路徑偽造，因為 ASPA 僅依據提供者資訊運作，且對對等互連關係一無所知。
因此，雖然 ASPA 可以是拒絕偽造來源劫持路由的有效手段，但在某些罕見情況下它仍會失效，而這些情況值得我們留意。
為您的網路（或自發系統）建立 ASPA 物件，現在在 RIPE 和 ARIN 等註冊機構中已是個簡單的流程。您只需要您的 AS 編號，以及您向其購買網際網路傳輸服務的提供者之 AS 編號。這些是您信任其將您的 IP 位址宣告至整個網際網路的授權上游網路。反過來說，這些也是您授權可以向您傳送完整路由表的網路，該路由表就像一張完整的地圖，指引您如何連接到網際網路的其他部分。
我們想透過一個簡短範例，向您展示建立 ASPA 物件是多麼容易。
假設我們需要為 AS203898 建立 ASPA 物件，這是我們用於 Cloudflare 倫敦辦公室網際網路的 AS。在撰寫本文時，該辦公室有三家網際網路提供者：AS8220、AS2860 和 AS1273。這表示我們將為 AS203898 建立一個 ASPA 物件，其提供者成員清單包含這三家。
首先，我們登入 RIPE RPKI 儀表板，然後導覽至 ASPA 區段：
接著，針對我們想要建立 ASPA 物件的物件，按一下「Create ASPA」（建立 ASPA）。在那之後，只需填寫該 AS 的提供者即可。
就是這麼簡單。經過短暫的等待後，我們就能查詢全球 RPKI 生態系統，找到我們為 AS203898 建立的、包含我們所定義提供者的 ASPA 物件。
ARIN 的流程也很類似，這是目前唯一另一個支援建立 ASPA 物件的區域網際網路註冊管理機構 (RIR)。登入 ARIN 線上平台，前往「Routing Security」（路由安全），然後按一下「Manage RPKI」（管理 RPKI）。
在該頁面中，您可按一下「Create ASPA」（建立 ASPA）。在本例中，我們將為另一個 ASN AS400095 建立 ASPA 物件。
這樣就完成了——現在我們已經為 AS40095 建立了包含提供者 AS0 的 ASPA 物件。
「AS0」這個提供者項目在使用時較為特殊，它表示該 AS 擁有者證明其網路沒有任何有效的上游提供者。根據定義，這意味著每個無傳輸服務的 Tier-1 網路，如果它們確實只有對等互連和客戶關係，最終都應簽署一個物件中僅包含「AS0」的 ASPA。
Cloudflare Radar 的新增 ASPA 功能
我們已在 Cloudflare Radar 中新增了一項 ASPA 部署監控功能。全新的 ASPA 部署檢視，讓使用者能夠查看 ASPA 採用率隨時間的成長，並可根據 AS 註冊資訊，視覺化呈現橫跨五個區域網際網路註冊管理機構 (RIR) 的趨勢。
我們也將 ASPA 資料直接整合進國家/地區和 ASN 路由頁面。使用者現在可以根據當地註冊的客戶 ASN 所關聯的 ASPA 記錄，追蹤不同地區在強化其基礎架構安全方面的進展。
當您深入檢視特定自發系統（例如 AS203898）時，還有更多新功能。
我們可以查看一個網路觀測到的 BGP 上游提供者是否經 ASPA 授權、其 ASPA 物件中的完整提供者清單，以及涉及該 AS 的 ASPA 變更時間表。
隨著 ASPA 終於成為現實，我們擁有了用於網際網路路徑驗證的加密升級。然而，那些從 RPKI 用於路由起始驗證初期就參與的人都知道，要讓 ASPA 在網際網路上真正發揮價值，仍是一條漫長的道路。要實際使用 ASPA 物件並以其驗證路徑，RPKI 中繼方 (RP) 套件、簽署器實作、RTR（RPKI-to-Router 通訊協定）軟體，以及 BGP 實作都需要進行相應修改。
除了採用 ASPA，營運商也應依照 RFC9234 的說明設定 BGP 角色。在 BGP 工作階段中設定的 BGP 角色，將幫助未來路由器上的 ASPA 實作判斷應套用哪種演算法：上游或下游。換句話說，BGP 角色賦予我們能力，可直接將與另一個 AS 的預期 BGP 關係，與實際的鄰居工作階段連結起來。請向您的路由設備供應商確認，是否支援 RFC9234 BGP 角色與 OTC (Only-to-Customer) 屬性實作。
要充分發揮 ASPA 的效益，我們鼓勵大家為自己的 AS 建立 ASPA 物件。建立與維護這些 ASPA 物件需謹慎處理。未來，當網路開始使用這些記錄主動封鎖無效路徑時，若遺漏了合法供應商，可能導致流量被丟棄。然而，管理這項風險的方式，與目前網路處理路由來源授權 (ROA) 的做法並無二致。ASPA 是網際網路路徑驗證的必要密碼學升級，很高興它終於問世！