RPKI và ROA: Xác thực origin BGP để bảo vệ prefix

BGP vốn không có cơ chế tích hợp để chứng minh một Autonomous System thực sự được phép quảng bá một prefix. Một lỗi cấu hình hoặc hành vi chiếm tuyến có thể làm lưu lượng Internet đi sai nơi, mất kết nối hoặc bị quan sát ngoài dự kiến. Resource Public Key Infrastructure (RPKI) bổ sung dữ liệu ủy quyền có chữ ký để các mạng đánh giá origin của tuyến.

RPKI không thay thế BGP và cũng không ký từng UPDATE. Nó tạo một nguồn dữ liệu kiểm chứng được: chủ sở hữu tài nguyên công bố Route Origin Authorization (ROA), validator chuyển các ROA hợp lệ thành tập dữ liệu để router thực hiện Route Origin Validation (ROV). Hiệu quả phụ thuộc vào cả hai phía: chủ prefix phải tạo ROA chính xác và nhà mạng phải áp policy cho kết quả validation.

1. Bài toán origin hijack

Một route BGP gồm prefix cùng AS_PATH; origin ASN nằm ở đầu nguồn của đường đi theo cách biểu diễn BGP. Khi AS sai quảng bá prefix của tổ chức khác, các mạng nhận tuyến có thể chọn nó theo policy và độ cụ thể của prefix. Tuyến cụ thể hơn thường đặc biệt nguy hiểm vì forwarding ưu tiên longest-prefix match.

RPKI giúp trả lời câu hỏi hẹp nhưng quan trọng: ASN ở origin có được chủ không gian địa chỉ ủy quyền quảng bá prefix này với độ dài này hay không? Nó không chứng minh toàn bộ AS_PATH hợp lệ và không tự phát hiện mọi route leak.

2. Bốn thành phần của luồng RPKI

1. Resource certificate: liên kết IP prefix/ASN với khóa công khai trong hệ thống phân cấp từ các trust anchor.
2. ROA: đối tượng có chữ ký nêu origin ASN được phép quảng bá một hoặc nhiều prefix.
3. Relying-party validator: tải repository, xác minh certificate, manifest, CRL và signed object, rồi sinh Validated ROA Payloads (VRP).
4. Router và policy ROV: nhận VRP từ validator, phân loại route và áp chính sách do operator cấu hình.

RFC 9582 là profile ROA hiện hành và thay thế RFC 6482. Tài liệu mô tả ROA là đối tượng có chữ ký cho phép xác minh rằng chủ khối IP đã ủy quyền một AS quảng bá các prefix tương ứng.

3. Một ROA chứa gì?

Một ROA xác định một ASN; nếu cùng prefix được nhiều ASN hợp lệ originate, cần authorization tương ứng cho từng ASN. Portal RIR thường che phần phức tạp của certificate và chữ ký, nhưng người vận hành vẫn chịu trách nhiệm đảm bảo prefix, ASN và maxLength khớp thiết kế BGP.

4. Valid, Invalid và NotFound

Theo quy trình trong RFC 6811, route được đối chiếu với VRP và nhận một trong ba trạng thái:

Invalid không phải “chữ ký BGP sai”; RPKI origin validation không ký UPDATE. Nó có nghĩa route mâu thuẫn với tập ủy quyền origin đã được xác minh.

5. Ví dụ tính trạng thái

Giả sử có VRP:

Prefix:     203.0.113.0/24
maxLength: 24
Origin:    AS64500

Nếu maxLength đổi thành 26, cùng ASN có thể quảng bá /24, /25 và /26 nằm trong khối. Điều đó tiện cho traffic engineering nhưng mở rộng quyền được công bố.

6. Vì sao maxLength cần tối thiểu?

Một ROA /20 maxLength /24 không chỉ cho phép các prefix đang quảng bá; nó cho phép origin ASN đó quảng bá mọi more-specific từ /20 đến /24 trong khối. Kẻ tấn công có thể giả origin ASN được ủy quyền và phát một more-specific nằm trong khoảng, khiến tuyến vẫn RPKI Valid dù đường đi không hợp pháp.

