Chống phát lại IPsec: RFC 4303, ESN 64-bit và cân bằng đa lõi

Các thuật toán mã hóa tầng truyền tải bảo vệ gói tin IP trước nguy cơ nghe lén và giả mạo dữ liệu. Các bộ mã hiện đại tính toán giá trị kiểm tra tính toàn vẹn (ICV) để xác thực từng khung dữ liệu riêng lẻ. Tuy nhiên, việc chỉ xác thực gói tin cô lập không thể bảo vệ các giao thức mạng không hướng kết nối trước các đòn tấn công phát lại.

Nếu thiếu cơ chế đánh số thứ tự có lưu trạng thái, kẻ tấn công trên đường truyền trung gian có thể ghi lại các gói tin mã hóa hợp lệ rồi phát lại liên tục về phía cổng đích. Những gói tin phát lại này vẫn vượt qua bước kiểm tra mã hóa, làm tiêu tốn tài nguyên xử lý của CPU, gây gián đoạn máy trạng thái giao thức và tạo ra tình trạng từ chối dịch vụ. Nhằm ngăn chặn nguy cơ này, tiêu chuẩn IPsec Encapsulating Security Payload (ESP) theo chuẩn RFC 4303 bắt buộc phải sử dụng bộ đếm số thứ tự cùng cơ chế cửa sổ trượt chống phát lại.

Vai trò của số thứ tự trong đường hầm mạng mã hóa

Các đường hầm không liên kết đóng gói dữ liệu IP tầng 3 vào tiêu đề IP hoặc UDP bên ngoài. Do các bộ định tuyến chuyển tiếp các gói tin qua nhiều tuyến đường khác nhau, dữ liệu thường xuyên bị đảo lộn thứ tự hoặc xuất hiện bản sao trên đường truyền.

Trong một liên kết bảo mật IPsec (Security Association - SA), bên gửi gán một số thứ tự tăng dần đều đặn cho mỗi gói tin ESP gửi đi. Số thứ tự này đảm nhiệm hai chức năng cốt lõi:

Cung cấp dữ liệu ngẫu nhiên duy nhất cho vector khởi tạo (IV) và nonce mã hóa AEAD, ngăn chặn nguy cơ tái sử dụng khóa dòng.
Cho phép thiết bị nhận phát hiện các khung tin trùng lặp và loại bỏ các gói tin nằm ngoài phạm vi tiếp nhận cho phép.

+-----------------------------------------------------------------------------+
|                CẤU TRÚC ĐÓNG GÓI GÓI TIN IPSEC ESP (RFC 4303)               |
+-----------------------------------------------------------------------------+
| Tiêu đề IP ngoài | SPI (32-bit) | Số thứ tự gói tin (32-bit) | Tải trọng... |
+-----------------------------------------------------------------------------+

Bên gửi không bao giờ giảm giá trị bộ đếm số thứ tự trong suốt vòng đời của một liên kết SA đang hoạt động. Khi bộ đếm đạt tới ngưỡng giới hạn, hệ thống bắt buộc phải đàm phán lại một SA mới thông qua giao thức IKEv2 trước khi gửi tiếp dữ liệu.

Cơ chế cửa sổ trượt chống phát lại IPsec ESP (RFC 4303)

Bởi vì hạ tầng mạng có thể phân phối gói tin không theo trình tự ban đầu, thiết bị nhận IPsec không thể từ chối một cách máy móc mọi gói tin có số thứ tự nhỏ hơn gói vừa nhận. Tiêu chuẩn RFC 4303 định nghĩa thuật toán cửa sổ trượt sử dụng một mảng bitmask có chiều rộng $W$, thông thường được thiết lập từ 32 đến 1024 bit.

       <- Gói cũ bị loại bỏ -> | <- Cửa sổ trượt (Độ rộng W) -> | <- Gói tương lai ->
  ... -------------------------+--------------------------------+-------------> Không gian số
                               ^                                ^
                            (M - W + 1)                         M (Gói hợp lệ cao đã nhận)

Cổng tiếp nhận duy trì hai biến số then chốt:

$M$: Số thứ tự cao đã được xác thực và chấp nhận thành công.
Mảng bitmask kích thước $W$: Đại diện cho trạng thái của $W - 1$ số thứ tự đứng liền trước $M$.

Sự dịch chuyển cửa sổ và theo dõi trạng thái bitmask

