介紹
2024 年 6 月 27 日，全球一小部分使用者可能發現 1.1.1.1 無法連線或降級。根本原因是 BGP（邊界閘道通訊協定）劫持和路由洩露的混合。
Cloudflare 是用於路由來源驗證 (ROV) 的資源公開金鑰基礎架構 (RPKI) 的早期採用者。藉助 RPKI，IP 首碼擁有者可以安全地儲存和共用擁有權資訊，其他營運者可以透過將收到的 BGP 路由與以路由來源授權 (ROA) 形式儲存的內容進行比較，來驗證 BGP 公告。當網路正確執行路由來源驗證並且透過 ROA 對首碼進行簽署時，BGP 劫持的影響將大大受到限制。儘管過去幾年 RPKI 的採用有所增加，並且 1.1.1.0/24 已成為簽署資源，但在事件期間，1.1.1.1/32 是由 ELETRONET S.A. (AS267613) 發起的，並被多個網路接受，包括至少一個一級提供者接受 1.1.1.1/32 作為黑洞路由。這導致 70 個國家/地區 300 多個網路的 DNS 解析程式位址立即無法存取，儘管對總體使用者百分比的影響相當低（例如，英國和德國的使用者比例不到 1%），並且一些國家/地區沒有使用者注意到影響。
路由洩漏是 Cloudflare 之前撰寫和討論過的問題，不幸的是，如今在廣泛的部署中，只是採取了盡力而為的保護措施，例如提供者的 IRR（網際網路路由註冊管理機構）首碼清單篩選。在 1.1.1.1/32 劫持的同一時期，1.1.1.0/24 被 Nova Rede de Telecomunicações Ltda (AS262504) 錯誤地洩漏到上游。這起外洩事件被 Peer-1 Global Internet Exchange (AS1031) 進一步廣泛傳播，這也加劇了客戶在事件期間感受到的影響。
對於 1.1.1.1 給使用者帶來的影響，我們深表歉意，並非常重視該服務的運作。儘管影響的根本原因來自 Cloudflare 外部，但我們將繼續改進現有的偵測方法，以實現更快的回應時間，並將利用我們在網際網路社群中的地位，進一步鼓勵採用基於 RPKI 的劫持和洩漏預防機制，例如用於 BGP 的路由來源驗證 (ROV) 和自發系統提供者授權 (ASPA) 物件。
背景
Cloudflare 於 2018 年推出了 1.1.1.1 公用 DNS 解析程式服務。自發佈以來，1.1.1.1 已成為最受歡迎的解析程式 IP 位址之一，任何人都可以免費使用。隨著 IP 位址的普及和易於識別，也帶來了一些操作困難。困難源自於過去實驗室網路使用 1.1.1.1 或將 1.1.1.1 用於測試 IP 位址，導致一些殘留的意外流量或黑洞路由行為。因此，Cloudflare 對於處理 BGP 錯誤路由流量的影響並不陌生，下面介紹了其中的兩個。
BGP 劫持
部分困難來自於 1.1.1.1 的潛在路由劫持。例如，如果某些虛構的 FooBar Networks 將 1.1.1.1/32 指派給他們的一台路由器並在其內部網路中共用此首碼，則其客戶將難以路由至 1.1.1.1 DNS 服務。如果他們在其直接網路之外宣告 1.1.1.1/32 首碼，則影響可能會更大。選擇 1.1.1.1/32 而不是 Cloudflare 宣佈的 1.1.1.0/24 BGP 的原因是最長首碼匹配 (LPM)。雖然路由表中的許多首碼可以匹配 1.1.1.1 位址，例如 1.1.1.0/24、1.1.1.0/29 和 1.1.1.1/32，但 1.1.1.1/32 被 LPM 演算法認為是「最長匹配」，因為它在匹配 1.1.1.1 位址時具有最多的相同位數和最長的子網路遮罩。簡單來說，我們將 1.1.1.1/32 稱為 1.1.1.1 可用的「最具體」路由。
前往 1.1.1.1 的流量不會透過 Anycast 路由到 Cloudflare 並登陸到我們全球的一台伺服器上，而是會登陸 FooBar Networks 內一個裝置上的某個位置，在這個裝置上，1.1.1.1 已經終止，並且合法回應將無法傳回給用戶端。這將被視為對 1.1.1.1 請求的劫持，無論這是由 FooBar Networks 內的網路營運者有意還是無意進行的。
BGP 路由洩露
1.1.1.1 有時會面臨的另一個影響來源是 BGP 路由洩露。就 BGP 公告而言，當一個網路成為其本不應該成為其上游提供者的網路的上游時，就會發生路由洩漏。
以下是路由洩露的範例，其中客戶將從一個提供者處獲知的路由轉發到另一個提供者，導致類型 1 洩露（在 RFC7908 中定義）。
如果無預設路由區域 (DFZ) 內有足夠多的網路接受路由洩漏，則它可能會廣泛用於沿著_不良_路徑轉送流量。通常，這會導致網路洩漏首碼，進而導致過載，因為它們沒有為現在吸引的全球流量做好準備。我們曾就一次大規模路由洩漏事件撰文，當時賓夕法尼亞州的一家提供者將流量吸引到通常不會傳輸流量的全球目的地，導致大部分網際網路癱瘓。儘管 Cloudflare 與全球 13,000 多個網路互連，但指派給洩漏路由的 BGP local-preference 可能高於網路直接從 Cloudflare 接收的路由。這聽起來適得其反，但不幸的是這是可能發生的。
為了解釋為什麼會發生這種情況，可以將 BGP 視為業務原則引擎以及網際網路的路由通訊協定。傳輸提供者的客戶向他們付費以傳輸資料，因此從邏輯上講，他們指派的 BGP local-preference 應高於與私人或 Internet Exchange (IX) 對等方的連線，以便付費的連線得到最充分的利用。將 local-preference 視為影響將流量傳送至哪個傳出連線的優先順序的一種方式。不同的網路也可以選擇私人網路互連 (PNI) 而非 Internet Exchange (IX) 接收的路由。部分原因是可靠性，因為私人連線可視為兩個網路之間的點對點連線，無需擔心中間有第三方受管理結構。另一個原因可能是成本效率，就比如如果您不辭辛勞地配置了路由器連接埠並在自己和另一個對等方之間購買了交叉連線，您肯定會希望利用它來獲得最佳的投資回報。
值得注意的是，BGP 劫持和路由洩漏都可能發生在網際網路上的任何 IP 和首碼上，而不僅僅是 1.1.1.1。但如前所述，1.1.1.1 是一個非常容易識別且過去曾被侵佔的位址，因此它比其他 IP 資源更容易發生意外劫持或洩漏。
在 2024 年 6 月 27 日發生的 Cloudflare 1.1.1.1 事件中，我們最終對抗了 BGP 劫持和路由洩漏共同造成的影響。
事件時間表和影響
所有時間均為世界標準時間 (UTC)。
2024-06-27 18:51:00 AS267613 (Eletronet) 開始向對等方、提供者和客戶宣告 1.1.1.1/32。1.1.1.1/32 由 AS267613 來源 AS 宣告
2024-06-27 18:52:00 AS262504 (Nova) 洩漏 1.1.1.0/24，同時也從 AS267613 接收，成為 AS1031 (PEER 1 Global Internet Exchange) 的上游，AS 路徑為「1031 262504 267613 13335」
2024-06-27 18:52:00 AS1031（Nova 的上游）將 1.1.1.0/24 傳播給各種 Internet Exchange 對等方和路由伺服器，從而擴大了洩漏的影響
2024-06-27 18:52:00 一家一級提供者從 AS267613 收到 1.1.1.1/32 公告作為 RTBH（遠端觸發黑洞）路由，導致該一級提供者的所有客戶的流量被重新導向
2024-06-27 20:03:00 針對來自不同國家/地區的 1.1.1.1 可存取性問題，Cloudflare 宣佈發生內部事件
2024-06-27 20:08:00 Cloudflare 停用正在接收流向 1.1.1.0/24 之流量的 AS267613 合作夥伴對等互連位置
2024-06-27 20:08:00 Cloudflare 團隊就此事件與對等互連合作夥伴 AS267613 進行接洽
2024-06-27 20:10:00 AS262504 洩漏了 1.1.1.0/24，並提供新的 AS 路徑「262504 53072 7738 13335」，該路徑也由 AS1031 重新分配。沿著此路徑，流量成功傳送到 Cloudflare，但受影響用戶端的延遲較高
2024-06-27 20:17:00 Cloudflare 就 1.1.1.0/24 路由洩漏到其上游提供者的問題與 AS262504 接洽
2024-06-27 21:56:00 Cloudflare 工程師停用 AS267613 的第二個對等互連點，該點正在從巴西以外的多個來源接收傳送至 1.1.1.0/24 的流量
2024-06-27 22:16:00 AS262504 再次洩漏 1.1.1.0/24，吸引了一些流量到與聖保羅的 AS267613 對等互連的 Cloudflare。結果，一些 1.1.1.1 請求以較高的延遲返回，但 1.1.1.1/32 的劫持和流量黑洞似乎已解決
2024-06-28 02:28:00 AS262504 徹底解決 1.1.1.0/24 的路由洩漏問題
對顧客的影響表現為以下兩種方式之一：完全無法存取 1.1.1.1；能夠存取 1.1.1.1，但每個請求的延遲較高
由於 AS267613 劫持了其網路內某處的 1.1.1.1/32 位址，因此許多請求在其自發系統中的某些裝置上失敗。在事件發生期間，服務時斷時續，或出現震盪，儘管出現高延遲，但他們將針對 1.1.1.1 的請求成功地路由到 Cloudflare 資料中心。
查看事件期間的兩個來源國家（德國和美國），1.1.1.1 流量的受影響情況如下所示：
使用者來源國家/地區：
請記住，總體而言，這可能代表每個來源國家/地區的總請求量相對較小，但通常不會有針對 1.1.1.1 的請求從美國或德國路由到巴西。
Cloudflare 資料中心城市：
從圖表中可以看出，對 1.1.1.1 的請求已到達巴西資料中心。峰值之間的間隙是當 1.1.1.1 請求在 AS267613 之前或內部被重新導向的情況，而峰值本身是當流量傳送到 Cloudflare 的情況，請求和回應呼叫的延遲很高。使用 AS267613 成功傳輸到 Cloudflare 對等互連位置的流量出現短暫峰值，可以解釋為 1.1.1.1/32 路由在其網路內波動，偶爾會讓流量流向 Cloudflare，而不是在中間路徑中的某個位置丟棄。
錯誤的技術說明及其發生的原因
通常，使用者對 1.1.1.1 的請求會透過 BGP Anycast 路由到最近的資料中心。事件期間，AS267613 (Eletronet) 向其對等方和上游提供者宣告 1.1.1.1/32，AS262504 向上游洩漏了 1.1.1.0/24，從而極大地改變了多個眼球網路的 BGP Anycast 正常路徑。
透過公用路由收集器和 monocle 工具，我們可以搜尋惡意 BGP 更新。
我們在上面看到 AS398465 和 AS13760 向 route-views 收集器報告，它們在影響開始時從 AS267613 收到了 1.1.1.1/32。通常，無預設路由區域 (DFZ) 中接受的最長 IPv4 首碼是 /24，但在本次情況中，我們觀察到多個網路使用來自 AS267613 的 1.1.1.1/32 路由進行轉寄，這從從未到達 Cloudflare POP（存在點）的流量重新導向中可以明顯看出來。AS267613 發起的 1.1.1.1/32 是 BGP 路由劫持。儘管路由來源授權 (ROA) 僅針對最大首碼長度為 /24 的 AS13335 (Cloudflare) 進行簽署，但它們還是宣告了來自 AS267613 的首碼。
當我們在 Cloudflare 查看我們自己的 BMP（BGP 監控通訊協定）資料時，我們甚至看到了 1.1.1.1/32 的 BGP 更新。至少從幾個不同的路由伺服器上，我們透過 BGP 收到了我們自己的 1.1.1.1/32 公告。值得慶幸的是，由於 AS 來源和首碼長度無效導致 RPKI Invalid 和 DFZ Invalid，Cloudflare 在匯入時拒絕了這些路由。BMP 資料顯示是預先原則，這表示即使我們拒絕了該路由，我們也可以看到透過對等互連工作階段接收 BGP 更新的位置。
monocle search --start-ts 2024-06-27T18:51:00Z --end-ts 2024-06-27T18:55:00Z --prefix '1.1.1.1/32'
A|1719514377.130203|206.126.236.209|398465|1.1.1.1/32|398465 267613|IGP|206.126.236.209|0|0||false|||route-views.eqix
–
A|1719514377.681932|206.82.104.185|398465|1.1.1.1/32|398465 267613|IGP|206.82.104.185|0|0|13538:1|false|||route-views.ny
–
A|1719514388.996829|198.32.132.129|13760|1.1.1.1/32|13760 267613|IGP|198.32.132.129|0|0||false|||route-views.telxatl因此多個網路不僅接受本不應該存在於全球路由表中的首碼，而且還接受 RPKI（資源公開金鑰基礎架構）Invalid 路由。雪上加霜的是，一家一級轉接服務提供者接受了來自 AS267613 的 1.1.1.1/32 公告作為 RTBH（遠端觸發黑洞）路由，並在其邊緣捨棄了通常會路由至 Cloudflare 的所有流量。僅這一點就造成了廣泛的影響，因為在事件發生期間，利用該特定一級提供者路由到 1.1.1.1 的任何網路都無法存取該 IP 位址。
遠端觸發黑洞是一種向提供者發出訊號的方法，表明您希望在其網路中捨棄流量的一組目的地。它也是一種抵禦 DDoS 攻擊的直接方法。當您的特定 IP 或首碼受到攻擊時，您可以告訴上游提供者，在流量到達您的網路連接埠之前將其捨棄，以吸收流向該目的地 IP 位址或首碼的所有流量。此次事件的主要問題是 AS267613 未經授權將 1.1.1.1/32 作為黑洞。Cloudflare 應該擁有獨家權利，利用 RTBH 來捨棄流向 AS13335 的流量，而這是我們在現實中永遠不會做的事情。
現在看看 1.1.1.0/24 的 BGP 更新，多個網路收到了來自 AS262504 的首碼並且接受了它。
在這裡，我們再次關注 AS 路徑。這一次，AS13335 是公告最後的來源 AS。此 BGP 公告的狀態為 RPKI Valid，因為正確的來演恰好就是 AS13335，但這屬於 1.1.1.0/24 的路由洩漏，因為該路徑本身無效。
我們如何知道這是路由洩漏？
~> monocle search --start-ts 2024-06-27T20:10:00Z --end-ts 2024-06-27T20:13:00Z --prefix '1.1.1.0/24' --as-path ".* 267613 13335" --include-sub
.. some advertisements removed for brevity ..
A|1719519011.378028|187.16.217.158|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|187.16.217.158|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views2.saopaulo
–
A|1719519011.629398|45.184.147.17|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|45.184.147.17|0|0|1031:1031 1031:4209 1031:4259 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519036.943174|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|route-views.amsix
–
A|1719519037|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|rrc03
–
A|1719519087.4546|45.184.146.59|199524|1.1.1.0/24|199524 1031 262504 267613 13335|IGP|45.184.147.17|0|0||false|13335|162.158.177.1|route-views.fortaleza
A|1719519087.464375|45.184.147.74|264409|1.1.1.0/24|264409 1031 262504 267613 13335|IGP|45.184.147.74|0|0|65100:7010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519096.059558|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3
–
A|1719519128.843415|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3查看範例路徑「199524 1031 262504 267613 13335」，從功能角度而言，AS267613 是 AS13335 的對等方，並且不應該與其對等方或上游提供者共用 1.1.1.0/24 公告，而只能與其客戶 (AS Cone) 共用。AS262504 是 AS267613 的客戶，也是路徑中的下一個相鄰 ASN，因此，到這個階段為止，這個特殊的公告沒有問題。1.1.1.0/24 出錯的地方是 AS262504，因為此時它們向上游的 AS1031 宣告了首碼。而且，AS1031 將該宣告重新分發給自己的對等方。
這意味著，AS262504 是洩露網路。AS1031 接受了來自其客戶 AS262504 的路由洩漏，並由於在全球多個對等互連位置分發該路由而造成了廣泛影響。AS1031 (Peer-1 Global Internet Exchange) 宣告自己是全球對等互連交換中心。Cloudflare 不是 AS1031 的客戶，因此，1.1.1.0/24 本不應被重新分發到 AS1031 的對等方、路由伺服器或上游提供者。AS1031 似乎並沒有對客戶 BGP 工作階段執行任何廣泛的篩選，而是僅匹配了相鄰的網路（在本次事件中為 AS262504）並重新分發符合此準則的所有內容。遺憾的是，AS1031 這種不負責任的行為，對 1.1.1.1 造成了直接影響，以及可能導致其他服務成為此次毫不謹慎的路由傳播的犧牲品。雖然最初洩露網路是 AS262504，但在 AS1031 和其他網路接受了劫持或洩露的路由並且進一步分發公告後，事件的影響顯著增大。
在本次事件的大部分時間裡，AS262504 引發的洩露最終導致請求進入 AS267613，而 AS267613 在其網路內的某個地方捨棄了 1.1.1.1/32 流量。最終，AS262504 實際上透過將路由洩漏到上游，放大了無法存取 1.1.1.1 所帶來的影響。
為減輕路由洩露的影響，Cloudflare 停用了 AS267613 在多個位置的對等互連。但問題並未徹底結束，因為 AS262504 仍在洩漏指向聖保羅的陳舊路徑。儘管回應使用者的往返時間較長，但到達聖保羅的請求能夠得到處理。Cloudflare 一直在與本篇部落格文章中提到的所有網路就 BGP 洩露和未來的預防機制進行溝通，以及與至少一家一級轉接提供者進行溝通，該提供者接受了 AS267613 傳送的 1.1.1.1/32，將其作為未經 Cloudflare 授權的黑洞路由，並造成了廣泛影響。
補救措施和後續步驟
BGP 劫持
RPKI 來源驗證RPKI 最近達到了一個重要里程碑：50% 的部署採用路由來源授權 (ROA) 對首碼進行簽署。雖然 RPKI 確實有助於限制遭到劫持的 BGP 首碼在整個網際網路中的傳播，但我們需要所有網路發揮各自的作用，特別是擁有大量下游自發系統 (AS) 的主要網路。在 1.1.1.1/32 劫持事件期間，多個網路接受並使用了 AS267613 宣告的路由來進行流量轉寄。
RPKI 和遠端觸發黑洞 (RTBH)此次事件造成的大部分影響，是因為一家一級提供者接受了 1.1.1.1/32 作為來自非 Cloudflare 的第三方的黑洞路由。這本身就是一種 1.1.1.1 劫持事件，而且是非常危險的行為。RTBH 是一個實用工具，許多網路在急需緩解大規模 DDoS 攻擊時都會使用 RTBH。但問題是，用於 RTBH 的 BGP 篩選機制本質上比較鬆散，通常僅依賴于網際網路路由註冊管理機構中的 AS-SET 物件。依靠路由來源授權 (ROA) 進行 RTBH 篩選是不可行的，因為這會需要為 Cloudflare 這樣規模龐大的網路建立數千個潛在的 ROA。不僅如此，建立特定的 /32 項目可能會導致某個單獨的位址（例如 1.1.1.1/32）被某個冒充 AS13335 的網路進行宣告，成為網際網路上通向 1.1.1.1 的最佳路由並造成嚴重影響。
AS-SET 篩選並不代表有權重新導向某個路由，例如 1.1.1.1/32。只有 Cloudflare 才能將自己有權操作的目的地重新導向。要解決在 RTBH 工作階段上對提供者進行的篩選過於寬鬆的問題，一個潛在方法仍然是利用 RPKI。使用來自 IETF 的一個範例，已過期的 draft-spaghetti-sidrops-rpki-doa-00 提案指定了一個捨棄來源授權 (DOA) 物件，該物件將用於僅授權特定來源對首碼執行重新導向動作。如果對該物件進行了簽署，並且對其執行了 RTBH 請求驗證，則 AS267613 嘗試對 1.1.1.1/32 執行未經授權的重新導向將被視為無效，而不會被一級提供者接受。
BGP 最佳做法只需按照 MANRS 所述的 BGP 最佳做法來操作，並拒絕無預設路由區域 (DFZ) 中長度超過 /24 的 IPv4 首碼，即可減輕對 1.1.1.1 的影響。拒絕更廣泛的網際網路中的無效首碼長度，應該成為所有網路的標準 BGP 原則的一部分。
BGP 路由洩露
路由洩漏檢測（Route Leak Detection）
雖然目前對於 Cloudflare 來說，路由洩露並非不可避免，但由於網際網路本質上依賴于信任來實現互連，因此，我們將採取一些措施來限制此類事件的影響範圍。
我們已擴充用於路由洩露偵測系統的資料來源，以涵蓋更多網路，並且正在將即時資料整合到偵測系統中，以便日後更及時地回應類似事件。
適用於 BGP 的 ASPA
我們會繼續提倡將 RPKI 納入基於 AS 路徑的路由洩露防禦機制中。自發系統提供者授權 (ASPA) 物件與 ROA 類似，不同之處則在於它不是使用已獲授權的來源 AS 來簽署首碼，而是使用允許傳播其路由的提供者網路清單對 AS 本身進行簽署。因此，對於 Cloudflare 而言，只有有效的上游轉接提供者才會獲得授權來宣告 AS13335 首碼，例如 1.1.1.0/24 上游提供者。
在路由洩露範例中，AS262504（AS267613 的客戶）與上游提供商共用了 1.1.1.0/24，如果 AS267613 對其授權提供者進行了簽署，並且 AS1031 根據該清單驗證了路徑，那麼 BGP ASPA 就可以發現此洩漏事件。不過，與 RPKI 來源驗證方法類似，這將是一項長期工作，並且依賴於網路（尤其是大型網路提供者）能夠基於 ASPA 物件拒絕無效的 AS 路徑。
其他可能的方法
在不同的採用階段，確實存在一些值得留意的 ASPA 替代方法。然而，並不能保證這些方法能夠進入網際網路廣泛部署的階段。
例如，RFC9234 在 BGP 功能和屬性中使用對等角色的概念，並根據更新路徑上的路由器設定，可以在首碼中新增「Only-To-Customer」(OTC) 屬性，以防首碼（例如 1.1.1.0/24）沿著洩漏路徑傳播到上游提供者。它的缺點是需要完成 BGP 設定，才能將各種角色指派給每個對等互連工作階段；以及仍然需要完全解決廠商的採用問題，才能使其在實際生產中得到應用並取得積極成果。
與所有解決路由洩露的方法一樣，網際網路上的網路營運商之間必須通力合作才能取得成功。
結論
Cloudflare 的 1.1.1.1 DNS 解析程式服務同時遭遇了 BGP 劫持和 BGP 路由洩漏事件。雖然外部網路的行為不在 Cloudflare 的直接控制範圍內，但我們計劃在網際網路社群和 Cloudflare 內部採取一切措施，加快偵測問題的速度並減輕對使用者的影響。
從長遠來看，Cloudflare 將繼續支援採用基於 RPKI 的來源驗證以及 AS 路徑驗證。前者已在全球最大型的網路中廣泛部署，而後者仍處於網際網路工程任務推動小組 (IETF) 的起草階段。與此同時，若要核實您的網際網路服務提供者 (ISP) 是否在強制執行 RPKI 來源驗證，您可以隨時造訪 isbgpsafeyet.com 並_測試您的 ISP_。