RFC 9319 khuyến nghị minimal ROAs: khi có thể, chỉ ủy quyền các prefix thực sự được originate, không mở phạm vi more-specific “để dành”. Ví dụ nếu mạng phát đúng bốn /24, tạo authorization chính xác cho bốn /24 thường tốt hơn một /22 với maxLength /24.

• Không mặc định maxLength là /32 cho IPv4 hoặc /128 cho IPv6.
• Chỉ mở more-specific đã có use case vận hành rõ ràng.
• Ghi nhận các tuyến DDoS blackhole và community-triggered announcement trong inventory.
• Rà soát maxLength khi thay đổi traffic engineering.

7. RPKI bảo vệ được gì và chưa bảo vệ gì?

RPKI-ROV là một lớp trong bảo mật định tuyến. Prefix filters, IRR, peer policy, max-prefix, monitoring, BMP và quy trình thay đổi vẫn cần thiết. Các cơ chế kiểm tra path là bài toán khác.

8. Hosted hay delegated RPKI?

Với hosted RPKI, RIR hoặc nhà cung cấp quản lý CA, private key và publication point; người giữ tài nguyên quản lý ROA qua portal/API. Đây thường là lựa chọn đơn giản cho đội chưa có nhu cầu hạ tầng PKI riêng.

Delegated RPKI cho phép tổ chức vận hành CA và có mức kiểm soát cao hơn, nhưng kéo theo trách nhiệm key management, availability, manifest/CRL, publication và kiểm thử liên tục. Không chọn delegated chỉ vì nghe “tự chủ” hơn; outage hoặc object lỗi ở publication plane có thể làm dữ liệu hợp lệ biến mất khỏi validator.

APNIC mô tả cả hosted và self-hosted/delegated, đồng thời khuyến nghị hosted mode cho phần lớn thành viên.

9. Kiến trúc validator an toàn

Router không nên tự tải và xác minh toàn bộ repository Internet. Relying-party validator làm việc đó, tạo bộ VRP cục bộ rồi cung cấp cho router qua RPKI-to-Router (RTR). Tách control plane này giúp router thực hiện lookup nhanh và giới hạn độ phức tạp.

• Chạy ít nhất hai validator độc lập về host, phần mềm hoặc failure domain khi quy mô yêu cầu.
• Kết nối RTR qua mạng quản trị được bảo vệ; chỉ cho phép peer dự kiến.
• Giám sát serial/session, thời điểm refresh, số VRP, lỗi trust anchor và repository.
• Đặt chính sách stale/expiry có chủ đích; tránh vừa mất validator đã xóa toàn bộ route.
• So sánh output giữa validator để phát hiện dữ liệu hoặc implementation bất thường.
• Nâng cấp validator theo quy trình canary thay vì đồng loạt.

10. Policy router là quyết định của operator

Validation state không tự động bắt router loại route. RFC 6811 yêu cầu hành vi policy phải được cấu hình rõ. Lộ trình phổ biến là quan sát trạng thái trước, xác minh false positive, rồi từ chối RPKI Invalid ở ingress phù hợp.

NotFound không nên bị xem như Invalid: nó chỉ nói không có VRP bao phủ. Nếu loại NotFound trong Internet table khi độ phủ chưa đầy đủ, nhà mạng có thể mất reachability tới nhiều prefix hợp lệ. Valid cũng không đồng nghĩa tuyến luôn tốt; các thuộc tính BGP và chính sách kinh doanh vẫn áp dụng.

11. Tạo ROA mà không tự gây sự cố

1. Xuất toàn bộ route thực tế theo IPv4/IPv6, origin ASN và độ dài prefix.
2. Đối chiếu với tài nguyên được RIR/parent phân bổ và các tuyến do downstream originate.
3. Lập kế hoạch cho multi-origin, anycast, DDoS mitigation và thời gian migration ASN.
4. Tạo minimal ROA bao phủ chính xác trạng thái đang chạy trước.
5. Chờ publication và kiểm tra qua nhiều validator/looking glass.
6. Xác nhận mọi route đang quảng bá là Valid hoặc NotFound đúng dự kiến, không có Invalid mới.
7. Chỉ sau đó mới bật reject-invalid theo từng biên mạng.

Khi chuyển origin từ AS cũ sang AS mới, hãy tạo ROA cho AS mới trước khi phát tuyến, giữ AS cũ trong giai đoạn overlap, chuyển traffic, xác minh toàn cầu rồi mới thu hồi ROA cũ. Thứ tự ngược lại tạo cửa sổ Invalid.

12. Multi-origin, anycast và nhà cung cấp chống DDoS

Cùng prefix có thể được nhiều ASN originate hợp lệ, chẳng hạn anycast hoặc giai đoạn migration. Cần authorization cho từng origin thực tế. Với dịch vụ DDoS scrubbing, nhà cung cấp có thể originate prefix của khách hàng khi kích hoạt; ROA và prefix length phải chuẩn bị trước hoặc playbook phải tạo authorization đủ sớm để propagation hoàn tất.

Không mở maxLength quá rộng chỉ để “phòng khi cần blackhole”. Ghi rõ prefix nào có thể được tách, ASN nào originate và thời gian duy trì. Sau sự cố, thu hồi quyền tạm không còn dùng.

13. Giám sát những gì?

• Prefix của tổ chức chuyển từ Valid sang Invalid hoặc NotFound.
• Origin ASN mới xuất hiện cho prefix sở hữu.
• ROA sắp hết hiệu lực, certificate/manifest/CRL lỗi hoặc publication thất bại.
• Validator mất đồng bộ, VRP count thay đổi bất thường hoặc RTR session flap.
• Route bị reject theo ROV tăng đột biến tại peer/transit cụ thể.
• Chênh lệch giữa intended route inventory, BGP table và ROA inventory.

Alert phải phân biệt lỗi dữ liệu của chính tổ chức với hijack bên ngoài. Một route Invalid ngay sau change window thường gợi ý ROA chưa chuẩn bị; một origin lạ không kèm thay đổi nội bộ cần được điều tra khẩn cấp.

14. Quy trình thay đổi và rollback

ROA là dữ liệu bảo mật có thể tác động reachability toàn cầu, nên cần review như thay đổi routing production. Mỗi thay đổi phải ghi prefix, ASN, maxLength, lý do, cửa sổ hiệu lực, người duyệt và bằng chứng kiểm tra.

Rollback không chỉ là xóa ROA mới. Nếu route đang chạy phụ thuộc authorization đó, xóa sẽ chuyển route sang Invalid hoặc NotFound tùy các VRP còn lại. Trước rollback, tính lại trạng thái mong đợi và thực hiện theo thứ tự add-before-remove.

15. Những anti-pattern phổ biến

• Tạo một ROA aggregate với maxLength rộng nhất cho tiện.
• Bật reject-invalid trước khi kiểm kê route của chính mình và khách hàng.
• Giả định Valid chứng minh toàn bộ AS_PATH an toàn.
• Đánh đồng NotFound với route độc hại.
• Chỉ chạy một validator mà không giám sát freshness.
• Thay ASN origin trước rồi mới tạo ROA.
• Quên route tạm do DDoS mitigation hoặc more-specific traffic engineering.
• Để quyền quản trị portal RIR không có MFA và quy trình phê duyệt.

Checklist production

• Inventory BGP và ROA khớp cho IPv4, IPv6, anycast và multi-origin.
• Mỗi maxLength chỉ cho phép các prefix thực sự cần quảng bá.
• ROA mới được publish và nhìn thấy trước khi thay đổi origin.
• Có tối thiểu hai nguồn kiểm tra trạng thái độc lập.
• Validator, RTR và freshness được giám sát.
• Policy phân biệt Valid, Invalid và NotFound.
• Reject-invalid được rollout theo giai đoạn và có đo lường.
• RIR account dùng MFA, least privilege và audit log.
• DDoS/migration runbook có thứ tự add-before-remove.
• Đội NOC biết cách chẩn đoán và rollback ROA sai.

Kết luận

RPKI biến quyền originate prefix từ một giả định của BGP thành dữ liệu có thể xác minh. Giá trị lớn nhất đến từ ROA tối thiểu, inventory đúng và policy ROV được rollout có quan sát. Hãy nhớ giới hạn cốt lõi: RPKI-ROV xác thực mối quan hệ giữa prefix và origin ASN, không xác thực toàn bộ đường đi. Kết hợp nó với filtering, monitoring và kỷ luật thay đổi sẽ giảm đáng kể rủi ro mis-origination mà không tạo thêm outage do chính cấu hình bảo mật.