Kiểm thử QUIC connection migration: NAT rebinding, path validation và anti-amplification

RFC 9000 cho phép endpoint xử lý thay đổi địa chỉ peer bằng path validation. Tuy nhiên, thay UDP port do NAT rebinding khác với client chủ động đổi từ Wi-Fi sang cellular; server đổi địa chỉ lại là preferred address hoặc cơ chế triển khai khác. Mỗi trường hợp cần một giả thuyết và bằng chứng riêng.

Bài đo phải trả lời: connection có giữ nguyên hay tạo handshake mới; application stream nào bị gián đoạn; đường mới được xác thực trong bao lâu; traffic trên đường chưa xác thực có vượt giới hạn; congestion control và RTT estimate có được xử lý phù hợp; và sau lỗi, goodput cùng tail latency có trở lại baseline không.

Topology tối thiểu gồm client QUIC, hai access path độc lập, hai NAT có thể đổi mapping, network emulator trên từng path, server/load balancer và điểm thu metric ứng dụng. Capture ở phía client, trước và sau NAT, cùng phía server; đồng bộ clock để ghép PATH_CHALLENGE, PATH_RESPONSE, packet number, stream event và fault timeline.

Nếu dùng anycast hoặc load balancer, cần pin hoặc ghi lại backend selection. Connection ID phải được route đúng sau đổi 5-tuple; nếu traffic sang node không có state, lỗi là bài toán steering/state distribution chứ không chỉ là QUIC transport.

Ghi rõ client/server library, phiên bản, QUIC version, ALPN, TLS configuration, Connection ID length/rotation, idle timeout, keepalive, datagram support và policy cho active migration. Khóa application mix: số stream, hướng truyền, object size, request rate, connection age và lượng dữ liệu in-flight tại thời điểm chuyển đường.

Với mạng, kiểm soát RTT và độ trễ một chiều, jitter, random/burst loss, bandwidth, queue, MTU, ECN, reordering và NAT mapping lifetime. Đổi một biến mỗi run trước khi ghép worst credible case; một migration lúc connection rỗi không đại diện migration khi upload hoặc streaming đang full-rate.

• Biến: Thay đổi địa chỉ · Baseline: Chỉ đổi UDP port · Ca biên cần thử: Đổi IP và port, mất path cũ
• Biến: Path mới · Baseline: RTT/bandwidth tương đương · Ca biên cần thử: RTT tăng, bandwidth giảm, asymmetric
• Biến: In-flight data · Baseline: Connection rỗi · Ca biên cần thử: Nhiều stream và burst lớn
• Biến: NAT · Baseline: Mapping ổn định · Ca biên cần thử: Rebinding, timeout, port collision
• Biến: CID · Baseline: CID còn hiệu lực · Ca biên cần thử: Rotation, retire, LB đổi backend
• Biến: MTU · Baseline: 1.280 byte trở lên · Ca biên cần thử: PMTU khác nhau giữa hai path

Endpoint dùng PATH_CHALLENGE và PATH_RESPONSE để kiểm chứng peer có thể nhận packet trên đường mới. Bằng chứng nên cho thấy challenge/response đúng path, token khớp và trạng thái validation chuyển đúng thời điểm; không coi một packet ứng dụng tới được server là đủ chứng minh hoàn tất validation.

Trước khi địa chỉ được xác thực, server bị giới hạn lượng dữ liệu gửi theo quy tắc anti-amplification của RFC 9000. Test phải đo byte nhận và byte gửi trên path chưa xác thực, đồng thời thử PATH_RESPONSE bị delay, loss hoặc giả mạo. Pass khi server không khuếch đại quá mức, dữ liệu vẫn được bảo vệ bởi QUIC và byte budget của đường chưa xác thực được tuân thủ và vẫn tiến triển khi response hợp lệ đến.

Path validation không đồng nghĩa path tốt. Sau validation, endpoint còn phải cập nhật RTT/congestion state phù hợp, xử lý PMTU và phát hiện path failure. Đừng gộp “validation thành công” với “service restoration đạt SLO”.

RFC 9000 áp dụng giới hạn gửi tối đa ba lần số byte nhận theo quy tắc của đường/địa chỉ chưa xác thực. Endpoint phản ứng với migration phải xét ngân sách này trên đường mới; không mặc định cấm mọi application data trước validation. QUIC cần hỗ trợ UDP payload ít nhất 1.200 byte; IP MTU phải đủ chứa cả UDP/IP overhead. PATH_CHALLENGE, PATH_RESPONSE và packet number cần qlog hoặc khả năng giải mã phù hợp để đọc được.

KPI chính là application interruption: thời gian từ phản hồi/byte hữu ích cuối trên path cũ đến phản hồi/byte hữu ích đầu ổn định trên path mới. Bổ sung migration success rate, validation duration, packet loss/reordering, retransmission, goodput, p95/p99 request latency, stream reset, duplicate transaction và thời gian về baseline.

Lưu qlog, pcap, config hash, random seed, NAT table trước–sau, impairment profile và timeline. Verdict phải gắn với cửa sổ đo; số trung bình cả bài dễ che khoảng ngắt ngắn nhưng gây lỗi giao dịch.

