SỰ CỐ BGP ROUTE LEAK VÀ GIẢI PHÁP TỐI ƯU TỪ RFC-9234

 

Rò rỉ định tuyến Internet (BGP Route Leak) là sự cố rất phổ biến và gây tác động lớn đến hệ thống mạng và dịch vụ quan trọng của nhiều tổ chức, doanh nghiệp. Một số giải pháp và chính sách đã được áp dụng để giải quyết sự cố này nhưng mang tính thủ công và chưa triệt để. Nhằm tìm kiếm một giải pháp tự động và tối ưu hơn, RFC-9234 đã đề xuất sử dụng và bổ sung một số đặc tính cho giao thức định tuyến BGP để có thể phát hiện và ngăn chặn sự cố này.

 

1. Hiện trạng sự cố BGP Route Leak

BGP Route Leak thường xảy ra đối với những đơn vị có kết nối đa hướng (Multi-homing) với nhiều nhà mạng. Sự cố xảy ra khi những tuyến mạng (BGP Route) học từ nhà mạng này được quảng bá sang cho các nhà mạng khác. Khi đó các đơn vị này vô tình trở thành điểm trung chuyển dữ liệu giữa các nhà mạng, dẫn đến hệ thống mạng của họ bị quá tải và làm ảnh hưởng đến dịch vụ của các nhà mạng.

Sự cố này xảy ra rất thường xuyên với số lượng tuyến bị rò rỉ rất lớn. Dưới đây là số liệu chi tiết về sự cố này trong quý I/2023.

 

Hình 1: Số hệ thống xảy ra tình trạng Route Leak và tuyến bị rò rỉ trong quý I/2023 (theo QratorLabs)

Để có cái nhìn xa hơn, tiếp theo là số liệu sự cố Route Leak xảy ra những quý gần đây. Trong quý I/2023 số hệ thống mạng bị sự cố ít hơn một chút so với quý IV/2022 nhưng số lượng Route bị rò rỉ lại tăng gần gấp đôi.

 

Hình 2: Số nhà mạng xảy ra tình trạng Route Leak và tuyến bị rò rỉ trong những quý gần đây (theo QratorLabs)

Sự cố Route Leak dù xuất phát từ những đơn vị có quy mô rất nhỏ nhưng vẫn có thể gây ảnh hưởng đến hàng triệu người dùng Internet. Điển hình là sự cố vào tháng 6/2019 từ một hệ thống mạng rất nhỏ có AS 396531 của công ty Allegheny Technologies Inc tại Mỹ. Họ đã quảng bá các dãy mạng (Prefix) của Cloudflare cho nhà mạng Verizon, tiếp tục Verizon quảng bá cho các đối tác của mình. Kết quả phần lớn lưu lượng đi đến Cloudflare được đổ về hướng AS 396531 và tình trạng nghẽn mạng đã xảy ra làm ảnh hưởng nặng đến dịch vụ của Cloudflare.

Trước đó, vào tháng 11/2018, nhà mạng nhỏ Mainon có AS 37282 tại Nigeria đã quảng bá một lượng lớn tuyến mạng của Google cho các nhà mạng khác làm ảnh hưởng nhiều dịch vụ của Google trong thời gian 74 phút.

Sự cố Route Leak không chỉ đến từ những nhà mạng nhỏ mà có thể từ những đơn vị rất lớn như sự cố gây ra bởi công ty Akamai vào 01/08/2022. Trong sự cố này Akamai làm rò rỉ 660 tuyến mạng của 203 đơn vị (ASN) thuộc 58 quốc gia và thời gian sự cố kéo dài 3 giờ 9 phút.

Hình 3: Sự cố Route Leak từ Akamai (theo QratorLabs)

Qua phân tích trên, chúng ta nhận thấy các sự cố Route Leak xảy ra liên tục và có thể xuất phát từ bất kỳ hệ thống nào, dù nhỏ hay lớn. Và có thể nói rằng vẫn chưa có giải pháp hữu hiệu thực sự để giải quyết sự cố này.

2. Các nguyên nhân gây ra BGP Route Leak

Trước khi đi sâu tìm hiểu cách thức phòng chống sự cố BGP Route Leak chúng ta điểm qua một số nguyên nhân dẫn đến sự cố này. Các nguyên nhân này được mô tả trong RFC-7908 và được trình bày chi tiết sau đây.

Trong thực tế, các kết nối Internet thường được phân ra hai loại chính là: Transit và Peering. Các đơn vị tham gia kết nối Internet thường đóng một trong ba vai trò là: Customer, Provider và Peer, hoặc có thể cả ba vai trò cùng một lúc.

Hình 4: Tổng quan về kết nối và mối quan hệ các thành phần trong mạng Internet

