我們今天來介紹一下 Cloudflare Radar 的路由洩露資料及 API，以便任何人皆可透過網際網路獲取路由洩露的相關資訊。我們已經構建一個綜合的系統，可從公開來源擷取資料，並透過我們龐大的全域網路來獲取 Cloudflare 的網際網路視圖。該系統目前透過 API 推送 Cloudflare Radar ASN 頁面上的路由洩露資料。
這篇部落格文章分為兩個部分，探討了 BGP 及路由洩露，接著詳細介紹了我們的路由洩露偵測系統及其如何為 Cloudflare Radar 推送資訊。
關於 BGP 及路由洩露
網域間路由（即於網路間交換連通性資訊）對網際網路的健康及效能至關重要。邊界閘道通訊協定 (BGP) 是一種實際上使用的路由通訊協定，可在組織及網路間交換路由資訊。BGP 的核心是假設待交換資訊均真實且值得信賴，可惜，對於當下的網際網路而言，這不再是一個有效假設。在許多情況下，網路可能會出錯或故意謊報可連通性資訊，並將其傳播至網際網路的其餘部分。此類事件可能會嚴重中斷網際網路的正常運作。這種破壞性事件的其中一種類型是路由洩露。
我們將路由洩露視為超出其預期範圍之路由公告的傳播 (RFC7908)。路由洩露可能導致出現影響數百萬網際網路使用者的重大中斷，正如我們在過去許多轟動事件中所看到的那樣。例如，2019 年 6 月，美國賓州一個小型網路 (AS396531 - Allegheny Technologies Inc) 中的設定錯誤不慎將 Cloudflare 首碼洩露給 Verizon，後者繼續將設定錯誤之路由傳播給其他對等體及客戶。如此一來，大部分網際網路的流量透過小型網路之有限容量連結予以擠壓。這樣會產生擁塞，導致進出受影響 IP 範圍的大部分 Cloudflare 流量出現下降。
2018 年 11 月發生的類似事件導致 Google 服務出現大面積癱瘓，當時，奈及利亞 ISP (AS37282 - Mainone) 不慎向其對等體及提供者洩露了數量龐大的 Google IP 首碼，這違反了無谷原則。
這些事件不僅說明路由洩露可能帶來極大的影響力，還說明小型區域網路中的設定錯誤可能對全球網際網路產生滾雪球效應。
儘管及時偵測及改正路線洩露至關重要，但通常只有在使用者開始報告洩露的顯著影響時，才會實施偵測。偵測及防止路由洩露的挑戰源於以下事實：AS 業務關係及 BGP 路由原則通常並未公開，而受影響網路通常與路由洩露的根源相距甚遠。
在過去幾年裡，已經提議防止傳播已洩露路由的解決方案。此類提議包括 RFC9234 和 ASPA，利用兩個相連 AS 網路之間的關係類型將 BGP 擴展至註釋工作階段，以阻止並防止路由洩露。
實施 BGP 角色類似信令的替代提議是使用 BGP 社群（一種在 BGP 公告中對中繼資料進行編碼的傳遞屬性）。雖然從長遠來看，這些方向大有前景，但它們仍處於非常初步的階段，預計不會很快得到大規模採用。
Cloudflare 開發了一個系統來自動偵測路由洩露事件，並將通知傳送至多個管道，從而實現可見性。隨著我們繼續努力向公眾提供更多相關資料，在此很榮幸宣布，我們今天為路由洩露偵測結果推出一個開放資料 API，並將結果整合至 Cloudflare Radar頁面。
路由洩露定義與類型
開始討論系統的設計方式之前，我們先快速了解什麼是路由洩露，以及為何偵測路由洩露非常重要。
我們參閱了已發布的 IETF RFC7908 文件「BGP 路由洩露的問題定義及分類」來定義路由洩露。
> 路由洩露是超出相應預期範圍的路由公告傳播。
_預期範圍_通常具體定義為基於自治系統 (AS) 間業務關係的網域間路由原則。儘管可能具有更複雜的安排，這些業務關係可大致分為四類：客戶、傳輸提供者、對等體及同級。
在客戶-提供者關係中，客戶 AS 與另一個網路達成協定，將其流量傳輸至全域路由表。在點對點關係中，兩個 AS 同意免費進行雙邊流量交換，但僅限在其自有 IP 與其客戶的 IP 間交換。最後，隸屬於同一個管理實體的 AS 可被視為同級，通常享有不受限制的流量交換。下圖闡述了如何將三種主要關係類型轉換為匯出原則。
透過對 AS 層級關係的類型及其對 BGP 路由傳播之影響作出分類，我們能夠在傳播期間定義首碼起始公告的多個階段：
向上：此階段的所有路徑區段均為客戶到提供者
對等：一個點對點路徑區段
向下：此階段的所有路徑區段均為提供者到客戶
遵循無谷路由原則的 AS 路徑將包含向上、對等、向下階段，所有這些階段皆為可選項，但必須按此順序排列。這裡有一個遵從無谷路由的 AS 路徑範例。
在 RFC7908「BGP 路由洩露的問題定義與分類」中，創建者定義了六種路由洩露類型，我們在系統設計中參考了這些定義。這裡是每種路由洩露類型的插圖。
類型 1：具有完整首碼的髮卡彎
> 多重主目錄 AS 從一個上游 ISP 獲知路由，並將其輕鬆傳播至另一個上游 ISP（轉彎與髮卡基本相似）。正在更新的首碼及 AS 路徑均不會更改。
包含提供者-客戶及客戶-提供者區段的 AS 路徑可視為類型 1 洩露。以下範例：AS4 → AS5 → AS6 形成類型 1 洩露。
類型 1 是最廣為人知的路由洩露類型，具有極大的影響力。在很多情況下，客戶路由比對等體或提供者路由更受青睞。在本範例中，AS6 可能更喜歡透過 AS5 而非其他對等體或提供者路由傳送流量，從而導致 AS5 意外成為傳輸提供者。這可能會對與洩露首碼相關的流量效能產生重大影響，如未佈建洩露 AS 來處理大量湧入的流量，則會導致出現中斷。
2015 年 6 月，區域性 ISP 馬來西亞電信 (AS4788) 將從提供者及對等體處獲知的逾 170,000 個路由洩露給另一個提供者 Level3（AS3549，現為 Lumen）。Level3 接受了這些路由，並將其進一步傳播到下游網路，繼而在全球範圍內導致出現嚴重的網路問題。
類型 2：橫向 ISP-ISP-ISP 洩露
根據定義，類型 2 洩露是將從一個對等體獲取的路由傳播給另一個對等體，從而建立兩個或多個連續點對點路徑區段。
這裡有一個範例：AS3 → AS4 → AS5 形成 2 型洩露。
此類洩露的其中一個範例是依次出現三個以上非常大型的網路。非常大型的網路（如 Verizon 及 Lumen）並未相互購買傳輸，並在路徑上依次排列三個以上的該等網路，這通常就是路由洩露的征兆。
不過，在現實世界中，多個小型對等網路交換路由並相互傳遞的情況不在少數。具備這種網路路徑存在合法的商業原因。較之類型 1，我們對這種路由洩露不甚關心。
類型 3 及 4：提供者路由到對等體；對等體路由到提供者
這兩種類型涉及將路由從提供者或對等體傳播至另一個對等體或提供者，而不是傳播到客戶。這裡闡述了兩種洩露類型：
如前述範例所述，與 Google 對等的奈及利亞 ISP 不慎將其路由洩露給提供者 AS4809，因而導致出現類型 4 路由洩露。由於透過客戶傳播的路由往往更受其他人青睞，因此大型提供者 (AS4809) 透過其客戶（即洩露 ASN）將其流量重新路由到 Google，導致小型 ISP 不堪重負，致使 Google 癱瘓一個多小時。
路由洩露摘要
迄今為止，我們已經研究 RFC7908 中定義的四種路由洩露。這四種路由洩露的共同點就是，它們係使用 AS 關係定義而來，即對等體、客戶及提供者。我們根據路由的獲悉和傳播位置對 AS 路徑傳播做出分類，從而匯總洩露類型。結果如下表所示。
路由自/傳播到
| Routes from / propagates to | To provider | To peer | To customer |
|---|---|---|---|
| From provider | Type 1 | Type 3 | Normal |
| From peer | Type 4 | Type 2 | Normal |
| From customer | Normal | Normal | Normal |
至提供者
至對等體
至客戶
來自提供者
類型 1
類型 3
普通
來自對等體
類型 4
類型 2
普通
來自客戶
普通
普通
普通
我們可以將整個表格改述為一個規則：從非客戶 AS 取得的路由僅可傳播至客戶。
注意：根據定義，類型 5 及類型 6 路由洩露係重新生成首碼以及公告私有首碼。類型 5 與首碼劫持更密切相關，我們計劃在後續步驟中擴展我們的系統，而類型 6 洩露並不屬於這項工作的範疇。感興趣的讀者可以參閱RFC7908的第 3.5 節及第 3.6 節了解更多資訊。
Cloudflare Radar 路線洩露系統
我們現在已經知道何謂路線洩露，再來講講我們如何設計路線洩露偵測系統。
從非常高的層面上說，我們將系統劃分為三個不同組成部分：
原始資料收集模組：負責從多種來源蒐集 BGP 資料，並向下游消費者提供 BGP 訊息串流。
洩露偵測模組：負責確定指定的 AS 層級路徑是否為路由洩露、預估評估的信賴區間，彙整並提供進一步分析事件所需的所有外部證據。
儲存及通知模組：負責提供對所偵測路由洩露事件的存取權限，並向相關方傳送通知。這還可能包括構建一個儀表板，以便輕鬆存取及搜尋歷史事件，並提供使用者介面，以便對事件執行高階分析。
資料收集模組
我們將三種類型的資料輸入納入考量：
歷史：過去某個時間範圍內的 BGP 封存檔案a. RouteViews 和 RIPE RIS 封存
半即時：BGP 封存檔案一經可用，會有 10-30 分鐘的延遲。a. RouteViews 及 RIPE RIS 封存具備可定期檢查新檔案的資料代理程式（例如 BGPKIT 代理程式）
即時：真正的即時資料來源a. RIPE RIS Liveb. Cloudflare 內部 BGP 來源
對於目前版本，我們會使用偵測系統的半即時資料來源（即來自 RouteViews 和 RIPE RIS 的 BGP 更新檔案。為了實現資料完整性，我們會處理來自這兩個專案的所有公用收集器（總共 63 個收集器及逾 2,400 個收集器對等體）的資料，並實施一個能在資料檔案可供使用時執行 BGP 資料處理的管道。
對於資料檔案索引和處理，我們部署了一個已啟用 Kafka 功能來傳遞訊息的內部部署 BGPKIT 代理程式實例，以及一個基於 BGPKIT 剖析器 Rust SDK 的自訂同時間 MRT 資料處理管道。資料收集模組處理 MRT 檔案，並以每天超過 20 億條 BGP 訊息（大約每秒 30,000 條訊息）的速度將結果轉化為 BGP 訊息流。
路由洩漏檢測（Route Leak Detection）
路由洩露偵測模組在個別 BGP 公告層級上運作。 偵測元件一次會調查一條 BGP 訊息，並預估指定的 BGP 訊息因路由洩露事件引發的可能性有多大。
我們的偵測演算法以無谷模型為主要依據，我們認為其能擷取大部分值得注意的路由洩露事件。如前所述，使用無谷模型偵測路由洩露時，保持較低誤判率的關鍵是擁有精準的 AS 層級關係。並非每個 AS 都會公開這些關係類型，但是，而透過使用公開觀察到的 BGP 資料來研究關係類型的推理已有二十多年的研究歷史。
雖已證明先進的關係推理演算法高度準確但即使是很小的誤差幅度，在偵測路由洩露時仍會導致不準確。為了減輕此類偽影，我們合成了多個資料來源推斷 AS 層級的關係，包括 CAIDA/UCSD 的 AS 關係資料以及我們內部構建的 AS 關係資料集。建基於兩個 AS 層級關係之上，我們在每個首碼及每個對等體層級建立了一個更精細的資料集。藉由改進的資料集，我們能夠回答以下問題：AS1 和 AS2 與收集器對等體 X 觀察到的首碼 P 之間是什麼關係。這消除了基於首碼及地理位置具有多種不同關係之網路個案中的大部分歧義，從而幫助我們減少系統中的誤判數量。除了 AS 關係資料集，我們亦應用來自 IHR IIJ 的 AS 霸權資料集，來進一步減少誤判。
路由洩露儲存及演示
處理每條 BGP 訊息後，我們會將產生的路由洩露條目儲存於資料庫中，以便長期儲存及探索。我們還匯總了單個路由洩露 BGP 公告，並在短時間內將來自同一洩露 ASN 的相關洩露分組到路由洩露事件中。隨後，路由洩露事件將可供Web UI、API 或警報等不同下游應用程式使用。
Cloudflare Radar 上的路由洩露
Cloudflare 旨在幫助打造一個更好的網際網路，包括分享我們在監控及保護網際網路路由方面所付出的努力。我們今天發布路由洩露偵測系統作為公開測試版。
從今日起，造訪 Cloudflare Radar ASN 頁面之使用者現將找到影響此 AS 的路由洩露清單。我們認為，當洩露者 AS 之前或之後在任意方向僅一跳之遙時，AS 就會受到影響。
可透過 https://radar.cloudflare.com/as{ASN} 直接存取 Cloudflare Radar ASN 頁面。例如，訪客可以導覽至 https://radar.cloudflare.com/as174 以檢視 Cogent AS174 的概觀頁面。ASN 頁面現會顯示一張專屬卡片，以供在所選時間範圍內偵測到與目前 ASN 相關的路由洩露。
使用者還可開始使用我們的公共資料 API 來查找與任何指定 ASN 相關的路由洩露事件。我們的 API 支援按時間範圍篩選路由洩露結果以及相關的 AS。下面是新更新的 API 文件網站上的路由洩露事件 API 文件頁面的螢幕擷取畫面。
更多路由網路安全資訊即將登場
我們計劃在路由洩露偵測方面付出更多努力。隨著時間的推移，更多功能（如全域視圖頁面、路由洩露通知、更進階的 API、自訂自動化指令碼及歷史封存資料集）將開始在 Cloudflare Radar 上亮相。 您的回饋及建議對於我們持續改進偵測結果並向公眾提供更好的資料亦非常重要。
此外，我們將繼續擴展我們在網際網路路由網路安全其他重要主題方面的工作，包括全域 BGP 劫持偵測（不限於我們的客戶網路）、RPKI 驗證監控、開源工具及架構設計，還有集中式路由網路安全 Web 閘道。我們的目標是為社群提供最佳的資料及工具，以維持路由網路安全，以便我們能夠攜手打造更美好、更安全的網際網路。
與此同時，我們在開發者 Discord 伺服器上開啟了一個 Radar 聊天室。歡迎加入並與我們交談，團隊熱切希望收到回饋以及解答疑問。
造訪 Cloudflare Radar 可了解更多網際網路洞見。您亦可在 Twitter 上關注我們，了解更多 Radar 更新動態。