Lỗi xử lý BGP gây bất ổn định định tuyến Internet

 (blog.benjojo.co.uk)
1 điểm bởi GN⁺ 2025-05-29 | 1 bình luận | Chia sẻ qua WhatsApp
  • Vào 07:00 UTC ngày 20/5/2025, một thông điệp BGP bị lỗi được lan truyền đã gây hành vi ngoài dự kiến trong 2 triển khai BGP lớn, khiến nhiều phiên BGP kết nối Internet bị reset, đồng thời gây bất ổn định định tuyến hoặc mất kết nối ngắn ở một số mạng
  • Bản cập nhật có vấn đề mang BGP Prefix-SID Attribute, thứ thường không được kỳ vọng xuất hiện trong các bản cập nhật BGP trên Internet, và ở trạng thái bị lỗi với toàn bộ dữ liệu bên trong là 0x00
  • IOS-XR/Nokia SR-OS có áp dụng cơ chế chịu lỗi dựa trên RFC7606 đã lọc được thông điệp này, nhưng JunOS đã chuyển tiếp còn Arista EOS reset phiên, có thể ảnh hưởng đến người dùng Arista kết nối với transit carrier dựa trên JunOS
  • Theo quan sát của bgp.tools, AS9304, AS135338, AS151326 và AS138077 xuất hiện lặp lại; bên đã thêm thuộc tính lỗi nhiều khả năng là Starcloud AS135338 hoặc Hutchison AS9304
  • Trong sự cố, tốc độ thông điệp trung bình 10 giây của route collector bgp.tools đã tăng từ mức bình thường 20.000–30.000 thông điệp/giây lên hơn 150.000/s, cho thấy khác biệt trong xử lý lỗi BGP có thể làm lung lay độ ổn định của tuyến Internet thực tế

Sự cố cập nhật BGP ngày 20/5/2025

  • Vào thứ Ba, ngày 20/5/2025 lúc 07:00 UTC, một thông điệp BGP được lan truyền đã gây hành vi ngoài dự kiến trong 2 triển khai BGP lớn thường dùng để chuyển tiếp lưu lượng Internet
  • Ảnh hưởng lan rộng khi nhiều phiên BGP kết nối Internet tự động bị chấm dứt
    • Bất ổn định định tuyến được xác nhận ở một số mạng
    • Trong trường hợp xấu nhất, có thể đã xảy ra mất kết nối trong thời gian ngắn

Thông điệp BGP gây vấn đề

  • Bản cập nhật được xác nhận trên các phiên cấp dữ liệu cho bgp.tools là một BGP Update tương đối bình thường cho một /16, nhưng có chứa BGP Prefix-SID Attribute gây vấn đề
  • Thuộc tính này nguy hiểm vì hai lý do
    • Đây là thuộc tính không được kỳ vọng xuất hiện trong các bản cập nhật BGP của bảng Internet
    • Đây là thuộc tính bị lỗi với toàn bộ dữ liệu bên trong là 0x00
  • Hầu hết các triển khai như IOS-XR/Nokia SR-OS, khi bật “BGP error tolerance” dựa trên RFC7606, đã lọc đúng thông điệp này và không gây vấn đề
  • Với tổ hợp JunOS và Arista EOS, kết quả lại khác
    • JunOS chuyển tiếp thông điệp bị lỗi
    • Thiết bị Arista EOS reset phiên khi nhận thông điệp dường như đến từ thiết bị JunOS này
  • Vì nhiều Internet transit carrier dùng phần cứng Juniper chạy JunOS, các mạng vận hành Arista EOS và kết nối với router transit carrier upstream dựa trên JunOS có thể đã bị mất truy cập Internet trong một khoảng thời gian
    • Thời lượng ước tính tối đa khoảng 10 phút

Các AS ứng viên đã thêm thuộc tính lỗi

  • Sau khi lọc kho lưu trữ bgp.tools trong giai đoạn đó, có vẻ nhiều origin AS đã liên quan đến sự cố
  • Điều này cho thấy thuộc tính có thể đã được thêm bởi một carrier trung gian trên đường ra Internet rộng hơn, chứ không phải mạng origin của prefix
  • 4 ứng viên xuất hiện lặp lại trong toàn bộ các thông điệp có vấn đề là:
    • AS9304 — Hutchison Global Communications Limited
    • AS135338 — Starcloud Information Limited
    • AS151326 — DCConnect Communication Pte. Ltd.
    • AS138077 — PT Abhinawa Sumberdaya Asia
  • bgp.tools đã quan sát thấy các prefix bị ảnh hưởng trên đường […] 151326 138077 […] mà không có thuộc tính BGP bị lỗi
    • Do đó, bên đã thêm thuộc tính lỗi nhiều khả năng là Starcloud AS135338 hoặc Hutchison AS9304
  • Một số prefix được quan sát trong các bản cập nhật có chứa thuộc tính này gồm:
    • 156.230.0.0/16
    • 138.113.116.0/24
    • 163.171.102.0/24
    • 163.171.103.0/24
    • 163.171.104.0/24

