Thủ thuật
Thao túng thuộc tính BGP ORIGIN và tác động đến hạ tầng Internet toàn cầu
(giờ Việt Nam)
Tóm tắt AI
Nghiên cứu của Cloudflare chỉ ra rằng 70% đường truyền BGP bị các nhà cung cấp dịch vụ can thiệp để tối ưu hóa lưu lượng, từ đó đề xuất loại bỏ thuộc tính ORIGIN trong định tuyến.
Bản dịch AI

Border Gateway Protocol (BGP) là giao thức định tuyến thực tế của Internet. Nó cung cấp các cơ chế tích hợp sẵn cho phép các thực thể, được đại diện bởi các Hệ thống tự trị (Autonomous Systems - ASes), thể hiện cách họ muốn gửi và nhận lưu lượng truy cập trên Internet. Một trong những cơ chế đó là các thuộc tính đường dẫn (path attributes), mang thông tin định tuyến thiết yếu và siêu dữ liệu cho tuyến đường liên quan của chúng. Thuật toán chọn đường dẫn xử lý một số thuộc tính đường dẫn này theo trình tự xác định để tính toán đường dẫn tốt nhất cho tiền tố (prefix) cụ thể này.
Tận dụng vị trí độc đáo của mình trên Internet, chúng tôi đã thực hiện một cuộc điều tra về một trong những thuộc tính bắt buộc nổi tiếng trong BGP, đó là thuộc tính ORIGIN. ORIGIN phải có mặt trong mọi thông báo tiền tố BGP và không được sửa đổi bởi bất kỳ bộ định tuyến nào sau khi đã được thiết lập bởi bộ định tuyến khởi tạo. Những gì chúng tôi tìm thấy qua các thử nghiệm của riêng mình là một con số đáng kinh ngạc: khoảng 70% các đường dẫn được quan sát tại nhiều điểm quan sát khác nhau có giá trị ORIGIN khác so với giá trị được thiết lập bởi Hệ thống tự trị khởi tạo. Việc thao túng thuộc tính ORIGIN này có tác động đáng kể đến cách lưu lượng truy cập được chuyển tiếp trên Internet, như chúng tôi sẽ khám phá trong bài viết này.
BGP ORIGIN và lịch sử hoạt động của nó
Thuộc tính ORIGIN cho biết cách một tuyến đường được đưa vào BGP — không nên nhầm lẫn với AS gốc (origin AS), vốn cho biết AS nào đã thông báo một tuyến đường. Nó có ba giá trị khả thi:
(0) IGP: Cho biết tuyến đường nằm bên trong AS khởi tạo.
(1) EGP: Một giá trị lịch sử cho biết tuyến đường đã được học thông qua Giao thức cổng ngoài (Exterior Gateway Protocol - EGP) cũ, vốn đã lỗi thời và không còn được sử dụng trong Internet hiện đại.
(2) INCOMPLETE: Cho biết tuyến đường đã được học thông qua một nguồn không xác định hoặc bên ngoài.
Trong tổng số các tuyến đường có thể quan sát được từ tất cả các bộ thu thập BGP công cộng của RIPE RIS và RouteViews, 89,8% có ORIGIN được đặt là IGP, 3,5% là EGP và 6,7% là INCOMPLETE. Như đã đề cập ở trên, EGP được coi là đã hoàn toàn lỗi thời và INCOMPLETE chỉ chiếm một phần nhỏ trong tổng số các tuyến đường. Những con số này cho thấy mặc dù IGP là giá trị phổ biến nhất cho ORIGIN, nhưng hơn 10% các tuyến đường có giá trị EGP hoặc INCOMPLETE có thể tạo ra sự khác biệt trong các quyết định định tuyến.
Là một phần của quá trình chọn đường dẫn BGP, bộ định tuyến sẽ đánh giá ORIGIN nếu hai tuyến đường có cùng Local Preference và độ dài AS_PATH, từ đó chọn và cài đặt đường dẫn có giá trị ORIGIN thấp hơn.
Ngoài quyết định chọn đường dẫn, cần lưu ý rằng RFC4271 nêu rõ những điều sau về ORIGIN:
Thuộc tính ORIGIN được tạo ra bởi thực thể khởi tạo thông tin định tuyến liên quan. Giá trị của nó KHÔNG NÊN bị thay đổi bởi bất kỳ thực thể nào khác.
Mặc dù hướng dẫn là không sửa đổi thuộc tính ORIGIN, nhưng do việc đánh giá sớm trong quá trình chọn tuyến đường, thuộc tính này đã trở thành một lựa chọn hấp dẫn để các AS thay đổi ưu tiên tuyến đường và chuyển hướng lưu lượng truy cập đi qua hoặc tránh xa mạng lưới của họ.
Ví dụ, trong sơ đồ dưới đây, AS64501 thông báo một tiền tố với ORIGIN được đặt là INCOMPLETE và truyền thông báo này đến cả hai khách hàng của mình là AS64502 và AS64503. Thông thường, cả hai đều nên thêm AS của riêng họ vào AS_PATH và chuyển tiếp thông báo đến khách hàng chung của họ là AS64504, giữ nguyên giá trị INCOMPLETE. Tuy nhiên, để tăng khả năng tuyến đường của họ được chọn thay vì của đối thủ cạnh tranh, AS64503 sửa đổi ORIGIN thành IGP. Kết quả là, AS64504 nhận được hai tuyến đường cho cùng một tiền tố với độ dài AS_PATH bằng nhau, nhưng tuyến đường từ AS64503 mang giá trị IGP được ưu tiên hơn. Do đó, AS64504 sẽ chọn tuyến đường thông qua AS64503 để gửi lưu lượng truy cập đến AS64501, từ đó thu hút nhiều lưu lượng truy cập và doanh thu hơn cho nhà cung cấp đó.
Thay đổi đơn giản này, hướng tới một giá trị ORIGIN không chính xác nhưng ưu tiên hơn, cho phép nhà cung cấp dịch vụ trung chuyển thu hút lưu lượng truy cập và kiếm lợi nhuận.
Cộng đồng các nhà vận hành mạng đã âm thầm chấp nhận thực tế rằng các nhà cung cấp dịch vụ trung chuyển đã và đang viết lại thuộc tính ORIGIN thành IGP để thu hút nhiều lưu lượng truy cập hơn vào các liên kết của họ. Tuy nhiên, James Bensley tại cuộc họp RIPE 91 là người đầu tiên làm nổi bật việc áp dụng rộng rãi kỹ thuật thao túng này bởi các mạng lưới lớn. Một bài thuyết trình tiếp theo của Celsa Sánchez tại cuộc họp LACNIC 45 đã điều tra tác động của hành vi này trong khu vực LACNIC (Mỹ Latinh và Caribe). Mặc dù việc công khai nên ngăn cản hành vi này, nhưng nó làm nổi bật thực tế rằng việc chọn tuyến đường là một cuộc chạy đua vũ trang dựa trên doanh thu. Thay vì chờ đợi các đối thủ cạnh tranh tuân thủ RFC, các nhà vận hành mạng có nhiều khả năng sẽ nhanh chóng sử dụng cách viết lại ORIGIN chỉ để tạo ra một sân chơi bình đẳng.
Việc xử lý ORIGIN ngày càng không nhất quán trên khắp Internet đã thúc đẩy việc tạo ra một Internet-Draft hiện đã hết hạn, trong đó khuyến nghị loại bỏ thuộc tính này. Để khám phá mức độ của hiện tượng này và theo dõi các tác nhân cùng với ý định của họ, chúng tôi đã thực hiện các thử nghiệm của riêng mình và chia sẻ kết quả trong phần tiếp theo.
Phân tích thao túng thuộc tính ORIGIN
Trong thử nghiệm của mình, chúng tôi đã thông báo ba tiền tố IPv4 và ba tiền tố IPv6, mỗi tiền tố với một giá trị ORIGIN khác nhau (IGP/EGP/INCOMPLETE) từ tất cả các vị trí peering của chúng tôi bằng cách sử dụng BGP Anycast. Sau khi xác nhận sự lan truyền toàn cầu, chúng tôi đã rút lại các tiền tố để kích hoạt quá trình tìm kiếm đường dẫn (path hunting), từ đó tiết lộ thêm nhiều đường dẫn đến các tiền tố thử nghiệm, giúp chúng tôi có nhiều cơ hội hơn để phát hiện các ORIGIN đã bị thay đổi. Như được hiển thị trong hình dưới đây, chúng tôi đã sử dụng bộ công cụ BGPKIT để phân tích các thông báo Update từ các tệp kết xuất Multi-threaded Routing Toolkit (MRT) của tất cả các bộ thu thập BGP công cộng từ RIPE RIS và RouteViews, cùng với dữ liệu BMP cục bộ mà chúng tôi thu thập từ các bộ định tuyến biên của mình. Lưu ý rằng chúng tôi chọn phân tích các bản Update thay vì các bản kết xuất Routing Information Base (RIB), vốn là các ảnh chụp nhanh bảng định tuyến của các AS ngang hàng, để truy xuất càng nhiều tuyến đường càng tốt trong cả giai đoạn thông báo và rút lại.
Một khó khăn cơ bản của phân tích BGP là thiếu khả năng hiển thị tất cả các AS trên Internet cho một thông báo định tuyến duy nhất. Khoảng cách này càng bị nới rộng bởi sự phẳng hóa của Internet hiện đại, được thúc đẩy bởi các hyperscaler và CDN bỏ qua các tuyến trung chuyển truyền thống để ưu tiên peering trực tiếp tại địa phương. Do đó, các bộ giám sát công cộng bỏ lỡ một phần đáng kể cấu trúc liên kết BGP cho một tiền tố nhất định, nghĩa là các suy luận về thuộc tính AS luôn mang tính không chắc chắn vốn có.
Tìm kiếm các thực thể viết lại ORIGIN trong AS_PATH hai chặng
Đầu tiên, chúng tôi tập trung vào các AS_PATH chỉ có hai AS: “ASX AS13335”, trong đó chúng tôi gọi ASX là một đối tác peering trực tiếp. Vì chúng tôi đã cấu hình các bộ định tuyến của mình để truyền các thông báo với một ORIGIN cụ thể, chúng tôi tin chắc rằng nếu chúng tôi quan sát thấy một ORIGIN khác, thì ASX chắc chắn đã thay đổi nó thành giá trị mới. Bảng dưới đây cho thấy hành vi thao túng của 352 đối tác trực tiếp đối với IPv4, trong đó cột “Advertised ORIGIN” hiển thị giá trị đang được quảng bá cho mỗi tiền tố trong ba tiền tố của chúng tôi, và các cột bên phải liệt kê các giá trị ORIGIN được quan sát bởi các AS đối tác trực tiếp:
Chúng tôi muốn chỉ ra hai quan sát thú vị. Thứ nhất, ba AS thay đổi ORIGIN thành EGP và bốn AS thay đổi nó thành INCOMPLETE, bất kể giá trị ban đầu của nó là gì, nghĩa là họ có khả năng đang cố gắng giảm ưu tiên các tuyến đường này. Chúng tôi đã liên hệ với kỹ sư mạng của một trong những AS này và xác nhận rằng họ đang viết lại ORIGIN thành EGP trên các tuyến đường nhận được từ các đối tác hoặc nhà cung cấp (để làm cho chúng ít được ưu tiên hơn so với các tuyến đường của khách hàng). Thứ hai, đối với các tiền tố không phải IGP, ba AS truyền các tuyến đường với cả giá trị gốc và IGP (hai cột ngoài cùng bên phải ở trên). Dựa trên các thuộc tính khác của tuyến đường như cộng đồng (communities) và AGGREGATOR, chúng tôi suy luận rằng các AS này nhận các tuyến đường của chúng tôi tại nhiều vị trí peering và cập nhật ORIGIN thành IGP, có lẽ để chuyển tiếp lưu lượng truy cập qua một điểm ưu tiên. Kết hợp các AS này với những AS liên tục viết lại thành IGP, chúng tôi phát hiện ra rằng gần 10% các đối tác trực tiếp thay đổi thuộc tính ORIGIN thành IGP.
Khi thử nghiệm IPv6, chúng tôi mong đợi kết quả tương tự nhưng muốn lưu ý đến những điểm khác biệt liên quan đến việc thao túng giá trị ORIGIN bởi cùng một AS giữa hai họ địa chỉ. Trong bảng sau, chúng tôi trình bày hành vi thao túng của 315 đối tác trực tiếp đối với IPv6:
Đáng chú ý nhất là hai đối tác trực tiếp thay đổi ORIGIN thành IGP chỉ đối với các tiền tố IPv4 chứ không phải IPv6, ngụ ý các cấu hình khác nhau cho hai họ địa chỉ này.
Thu hẹp phân tích của chúng tôi vào các AS Tier-1, sáu trong số 16 AS dường như thao túng giá trị ORIGIN thành IGP, khớp với kết quả của nghiên cứu trước đó. Lưu ý rằng thông qua điều tra thủ công, chúng tôi phát hiện ra rằng một mạng Tier-1 thay đổi giá trị ORIGIN thành IGP cho các tuyến đường học được từ các đối tác, trong khi nó bảo toàn giá trị này cho các tuyến đường của khách hàng. Mô hình hành vi này trên một số mạng Tier-1 phản ánh động lực thu hút nhiều lưu lượng truy cập nhất và triệt tiêu lợi thế của các bộ sửa đổi ORIGIN khác.
Xác định các thực thể viết lại trong AS_PATH dài hơn
Dựa trên những kết quả ban đầu này, chúng tôi đã mở rộng phương pháp luận của mình để xử lý các đường dẫn dài hơn và suy luận hành vi của nhiều AS hơn. Tóm lại, thuật toán của chúng tôi hoạt động như sau:
Được áp dụng cho các tuyến đường của các tiền tố IPv4 và IPv6 của chúng tôi bắt đầu với EGP và INCOMPLETE, phương pháp này tăng khả năng quy gán AS của chúng tôi lên 606 trong số 802 (75,6%) AS có thể nhìn thấy trong AS_PATH, trong đó 64 (10,6%) đang thay đổi ORIGIN thành IGP. Được thúc đẩy bởi việc các Tier-1 áp dụng kỹ thuật này, chúng tôi đã nghiên cứu tầm quan trọng của các AS được quy gán bằng cách sử dụng AS Rank của CAIDA. AS Rank cung cấp bảng xếp hạng các AS dựa trên nón khách hàng (customer cone) của chúng (tức là chính chúng và tất cả các AS có thể đạt được thông qua các liên kết nhà cung cấp-khách hàng).
Trong hình dưới đây, chúng tôi hiển thị phân phối tích lũy (CDF) của AS Rank của các AS được quy gán. Một quan sát thú vị là các AS viết lại IGP tập trung cao độ ở cấp cao nhất của hệ thống phân cấp AS, với 20,3% các AS viết lại nằm trong top 50 của AS Rank.
Tác động của các AS lớn khi viết lại ORIGIN
Tổng cộng, 26% trong top 50 AS và 20% trong top 100 AS đang thao túng thuộc tính ORIGIN, làm nổi bật rằng mặc dù tỷ lệ phần trăm tổng thể thấp, nhưng các AS đặt lại ORIGIN lại có tính trung tâm cao và có ảnh hưởng lớn trên Internet.
Tác động này càng được củng cố bởi phát hiện rằng một con số đáng kinh ngạc là 70% các AS_PATH IPv4 duy nhất và 67% các AS_PATH IPv6 được quan sát trong thử nghiệm đã bị đặt lại ORIGIN thành IGP. Chúng tôi cũng đã nghiên cứu các thay đổi áp đặt lên việc chọn đường dẫn tốt nhất bằng cách hợp nhất các bản cập nhật BGP để tính toán trạng thái bảng định tuyến hoạt động đã hội tụ của mỗi AS đối tác. Chúng tôi đã sử dụng thông báo tiền tố với ORIGIN được đặt là IGP làm nhóm đối chứng để so sánh các AS_PATH được quan sát với các thông báo EGP và INCOMPLETE của chúng tôi. Khi làm như vậy, chúng tôi phát hiện ra trong IPv4 rằng 110 AS_PATH trong tổng số 539 (20%) đã đi qua các mạng Tier-1 và việc đặt lại ORIGIN thành IGP đã giúp các thực thể viết lại ORIGIN giành được thêm 12 đường dẫn (tăng 18%) mà nếu không sẽ đi qua các mạng bảo toàn ORIGIN. Hiệu ứng này thậm chí còn mạnh hơn ở IPv6, nơi các thực thể viết lại giành được thêm 33 đường dẫn (40%). Những đường dẫn này bao gồm 11 đường dẫn mà đối với nhóm đối chứng của chúng tôi đã không đi qua bất kỳ mạng Tier-1 nào. Điều này làm nổi bật việc chuyển hướng lưu lượng truy cập về phía các ISP Tier-1 lớn khi ORIGIN bị thao túng, làm chệch hướng lưu lượng truy cập khỏi các ISP thay thế.
Như bạn có thể thấy, định tuyến Internet bị ảnh hưởng đáng kể bởi việc thao túng thuộc tính ORIGIN. Trong các thử nghiệm của mình, chúng tôi có thể dễ dàng quan sát các tác động đối với việc chọn đường dẫn BGP và chứng minh cách viết lại ORIGIN là một cách để hút lưu lượng truy cập và tạo doanh thu. Không có lý do kỹ thuật hợp lệ nào để yêu cầu viết lại thuộc tính ORIGIN, và chúng ta có thể thấy rằng việc phụ thuộc vào ORIGIN như một yếu tố thúc đẩy trong việc quyết định chọn tuyến đường nào là không hợp lý.
Loại bỏ thuộc tính ORIGIN
Với những phát hiện của chúng tôi về việc thao túng ORIGIN trên diện rộng, chúng ta phải tự hỏi liệu thuộc tính này có vai trò ý nghĩa nào trong Internet hiện đại hay không. Chúng tôi nghĩ câu trả lời là Không.
Việc xử lý không nhất quán đối với ORIGIN tạo ra sự bất công giữa các mạng thay đổi nó một cách cơ hội và các mạng tuân thủ RFC. Mặc dù việc loại bỏ ngay lập tức một thuộc tính bắt buộc trong BGP là không khả thi, nhưng đã có những công việc được đề xuất trong IETF để làm cho thuộc tính ORIGIN ít liên quan hơn trong việc chọn đường dẫn BGP. Chúng tôi tin rằng việc yêu cầu các triển khai BGP (của nhà cung cấp) đặt ORIGIN là IGP trên tất cả các tuyến đường nhận được và quảng bá là một điểm khởi đầu hợp lý. IGP vốn đã được đặt làm ORIGIN trên phần lớn các tuyến đường.
Chúng tôi muốn khơi dậy những cuộc trò chuyện này trong cộng đồng và IETF về thuộc tính ORIGIN và tương lai của nó (hoặc sự thiếu vắng tương lai đó) trên Internet. Điều này có thể bao gồm việc làm mới bản dự thảo đã hết hạn “Scrubbing BGP ORIGIN Attribute” (draft-marenamat-idr-scrub-bgp-origin-00), hoặc có thể bao gồm một cách tiếp cận hoàn toàn mới. Định tuyến Internet sẽ tốt hơn và công bằng hơn nếu không có thuộc tính ORIGIN gây ảnh hưởng.
Bài viết được AI dịch và tổng hợp tự động từ Cloudflare Blog. Liên kết bài gốc ở phía trên. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.