Lỗi xử lý BGP gây ra tình trạng 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
  • Do lỗi xử lý thông điệp BGP, vào ngày 20 tháng 5 năm 2025 đã xảy ra tình trạng bất ổn định định tuyến trên diện rộng và hiện tượng gián đoạn kết nối Internet ở một số mạng
  • Nguyên nhân của sự cố là BGP Prefix-SID Attribute bị lỗi, gây ra phản ứng bất thường trong các triển khai BGP lớn, đặc biệt là JunOS và Arista EOS
  • Một số nhà mạng transit, bao gồm Hutchison và Starcloud, đã chuyển tiếp thông điệp gây lỗi, khiến thiệt hại lan rộng
  • Sự cố đã gây ra reset hàng loạt các phiên BGP và bất ổn định tại hơn khoảng 100 mạng
  • Sự việc lần này nhấn mạnh lỗ hổng trong khả năng chịu lỗi BGP theo từng vendor và nhu cầu cải thiện

27 tháng 5 năm 2025

Tình trạng bất ổn định định tuyến Internet toàn cầu do lỗi xử lý BGP

Vào 7 giờ sáng UTC thứ Ba, ngày 20 tháng 5 năm 2025, khi một thông điệp BGP được lan truyền, đã xuất hiện hành vi ngoài dự kiến ở hai triển khai BGP chủ chốt thường được dùng để xử lý lưu lượng Internet

Hệ quả là nhiều “phiên BGP kết nối Internet” bị tự động đóng, dẫn đến từ mức bất ổn định định tuyến tối thiểu cho đến nghiêm trọng nhất là mất kết nối tạm thời ở một số mạng

Thông điệp BGP gây sự cố

  • Phân tích các phiên được thu thập bởi bgp.tools cho thấy thông điệp BGP Update gây ra hiện tượng này trông có vẻ bình thường, nhưng chứa BGP Prefix-SID Attribute bị hỏng với dữ liệu bên trong được lấp đầy bằng 0x00
  • Hầu hết các triển khai BGP (IOS-XR, Nokia SR-OS) đều lọc đúng theo RFC7606 (BGP error handling), nhưng sự cố phát sinh trong tương tác giữa JunOS và Arista EOS
    • JunOS giữ lại rồi chuyển tiếp thông điệp bị lỗi, còn Arista EOS khi nhận thông điệp đó sẽ đặt lại phiên BGP
  • Trong các môi trường sử dụng nhiều phần cứng Juniper (JunOS), nếu kết nối với Arista EOS thì có thể xảy ra gián đoạn truy cập Internet kéo dài tới khoảng 10 phút

Bên phát ra thông điệp lỗi

  • Khi phân tích kho lưu trữ bgp.tools trong giai đoạn đó, có nhiều AS origin liên quan

  • Điều này cho thấy không phải mạng tạo ra Prefix, mà là nhà mạng transit ở giữa đường đi đã thêm Attribute sai

  • Các AS chính có liên quan đến sự cố gồm:

    • AS9304 (Hutchison Global Communications Limited)
    • AS135338 (Starcloud Information Limited)
    • AS151326 (DCConnect Communication Pte. Ltd.)
    • AS138077 (PT Abhinawa Sumberdaya Asia)

  • Dựa trên dữ liệu bgp.tools, bên thực sự thêm Attribute nhiều khả năng là Starcloud (AS135338) hoặc Hutchison (AS9304)

  • Các Prefix tiêu biểu mà Attribute đó được lan truyền qua gồm 156.230.0.0/16, 138.113.116.0/24, v.v.

  • Hutchison/AS9304 kết nối với nhiều Internet exchange (IX), đồng thời thông điệp cũng được lan tới các route server dùng bird

  • Bird không hỗ trợ BGP SID nên đã chuyển thông điệp tới rất nhiều IX mà không lọc, làm mức độ hỗn loạn trên toàn mạng trở nên trầm trọng hơn

BGP Prefix-SID là gì?

  • BGP Prefix-SID Attribute thông thường chỉ nên được dùng trong các phiên iBGP, và được sử dụng để định nghĩa đường đi tới đích trong một mạng duy nhất (RFC8669)
  • Nguyên nhân Attribute này bị rò rỉ ra bảng định tuyến toàn cầu có thể là do các phiên eBGP được cấu hình giống như phiên nội bộ