Customer là khách hàng sử dụng dịch vụ của nhà mạng Provider (ISP). Các Provider lại sử dụng dịch vụ của các nhà mạng quốc tế khác có tên là Upstream Provider. Kết nối giữa Customer với Provider và Provider với Upstream được gọi là Transit vì dùng kết nối này dùng để trung chuyển dữ liệu giữa các bên cho nhau. Một bên của mỗi kết nối phải trả phí định kỳ cho bên kia. Một số nhà mạng (thường trong nước) có kết nối trực tiếp với nhau để trao đổi dữ liệu thay vì phải đi vòng qua Upstream. Trên kết nối này chỉ có dữ liệu của hai nhà mạng mới được trao đổi nên nó có tên gọi là Peering. Với kết nối Peering, mỗi nhà mạng là đối tác ngang hàng (Peer) và cả hai bên không phải trả phí định kỳ.

Từ các việc nắm rõ vai trò của mỗi đơn vị tham gia kết nối Internet như trên, tiếp theo chúng ta cùng tìm hiểu chi tiết các nguyên nhân gây nên tình trạng BGP Route Leak như mô tả trong RFC-7908:

• Tình huống 1 “Nhà mạng-khách hàng-nhà mạng”: Trong trường hợp này, một Customer nhận được Route từ nhà mạng ISP1 lại quảng bá cho nhà mạng ISP2 và trở thành điểm trung chuyển dữ liệu chiều từ ISP2 về ISP1. Khi kết nối giữa Customer với ISP1 hoặc ISP2 bị nghẽn thì việc truy cập dịch vụ của ISP1 bị ảnh hưởng nặng. Đây là trường hợp xảy ra nhiều nhất và thường xuyên trong thực tế.

Hình 5: Tình huống 1 khách hàng làm rò rỉ Route nhận được từ nhà mạng

• Tình huống 2 “Nhà mạng-nhà mạng-nhà mạng”: Trường hợp này các nhà mạng tự làm rò rỉ tuyến mạng. Nhà mạng ISP2 nhận Route từ ISP1 lại vô tình quảng bá cho ISP3 nên ISP2 trở thành điểm trung chuyển lưu lượng chiều từ ISP3 về ISP1. Trường hợp này cũng hay xảy ra nhưng tần suất rất thấp so với trường hợp thứ nhất và ít khi xảy ra tình trạng nghẽn mạng nhưng có thể làm tăng độ trễ mạng, ảnh hưởng đến chất lượng dịch vụ của nhà mạng khác.

Hình 6: Tình huống 2 nhà mạng làm rò rỉ Route nhận được từ đối tác ngang hàng (Peer) khác

 

• Tình huống 3 “Quốc tế-đối tác ngang hàng”: Trường hợp này nhà mạng ISP1 sau khi nhận Route từ hướng kết nối Transit đã quảng bá cho các Peer thay vì chỉ quảng bá những dãy địa chỉ của riêng mình. Việc này làm đổi hướng lưu lượng từ ISP2 đi qua ISP1 rồi truyền tải qua kết nối Transit.

Hình 7: Tình huống 3 nhà mạng làm rò rỉ Route nhận được từ hướng Transit sang cho Peer

• Tình huống 4 “Đối tác ngang hàng-quốc tế”: Trường hợp này ngược  lại với trường hợp trước. Nhà mạng ISP1 khi nhận Route từ hướng kết nối Peering với ISP2 đã quảng bá cho các hệ thống kết nối Transit khác. Việc này làm đổi hướng lưu lượng từ bên ngoài đi về ISP2 thông qua ISP1.

Hình 8: Tình huống 4 nhà mạng làm rò rỉ Route nhận được từ Peer sang hướng Transit

RFC-7908 còn mô tả hai trường hợp tác động làm thay đổi thuộc tính BGP Originate AS hoặc quảng bá Route chi tiết hơn (More-Specific Route) cố tình làm đổi hướng dữ liệu để tấn công hoặc vì mục đích xấu. Hai loại này được phân loại là BGP Route Hijack nên không trình bày chi tiết ở bài viết này.

Dưới đây là bảng tổng kết các trường hợp gây ra sự cố Route Leak, chỉ có sự quảng bá từ hoặc đến Customer là không gây ra sự cố này.

Hình 9: Tổng quát các trường hợp gây ra sự cố Route Leak

3. Các phương án cho BGP Route Leak và giải pháp tối ưu từ RFC-9234

Trước thực tế của vấn đề BGP Route Leak đã có nhiều giải pháp được đề ra và áp dụng trong thực tế, những giải pháp này tập trung vào hai nhóm chính:

- Lọc định tuyến (Route Filtering): Việc đầu tiên và quan trọng nhất đó là kiểm soát việc nhận hoặc quảng bá Route giữa các bên tham gia như trình bày ở trên. Việc khai báo sai chắc chắn sẽ gây ra sự cố. Đối với hướng nhận chỉ nên nhận Route thuộc sở hữu của mỗi bên hoặc theo đồng thuận, cam kết giữa các bên. Việc lọc định tuyến thường dựa vào dãy địa chỉ (Prefix), theo số hiệu mạng ASN (Autonomous System Number) hoặc theo thuộc tính phân nhóm (Community).

- Cập nhật thông tin định tuyến toàn cầu: Các đơn vị sở hữu thông tin định tuyến cần cập nhật thông tin của mình lên các cơ sở dữ liệu toàn cầu như: Internet Routing Registries (IRRs), PeeringDB, khai báo bản ghi ROA (Route Origin Authorization), triển khai xác thực định tuyến RPKI (Resource Public Key Infrastructure) … Ngoài việc khai báo thông tin định tuyến, các đơn vị cần cập nhật cả thông tin liên lạc để có thể phối hợp nhanh chóng khi sự cố xảy ra.

Trong một nỗ lực khác nhằm tăng cường an toàn định tuyến Internet tổ chức Internet Society đã đưa ra chương trình hành động ở quy mô toàn cầu có tên là MANRS (Mutually Agreed Norms for Routing Security). Đây là một tập hợp các hành động chuẩn mực mà tất cả các đơn vị tham gia Internet cần cam kết tuân thủ nhằm đảm bảo cho hạ tầng định tuyến toàn cầu hoạt động ổn định và an toàn. Các hành động trong chương trình MANRS được chia thành bốn nhóm chính: Sàng lọc định tuyến, phòng chống giả mạo địa chỉ, tăng cường phối hợp và cập nhật thông tin định tuyến trên các cơ sở dữ liệu toàn cầu. Thông tin chi tiết về chương trình này tại địa chỉ https://www.manrs.org/programs/.

Hình 10: Bốn nhóm hành động chính của chương trình MANRS

Ngoài các hành động trên, theo kinh nghiệm thực tế, việc đấu nối với trạm trung chuyển Internet cũng là cách giúp giảm thiểu tác động của sự cố. Ví dụ minh họa bên dưới đây mô tả hướng trao đổi dữ liệu không bị tác động dù xảy ra hiện tượng Route Leak loại 1 và 2 nếu các nhà mạng đấu nối với trạm trung chuyển quốc gia VNIX.

Hình 11: Kết nối với VNIX giúp hạn chế ảnh hưởng của sự cố Route Leak

Dù có nhiều giải pháp và chương trình đã được đề xuất nhưng sự sai sót do cấu hình bằng tay là điều không thể tránh khỏi, vì thế cần có một giải pháp mang tính tự động thông qua sử dụng các giao thức. Thay vì sử dụng một giao thức mới để phòng chống sự cố Route Leak, RFC-9234 đã đề xuất sử dụng chính giao thức BGP để tự bảo vệ cho mình thông qua việc bổ sung những tính năng mới cho BGP gồm: khả năng (Capacity), báo hiệu lỗi (Notification) và thuộc tính (Attribute).

Hình 13: Các tính năng bổ sung cho BGP theo RFC-9234

• BGP Role:

Đây là thành phần bổ sung quan trọng nhất, yêu cầu các bên tham gia phiên BGP thống nhất và khai báo chuẩn xác. Vai trò của mỗi bên được mô tả trong RFC-9234. Các vai trò này bắt buộc phải khai báo theo cặp như bảng dưới đây.

Hình 14: Các cặp vai trò BGP Role theo RFC-9234

Các vai trò Provider, Peer và Customer như đã trình bày ở trên. Trong trường hợp các nhà mạng đấu nối thông qua trạm trung chuyển Internet, như VNIX, thì việc khai báo Peering sẽ thông qua thiết bị Route-Server (RS) thay vì sử dụng trực tiếp địa chỉ của nhau, vì thế sẽ phát sinh cặp vai trò RS và RS-Client.

Một Router có thể có nhiều vai trò khác nhau nhưng tại mỗi hướng kết nối chỉ có một vai trò duy nhất. Thông tin BGP Role này được trao đổi thông qua bản tin BGP OPEN ngay sau khi phiên TCP được thiết lập thành công giữa hai BGP Neighbor.

Hình 15: Mô tả cặp vai trò BGP Role trong thực tế

Trong bản tin BGP OPEN có một trường gọi là Optional mô tả khả năng (Capacity) của các BGP Router như: Multi-Protocol (MP-BGP), Graceful Restart, hỗ trợ 4-Byte ASN hay không, Route-Refresh, IPv6, VPNv4, L2VPN, EVPN … BGP Role cũng được mô tả trong trường Optional của bản tin BGP OPEN này.