• KPI: Validation duration · Cách đo: PATH_CHALLENGE → PATH_RESPONSE hợp lệ · Bằng chứng: qlog/pcap hai đầu
• KPI: Interruption · Cách đo: Khoảng trống dữ liệu hữu ích · Bằng chứng: Application log + qlog
• KPI: Loss/reordering · Cách đo: Packet number và ACK range · Bằng chứng: qlog/pcap
• KPI: Goodput recovery · Cách đo: Payload/s sau fault so với baseline · Bằng chứng: Generator/server metric
• KPI: Anti-amplification · Cách đo: Byte TX/RX trước validation · Bằng chứng: Counter theo path
• KPI: Session integrity · Cách đo: Stream, request, commit không lặp · Bằng chứng: Trace/audit log
• KPI: Backend continuity · Cách đo: CID → backend/state · Bằng chứng: LB log và server ID

Khi mục tiêu là mobility, ưu tiên interruption và session integrity. Khi mục tiêu là chống lạm dụng, ưu tiên validation, byte budget và xử lý địa chỉ giả. Khi mục tiêu là capacity, migration storm phải là traffic profile riêng để không che tải steady-state.

• Kịch bản: NAT rebinding · Điều cần chứng minh: Giữ connection, xác thực mapping mới · Dấu hiệu fail: Handshake lại hoặc timeout
• Kịch bản: Wi-Fi → cellular · Điều cần chứng minh: Stream tiếp tục trong SLO · Dấu hiệu fail: Reset/duplicate transaction
• Kịch bản: Path cũ còn sống · Điều cần chứng minh: Policy chọn path có thể giải thích · Dấu hiệu fail: Ping-pong hoặc dùng nhầm path
• Kịch bản: PATH_RESPONSE mất · Điều cần chứng minh: Retry có giới hạn · Dấu hiệu fail: Loop challenge/reconnect storm
• Kịch bản: Path mới MTU thấp · Điều cần chứng minh: Không blackhole payload lớn · Dấu hiệu fail: Small packet qua, data stream treo
• Kịch bản: LB đổi backend · Điều cần chứng minh: CID steering/state đúng · Dấu hiệu fail: Stateless reset ngoài dự kiến
• Kịch bản: Địa chỉ giả mạo · Điều cần chứng minh: Không amplification/data leak · Dấu hiệu fail: Vượt byte budget của đường chưa xác thực

Pha 1 chạy baseline không đổi đường ở nhiều connection age và application mix. Pha 2 chỉ đổi UDP port để mô phỏng NAT rebinding. Pha 3 đổi IP/port có overlap giữa hai path; pha 4 cắt path cũ tức thời. Pha 5 thêm RTT/loss/MTU bất lợi trên path mới; pha 6 tạo migration storm theo phân phối thực tế.

Mỗi pha chạy connection rỗi, download, upload và bidirectional stream. Thử cả request idempotent và giao dịch có side effect với idempotency key. Fault injection phải có timestamp chính xác và control run tương ứng; lặp tối thiểu ba lần hoặc đủ mẫu để báo confidence interval.

Checklist pass/fail cần tách transport, security và application. Có thể pass path validation nhưng fail SLO; cũng có thể ứng dụng tự reconnect thành công nhưng QUIC migration thực tế không hoạt động.

• Ghi version, ALPN, QUIC transport parameters, CID và LB policy.
• Kiểm tra capture/qlog nhìn thấy path event và application correlation ID.
• Chạy baseline theo từng traffic profile; xác lập p95/p99 và goodput.
• Tạo NAT rebinding có kiểm soát, rồi đổi access path với overlap.
• Lặp lại khi cắt path cũ, làm mất PATH_RESPONSE và giảm MTU path mới.
• Kiểm byte budget trước validation và mọi stream/transaction sau migration.
• Tăng số migration/giây; theo dõi CPU, state table, queue và LB skew.
• Dừng fault, đo recovery về baseline và kiểm state/NAT entry được dọn.
• Xuất raw result, qlog, pcap, topology, config và verdict từng KPI.

Kết quả chỉ áp dụng cho implementation, version, QUIC parameters, LB architecture, NAT, CID policy và traffic profile đã thử. HTTP/3 chạy trên QUIC nhưng hành vi application retry/cache có thể che lỗi transport; cần phân biệt request mới với stream tiếp tục trên cùng connection.

Packet capture giữa đường có thể không giải mã payload và có thể bị offload làm méo quan sát tại host. qlog là bằng chứng implementation, không thay thế counter mạng hay audit nghiệp vụ. Không tuyên bố “hỗ trợ mobility” nếu chưa thử đổi IP thật, path bất lợi và session có dữ liệu in-flight.

• Connection ID: Định danh QUIC cho phép route connection độc lập với 5-tuple.
• NAT rebinding: Mapping IP/port phía ngoài của NAT thay đổi.
• Path validation: Cơ chế xác minh peer nhận được packet tại địa chỉ mới.
• Anti-amplification: Giới hạn dữ liệu endpoint gửi tới địa chỉ chưa xác thực.
• qlog: Định dạng log sự kiện QUIC phục vụ phân tích transport.
• Goodput: Tốc độ payload hữu ích, không gồm overhead và retransmission.
• Stateless reset: Cách endpoint báo không còn trạng thái connection mà không cần giữ state.