Khi một gói tin ESP có số thứ tự $S$ đi tới cổng nhận, bộ xử lý chống phát lại sẽ đánh giá giá trị $S$ dựa trên biên giới hạn của cửa sổ trước khi thực hiện giải mã:

Trường hợp 1 ($S > M$): Gói tin mới hơn mọi gói tin từng ghi nhận. Hệ thống kiểm tra giá trị ICV. Nếu hợp lệ, cửa sổ dịch chuyển sang phải bằng cách dời bitmask sang trái $(S - M)$ vị trí, cập nhật $M = S$ và đánh dấu bit cho $S$.
Trường hợp 2 ($M - W + 1 \le S \le M$): Gói tin nằm trong phạm vi cửa sổ hiện tại. Bộ xử lý kiểm tra bit tại vị trí bù $(M - S)$. Nếu bit đã được bật, gói tin bị loại bỏ do trùng lặp. Nếu bit chưa bật, gói tin được đưa vào kiểm tra tính toàn vẹn và bit tương ứng được gán lên 1 khi xác thực thành công.
Trường hợp 3 ($S < M - W + 1$): Gói tin rơi về phía sau cửa sổ. Thiết bị lập tức loại bỏ gói tin mà không cần giải mã, đồng thời tăng bộ đếm lỗi chống phát lại.

Quy tắc loại bỏ gói tin cũ và gói tin trùng lặp

Việc lọc gói tin trước khi giải mã mang lại hiệu năng vượt trội. Bằng cách kiểm tra độ mới của số thứ tự trước khi kích hoạt thuật toán mã hóa nặng nề, cổng bảo mật ngăn chặn các đòn tấn công phát lại mà tiêu tốn rất ít chu kỳ tính toán của vi xử lý.

Các đòn tấn công làm nghẽn tài nguyên nhắm vào cổng kết thúc VPN bị triệt tiêu ngay tại tầng tiếp nhận dữ liệu. Những gói tin hợp lệ bị trễ do biến động đường truyền vẫn được xử lý an toàn miễn là độ lệch thời gian không vượt quá độ sâu $W$ của cửa sổ.

Nguy cơ cạn kiệt không gian số thứ tự 32-bit ở băng thông cao

Tiêu chuẩn IPsec đời đầu (RFC 2401) chỉ dành 32-bit cho trường số thứ tự ESP. Không gian 32-bit cho phép tối đa $2^{32} - 1 \approx 4.29 \times 10^9$ gói tin trước khi bộ đếm bị tràn. Giới hạn này nhanh chóng bị phá vỡ trên các đường truyền tốc độ nhiều gigabit hiện đại:

Tốc độ kết nối	Kích thước gói tin	Lưu lượng gói tin	Thời gian cạn kiệt bộ đếm
1 Gbps	1400 Bytes	89.2 Kpps	13.3 giờ
10 Gbps	1400 Bytes	892.8 Kpps	80.0 phút
40 Gbps	1400 Bytes	3.57 Mpps	20.0 phút
100 Gbps	1400 Bytes	8.92 Mpps	8.0 phút
100 Gbps	64 Bytes	148.8 Mpps	28.8 giây

Nếu liên kết SA cạn kiệt không gian số mà không hỗ trợ số thứ tự mở rộng, quá trình truyền dữ liệu sẽ phải tạm dừng để IKEv2 thiết lập lại phiên SA mới. Việc tái tạo khóa liên tục gây quá tải bộ xử lý và gây rớt gói tin định kỳ.

Số thứ tự mở rộng ESN: Bảo toàn tính toàn vẹn 64-bit

Tiêu chuẩn RFC 4303 và RFC 4304 định nghĩa cơ chế Extended Sequence Numbers (ESN) nhằm xóa bỏ hoàn toàn rào cản 32-bit. ESN mở rộng không gian số thứ tự lên 64-bit ($2^{64} - 1 \approx 1.84 \times 10^{19}$ gói tin). Ngay cả khi truyền tải gói tin kích thước tối thiểu ở tốc độ 100 Gbps, bộ đếm 64-bit vẫn có thể duy trì hoạt động liên tục trong hàng thiên niên kỷ mà không cần đàm phán lại phiên làm việc.

Cơ chế ESN tiết kiệm băng thông đường truyền bằng cách giữ nguyên cấu trúc tiêu đề ESP trên đường cáp. Tiêu đề vẫn chỉ truyền tải 32-bit thấp ($Seq_{low}$).

