Kiểm thử uRPF: chặn source giả mà không làm hỏng định tuyến bất đối xứng

BCP 38/RFC 2827 khuyến nghị ingress filtering để hạn chế traffic dùng source address không phù hợp. RFC 3704 mô tả các kỹ thuật ingress filtering cho multihomed network, trong đó strict RPF yêu cầu best reverse path đi qua đúng ingress interface, còn loose RPF thường chỉ cần source có route. Mỗi cách có đánh đổi giữa khả năng chặn giả mạo và false reject.

RFC 8704 mô tả Enhanced Feasible-Path Unicast Reverse Path Forwarding để xem xét feasible paths thay vì chỉ best path, phù hợp hơn với một số topology multihoming/asymmetric. Có RFC không đồng nghĩa nền tảng hỗ trợ đầy đủ; tên mode, RIB dùng để kiểm tra, VRF awareness, default-route handling và ACL exception phải gắn với model/version.

Topology tối thiểu có DUT biên với hai uplink/peer, một hoặc nhiều downstream prefix, traffic generator ở từng hướng và sink. Thiết kế cả symmetric path lẫn asymmetric return path; thêm ECMP hoặc primary/backup. Tách interface khách hàng, transit và management để xác định nơi source validation có ý nghĩa.

Tạo source class: prefix hợp lệ đúng interface; prefix hợp lệ đi vào alternate interface; prefix không được quảng bá; RFC 1918/bogon ở vị trí không phù hợp; source của chính hạ tầng; và spoofed address trùng victim. Thu packet hai phía DUT, RIB/FIB/adjacency, uRPF counter, hardware ACL/drop reason, route update và application transaction.

Ghi model/OS/version, interface/VRF, mode, allow-default, ACL exception, recursive resolution, ECMP, BGP multipath/add-path và FIB programming. Khóa route policy, prefix list, default route, next-hop reachability, convergence timer và BFD nếu có. Một route có trong RIB nhưng chưa vào FIB có thể cho kết quả khác theo implementation.

Traffic profile gồm source/destination prefix, protocol, fragment, packet size, flow count, packet rate và direction. Tạo traffic hợp lệ và spoofed với cùng các thuộc tính còn lại để tránh firewall/CoPP khác che verdict. Đặt offered load dưới data-plane capacity trước khi stress PPS; nếu không, congestion drop dễ bị quy nhầm cho uRPF.

• Mode — Giá trị cần lưu: strict/loose/feasible, allow-default; Rủi ro nếu bỏ sót: Không biết điều kiện pass/drop
• Route state — Giá trị cần lưu: RIB/FIB, VRF, ECMP, recursion; Rủi ro nếu bỏ sót: False reject không giải thích được
• Source class — Giá trị cần lưu: valid, alternate, absent, bogon; Rủi ro nếu bỏ sót: Corpus không đo đúng security
• Exception — Giá trị cần lưu: ACL/prefix/management; Rủi ro nếu bỏ sót: Lỗ hổng hoặc outage ẩn
• Traffic — Giá trị cần lưu: pps, flows, size, fragments; Rủi ro nếu bỏ sót: Counter/drop bị nhiễu bởi capacity

KPI security gồm false-accept rate cho spoofed source, tỷ lệ drop đúng reason và leak trong cửa sổ route change. KPI dịch vụ gồm false-reject rate, transaction success, packet loss, latency p95/p99 và thời gian phục hồi sau failover. Theo dõi CPU, hardware table utilization, counter update delay và log loss ở scale.

Chuỗi bằng chứng cho mỗi packet class: route/FIB snapshot; ingress interface/VRF; packet fields; configured mode/exception; hardware/software drop reason; egress capture hoặc application result. Dùng sequence ID để phát hiện leak/drop, cùng run ID để nối config, route event và verdict. Không dùng counter tổng làm bằng chứng duy nhất.

