Mô hình vai trò BGP: Theo dõi mức độ áp dụng tiêu chuẩn RFC 9234

Rò rỉ định tuyến (route leak) đẩy lưu lượng truy cập đi theo những con đường không bao giờ được dự định. Trong quá khứ, chúng tôi đã viết và công khai thảo luận về các vụ rò rỉ định tuyến trong Border Gateway Protocol (BGP), mô tả đây là những sự cố gây ảnh hưởng nghiêm trọng, dẫn đến việc điều hướng sai lưu lượng truy cập qua các đường truyền mạng không mong muốn. Định tuyến BGP được thúc đẩy bởi mối quan hệ giữa các Autonomous Systems (ASes), ví dụ như mối quan hệ khách hàng-nhà cung cấp (customer-provider) và ngang hàng (peer-peer). Khách hàng trả tiền cho nhà cung cấp để truy cập vào phần còn lại của Internet, trong khi các đối tác ngang hàng trao đổi lưu lượng với nhau thường theo thỏa thuận "không thanh toán" (settlement-free), nơi không có tiền bạc trao đổi. Những mối quan hệ này giúp xác định các quy tắc định tuyến tạo nên những con đường hợp lý. Ví dụ, các quy tắc tạo thành một hệ thống phân cấp "không thung lũng" (valley-free) về cách các tuyến đường nên lan truyền: một tuyến đường học được từ nhà cung cấp hoặc đối tác ngang hàng chỉ nên được quảng bá xuống phía dưới cho khách hàng, không bao giờ được quảng bá ngược lên một nhà cung cấp hoặc đối tác ngang hàng khác. Các quy tắc như thế này thể hiện một ý định hoặc kỳ vọng về các tuyến đường Internet. Rò rỉ định tuyến là những gì xảy ra khi ý định đó bị vi phạm.

Trong lịch sử, mỗi mạng lưới phải tự thực hiện ý định này bằng cách sử dụng các chính sách định tuyến phức tạp và dễ xảy ra lỗi. RFC 9234 (Ngăn chặn và phát hiện rò rỉ định tuyến bằng cách sử dụng vai trò trong thông điệp UPDATE và OPEN) đơn giản hóa điều này bằng cách thể hiện ý định ngay trong chính giao thức. Nó giới thiệu một khả năng "BGP Role" mới, yêu cầu hai láng giềng BGP phải đồng ý về mối quan hệ của họ khi phiên làm việc bắt đầu, và một thuộc tính đường dẫn "Only to Customer" (OTC), dùng để đánh dấu các tuyến đường không được phép lan truyền ra ngoài phạm vi khách hàng. Một bộ định tuyến hiểu được OTC có thể tự từ chối một tuyến đường bị rò rỉ mà không cần chính sách do người vận hành viết.

Chúng tôi bắt đầu đánh giá mức độ hiệu quả của RFC 9234 trên Internet và mức độ phổ biến của nó. Dựa vào sự hiện diện ngang hàng toàn cầu của mình, chúng tôi đã phát triển một phương pháp độc đáo để theo dõi việc áp dụng cấu hình BGP Role bằng cách giám sát xem các AS đối tác nào gửi thuộc tính OTC đến Cloudflare. Trong quá trình đó, chúng tôi đã phát hiện ra một điều không ngờ tới: hai mạng lưới Tier-1 lớn đã loại bỏ thuộc tính OTC khỏi các tuyến đường mà họ chuyển tiếp. Chúng tôi đã làm việc với các mạng Tier-1 này để cho phép thuộc tính OTC lan truyền qua mạng của họ, điều này giúp kích hoạt các khả năng ngăn chặn rò rỉ định tuyến cho những người áp dụng sớm RFC 9234. Dưới đây, chúng tôi sẽ trình bày phân tích của mình, lý do tại sao việc loại bỏ OTC lại quan trọng và cách kích hoạt BGP Roles trong mạng lưới của riêng bạn.

Ngăn chặn rò rỉ định tuyến bằng BGP Roles và thuộc tính OTC

Trước khi đi vào các phép đo, hãy nói về cách BGP Roles và thuộc tính OTC thực sự hoạt động.

Rò rỉ định tuyến

Rò rỉ định tuyến là "sự lan truyền của các thông báo định tuyến vượt ra ngoài phạm vi dự định của chúng", như được định nghĩa trong RFC 7908. Phạm vi dự định được xác định bởi các mối quan hệ AS: nhà cung cấp-khách hàng hoặc ngang hàng-ngang hàng.