+-----------------------------------------------------------------------------+
|                KIẾN TRÚC SỐ THỨ TỰ MỞ RỘNG (ESN) THEO RFC 4303              |
+-----------------------------------------------------------------------------+
| Truyền trên dây mạng:    [ SPI (32-bit) ] [ Số thứ tự 32-bit thấp ]         |
| Lưu trữ nội bộ:          [ Số thứ tự 32-bit cao ]                           |
| Xác thực qua ICV:        [ 32-bit cao ngầm định ] + [ Toàn bộ khung ESP ]   |
+-----------------------------------------------------------------------------+

Tái tạo các bit bậc cao qua trạng thái bộ đếm ngầm định

Vì chỉ có $Seq_{low}$ xuất hiện trên đường truyền, bên nhận sẽ suy luận 32-bit bậc cao ($Seq_{high}$) dựa trên vị trí cửa sổ hiện tại:

Nếu $Seq_{low} \ge M_{low}$, gói tin thuộc về chu kỳ hiện tại, bên nhận gán $Seq_{high} = M_{high}$.
Nếu $Seq_{low} < M_{low}$ nhưng vẫn nằm gọn trong phạm vi cửa sổ trượt, bên nhận ghép $Seq_{low}$ với $M_{high}$.
Khi $M_{low}$ tiệm cận ngưỡng $2^{32} - 1$ và các số thứ tự bắt đầu quay vòng, bộ xử lý sẽ xác định xem $Seq_{low}$ thuộc chu kỳ mới $M_{high} + 1$ hay là gói tin trễ thuộc chu kỳ cũ $M_{high}$.

Để ngăn chặn các cuộc tấn công làm mất đồng bộ, mã xác thực ICV được tính toán trên toàn bộ giá trị 64-bit của số thứ tự. Nếu kẻ gian cố tình chèn số thứ tự sai lệch qua ranh giới quay vòng, bước kiểm tra ICV sẽ thất bại và gói tin lập tức bị hủy bỏ.

Điều hướng hàng đợi đa luồng và đảo lộn thứ tự gói tin

Các máy chủ và thiết bị định tuyến phân phối lưu lượng đi vào qua nhiều lõi CPU nhờ kỹ thuật Receive Side Scaling (RSS). Với các luồng tin thông thường, RSS tính toán băm trên 5 giá trị (giao thức, IP nguồn, cổng nguồn, IP đích, cổng đích). Tuy nhiên, gói tin IPsec ESP đã được mã hóa nên không có trường cổng ở tiêu đề ngoài.

Do đó, card mạng phần cứng chỉ có thể băm gói tin ESP dựa trên IP nguồn, IP đích và trường SPI 32-bit.

[ Gói tin ESP đi vào ] ---> [ Băm RSS card mạng (IP + SPI) ]
                                    |
                    +---------------+---------------+
                    v                               v
             [ Lõi CPU 0 ]                   [ Lõi CPU 1 ]
             (Giải mã gói)                   (Giải mã gói)
                    \                               /
                     +-------------> <-------------+
                                    |
                       [ Đảo lộn thứ tự gói tin ]
                                    v
                     [ Kiểm tra cửa sổ chống phát lại ]

Xung đột tài nguyên và mất gói tin với kích thước cửa sổ cũ

Khi nhiều lõi CPU cùng lúc xử lý các gói tin từ một phiên IPsec lưu lượng lớn, sự chênh lệch về thời gian thực thi giữa các nhân vi xử lý làm xáo trộn trật tự gói tin. Một gói tin trên Lõi 1 có thể đi tới bộ kiểm tra chống phát lại sớm hơn hàng trăm vị trí so với gói tin trên Lõi 0.

Nếu cửa sổ chống phát lại $W$ được cấu hình ở mức mặc định cũ là 32 hoặc 64 gói tin, sự đảo lộn thứ tự này sẽ dẫn tới tình trạng rơi rụng dữ liệu nghiêm trọng:

Lõi 1 đưa giá trị $M$ nhảy vọt lên trước 120 vị trí.
Lõi 0 chuyển tiếp gói tin tiếp theo với số $S < M - W + 1$.
Cổng tiếp nhận nhận định sai lầm rằng đây là gói tin cũ và hủy bỏ nó.

