Kiểm thử RPKI Route Origin Validation: từ ROA đến quyết định định tuyến

Mục tiêu không chỉ là thấy nhãn “RPKI Invalid” trên CLI. Cần chứng minh router nhận đúng Validated ROA Payload, tính đúng trạng thái cho route, áp policy đúng hướng và chuyển tiếp theo kết quả mong đợi. RFC 6811 mô tả BGP Prefix Origin Validation; RFC 7115 đưa ra cân nhắc vận hành khi dùng kết quả đó.

ROV chỉ xác thực origin AS so với ROA, không xác thực toàn bộ AS_PATH. Bài kiểm thử không được gọi ROV là cơ chế ngăn mọi route leak hoặc hijack. Phạm vi phải nêu rõ eBGP/iBGP, ingress/egress, address family và chính sách với Invalid/NotFound.

Topology tối thiểu gồm một publication/test repository hoặc bộ dữ liệu ROA cô lập, một hoặc hai relying party validator/cache, router under test và hai BGP peers phát prefix kiểm thử. Dùng ASN/prefix dành cho lab hoặc môi trường được kiểm soát; không phát route thử ra Internet.

Đặt điểm quan sát tại cache, phiên RTR tới router, RIB/FIB và traffic generator. Nếu high availability là yêu cầu, dùng hai cache và thử router chuyển giữa chúng. Đồng bộ thời gian để đo từ lúc ROA thay đổi tới khi policy/forwarding ổn định.

Tạo bộ route/ROA có kiểm soát cho exact prefix, more-specific trong maxLength, more-specific vượt maxLength, origin ASN khớp, origin ASN không khớp và prefix không có ROA. RFC 6907 có các ví dụ diễn giải hữu ích cho Valid, Invalid và NotFound.

Khóa phiên bản router OS, validator, RTR protocol, refresh/retry/expire timer, BGP policy, local preference, multipath và route damping. Một route Invalid vẫn có thể thắng nếu policy chỉ gắn community mà không hạ ưu tiên; đó là policy, không phải lỗi validation.

KPI gồm thời gian repository-to-cache, cache-to-router, validation-state transition, BGP best-path change, FIB programming và packet loss trong chuyển đổi. Theo dõi số VRP, serial/session RTR, cache health, CPU/memory và số route theo từng trạng thái.

Bằng chứng cần có: snapshot ROA/VRP, log validator, trạng thái RTR, BGP route detail trước/sau policy, RIB/FIB và traffic result. Không chỉ chụp CLI cuối cùng; cần timeline để biết chậm ở repository, cache, router hay policy.

Policy pass/fail phải được viết trước thử nghiệm. RFC không thay tổ chức quyết định chính sách vận hành, nhưng việc dùng trạng thái phải nhất quán và có bằng chứng.

• Route quảng bá: Prefix và origin khớp · ROA: Exact/covering, maxLength hợp lệ · Trạng thái kỳ vọng: Valid · Policy kỳ vọng: Chấp nhận theo policy
• Route quảng bá: Origin khác · ROA: Prefix được cover · Trạng thái kỳ vọng: Invalid · Policy kỳ vọng: Reject hoặc hạ ưu tiên theo thiết kế
• Route quảng bá: Prefix dài hơn maxLength · ROA: Origin vẫn khớp · Trạng thái kỳ vọng: Invalid · Policy kỳ vọng: Xử lý như Invalid
• Route quảng bá: Không có covering ROA · ROA: Không có · Trạng thái kỳ vọng: NotFound · Policy kỳ vọng: Không tự coi là Invalid
• Route quảng bá: ROA AS0 cover prefix · ROA: AS0 · Trạng thái kỳ vọng: Invalid · Policy kỳ vọng: Không dùng route theo policy
• Route quảng bá: Hai path, một Valid một Invalid · ROA: Có · Trạng thái kỳ vọng: Hai trạng thái khác nhau · Policy kỳ vọng: Valid thắng theo policy đã chốt

Chạy functional test với từng dòng ma trận, sau đó thay đổi một trường ROA hoặc route và đo hội tụ. Các sự kiện nên gồm tạo ROA, đổi origin, sửa maxLength, rút ROA, hết hạn dữ liệu và BGP withdraw/reannounce. Kiểm tra cả route đã tồn tại lẫn route mới.

Với hai cache, thử dữ liệu nhất quán và lệch tạm thời. Kiểm tra router có dùng trạng thái cũ trong cửa sổ nào, khi nào đánh dấu stale và cách nó phục hồi. Không rút kết nối production chỉ để tạo kịch bản nếu chưa có lab/change window.

Nên thực thi theo từng phase. Phase 1 chỉ xác minh state calculation, chưa áp reject policy. Phase 2 gắn community hoặc local preference để quan sát mà chưa làm thay đổi forwarding. Phase 3 mới áp enforcement trong lab và phát traffic qua các path cạnh tranh. Cách chia này giúp phân biệt route bị mất vì dữ liệu validation sai với route bị loại đúng theo policy.

Với IPv6, lặp lại ma trận thay vì suy luận từ IPv4. Kiểm tra route aggregate và more-specific riêng, bởi maxLength sai là nguyên nhân phổ biến làm route hợp lệ về mặt vận hành bị đánh dấu Invalid. Khi sửa ROA, đo cả thời gian trạng thái đổi và thời gian dịch vụ phục hồi.

Mất một repository không đồng nghĩa lập tức mọi route chuyển NotFound; hành vi phụ thuộc dữ liệu đã cache và timer. Thử mất repository, cache restart, RTR reset, dữ liệu lỗi và clock sai. Ghi rõ fail-open/fail-closed thực tế theo nền tảng và policy.

Một quyết định quá mạnh khi cache tạm lỗi có thể gây outage diện rộng. Ngược lại, giữ dữ liệu quá lâu có thể chậm phản ánh thay đổi hợp lệ. Test plan phải đo trade-off, không áp một timer chung cho mọi mạng.

• Cô lập prefix/ASN thử nghiệm khỏi Internet.
• Ghi phiên bản router, validator và cấu hình timer.
• Lưu baseline VRP, RIB, FIB và traffic.
• Chạy Valid, Invalid-origin, Invalid-maxLength và NotFound.
• Thử AS0 ROA và two-path selection nếu thuộc phạm vi.
• Đo thời gian từ ROA tới forwarding.
• Thử repository/cache/RTR failure có kiểm soát.
• Xác nhận IPv4/IPv6 và ingress/egress policy cần thiết.
• Lặp sau restart/HA switchover.
• Lưu raw evidence và rollback.

Lab không phản ánh đầy đủ quy mô global RPKI repository, Internet route churn hoặc lỗi đồng thời nhiều publication point. Kết quả ROV không chứng minh AS_PATH hợp lệ và không thay thế IRR, filtering, max-prefix hay monitoring.

Tính đúng của route state và tính phù hợp của policy là hai kết luận khác nhau. Mọi tuyên bố về thời gian hội tụ phải gắn với refresh/retry/expire timer, validator, router version và số lượng route/VRP.