Đối tượng bị ảnh hưởng

  • Dù khó xác định chính xác nạn nhân, sự cố đã được ghi nhận ở khoảng hơn 100 mạng có mức biến động (churn) rất lớn sau thông điệp BGP ban đầu
  • Bình thường, route collector của bgp.tools thu thập 20.000 đến 30.000 thông điệp mỗi giây, nhưng tại thời điểm sự cố đã ghi nhận trung bình hơn 150.000 trong mỗi 10 giây
  • Đây là tín hiệu cho thấy sự cố nghiêm trọng đã xảy ra trên diện rộng đối với các tuyến Internet

Trách nhiệm của vendor và hàm ý từ sự cố

  • Dù nguyên nhân gốc chưa hoàn toàn chắc chắn, việc một thông điệp lỗi có thể lan rộng ở quy mô Internet chứng minh rằng các vấn đề xử lý lỗi BGP hiện có là rủi ro thực tế
  • Các vendor khác đã lọc Attribute lỗi, nhưng Juniper đã gián tiếp cho phép nó đi qua và chuyển tới thiết bị Arista, dẫn tới reset phiên do phần mã chịu lỗi BGP còn thiếu sót
  • Tài liệu chính thức của JunOS cũng nêu rõ rằng hệ thống “không kiểm tra toàn bộ thông điệp”
  • Với thiết kế này, JunOS ngăn được rủi ro reset phiên từ xa đối với chính nó, nhưng vẫn có khả năng chuyển tiếp thông điệp lỗi sang peer hoặc khách hàng khác

Kết luận

  • Sự cố lần này chỉ kéo dài trong thời gian ngắn, nhưng cho thấy nếu quy mô lớn hơn thì hậu quả có thể nghiêm trọng hơn nhiều

  • Khi các dịch vụ ngày càng chuyển sang nền tảng IP, tác động của sự cố Internet có thể vượt xa việc người dùng không truy cập được email, mà còn lan sang phát sóng TV bị gián đoạn, không gọi được dịch vụ khẩn cấp, v.v.

  • Điều này nhấn mạnh rằng về mặt thực tế, thậm chí có thể dẫn tới thiệt hại về nhân mạng, và do đó cần triển khai chắc chắn hơn khả năng chịu lỗi BGP ở từng vendor

  • Có thông tin mời các nhà vận hành mạng tham gia hỗ trợ phân tích dữ liệu bgp.tools (có cung cấp liên kết)

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-05-29
Ý kiến trên Hacker News

  • Nhìn chung, nguyên tắc "hào phóng khi nhận, cụ thể khi gửi ra" được biết đến như cách tiếp cận tiêu chuẩn

    • Có các lựa chọn như lọc bỏ thông điệp bị lỗi (drop, filter), bỏ qua riêng thuộc tính rồi vẫn chuyển tiếp (break), hoặc cắt hẳn kết nối (như Arista)

    • Tôi cho rằng cách thứ tư (kiểu Arista) là hành vi thực sự khó chấp nhận nhất

    • Cách thứ ba (Juniper) cũng không lý tưởng, nhưng tôi không nghĩ có thể xem đó là vấn đề mang tính chí mạng

    • Chỉnh sửa: đọc lại thì hóa ra Arista không phải cách thứ tư mà là cách thứ hai (đóng kết nối)

    • Họ chỉ coi luôn kết nối là không hợp lệ rồi đóng lại; xét về trải nghiệm người dùng thì đây không hẳn là quyết định tốt, nhưng vẫn ở mức có thể chấp nhận được

    • RFC 7606 (xử lý lỗi cải tiến cho thông điệp BGP UPDATE) đã tồn tại từ trước, và trong đó nêu rất cụ thể cách xử lý thông điệp bị lỗi

      • Cách phổ biến nhất là 'treat-as-withdraw' (xử lý như thể tuyến đã bị withdraw)
      • Nếu chỉ đơn giản bỏ qua thông điệp lỗi thì sẽ phát sinh vấn đề là trạng thái cũ vẫn được giữ nguyên dù trên thực tế nó không còn hợp lệ

    • Nguyên tắc "hào phóng khi nhận và cụ thể khi gửi ra" chính là điều người ta vẫn gọi là "robustness principle" hoặc "Postel's law"

      • Đây là khái niệm có nguồn gốc từ thời kỳ đầu của Internet trong thập niên 1980~90
      • Nhưng hiện nay ngành này đã nhìn nhận rộng rãi rằng đó là một lối suy nghĩ sai lầm
      • Chính nguyên tắc đó đã gây ra sự cứng hóa giao thức và vô số vấn đề bảo mật

    • Đã từng có nhiều vấn đề diễn ra trên toàn mạng do lợi dụng đặc tính hoạt động của BGP, cụ thể là thiết bị cục bộ có thể chuyển tiếp nguyên trạng các thuộc tính mà nó không hiểu

      • Giờ đây chúng ta đang trải nghiệm thực tế nơi nhược điểm của "tính năng" này dần lộ rõ

    • Tác giả cũng chỉ ra điểm này trong bài viết liên quan

      • "Tính năng" này buộc hệ thống chuyển tiếp dữ liệu mà nó không hiểu một cách thiếu phê phán, nên thoạt nhìn đây là một ý tưởng cực kỳ tệ
      • Tuy vậy, nhờ tính năng này mà các tính năng mới như Large Communities có thể lan rộng rất nhanh, và việc đưa các tính năng BGP mới vào sử dụng cũng trở nên khả thi

    • Tôi không đồng ý với cách tiếp cận đó

      • Theo tôi, tốt hơn nhiều là phải chặt chẽ và cụ thể cả ở thứ chấp nhận lẫn thứ gửi ra

  • Tôi vẫn còn nhớ như in cảnh phải cuống cuồng vá lỗi CVE-2023-4481 trên toàn mạng

    • Loại lỗi này về sau cũng sẽ tiếp tục là cơn ác mộng để xử lý
    • Với đặc thù trong thiết kế và cách triển khai của BGP, tôi lo rằng sẽ mất rất lâu mới sửa được hẳn những hành vi kiểu này

  • Trước đây tôi từng phát triển tính năng BGP ở một hãng thiết bị viễn thông (chuyện cũng khá lâu rồi)

    • Tôi vẫn thấy BGP quá phức tạp

    • Người ta cứ tiếp tục thêm tính năng mới, còn vendor thì lặp đi lặp lại việc triển khai theo tiêu chuẩn hoặc draft

    • Với bản chất gần như sẽ không bao giờ bị loại bỏ của BGP, tôi có cảm giác các lỗi kiểu này sẽ cứ tái diễn mãi

      • Trước đây, các nhà mạng như AT&T cùng các vendor như Juniper, Cisco... từng đẩy BGP vào các tính năng liên quan đến MPLS và VPN, khiến hệ thống rơi vào độ phức tạp rất sâu
        • Quá mức phức tạp, nhưng một số bên đã kiếm được rất nhiều tiền từ đó

  • HGC Global Communications Limited (đổi tên từ Hutchison Global Communications Limited, viết tắt là HGC) là một nhà cung cấp dịch vụ Internet ở Hồng Kông

  • Có cảm giác BGP sẽ ổn định hơn nhiều nếu các vendor phần cứng cùng thống nhất tiêu chuẩn cho những vấn đề như thế này

    • Tôi tự hỏi liệu vấn đề thực sự có nằm ở chỗ mỗi vendor ngại tiêu chuẩn hóa để giữ chân khách hàng trong hệ sinh thái riêng của họ hay không
    • Xin nói trước là hiểu biết của tôi về BGP chỉ ở mức nông

  • Không biết có phải chỉ mình tôi không, nhưng trước khi nghe nói nó gây ra sự cố gì đó thì tôi còn chưa từng nghe đến BGP

    • Đây là giao thức thiết yếu của Internet giống như TCP/IP, nhưng trong khi TCP/IP được dạy nhiều ở trường, trong công việc và trong sách vở, thì tôi chưa từng được học về BGP lần nào
    • Ở nhà vẫn có thể tự thực hành và học TCP/IP, nhưng tôi hoàn toàn không biết phải "vọc ở nhà" với BGP như thế nào

      • Nếu có cách nào để tự thực hành BGP tại nhà thì tôi rất muốn biết

      • Bạn có thể mua router thật có triển khai BGP (trong phân khúc rẻ có những thiết bị như Mikrotik), hoặc dùng các implementation mã nguồn mở

        • Có bird trong bài viết, và FRR (Free Range Routing) rất phổ biến
        • Bạn có thể chạy hai Docker container, thiết lập phiên BGP giữa chúng rồi thử quảng bá static route các kiểu
        • Nếu muốn có tutorial, hướng dẫn ở liên kết này được trình bày khá tốt để làm theo bằng phần mềm miễn phí

      • DN42 là một sân chơi để thực hành kỹ thuật định tuyến

        • Tuy nhiên phải đầu tư thời gian đáng kể, không phải kiểu có thể thử nhẹ nhàng
        • Bản thân tôi cũng làm networking khá nhiều nhưng vẫn thấy định tuyến WAN khó hiểu
        • GNS3 là cách dễ nhất để tự thực hành hầu như mọi công nghệ mạng
        • Wiki DN42

      • Trong môn mạng ở bậc cử nhân của tôi không có BGP, nhưng ở lớp cao học thì có học về BGP

        • Hồi đó chúng tôi dùng một gói Python có thể mô phỏng nhiều AS, nhưng tôi không còn nhớ chính xác tên gói nữa

      • Trong lớp mạng bậc cử nhân mà tôi từng học, BGP chỉ được nhắc sơ qua trên bảng

        • Để thực hành BGP, bạn có thể dùng network simulator như tác giả đã dùng
        • Lớp của chúng tôi dùng simulator tên là gini, đó là chương trình do nghiên cứu sinh của giáo sư viết
        • gns3 mà tác giả dùng giống như một phiên bản kiểu ns3 thiên về Cisco
        • ns3 có quá nhiều thứ để học nên thấy khá khó
        • gini có giao diện dễ hơn nhưng hiệu năng kém hơn
        • Giới thiệu dự án gini
        • Tài liệu chính thức của gns3

      • Có cảm giác muốn thật sự "thực hành" BGP thì phải quản lý một mạng quy mô lớn có kết nối với lưu lượng Internet thật

        • Còn những gì có thể đụng vào ở nhà thì chỉ là dùng network simulator mà thôi

  • Trước đây nhiều vendor khác cũng từng có lỗi tương tự như trong bài

    • Thông tin lỗ hổng liên quan
    • CVE-2023-4481 (Juniper), CVE-2023-38802 (FRR), CVE-2023-38283 (OpenBGPd), CVE-2023-40457 (EXOS), v.v.
    • Arista là bên không bị ảnh hưởng trong đợt đó

  • Thiết bị chassis IOS XR của chúng tôi cũng từng nhận gói tin tương tự

    • Đồng thời cũng có trải nghiệm xuất hiện rất nhiều quảng bá tuyến BGP

    • Tôi không rõ chính xác thiết bị upstream là gì

    • Điều này khiến tôi tự hỏi liệu giao thức BGP có đang được fuzz test một cách bài bản hay không

    • Vì đây là giao thức quá quan trọng nên có thể người ta cũng không dám chủ động tạo sự cố để thử

    • Viết fuzzer cho BGP có lẽ không khó, nhưng việc chẩn đoán crash thì có thể cực kỳ khó

      • (tác giả bài viết)
        • Vâng, đó chính xác là điều tôi đã thực sự làm trong bài đăng của mình
        • Bài viết liên quan

  • Điều này khiến người ta phải tự hỏi liệu còn có hệ thống nào khác vừa đồ sộ như Internet backbone lại vừa chồng chất nhiều độ phức tạp ngẫu phát đến vậy hay không

  • Xét đến mức độ ảnh hưởng của kiểu lỗi này, tôi khá ngạc nhiên vì tưởng phải có một consortium nào đó vận hành bộ kiểm thử tương tác như interoperability test suite

    • Hoặc cũng có thể nó thực sự tồn tại, chỉ là vấn đề này bị lọt khỏi phạm vi kiểm thử
    • Có vẻ hiển nhiên là nên dùng fuzzer hay máy móc để tự động tạo ra nhiều test case với mọi lỗi gói tin có thể, nhằm tăng độ bao phủ
    • Dù thời gian chạy có kéo dài vài ngày cũng không sao
    • Tác giả bài gốc thực sự đã tạo và dùng fuzzer, và gặp nhiều vấn đề tương tự nhiều lần
    • Tôi thấy khá lạ khi các vendor lại không tích cực quan tâm đến những nghiên cứu quan trọng như thế này