Các quy tắc này không đối xứng và phụ thuộc vào hướng đi. Các tuyến đường lan truyền tự do xuống dưới: một nhà cung cấp có thể cung cấp cho khách hàng bất cứ thứ gì trong bảng định tuyến của mình. Việc lan truyền các tuyến đường lên trên hoặc sang ngang bị giới hạn ở thông tin 'cục bộ'. Cụ thể, một AS chỉ có thể gửi theo hướng lên trên hoặc sang ngang các tuyến đường mà nó khởi tạo và học được từ chính khách hàng của mình.

Hình dưới đây cho thấy những gì B thực hiện với một tuyến đường mà nó học được từ A, tùy thuộc vào mối quan hệ của A với B.

Nói một cách đơn giản, rò rỉ định tuyến xảy ra khi một AS lấy một tuyến đường học được từ nhà cung cấp hoặc đối tác ngang hàng và quảng bá nó cho một nhà cung cấp hoặc đối tác ngang hàng khác. Tuyến đường này đi xuống hệ thống phân cấp rồi lại đi ngược lên, tạo ra một "thung lũng" trong hệ thống phân cấp mà các mối quan hệ cơ bản chưa bao giờ cho phép. Các đường dẫn định tuyến bắt buộc phải là "không thung lũng" (valley-free).

Vi phạm thuộc tính "không thung lũng" có nhiều hình thức. Một dạng phổ biến là một khách hàng quảng bá một tuyến đường giữa hai nhà cung cấp của mình, còn được gọi là khúc cua kẹp tóc (hairpin turn).

Kịch bản này gây hại cho tất cả mọi người: khách hàng (AS64504) không được trả tiền để chuyển lưu lượng giữa các nhà cung cấp của mình, và nó cũng có thể không đủ khả năng hấp thụ lưu lượng chảy giữa hai mạng lưới thượng nguồn, dẫn đến tăng độ trễ hoặc mất gói tin.

Rò rỉ định tuyến ảnh hưởng đến tất cả mọi người và chúng xảy ra thường xuyên. Đó là lý do tại sao chúng tôi xây dựng hệ thống phát hiện rò rỉ định tuyến Cloudflare Radar để giúp theo dõi các bất thường định tuyến một cách liên tục. Tuy nhiên, bất chấp tần suất và tác động, các biện pháp phòng thủ hiện tại đặt gánh nặng lên các nhà vận hành mạng, những người phải dựa vào bộ lọc tiền tố (prefix filters) và các chính sách bắt nguồn từ IRR. Những cơ chế như vậy đòi hỏi mỗi AS phải tự thể hiện mối quan hệ của mình một cách chính xác, thủ công, trên mọi phiên làm việc. RFC 9234 chuyển gánh nặng đó vào giao thức định tuyến BGP.

BGP Roles

Một BGP Role tuyên bố vị trí của bạn so với một láng giềng trên phiên eBGP (External BGP) nhất định. Role mô tả từng phía của mối quan hệ láng giềng: trên một phiên với nhà cung cấp dịch vụ trung chuyển (transit provider) của bạn, bạn cấu hình Role là customer, và họ cấu hình Role là provider.

Có năm tùy chọn: Provider, Customer, Peer, RS và RS-Client. Ba tùy chọn đầu tiên là các mối quan hệ trung chuyển và ngang hàng bên cạnh đã mô tả ở trên. RS và RS-Client liên quan đến các máy chủ định tuyến (route server) tại Internet Exchange (IX), nơi một máy chủ định tuyến đóng vai trò như một nhà cung cấp cho tất cả các khách hàng của nó, quảng bá lại các tiền tố giữa các thành viên IX một cách minh bạch.

Chỉ có năm cặp vai trò hợp lệ:

Role của AS cục bộ

Role của AS từ xa

Provider

Customer

Customer

Provider

RS

RS-Client

RS-Client

RS

Peer

Peer