Việc đánh rơi gói tin nhầm lẫn này kích hoạt cơ chế truyền lại nhanh của TCP và bóp nghẹt cửa sổ tắc nghẽn của luồng dữ liệu. Kỹ sư hệ thống có thể kiểm tra địa chỉ định tuyến bên ngoài với công cụ kiểm tra IP.

Tối ưu hóa mảng bit vòng RFC 6479 cho đường hầm hiệu năng cao

Thuật toán cửa sổ trượt truyền thống phải dịch chuyển toàn bộ mảng bitmask mỗi khi nhận được số thứ tự mới. Với cửa sổ hẹp 32 hoặc 64-bit, việc này chỉ tốn vài phép tính dịch bit đơn giản (bitmask <<= shift).

Thế nhưng để khắc phục hiện tượng đảo thứ tự trên hệ thống đa lõi, kích thước $W$ cần mở rộng lên 1024 hoặc 4096 gói tin. Việc dịch chuyển khối bộ nhớ 4096-bit cho từng gói tin sẽ làm nghẽn băng thông bộ nhớ và gây lãng phí bộ nhớ đệm CPU.

Tiêu chuẩn RFC 6479 giải quyết triệt để vấn đề này bằng cách áp dụng cấu trúc đệm bitmask dạng vòng tròn không cần dịch chuyển bit:

+-----------------------------------------------------------------------------+
|             BỘ ĐỆM BITMASK VÒNG TRÒN CHỐNG PHÁT LẠI THEO RFC 6479           |
+-----------------------------------------------------------------------------+
| Khối 0 (64-bit)  | Khối 1 (64-bit)  | ... | Khối N (64-bit)                 |
+-----------------------------------------------------------------------------+
         ^                                      ^
   Chỉ mục: (Seq / 64) % Số_khối          Con trỏ vị trí đầu

Theo RFC 6479:

Mảng bit được chia thành các khối cố định có kích thước 32 hoặc 64-bit.
Số thứ tự mới được ánh xạ vào chỉ mục khối thông qua phép chia lấy dư: chi_muc = (seq / 64) % tong_so_khoi.
Khi cửa sổ tịnh tiến, thuật toán chỉ xóa trắng các khối trung gian mà con trỏ đi qua mà không cần sao chép bộ nhớ hàng loạt.
Tốc độ tra cứu đạt độ phức tạp hằng số $O(1)$ bất kể chiều rộng của cửa sổ lớn đến mức nào.

Cấu hình củng cố cửa sổ chống phát lại trên Linux XFRM và BSD

Các hệ điều hành hiện nay cung cấp đầy đủ các tham số tinh chỉnh để mở rộng cửa sổ chống phát lại và kích hoạt tính năng ESN.

Trên Linux, phân hệ XFRM quản lý trạng thái bảo mật IPsec qua bộ công cụ iproute2. Để khởi tạo một liên kết SA với cửa sổ 1024 gói tin theo chuẩn RFC 6479 và hỗ trợ ESN 64-bit:

# Thiết lập liên kết XFRM với cửa sổ trượt 1024 gói và cờ ESN
ip xfrm state add src 198.51.100.1 dst 203.0.113.1 \
    proto esp spi 0x1a2b3c4d reqid 1 mode tunnel \
    replay-window 1024 flag esn \
    aead "rfc4106(gcm(aes))" 0x0123456789abcdef0123456789abcdef01234567 128

Để theo dõi chỉ số thống kê và kiểm tra số gói tin bị loại bỏ trên cổng Linux:

# Kiểm tra bộ đếm lỗi chống phát lại của phiên SA
ip -s xfrm state show spi 0x1a2b3c4d

Thông số hiển thị sẽ chỉ rõ kích thước replay-window và biến đếm lỗi replay. Nếu biến đếm này liên tục tăng trong điều kiện đường truyền tải nặng mà không có dấu hiệu bị tấn công, kích thước cửa sổ hiện tại chưa đủ rộng để bù đắp độ trễ đa lõi.

Đối với môi trường FreeBSD và OpenBSD, người quản trị có thể thay đổi tham số hạt nhân thông qua lệnh sysctl:

# Tinh chỉnh độ sâu cửa sổ nhận ESP trên hệ điều hành BSD
sysctl net.inet.ipsec.esp_replaywindow=1024