Hình 16: Cấu trúc bản tin BGP OPEN

• Role Mismatch Notification:

Vì các vai trò của mỗi Routet bắt buộc phải đi theo cặp nên khi một Router đóng vai trò này sẽ dự kiến nhận được bản tin thông báo vai trò bắt cặp tương ứng từ Neighbor. Nếu vai trò nhận được từ Neighbor không tương ứng với vai trò hiện đang khai báo thì Router sẽ gửi phản hồi bằng bản tin BGP Notification với nội dung Role Mismatch (Có Error Code=2, Subcode=11) và hủy thiết lập phiên BGP.

Hình 17: Cấu trúc bản tin BGP NOTIFICATION

Trong trường hợp bản tin BGP Role được gửi đi nhưng Router không nhận được bản tin phản hồi thì sẽ có 2 cách thức xử lý:

- Trường hợp không bắt buộc (Backward Compatibility): Bỏ qua kiểm tra BGP Role, không thông báo Role Mismatch và cho phép thiết lập phiên.

- Trường hợp bắt buộc (Strict Mode): Yêu cầu phải có sự phản hồi vai trò theo cặp tương ứng như quy định nếu không thì gửi thông báo Role Mismatch và không cho phép thiết lập phiên BGP.

• OTC Attribute:

Đây là bổ sung rất quan trọng giúp phát hiện và phòng chống BGP Route Leak một cách tự động. Sau khi đã xác định được vai trò của mỗi BGP Neighbor thì các Router sẽ tự gán thuộc tính OTC cho các Route. Thuộc tính này sẽ không bị thay đổi trong quá trình trao đổi giữa các Router.

Việc xử lý thuộc tính OTC sẽ tùy thuộc vào hướng gửi và nhận, cụ thể theo các quy trình như sau:

Quy trình xử lý hướng GỬI:

- Nếu Route đã có thuộc tính OTC thì Route này sẽ không được gửi cho những Neighbor có vai trò là Provider, Peer và RS.

- Nếu Route chưa có thuộc tính OTC thì sẽ được gán thuộc tính OTC và gửi ra cho Peer, Customer và RS-Client (nếu Router đang đóng vai trò RS). Nội dung gán cho thuộc tính OTC chính là giá trị ASN của Router đó.

Quy trình xử lý hướng NHẬN:

- Nếu Route nhận được từ Provider, Peer hoặc RS mà chưa có thuộc tính OTC thì Router sẽ gán giá trị ASN của Provider, Peer hoặc RS đó cho thuộc tính OTC.

- Nếu một Route nhận được từ Customer hoặc RS-Client và có thuộc tính OTC thì chắc chắn đã xảy ra tình trạng Route Leak, Router nhận được sẽ loại bỏ Route này.

- Nếu một Route nhận được từ Peer với thuộc tính OTC chứa giá trị là ASN khác với ASN của Peer đó thì chắc chắn đang xảy ra tình trạng Route Leak và sẽ loại bỏ thông tin.

Việc khai báo cho tính năng BGP Role rất đơn giản, hình minh họa sau mô tả cách khai báo tính năng này trong phần mềm định tuyến mã nguồn mở BIRD.

Hình 18: Khai báo BGP Role trong BIRD

RFC-9234 này còn rất mới, được ban hành chính thức vào tháng 5/2022, nên hiện nay chưa có nhiều hãng và thiết bị hỗ trợ những tính năng mới này.

Hình 19: Một số phần mềm hỗ trợ RFC-9234

4. Lời kết

Qua nội dung trình bày ở trên, có thể nói rằng tính năng BGP Role và thuộc tính OTC được đề xuất trong RFC-9234 là giải pháp tối ưu nhất hiện nay cho vấn đề BGP Route Leak. Việc sử dụng chính giao thức BGP để tự động phát hiện và ngăn chặn sự cố sẽ cải thiện những hạn chế của các giải pháp trước đây. Một số chuyên gia cho rằng 80% sự cố BGP Route Leak được giảm thiểu nếu sử dụng giải pháp này.

Việc triển khai giải pháp này trong thực tế sẽ tùy thuộc vào đặc thù của đơn vị là nhà mạng, khách hàng hay trạm trung chuyển Internet, đặc biệt là phụ thuộc vào thời điểm tích hợp giải pháp này trên các thiết bị định tuyến của các hãng. Vì thế các đơn vị cần theo dõi thông tin từ các hãng sản xuất về việc hỗ trợ này để có kế hoạch nâng cấp thiết bị và triển khai áp dụng giải pháp một cách sớm nhất.

Hy vọng rằng RFC-9234 là một bước khởi đầu mới để giúp mạng Internet trở nên an toàn và ổn định hơn.

Nguyễn Văn Bình