Con đường lan sang các Internet exchange

  • Sự cố trở nên lớn hơn vì Hutchison/AS9304 kết nối với nhiều Internet exchange
  • Thông điệp có vấn đề được gửi tới các IX route server, và các route server này thường chạy bird
  • Bird không hỗ trợ BGP SID nên không thể lọc thông điệp, và đã phân phối nguyên trạng đến nhiều Internet exchange quy mô multi-terabit
  • Kết quả là sự hỗn loạn lan ra phạm vi rộng hơn, vượt ngoài các phiên Internet transit

Bản chất của BGP Prefix-SID

  • BGP Prefix-SID Attribute thường chỉ nên xuất hiện trong các phiên BGP nội bộ
  • Mục đích được định nghĩa trong RFC8669 là giúp xác định lưu lượng sẽ đi theo đường nào tới đích bên trong một mạng đơn lẻ
  • Lý do thuộc tính này rò rỉ ra bảng định tuyến toàn cầu có thể là do một phiên BGP bên ngoài đã được cấu hình như phiên nội bộ

Các mạng bị ảnh hưởng và chỉ số quan sát

  • Khó khẳng định chính xác ai bị ảnh hưởng, nhưng dựa trên các nơi có mức churn rất lớn so với quy mô mạng ngay sau thông điệp BGP gây vấn đề đầu tiên, ước tính khoảng 100 mạng đã gặp sự cố
  • Các ví dụ có độ tin cậy cao gồm:
  • Bình thường, route collector bgp.tools thu thập khoảng 20.000–30.000 thông điệp mỗi giây
  • Trong sự cố này, tốc độ thông điệp trung bình 10 giây đã vượt xa 150.000/s
    • Điều này cho thấy đã có gián đoạn đáng kể trên nhiều tuyến Internet

Khác biệt xử lý lỗi giữa các nhà cung cấp

  • Dù nguyên nhân gốc rễ hoặc bên thực sự gây ra chưa hoàn toàn rõ ràng, việc một thông điệp lỗi được lan truyền ở quy mô Internet cho thấy rủi ro trong xử lý lỗi BGP
  • Các nhà cung cấp khác đã phát hiện thuộc tính lỗi và chặn quảng bá route, nhưng Juniper đã lan truyền nó tới peer
  • Sau khi thông điệp này đến thiết bị Arista, mã BGP error tolerance không tồn tại hoặc có lỗi, dẫn đến reset phiên
  • Tài liệu BGP error tolerance của JunOS của Juniper cho biết JunOS không kiểm tra mọi phần của thông điệp
  • Hành vi này khiến JunOS tự tránh được việc bị reset phiên từ xa, nhưng lại chuyển tiếp cùng thông điệp đó sang peer khác hoặc về phía khách hàng