Khi sử dụng các dịch vụ tự động như StrongSwan, tính năng ESN được thiết lập trong cấu hình đề xuất Child SA giai đoạn 2 bằng cách thêm chỉ định esn (esp=aes256gcm128-esn!).

Cách RiceGuard giải quyết đảo lộn thứ tự mà không tạo lỗ hổng

VPNRice phát triển công nghệ tăng tốc RiceGuard trên toàn bộ hệ thống máy chủ biên. Thay vì bắt buộc người dùng đánh đổi giữa mức độ bảo mật chống phát lại và năng lực xử lý đa lõi, RiceGuard kết hợp chu trình điều hướng luồng thông minh.

[ Lưu lượng người dùng ] -> [ Điều hướng luồng RiceGuard ] -> [ Xử lý mã hóa đa lõi ]
                                  |
                                  v
            [ Ma trận cửa sổ 4096-bit RFC 6479 ] -> [ Chuyển giao dữ liệu thông suốt ]

Điều hướng luồng vào lõi chuyên biệt: RiceGuard phân tích định danh phiên dữ liệu trước khi đóng gói, gán các luồng TCP và UDP riêng lẻ vào các luồng xử lý CPU cố định. Kỹ thuật này đảm bảo gói tin luôn đi vào tiến trình mã hóa theo đúng trình tự phát sinh.
Ma trận cửa sổ động 4096-bit: Trên các kết nối công cộng thường xuyên xuất hiện độ biến động đường truyền BGP, RiceGuard tự động co giãn bitmask lên tới 4096 gói tin theo thuật toán mảng vòng RFC 6479, triệt tiêu hiện tượng rớt gói tin oan uổng.
Đồng bộ hóa ESN bằng phần cứng: Các nút mạng biên thực hiện đồng bộ bộ đếm 64-bit ngay trên chip tăng tốc phần cứng chuyên dụng, ngăn ngừa nguy cơ nghẽn mạng khi truyền tải dữ liệu ở tốc độ 100 Gbps.

Để tận hưởng sự ổn định cùng năng lực bảo vệ mã hóa toàn diện trên các thiết bị máy tính và điện thoại, người dùng có thể cài đặt ứng dụng.

Tải VPNRice.

Các kỹ sư mạng quản trị hạ tầng trung tâm dữ liệu có thể tham khảo thêm bài phân tích về phát hiện sự cố mạng dưới một giây với BFD và tìm hiểu cơ chế cửa sổ trượt chống phát lại trong WireGuard. Đồng thời, hãy tìm hiểu thêm hướng dẫn tối ưu với thuật toán kiểm soát tắc nghẽn TCP BBR.

Danh mục triển khai cho cổng bảo mật IPsec thông lượng cao

Triển khai cơ chế chống phát lại an toàn trên hạ tầng VPN tốc độ cao đòi hỏi các bước rà soát bài bản:

Xác nhận đàm phán ESN: Kiểm tra cấu hình dịch vụ IKEv2 để đảm bảo đã kích hoạt tham số ESN cho các đề xuất ESP Child SA nhằm ngăn chặn quay vòng bộ đếm 32-bit.
Mở rộng kích thước cửa sổ: Tăng kích thước cửa sổ chống phát lại từ mức 32/64 mặc định lên tối thiểu 512 hoặc 1024 gói tin trên các cổng giao tiếp từ 1 Gbps trở lên.
Kích hoạt mảng bit RFC 6479: Đảm bảo nhân hệ điều hành đang vận hành thuật toán bitmask dạng vòng tròn để tránh lãng phí chu kỳ vi xử lý vào các thao tác dịch bit.
Đồng bộ hóa băm RSS card mạng: Thiết lập băm lưu lượng card mạng hợp lý hoặc áp dụng đóng gói UDP bên ngoài (NAT-T RFC 3948) để phân bố đều các luồng đối xứng vào các hàng đợi nhận.
Giám sát thông số lỗi rớt gói: Theo dõi biến đếm XfrmInReplayError (Linux SNMP) hoặc netstat -s -p esp trong Prometheus để phân biệt sự cố trễ mạng với các hành vi phát lại có chủ đích.
Duy trì kiểm tra tính toàn vẹn nghiêm ngặt: Không bao giờ tắt bỏ hoàn toàn chức năng chống phát lại (replay-window 0) như một giải pháp tạm thời, vì hành động này khiến toàn bộ hệ thống đối mặt với nguy cơ bị tấn công phá hoại nghiêm trọng.