RFC 9234 quy định rằng một Role nên được cấu hình tại AS cục bộ trên mọi phiên eBGP. Trong quá trình triển khai một phần, hầu hết các phiên sẽ chỉ có Role ở một phía. RFC 9234 xử lý điều đó theo mặc định: nếu bạn gửi khả năng Role mà láng giềng của bạn không gửi, phiên làm việc vẫn được thiết lập và Role được cấu hình cục bộ của bạn vẫn thúc đẩy việc ngăn chặn rò rỉ định tuyến một phần. Một nhà vận hành muốn có sự đảm bảo mạnh mẽ hơn có thể kích hoạt "chế độ nghiêm ngặt" (strict mode), chế độ này sẽ từ chối bất kỳ phiên nào mà láng giềng không gửi khả năng Role. Chế độ nghiêm ngặt là tùy chọn, và như các số liệu áp dụng sau đó trong bài viết này cho thấy, nó vẫn chưa thực tế đối với hầu hết các mạng lưới.

Khi cả hai bên gửi Role và cặp đó không nằm trong năm cặp hợp lệ ở trên (ví dụ: một đầu là customer và đầu kia là peer), phiên làm việc sẽ bị từ chối với thông báo Role Mismatch (mã 2, mã phụ 11).

Việc từ chối là một lý do khiến Roles trở nên hữu ích: Role không khớp có nghĩa là hai mạng lưới không đồng ý về mối quan hệ thực sự của họ, đây chính xác là loại hiểu lầm tiềm ẩn mà sau này sẽ lộ ra dưới dạng rò rỉ định tuyến. Role không khớp sẽ làm thất bại quá trình bắt tay thay vì thất bại sau đó dưới dạng một sự cố.

Không một Role đơn lẻ nào có thể mô tả nhiều vai trò, ví dụ, nếu bạn có nhiều hơn một mối quan hệ với cùng một láng giềng trên một phiên duy nhất (ví dụ: nhà cung cấp-khách hàng cho một số tiền tố, ngang hàng-ngang hàng cho các tiền tố khác). RFC 9234 nói rằng Roles không được cấu hình trên phiên như vậy. Thay vào đó, các mạng lưới cần chia mối quan hệ phức tạp thành các phiên eBGP riêng biệt với các mối quan hệ thông thường và cấu hình Role liên quan trên mỗi phiên. Nếu không có các phiên riêng lẻ được gán Role, nhà vận hành mạng phải thực hiện chính sách phức tạp hơn cho từng tiền tố mà không có cách nào kiểm tra trong băng thông (in-band) xem chính sách đó có đúng hay không — điều này quay trở lại các cơ chế 'thủ công' dễ lỗi mà chính Roles đã được tạo ra để giải quyết.

Roles có công dụng thứ hai ngoài việc thương lượng phiên. Trong bài viết trước của chúng tôi về xác thực ASPA, chúng tôi đã mô tả cách một thuật toán khác áp dụng cho các đường dẫn nhận được từ nhà cung cấp so với các đường dẫn nhận được từ đối tác ngang hàng, khách hàng, máy chủ định tuyến hoặc khách hàng của máy chủ định tuyến. Các tuyến đường từ nhà cung cấp có thể chứa toàn bộ chuyển động lên trên, sang ngang và xuống dưới trong đường dẫn. Tuy nhiên, các tuyến đường từ một thực thể không phải nhà cung cấp chỉ được chứa một đường dốc hướng xuống các AS khách hàng.

BGP Role là thứ cho bộ định tuyến biết nên chạy cái nào trong hai cái đó, vì vậy BGP Roles và ASPA nên được cấu hình cùng nhau trên các bộ định tuyến hỗ trợ cả hai.

Thuộc tính Only to Customer (OTC)

OTC là một thuộc tính đường dẫn tùy chọn có tính lan truyền (mã loại 35) mang một giá trị, đó là một số AS. Giá trị đó ghi lại AS đầu tiên gửi tuyến đường sang ngang hoặc xuống dưới. Nó đánh dấu đỉnh của đường dẫn, sau đó tuyến đường chỉ có thể tiếp tục đi xuống. Khi OTC đã được thiết lập, RFC 9234 yêu cầu nó phải được giữ nguyên không thay đổi. Và vì thuộc tính này là tùy chọn có tính lan truyền, ngay cả một bộ định tuyến không hỗ trợ RFC 9234 cũng được mong đợi sẽ chuyển tiếp nó thay vì loại bỏ. Cả hai sự thật đó đều quan trọng sau này.

Role của bạn trên mỗi phiên quyết định quy tắc nào được áp dụng.

Thiết lập OTC. Một tuyến đường được đóng dấu lần đầu tiên khi nó ngừng di chuyển hoàn toàn theo hướng đi lên: