Kiểm thử BGP FlowSpec: rule precedence, validation, TCAM và safe withdrawal

RFC 8955 mô tả dissemination FlowSpec cho IPv4; RFC 8956 mở rộng cho IPv6. Flow specification NLRI mang các component match và extended communities mang traffic-filtering action. Mục tiêu test phải ghi rõ address family, action được phép, origin/controller, validation policy và router/model đích.

Validation không chỉ là xác thực peer: RFC 8955 quy định liên hệ với route unicast; RFC 9117 sửa quy trình cho các tình huống iBGP, nên phải ghi rõ bộ quy tắc validation implementation sử dụng. Không coi FlowSpec là firewall policy tổng quát. Nó thường phù hợp mitigation có phạm vi và thời gian rõ, nhưng quyền quảng bá rule tạo blast radius lớn. Câu hỏi đầu tiên là “ai được phép phát rule nào tới đâu”, trước khi đo packets per second.

Topology lab gồm FlowSpec controller hoặc test BGP speaker, route reflector nếu production có, router biên/DUT, traffic generator hai chiều và collector telemetry. Tạo victim prefix, benign service và attack flows riêng; không dùng default route hay production prefix.

Thu bốn lớp bằng chứng: BGP update/raw NLRI-action, received/validated FlowSpec RIB, hardware/forwarding entry và packet counters/capture. Với redirect-to-VRF hoặc redirect-to-IP nếu implementation hỗ trợ, bổ sung scrubbing path và kiểm return traffic.

Khóa software build, AFI/SAFI, BGP policy, source AS/path, validation mode, component order, action set, update batching, hardware profile và existing ACL/QoS. Tách IPv4/IPv6 và control-plane-only/hardware-installed state.

Traffic profile phải có packet size, protocol, source/destination prefix/port, fragments, DSCP, TCP flags và offered rate. Mỗi rule cần near-match traffic để phát hiện match rộng quá mức. Chạy cùng profile khi chưa có FlowSpec làm baseline.

KPI cần percentile hoặc worst-case trong burst update, không chỉ một lần quảng bá. Nếu controller timestamp và router clock khác nhau, dùng orchestrator/traffic observation thống nhất để đo duration.

• KPI: Rule acceptance · Cách đo: Inject → validated RIB · Bằng chứng: BGP trace + policy log · Pass/fail: Đúng origin/component
• KPI: Hardware install · Cách đo: Validated → active entry · Bằng chứng: FIB/TCAM state · Pass/fail: Không silent reject
• KPI: Mitigation latency · Cách đo: Inject → attack giảm · Bằng chứng: Continuous counter · Pass/fail: Theo response SLO
• KPI: Collateral damage · Cách đo: Benign loss/latency · Bằng chứng: Near-match flows · Pass/fail: Không vượt ngân sách
• KPI: Withdrawal recovery · Cách đo: Withdraw → normal traffic · Bằng chứng: Timeline + counters · Pass/fail: Không stale entry
• KPI: Capacity behavior · Cách đo: Rule Count/rate tăng dần · Bằng chứng: TCAM/CPU/queue · Pass/fail: Fail rõ, không chặn rộng

FlowSpec match các trường packet được chuẩn hỗ trợ, không nhận diện tên ứng dụng như nginx. Rule ordering/precedence theo RFC 8955 phải kiểm bằng packet, không suy từ UI; cần kiểm thêm traffic-action terminal bit và tương tác nhiều action, không mặc định mọi rule đều hoạt động như first-match ACL. Tạo cặp overlap có kết quả khác nhau để chứng minh implementation áp đúng rule được ưu tiên và counter gắn đúng entry.

• Trường hợp: Exact victim · Rule: Prefix lab /32 + TCP + destination port 443 · Traffic phải tác động: Chỉ victim/port · Negative control: Cùng IP port khác
• Trường hợp: Prefix range · Rule: Destination subnet · Traffic phải tác động: Subset đã duyệt · Negative control: Prefix kế cận
• Trường hợp: TCP flags · Rule: SYN pattern · Traffic phải tác động: SYN flood · Negative control: Established/ACK
• Trường hợp: Rate limit · Rule: Match cụ thể · Traffic phải tác động: Rate theo policy · Negative control: Benign class khác
• Trường hợp: Discard · Rule: IOC/attack tuple · Traffic phải tác động: Drop có counter · Negative control: Near-match vẫn đi
• Trường hợp: Overlap · Rule: Rule rộng + hẹp · Traffic phải tác động: Precedence xác định · Negative control: Không phụ thuộc thứ tự inject

• Bước 1: Chốt controller identity, peer/authentication, import/export policy và allowlist action/prefix.
• Bước 2: Capture baseline RIB, TCAM/resource và benign/attack traffic.
• Bước 3: Inject rule exact-match; xác nhận parse, validation, propagation và hardware install.
• Bước 4: Đo attack suppression, benign throughput/latency/packet loss và per-rule counter.
• Bước 5: Thử component biên: port range, fragment, TCP flag, IPv6 prefix nếu có.
• Bước 6: Inject rule từ peer/AS không được phép, malformed/unsupported action và prefix ngoài scope; yêu cầu reject có log.
• Bước 7: Tạo overlap/precedence matrix; đảo thứ tự quảng bá để loại trừ phụ thuộc không chủ ý.
• Bước 8: Withdraw rule; xác nhận hardware entry/counter biến mất và service trở lại baseline.

Tăng số rule và update rate theo bậc, phối hợp rule size/action khác nhau. Theo dõi BGP CPU, policy queue, TCAM utilization, install failure và thời gian cập nhật. Khi gần capacity, hệ thống phải có hành vi quan sát được; silent accept trong control plane nhưng không enforce là lỗi nghiêm trọng.

Fault set gồm controller disconnect, RR failover, partial propagation, router reboot và withdrawal storm. BGP FlowSpec không có TTL/expiry per-rule mặc định; mất controller không bảo đảm rule biến mất ngay nếu phiên BGP hoặc cơ chế giữ stale route còn hiệu lực. Thiết kế canary rule trên prefix test, expiry/lease ở controller nếu kiến trúc có, two-person approval cho discard/redirect rộng và emergency withdrawal đã diễn tập.

Checklist release gate:

• Prefix/action nằm trong allowlist.
• Near-match benign flow có probe liên tục.
• Hardware capacity còn headroom đã định.
• Một lệnh/transaction withdrawal được xác minh.
• Có snapshot rule owner, ticket và expiry.

Đầu tiên xác định rule owner, NLRI/action, propagation scope và hardware entry; bảo toàn update/log trước khi withdraw. Nếu blast radius lớn, dùng emergency withdrawal hoặc import-policy block đã được duyệt thay vì chỉnh nhiều router thủ công.

Sau khi traffic phục hồi, kiểm rule đã biến mất ở controller, RR, FlowSpec RIB và hardware trên mọi edge. Re-run benign/attack controls, rà counter và tìm node stale. Root cause cần phân loại: generator logic, validation policy, precedence, platform resource hay change governance.

Một router chấp nhận FlowSpec không chứng minh router khác, ASIC khác hoặc software khác có cùng action/capacity. RFC wire behavior không cam kết model-specific hardware implementation.

Mitigation pass trong lab không dự báo DDoS production nếu traffic distribution, attack vector, routing và upstream capacity khác. FlowSpec chỉ là một control trong response plan; cần telemetry, routing, scrubbing và quy trình điều hành tương ứng.

• FlowSpec NLRI: tập component mô tả flow cần match.
• Traffic action: hành động như discard, rate-limit hoặc redirect theo hỗ trợ.
• Validation: policy kiểm route/rule có đủ điều kiện được chấp nhận.
• TCAM: tài nguyên lookup phần cứng thường dùng cho match/action.
• Collateral damage: ảnh hưởng ngoài mục tiêu tới lưu lượng hợp lệ.
• Safe withdrawal: thu hồi rule có kiểm soát và xác minh toàn chuỗi.