Hàm ý vận hành

  • Outage lần này diễn ra ngắn, nhưng đã có thể gây tác động lớn hơn
  • Khi ngày càng nhiều dịch vụ chuyển sang dựa trên IP, phạm vi của sự cố Internet có thể vượt xa việc không truy cập được email
    • Lỗi phát sóng TV
    • Gián đoạn cuộc gọi dịch vụ khẩn cấp
  • Những lỗi kiểu này làm tăng khả năng gây ra hoặc làm trầm trọng thêm thiệt hại về người trong thế giới thực
  • Nhà vận hành mạng có toàn bộ bảng định tuyến có thể cung cấp data feed cho bgp.tools để hỗ trợ debug các sự cố trong tương lai

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-05-29
Các ý kiến trên Hacker News

  • Cách tiếp cận tiêu chuẩn là phải khoan dung khi nhận vào và nghiêm ngặt khi gửi ra
    Các lựa chọn là lọc các thông điệp bị lỗi, loại bỏ chúng, bỏ qua thuộc tính bị lỗi nhưng vẫn chuyển tiếp, hoặc bị hỏng vì thuộc tính bị lỗi; theo tôi, điều thật sự khó chấp nhận chỉ là lựa chọn số 4, tức hành vi kiểu Arista. Hành vi kiểu Juniper ở số 3 tuy không lý tưởng nhưng cũng không chí mạng
    Đọc lại thì có vẻ Arista không phải số 4 mà gần với số 2 hơn; dường như họ coi đó là kết nối sai và đóng lại, chứ không crash hoàn toàn. Với người dùng thì không tốt, nhưng xét về mặt tranh luận thì vẫn có thể chấp nhận được

    • Đã có RFC 7606 (Revised Error Handling for BGP UPDATE Messages), quy định khá chi tiết cách xử lý các thông điệp BGP bị lỗi
      Cách phổ biến nhất là treat-as-withdraw, tức xử lý bản cập nhật quảng bá tuyến như một thao tác thu hồi tuyến đã quảng bá trước đó. Nếu chỉ bỏ qua thông điệp bị lỗi thì sẽ tiếp tục giữ trạng thái cũ không còn hợp lệ nữa, nên không được làm vậy
    • Điều được diễn đạt lại ở đây là cái gọi là nguyên tắc vững chắc, tức định luật Postel
      Đây là một ý tưởng xuất phát từ thời cổ đại của Internet trong thập niên 1980 và 1990, nhưng ngày nay được hiểu rộng rãi là một ý tưởng sai lầm đã gây ra sự cứng hóa giao thức và rất nhiều vấn đề bảo mật
    • Vấn đề nằm ở chỗ mọi người đã tận dụng trên toàn mạng hành vi của BGP là chuyển tiếp cả các thuộc tính không xác định mà thiết bị cục bộ không hiểu
      Giờ đây nhiều hệ thống phụ thuộc vào hành vi đó, và đang phải chịu các nhược điểm của “tính năng” ấy
    • Trong bài liên quan, tác giả cũng chỉ ra đúng điểm này
      Nhìn bề ngoài, “tính năng” này có vẻ là một ý tưởng rất tệ, vì nó khiến thông tin không xác định lan truyền mù quáng qua các hệ thống không hiểu tác động của thông tin mà chúng chuyển tiếp. Nhưng cũng có thể nói chính nhờ tính năng này mà những thứ như Large Communities có thể được triển khai rộng rãi nhanh hơn, và bản thân việc triển khai các tính năng BGP mới mới trở nên khả thi
    • Tôi không đồng ý với cách tiếp cận này. Theo tôi, tốt hơn là phải rất nghiêm ngặt cả khi nhận vào lẫn khi gửi ra

  • Tôi vẫn còn nhớ cảnh phải chạy đôn chạy đáo như điên để vá CVE-2023-4481 trên toàn bộ mạng
    Những loại lỗi như thế này đúng là ác mộng để xử lý, và do cách BGP được thiết kế/triển khai, việc sửa những hành vi như vậy sẽ mất rất lâu

  • Dù đã là chuyện từ vài chục năm trước, tôi từng phát triển tính năng BGP tại một hãng thiết bị viễn thông
    Tôi vẫn nghĩ BGP quá phức tạp, còn mọi người thì cứ tiếp tục thêm tính năng mới và các hãng thì liên tục triển khai dựa trên tiêu chuẩn hoặc bản nháp RFC
    Có vẻ BGP cũng sẽ không bị loại bỏ, nên những lỗi kiểu này có lẽ sẽ còn được phát hiện lặp đi lặp lại trong tương lai

    • Chắc chắn đã có một giai đoạn AT&T cùng Juniper và Cisco đẩy BGP vào một vùng hoàn toàn phức tạp thông qua các tính năng liên quan đến MPLS và VPN
      Cá nhân tôi thấy nó phức tạp đến đáng sợ, nhưng với ai đó thì lại rất sinh lời

  • HGC Global Communications Limited là công ty trước đây được biết đến với tên Hutchison Global Communications Limited, một nhà cung cấp dịch vụ Internet tại Hồng Kông
    https://en.wikipedia.org/wiki/HGC_Global_Communications

  • Các khung máy IOS XR của chúng tôi cũng nhận được một số gói kiểu này, và thời điểm trùng với lượng quảng bá tuyến BGP tăng cao. Nói thật là tôi không biết upstream đang dùng thiết bị gì
    Tôi tự hỏi liệu giao thức BGP có đang được fuzzing đúng cách không. Có thể đây là lĩnh vực quá quan trọng nên ai cũng sợ thử làm hỏng nó
    Viết một BGP fuzzer có thể dễ, nhưng chẩn đoán nguyên nhân crash thì có vẻ sẽ rất khó

  • Có lẽ tôi chưa từng học về BGP cho đến khi nghe nói nó gây ra vấn đề. Dù cũng thiết yếu với Internet như TCP/IP, TCP/IP thì được học ở đại học, gặp trong quá trình làm việc, và cũng đọc nhiều sách về nó, nhưng BGP thì hầu như không gặp ở đại học, nơi làm việc hay trong sách
    Với TCP/IP, có thể học bằng cách “nghịch” các dự án đồ chơi ở nhà, còn BGP thì không biết phải làm thế nào. Muốn học BGP ở nhà thì nên làm gì?

    • Mua một router có triển khai BGP là được. Có cả thiết bị rẻ như Mikrotik, và cũng có các triển khai mã nguồn mở
      Bài viết có nhắc đến bird, và còn có một triển khai rất phổ biến là FRR (free range routing). Chạy hai container Docker, tạo một phiên BGP giữa chúng, rồi chẳng hạn quảng bá các tuyến tĩnh đã cấu hình bên trong là việc rất đơn giản
      Nếu thích tutorial dạng có hướng dẫn, https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/ khá tốt, và còn mở rộng sang các chủ đề nâng cao hơn một chút. Mọi thứ cần để làm theo đều là phần mềm tự do
    • DN42[1] cung cấp một sân chơi để thử nghiệm các kỹ thuật định tuyến. Nếu không định bỏ nhiều thời gian, tôi không khuyến nghị đào quá sâu. Ngay cả với người khá quen thuộc với networking, định tuyến WAN vẫn dễ gây bối rối
      Cách dễ nhất để có trải nghiệm thực tế với bất kỳ công nghệ networking nào có lẽ là GNS3
      [1]: https://wiki.dn42.us/home
    • BGP giống như vận tải biển quốc tế. Nó bắt buộc phải có để thế giới vận hành, nhưng đa số mọi người không cần tương tác trực tiếp với nó
      Một cách để thử nghiệm là thế này: https://www.eve-ng.net/
      Cách khác là tạo vài máy ảo có vài network interface, dựng mạng giữa chúng, rồi dùng daemon định tuyến BGP
      https://bird.network.cz/
      https://www.nongnu.org/quagga/
      Có những thứ như vậy
    • Trong lớp networking bậc cử nhân thì không học BGP, còn lớp networking cao học thì có
      Chúng tôi dùng một package Python để mô phỏng nhiều AS, nhưng tôi không nhớ đó là package nào
    • Trong lớp mạng bậc cử nhân có học một chút về BGP, nhưng chỉ là giải thích trên bảng
      Muốn thử nghiệm BGP thì có thể dùng trình mô phỏng mạng như tác giả bài này. Trong lớp, chúng tôi dùng gini[1], hình như do nghiên cứu sinh của giáo sư làm, còn tác giả có vẻ dùng gns3, trông như một phiên bản ns3 chuyên cho Cisco. Tôi từng dùng ns3 một lần và thấy đường cong học tập khá dốc. Trình mô phỏng gini có giao diện người dùng cơ bản hơn, nhưng có lẽ chức năng cũng kém mạnh hơn
      [1] https://citelab.github.io/gini5/
      [2] https://docs.gns3.com/docs/

  • Có vẻ BGP sẽ ổn định hơn nhiều nếu nhiều nhà cung cấp phần cứng thống nhất được một cách tiêu chuẩn để xử lý loại việc này
    Vấn đề thực sự có phải là mỗi nhà cung cấp đều muốn hiệu ứng khóa chân khách hàng nên không chuẩn hóa không?
    Tuy nhiên, hiểu biết của tôi về BGP còn nông và yếu, tôi không phải chuyên gia

  • Nghĩ đến ảnh hưởng của những lỗi như thế này, thật ngạc nhiên là không có một consortium nào có bộ kiểm thử tương tác liên thông
    Có lẽ là có, nhưng vấn đề cụ thể này không nằm trong test suite. Nếu vậy thì cũng đáng ngạc nhiên là họ không dùng fuzzer hoặc cách sinh bằng máy để rà soát mọi lỗi packet có thể và tạo test case. Dù chạy bộ test mất vài giờ hay vài ngày thì cũng đáng mà
    Tác giả bài này đã tạo một fuzzer có mức độ bao phủ nhất định, và có vẻ trước đây cũng từng gặp vấn đề tương tự. Thật ngạc nhiên là các nhà cung cấp không chủ động tiếp nhận công việc này

  • Nhiều nhà cung cấp từng gặp lỗi này trong quá khứ: https://www.kb.cert.org/vuls/id/347067
    Đã có CVE-2023-4481 (Juniper), CVE-2023-38802 (FRR), CVE-2023-38283 (OpenBGPd), CVE-2023-40457 (EXOS)
    Khi đó Arista không bị ảnh hưởng

  • Không biết có thứ gì vừa có quy mô lớn vừa có độ phức tạp ngẫu nhiên rối rắm kiểu Byzantine như hệ thống đường ống của Internet không