• Source đúng ingress/best path — Strict: Pass; Loose: Pass; Feasible-path: Pass; Điều cần chứng minh: Không false reject
• Source hợp lệ, return path khác — Strict: Có thể drop; Loose: Pass nếu có route; Feasible-path: Pass nếu feasible; Điều cần chứng minh: Hành vi đúng policy
• Source không có route — Strict: Drop; Loose: Drop; Feasible-path: Drop; Điều cần chứng minh: Chặn spoof cơ bản
• Chỉ có default route — Strict: Tùy allow-default; Loose: Tùy policy; Feasible-path: Tùy implementation; Điều cần chứng minh: Không mở rộng ngoài ý muốn
• Prefix alternate/backup — Strict: Dễ false reject; Loose: Có thể pass; Feasible-path: Có thể pass; Điều cần chứng minh: Test trước/sau failover
• Bogon/private ngoài phạm vi — Strict: Cần ACL bổ sung; Loose: Route-dependent; Feasible-path: Route-dependent; Điều cần chứng minh: uRPF không thay bogon filter
• FIB programming chậm — Strict: Cửa sổ drop/leak; Loose: Cửa sổ khác; Feasible-path: Cửa sổ khác; Điều cần chứng minh: Nối FIB với traffic
• VRF route leak — Strict: Theo table dùng; Loose: Theo table dùng; Feasible-path: Theo table dùng; Điều cần chứng minh: Isolation đúng VRF

Bắt đầu khi uRPF tắt để baseline forwarding của mọi source class và xác nhận attack corpus thật sự tới DUT. Bật loose mode trước nếu phù hợp, chạy valid/invalid class, sau đó strict và feasible-path support trong cùng route state. Chỉ thay một biến mỗi lượt; reset counter và lưu hash cấu hình.

Với mỗi mode, thử traffic hai chiều, ECMP, alternate uplink và prefix có/không có route. Xác nhận packet hợp lệ qua application transaction, packet spoofed bị drop theo đúng reason. Thêm fragment và protocol khác nếu nằm trong scope, nhưng không gọi bypass ở lớp khác là lỗi uRPF nếu source check không được thiết kế xử lý trường hợp đó.

Withdraw best route, chuyển primary/backup, thêm/xóa ECMP path và thay default route khi traffic đang chạy. Đo thời điểm RIB đổi, FIB program và uRPF verdict đổi; cửa sổ giữa các stage là nơi false reject hoặc leak có thể xuất hiện. Lặp với control-plane restart và BFD-triggered convergence nếu thuộc kiến trúc.

Tăng prefix, flow và PPS theo bậc, theo dõi table/CPU/log. Test interface flap và policy rollback để xác nhận protection tự phục hồi. Với exception, kiểm tra scope tối thiểu và negative test quanh biên prefix; một ACL ngoại lệ quá rộng có thể vô hiệu hóa mục tiêu source validation.

• Vẽ trust boundary và asymmetric return path.
• Ghi model/OS, VRF, mode, default-route và exception.
• Lưu RIB/FIB/ECMP state trước từng run.
• Tạo corpus valid, alternate, absent, bogon và spoofed source.
• Baseline khi uRPF tắt; kiểm tra từng mode riêng.
• Đo false accept, false reject và drop reason.
• Gây route withdraw, failover, ECMP change và interface flap.
• Nối RIB/FIB programming với traffic timeline.
• Stress prefix/PPS; theo dõi CPU, table và log loss.
• Lưu pcap, sequence, route dump, config và verdict.

uRPF là một lớp source address validation, không thay thế ACL bogon, DDoS protection, authentication hoặc SAV ở access layer. Loose mode có thể cho qua source giả nếu route tồn tại; strict mode có thể không phù hợp với asymmetry. Feasible-path hiệu quả phụ thuộc route information và implementation.

Kết quả chỉ áp dụng cho topology, RIB/FIB, VRF, route scale, mode và version đã đo. Không tuyên bố “chặn spoofing hoàn toàn” từ vài prefix mẫu; phải công bố corpus, interface role, exception và route state.

• uRPF: Kiểm tra reverse reachability của source address theo policy.
• Strict mode: Thường yêu cầu best reverse path trùng ingress interface.
• Loose mode: Thường yêu cầu source có route, không nhất thiết cùng interface.
• Feasible path: Đường reverse hợp lệ/khả thi ngoài best path hiện tại.
• False reject: Traffic hợp lệ bị source validation chặn.
• False accept: Traffic source giả vượt qua validation.
• BCP 38: Thực hành ingress filtering chống source spoofing.