Kiểm thử IPsec anti-replay: cửa sổ sequence, packet reordering và multipath

Hai yêu cầu phải cùng đúng: gói ESP trùng sequence trong cùng Security Association (SA) bị loại; gói hợp lệ đến muộn trong biên thiết kế vẫn được nhận. Chỉ kiểm tra throughput khi đường ổn định sẽ bỏ qua failure mode phổ biến nhất: burst reordering lúc reroute hoặc khi hai member có latency chênh lệch.

Tiêu chí nên nêu rõ phạm vi: tunnel/transport mode, IPv4/IPv6, thuật toán, SA lifetime, số luồng, tải, độ sâu reordering và loại failover. “Không loss” không đủ nếu anti-replay đã bị tắt hoặc counter không chứng minh gói lặp bị chặn.

RFC 4303 quy định sequence number tăng đơn điệu theo SA; receiver dùng cửa sổ để phát hiện replay. Gói có sequence thấp hơn mép trái bị coi là quá cũ; gói nằm trong cửa sổ chỉ được chấp nhận nếu chưa thấy; gói mới hơn đẩy cửa sổ tiến lên. Extended Sequence Number thay đổi cách xử lý không gian sequence nhưng không xóa bài toán reordering.

RFC 6479 mô tả thuật toán anti-replay không cần bit shifting, nhưng implementation và kích thước cửa sổ vẫn là vấn đề của sản phẩm. Không suy từ RFC rằng mọi thiết bị hỗ trợ cùng mức window, cùng scale SA hay cùng telemetry.

Dùng hai IPsec peers, mỗi bên có capture trước mã hóa và sau giải mã. Giữa chúng đặt network emulator với hai nhánh latency khác nhau hoặc một cơ chế reorder theo độ sâu/xác suất. Nếu kiểm thử thiết bị HA, thêm đường quản lý độc lập để thu event và counter khi data path gián đoạn.

Traffic profile phải có nhiều flow, packet size và rate. Một UDP flow giúp thấy sequence rõ; TCP cho biết tác động lên application do retransmission và reordering. Chạy baseline không impairment, sau đó tăng reordering depth từng bậc trong khi giữ loss và delay cố định.

Khóa window size, ESN, SA lifetime, rekey margin, số SA, cipher suite, MTU, offload và policy selector. Rekey giữa bài có thể reset sequence context và làm sai kết luận. Offload phần cứng có thể dùng counter khác software path; cần biết nguồn counter nào là authoritative cho phiên bản đang thử.

Giữ riêng bốn impairment: reordering, duplication, loss và delay. Nếu vừa duplicate vừa reorder, một anti-replay drop có thể đúng về bảo mật nhưng khó xác định gói nguồn nào gây ra. Dùng packet identifier ở clear side và ESP sequence ở encrypted side để correlation.

Một test chỉ pass khi replay injection bị chặn và lưu lượng hợp lệ đạt SLO. Không bù một failure bảo mật bằng một pass hiệu năng.

• Bảo mật — KPI: Tỷ lệ replay bị chặn; Bằng chứng: Counter anti-replay, ESP sequence capture
• Chất lượng — KPI: Loss của gói hợp lệ; Bằng chứng: Tx/Rx application counter, clear-side capture
• Chịu reorder — KPI: Độ sâu tối đa trước drop; Bằng chứng: Emulator log, sequence arrival order
• Hiệu năng — KPI: Throughput, latency, CPU; Bằng chứng: Generator và DUT telemetry
• Failover — KPI: Detection và restoration; Bằng chứng: Event log, traffic time series
• Vòng đời SA — KPI: Rekey loss/duplicate; Bằng chứng: IKE log, SPI transition

• Drop khi failover, counter replay tăng — Khả năng: Reordering vượt window; Hành động ưu tiên: Đo depth, kiểm tra path latency, cân nhắc tăng window; Rủi ro: Window lớn dùng thêm trạng thái
• Duplicate bị nhận — Khả năng: Anti-replay tắt/sai SA; Hành động ưu tiên: Kiểm tra policy, SPI và counter; Rủi ro: Replay attack không bị chặn
• Drop định kỳ gần rekey — Khả năng: Chuyển SA không sạch; Hành động ưu tiên: Đối chiếu IKE/ESP timeline; Rủi ro: Có thể nhầm với congestion
• Chỉ TCP giảm throughput — Khả năng: Reordering gây retransmission; Hành động ưu tiên: Đo out-of-order và TCP recovery; Rủi ro: Không nhất thiết là ESP drop
• Counter không khớp capture — Khả năng: Offload/telemetry khác path; Hành động ưu tiên: Xác minh nguồn counter; Rủi ro: Kết luận sai nếu chỉ nhìn CLI tổng

1. Ghi inventory model, software, license, crypto profile và giới hạn window công bố. 2. Xác nhận anti-replay bật; lưu SA, SPI, ESN và counter baseline. 3. Chạy UDP/TCP baseline ở nhiều frame size, không impairment. 4. Tiêm một bản sao của gói đã nhận; xác minh receiver drop và counter tăng đúng một. 5. Tạo late packet còn trong window; xác minh nhận đúng nếu chưa thấy. 6. Tăng reordering depth qua biên window; ghi điểm bắt đầu drop, không coi đó là lỗi nếu đúng thiết kế. 7. Thử asymmetric multipath với latency delta tăng dần. 8. Kích hoạt link/peer failover khi tải ổn định; đo service restoration và anti-replay drop burst. 9. Thử rekey theo thời gian và theo byte; correlation SPI cũ/mới. 10. Lặp sau khi thay đổi window hoặc traffic engineering, giữ mọi biến còn lại.

Đầu tiên xác nhận drop ở đâu bằng capture clear/encrypted hai phía. Sau đó kiểm tra SPI, ESP sequence, anti-replay counter và thời điểm rekey. Nếu sequence đến lệch nhưng vẫn trong cửa sổ, tìm authentication failure hoặc MTU. Nếu vượt cửa sổ, đo latency delta giữa các path thay vì lập tức tắt bảo vệ.

Ưu tiên biện pháp theo thứ tự: sửa bất cân bằng đường; pin flow để tránh per-packet load balancing; điều chỉnh queue; tăng window trong giới hạn được hỗ trợ và kiểm chứng resource; chỉ chấp nhận tắt anti-replay khi có quyết định rủi ro chính thức và biện pháp bù—không coi đó là “fix” mặc định.

Kết quả lab không đại diện cho mọi ASIC, cipher, SA scale hay tốc độ. Capture trên đường mã hóa không nhìn thấy payload; capture trên clear side phải được bảo vệ vì chứa dữ liệu nhạy cảm. Một gói bị drop theo đúng anti-replay có thể là hành vi đúng, trong khi dịch vụ vẫn không đạt SLO do thiết kế multipath.

• Security Association (SA): ngữ cảnh một chiều chứa thuật toán, khóa, SPI và sequence state.
• SPI: chỉ số nhận diện SA trong ESP.
• Anti-replay window: cửa sổ theo dõi sequence đã nhận.
• Reordering depth: khoảng cách sequence tối đa của gói đến lệch thứ tự.
• ESN: extended sequence number mở rộng không gian đếm.
• Rekey: tạo SA/khóa mới theo thời gian hoặc lưu lượng.