Bài viết đề xuất giải pháp thiết kế hệ thống và xây dựng driver giao tiếp giữa khối trung tâm với khối mã hóa trên card PCIe – FPGA để có tăng tốc IPsec VPN cũng như giảm tải các tác vụ liên quan đến IPsec.
Trang 1Thiết kế hệ thống và xây dựng driver giúp tăng tốc mã hóa trên nền tảng FPGA hỗ trợ IPSEC
VPN
Nguyễn Hồng Hòa, Nguyễn Phan Hải Phú, Bùi Quốc Bảo, Hoàng Trang
Khoa Điện-Điện Tử, Trường Đại học Bách Khoa TP HCM Đại học Quốc gia Thành phố Hồ Chí Minh
Email: hoangtrang@hcmut.edu.vn
Tóm tắt— Trong bài báo này, chúng tôi đề xuất giải pháp
thiết kế hệ thống và xây dựng driver giao tiếp giữa khối
trung tâm với khối mã hóa trên card PCIe – FPGA để có
tăng tốc IPsec VPN cũng như giảm tải các tác vụ liên quan
đến IPsec Với hệ thống này, nó sẽ đòi hỏi độ phức tạp thấp
hơn khi không đảm nhận các giai đoạn khác trong giao
thức Encapsulating Security (ESP) cũng như giai đoạn
trao đổi khóa Internet Key Exchange (IKE) ban đầu Với
những lợi ích và khả năng của hệ thống này, nó sẽ phù hợp
để tích hợp với các thiết bị nhúng cỡ nhỏ hay các nút mạng
có năng lực xử lý không mạnh
Từ khóa- Internet Protocol Security (IPsec), Peripheral
Component Interconnect Express (PCIe), Driver giao tiếp
PCIe, OS Specific, Driver Specific
I GIỚITHIỆU Ngày nay, khi mà thời đại Internet phát triển rộng
khắp, những dịch vụ như đào tạo từ xa, mua hàng trực
tuyến, tư vấn y tế trực tuyến đã trở nên khá phổ biến với
tất cả mọi người Từ đó, người ta đã đưa ra mô hình mới
nhằm thỏa mãn những yêu cầu trên mà vẫn tận dụng
được cơ sở hạ tầng mạng vốn có, đó chính là mạng riêng
ảo (Virtual Private Network-VPN) VPN cung cấp cơ
chế mã hóa dữ liệu trên đường truyền tạo ra một đường
ống (tunnel) bảo mật giữa nơi gửi và nơi nhận và IPsec
(Internet Protocol Security) chính là một trong những
giao thức tạo nên cơ chế “đường ống bảo mật” cho VPN
IPsec là một bộ giao thức bổ sung bảo mật đối với thông
tin trao đổi ở lớp IP trong mô hình mạng TCP/IP Đối
với một nút mạng điển hình, việc triển khai thực thi giao
thức IPsec được mặc định sử dụng phần mềm đơn thuần
và ít nhiều đã gây ra giảm thông lượng mạng đi qua nút
cũng như làm quá tải CPU của thiết bị đó Khi tốc độ
mạng tăng lên, việc giảm thiểu chi phí xử lý (processing
overheads) gói IPsec là yêu cầu tất yếu trong nhiều hệ
thống đặc biệt là những gateway, những thiết bị nhúng
cỡ nhỏ nhưng đồng thời cũng đặt ra nhiều thách thức cần
phải đối mặt
Khi xây dựng hệ thống IPsec VPN có nhiều vấn đề
gặp phải Khi kết nối VPN tồn tại trong một khoảng thời
gian ngắn, chi phí cho quá trình trao đổi khóa IKE (IKE
overheads) sẽ chiếm tỉ lệ lớn nhất trong tổng chi phí (overheads) [1] Mặc dù giao thức ESP chỉ chiếm chi phí
ít cho 1 gói nhưng khi xử lý một số lượng lớn các gói trong cùng 1 kết nối thì chi phí cho việc xử lý ESP (ESP overheads) có thể vượt trội so với chi phí cho IKE Đối với một kết nối IPsec VPN có thời gian tồn tại đủ lâu, việc thực hiện mã hóa đóng vai trò then chốt trong thời gian xử lý gói ESP Lựa chọn một thuật toán tối ưu cùng việc sử dụng phần cứng tăng tốc cho việc mã hóa có thể
cải thiện thời gian quá trình xử lý gói ESP [1] Công trình [2] đã đưa ra cách nhìn tổng quan về bộ giao thức
IPsec và kiến trúc cũng như đưa ra những ứng dụng thực
tế việc triển khai IPsec có thể tăng lên sự tiêu thụ tài nguyên của CPU một cách đáng kể Sự tiêu thụ tài nguyên CPU phụ thuộc vào lưu lượng IPsec hay giao thức mã hóa đã sử dụng Hiện tại, các thuật toán thể hiện tốt nhất sự cân bằng giữa sự cung cấp bảo mật và hiệu năng là GCM-AES bởi vì nó cho phép việc triển khai
trên phần cứng [2] Với sự sẵn có của các sản phẩm
thương mại hỗ trợ việc giảm tải IPsec, các giải pháp IPsec cung cấp sự đánh đổi giữa sự đơn giản của việc triển khai với sự phổ biến của việc thực thi bằng phần mềm và tổng thể hiệu suất nền tảng có thể đạt với giải pháp phần cứng Các giải pháp dựa trên phần mềm là được đề xuất như là một điểm bắt đầu mặc định Khi chi phí CPU cho việc xử lý lưu lượng IPsec là một vấn đề, hướng giải quyết bằng cách giảm tải phần cứng nên được cân nhắc Dựa trên những đánh giá của các nghiên cứu trong các bài báo và sách đã đề cập ở trên, ta đi đến những đánh giá chung cho việc cải thiện tốc độ IPsec VPN nói chung cũng như hiệu năng của việc thực thi bộ giao thức IPsec nói triêng Ta thấy rằng việc thực thi xử
lý gói theo giao thức IPsec có thể làm tăng lên sự tiêu thụ tài nguyên của CPU một cách đáng kể và sự tiêu thụ
tài nguyên CPU này phụ thuộc vào lưu lượng IPsec Và
khi đó giải pháp dựa trên phần cứng tăng tốc mã hóa sẽ đóng vai trò quan trọng trong việc đạt đến hiệu năng cao
ở trong hệ thống lớn cũng như là một cách tiếp cận hữu ích trong việc làm giảm mức sử dụng CPU ở hệ thống nhỏ và chậm
Trang 2Trong bài báo này, chúng tôi sẽ trình bày cách xây
dựng mô hình hệ thống, trong đó phần tăng tốc mã hóa
sẽ thực hiện trên nền tảng FPGA Và để nâng cao hơn
hiệu năng ở trong các hệ thống, thiết kế driver giúp tăng
tốc giữa khối FPGA và hệ thống chính thông qua cổng
PCIe là một yếu tố quan trọng và được đề xuất trong bài
báo này Với thiết kế hệ thống của chúng tôi sẽ hỗ trợ
hiệu quả cho những thiết bị nhúng để giảm tải cho CPU
khi xét đến chi phí xử lý mã hóa cho giao thức IPsec Hệ
thống mã hóa sẽ gồm hai phần: Lõi IP thực thi mã hóa
và Linux driver Trong đó bài báo sẽ đi sâu vào việc xây
dựng Linux driver để tích hợp thiết bị mã hóa này vào
các thiết bị nhúng Linux đang cần xử lý các vấn đề liên
quan đến IPsec VPN Linux driver sẽ thực hiện giao tiếp
và xử lý các vấn đề truyền nhận dữ liệu giữa IPsec Stack
Phần xây dựng bộ mã hóa và giải mã trên phần cứng sẽ
không được đề cập đến trong bài báo này
Phần còn lại của bài báo được tổ chức như sau:
Chúng tôi sẽ trình bày phương thức thực hiện của giao
thức IPsec VPN trong Phần II Phần III sẽ đưa ra mô
hình để nâng cao hiệu suất trong việc triển khai IPsec
VPN Chúng tôi sẽ tiến hành thiết kế phần Device Driver
cho mô hình đã được nêu bên trên trong phần IV Phần
V sẽ cung cấp các kết quả của bài kiểm tra hệ thống để
từ đó đưa ra các nhận xét về hiệu suất của mô hình đã đề
cập Cuối cùng, chúng tôi kết luận bài báo trong phần
VI
II GIAO THỨC BẢO MẬT INTERNET
Giao thức bảo mật Internet, hay còn gọi là IPsec, là
một tập hợp các giao thức hỗ trợ bảo vệ thông tin liên
lạc qua mạng IP [3] Các giao thức IPsec làm việc cùng
nhau theo nhiều cách kết hợp khác nhau để bảo vệ thông
tin liên lạc IPsec là giao thức nằm ở lớp 3 – lớp Network
trong mô hình OSI hay TCP/IP Hai giao thức cốt lõi
trong IPsec, được thể hiện trong hình 1, là
Authentication Header (AH) và Encapsulating Security
Payload (ESP) Điều cần lưu ý để IPsec có thể hoạt động
là mô hình phải có hỗ trợ trao đổi khóa (IKE) để giúp
hai điểm trên mạng có thể trao đổi thông tin một cách
bảo mật IKE giúp máy tính có thể trao đổi khóa để mã
hóa, phương thức mã hóa được dùng cho IPsec qua môi
trường mạng không tin cậy mà vẫn giữ được tính bảo
mật và điểm kết nối IPsec phải có hỗ trợ các bộ mã hóa,
hàm băm để hoạt động
Hình 1 Giao thức cốt lõi của IPsec
Tổng quan về kết nối IPsec VPN được thể hiện bởi hình 2:
Hình 2 Tổng quan về kết nối IPsec Mục đích của giao thức trao đổi khóa (IKE) là thương lượng, tạo và quản lý các liên kết bảo mật (SA) [7] Liên kết bảo mật (SA) là một thuật ngữ chung cho một tập hợp các giá trị xác định các tính năng và bảo vệ IPsec được áp dụng cho một kết nối Các SA cũng có thể được tạo theo cách thủ công, sử dụng các giá trị được thỏa thuận trước bởi cả hai bên, nhưng các SA này không thể được cập nhật; phương pháp này không mở rộng quy mô cho các VPN quy mô lớn trong đời thực Trong IPsec, IKE được sử dụng để cung cấp một cơ chế
an toàn để thiết lập các kết nối được bảo vệ bằng IPsec Các phần sau mô tả năm loại trao đổi IKE (chế độ chính, chế độ tích cực, chế độ nhanh, thông tin và nhóm) và giải thích cách chúng hoạt động cùng nhau cho IPsec
Để triển khai IPsec trong Linux Kernel, ta sẽ bắt đầu với một sự trình bày ngắn về trình xử lý ngầm (daemon) nằm trên không gian người dùng (user space) là Internet Key Exchange (IKE) và mật mã trong IPsec Để thiết lập kết nối IPsec, ta cần phải thiết lập liên kết bảo mật (SA) với sự trợ giúp của các project ở không gian người dùng (userspace) Trong đó, địa chỉ nguồn và chỉ số tham số bảo mật (SPI) (được gọi là trình khởi tạo và trình phản hồi trong thuật ngữ IPsec) nên đồng ý về các tham số như một khóa (hoặc nhiều hơn một khóa), xác thực, mã hóa, tính toàn vẹn dữ liệu và các thuật toán trao đổi khóa
và các tham số khác như thời gian tồn tại của khóa (chỉ IKEv1) Trong nhân Linux, hầu hết API Crypto thực hiện các lệnh gọi đồng bộ Có các triển khai không đồng
bộ cho tất cả các loại thuật toán Rất nhiều bộ phần cứng tăng tốc sử dụng giao diện API mật mã (cryptography) không đồng bộ để giảm tải cho việc xử lý yêu cầu liên quan đến mã hóa Quá trình nhận gói IPsec được thể hiện bằng lưu đồ ở hình 3 Nhìn chung, khi lớp IP nhận được gói tin (message) Dựa theo trường giao thức của gói tin (message), nếu là loại IPsec (AH, ESP), nó sẽ được xử
lý với XFRM framework Đối với quá trình gửi gói IPsec, sau khi tra cứu định tuyến tin nhắn, SA sẽ được xem xét có đáp ứng yêu cầu hay không Nếu không thì được đưa ra IP Output; nếu có, nó sẽ đi vào quá trình XFRM và thực hiện xử lý tương ứng theo chế độ và giao thức
Trang 3Hình 3 Quá trình xử lý IPsec Outbound
Các gói tin từ lớp 4 (UDP,TCP) xuống lớp 3 là lớp
IP Khi bắt đầu ở lớp 3, các gói tin được chuển đến đích
bằng các tra bảng routing table, bước này gọi là IP
routing decision Sau đó đến phần IP source address
selection, đây là bước quan trọng bởi vì khi tạo một gói
tin IP, nó phải chọn địa chỉ IP nguồn để khi gửi đến bên
thu, bên phía thu mới biết được chính xác địa chỉ IP mà
cần phải phản hồi về Các bước tiếp theo sẽ xác định gói
đó có được mã hóa (ESP) hay xác thực (AH) không Nếu
có, gói tin sẽ chuyển đến phần mã hóa hoặc phần xác
thực gói tin Sau khi đã được mã hóa và xác thực, bước
tiếp theo sẽ kiểm tra sự thay đổi về header của gói tin
Do ESP có 2 chế độ là chế độ tunnel và chế độ transport
Chế độ tunnel sẽ mã hóa toàn bộ gói, bao gồm cả header
gốc và thay vào đó là một header mới Chế độ transport
chỉ mã hóa phần data, giữ lại header gốc Cuối cùng, gói
tin IP sẽ chuyển đến lớp dưới Tuy nhiên, nếu như ESP
ở chế độ tunnel, thì nó sẽ tiến hành mã hóa toàn bộ gói
ESP ròi quay lại lớp 3 (lớp IP)
III MÔHÌNHTRIỂNKHAIIPSEC
Hiện nay, có rất nhiều tùy chọn để nâng cao hiệu suất
trong việc triển khai IPsec, từ triển khai phần mềm thuần
túy bằng cách sử dụng tập lệnh CPU (Instruction Set)
dành riêng cho việc mã hóa cho đến sử dụng một phần
cứng chuyên biệt cho việc giảm tải thời gian xử lý gói
IPsec Thông thường, có 2 kiểu kiến trúc thiết kế là
Look-aside và Flow-through để giải quyết vấn đề trên
Kiến trúc Look-aside sẽ giúp ta giảm tải nhiều cho quá trình xử lý gói theo giao thức ESP Kiến trúc Look-aside cung cấp giải pháp để tăng tốc quá trình xử lý IPsec và tập trung chủ yếu ở giao thức ESP – được diễn ra trong quá trình trao đổi dữ liệu trong đường hầm IPsec (Phase 2) Trong khi đó, giải pháp Flow-through có thể hỗ trợ nhà sản xuất thiết bị gốc phát triển thiết bị VPN vì nhà thiết kế có thể tích hợp các thiết bị Flow-through trực tiếp vào đường dẫn chính (data path) do chúng hầu như không ảnh hưởng phần còn lại của hệ thống Điều này
có thể làm khối lượng thiết kế hệ thống cần thiết của các nhà phát triển OEM Các thiết bị Flow-through có thể giảm thêm rủi ro thiết kế bằng cách kết hợp giải pháp IPsec/IKE được chứng nhận của ICSA Labs, đảm bảo khả năng tương tác được kiểm tra và chứng nhận [4] Tuy nhiên việc xây dựng hệ thống IPsec theo kiến trúc Flow-through đòi hỏi độ phức tạp cao, chưa thật sự cần thiết cho mô hình tăng tốc này
Bộ tăng tốc IPsec có thể được sử dụng để hạn chế số chu kỳ CPU thực hiện việc xử lý IPsec-ESP Trong các tác vụ xử lý được đề cập ở trên, quá trình mã hóa và giải
mã sẽ là hai công việc tính toán nhiều nhất Thiết bị tăng tốc mã hóa có thể được sử dụng hiệu quả để giảm tải các tác vụ IPsec liên quan đến việc mã hóa/giải mã Các bộ tăng tốc này có thể là một phần của CPU, hay là một bộ
xử lý mật mã nằm trong SoC hay là một card PCIe được gắn thêm Do vậy, bộ tăng tốc theo kiểu Look-aside được mô tả như là một bộ tăng tốc mã hóa độc lập với CPU
Qua những đánh giá và phân tích về các giải pháp cho việc giảm tải các tác vụ liên quan đến IPsec được đề cập ở trên, nhóm đề xuất giải pháp thiết kế hệ thống với khối mã hóa theo trên card PCIe - FPGA để có thể tăng tốc IPsec VPN cũng như giảm tải các tác vụ liên quan đến IPsec Với hệ thống này, nó sẽ được thiết kế theo kiểu Look-aside và đảm nhận công việc yêu cầu tính toán nhiều nhất - mã hóa và giải mã Hệ thống mã hóa này sẽ đòi hỏi ít độ phức tạp hơn khi không đảm nhận các giai đoạn khác trong giao thức ESP (ví dụ như giai đoạn tra bảng SA) cũng như giai đoạn trao đổi khóa IKE (lúc thiết lập kết nối) Với những lợi ích và khả năng của
hệ thống này, nó sẽ phù hợp để tích hợp với các thiết bị nhúng cỡ nhỏ hay các nút mạng có năng lực xử lý không mạnh
IV THIẾTKẾDEVICEDRIVERGIAOTIẾP
THIẾTBỊCARDPCIE Peripheral Component Interconnect Express (sau đây viết tắt là PCIe), như tên gọi, là một chuẩn giao tiếp tốc độ cao dùng để giao tiếp giữa các phần tử trong hệ thống (giao tiếp giữa vi xử lý và ngoại vi hoặc giữa các ngoại vi) PCIe ra đời để đáp ứng nhu cầu về tốc độ khi tần số hoạt động ngày càng cao của vi xử lý cũng như các ngoại vi Điểm căn bản khác biệt để PCIe đạt được tốc độ cao hơn PCI là do PCI dùng kiểu giao tiếp song song còn PCIe dùng kiểu truyền nối tiếp
Trang 4Để hệ thống có thể nhận diện được thiết bị có chứa
card PCIe thì ta cần xây dựng Driver giao tiếp với yêu
cầu phải xây dựng lớp giao tiếp với card thông qua PCIe
và đảm bảo truyền nhận chính xác dữ liệu với thiết bị
card PCIe; xây dựng lớp giao tiếp với các ứng dụng cũng
như IPsec Stack trong Linux kernel để những ứng dụng
này có thể sử dụng được driver này; đảm bảo độ chính
xác của giải thuật mã hóa khi được sử dụng bởi IPsec
stack trong Linux Kernel với các ứng dụng trên lớp User
space; và đồng thời phải đạt tốc độ mã hóa và thông
lượng IPsec VPN cao (hơn 100 Mbps) Device Driver là
khối phần mềm chính mà khi triển khai một thiết bị mới
thì lập trình viên phải lập trình lại gần như hoàn toàn
Việc tách khối Driver và khối Bus Driver giúp các thiết
bị có chức năng khác nhau mà sử dụng chung một giao
thức bus để giao tiếp với hệ thống sử dụng toàn bộ các
hàm thực hiện chức năng giao tiếp qua bus
Hình 4 Tiến trình yêu cầu xử lý mã hóa
Khối Driver gồm hai phần là OS specific và phần
Device specific OS Specific giúp cung cấp cho hệ hành
các dịch vụ cơ bản của thiết bị (ví dụ như đọc, ghi vào
bộ nhớ của thiết bị) theo một chuẩn chung Điều này
giúp việc phát triển hệ điều hành một cách độc lập mà
không ảnh hưởng đến các driver cũ Trong khi đó, device
specific có chức năng điều khiển thiết bị thực hiện đúng
tính năng của nó Lấy driver cho card mạng làm ví dụ:
Phần OS specific của driver sẽ đảm bảo việc giao tiếp
mạng với các module khác của hệ thống theo đúng
chuẩn cũng như cung cấp các dịch vụ cho các hệ thống
khác trong nhân Linux Phần Device specific nhận các
yêu cầu từ phần OS specific và thực hiện cấu hình, kiểm
soát quá trình hoạt động của card mạng và trả về kết quả
cho lớp OS specific
Hình 5 Tiến trình xử lý kết quả mã hóa và gọi hàm callback
cho IPsec Với tiến trình (process) xử lý yêu cầu mã hóa, nó sẽ khởi tạo giá trị các trường trong struct private context của gói yêu cầu mã hóa; thực hiện kiểm tra các bộ đệm lưu trữ dữ liệu cần xử lý ( mã hóa hoặc giải mã) và kiểm tra các điều kiện entry của của scatter gather list; thêm gói yêu cầu mã hóa vào danh sách hàng đợi và tiến trình này sẽ lập lịch cho 1 work thực thi tiến trình “xử lý và gửi gói yêu cầu cho lớp device-specific” trong tương lai Cuối cùng, tiến trình sẽ kết thúc bằng cách trả về giá trị
“đang xử lý” cho API gọi nó và kết thúc tiến trình Việc
triển khai mã hóa trên bộ phần cứng tăng tốc thường sử dụng giao diện API mã hóa bất đồng bộ, đơn giản bởi vì các tác vụ xử lý mã hóa không thể bị blocking cho đến khi thực hiện xong Vì vậy, tiến trình này được thiết kế
sẽ kết thúc ngay sau khi thêm các gói yêu cầu vào danh sách hàng đợi
Với tiến trình thiết lập và gửi gói yêu cầu cho lớp device-specific, nó lấy gói yêu cầu mã hóa từ trong hàng đợi; thực hiện cấp phát và khởi tạo gói yêu cầu vận chuyển tương ứng với các gói yêu cầu mã hóa Những gói yêu cầu này có chứa các dữ liệu cần mã hóa phù hợp với định dạng dữ liệu trên FPGA và tiến hành gửi gói yêu cầu vận chuyển xuống lớp xử lý device-specific driver.
Sơ đồ hình 6 giải thích cách hoạt động của quá trình
di chuyển dữ liệu qua lại giữa card FPGA và Host dùng DMA qua PCIe Trong đó: “Tiến trình sử dụng” và
“Tiến trình phục vụ ngắt” là các tiến trình bình thường
và chạy ở bối cảnh tiến trình “Trình phục vụ ngắt MSI” chạy ở bối cảnh ngắt
Tiến trình gọi API để di chuyển dữ liệu dùng DMA
bị rơi vào trạng thái Sleep trong quá trình hoạt động Do
đó, không thể gọi hàm này trong ngữ cảnh ngắt hoặc Bottom Halves Hàm ngắt phục vụ cho user_irq được
Trang 5thực hiện trong bối cảnh ngắt, do đó, không được dùng
các hàm có thể gây Sleep Trình phục vụ ngắt để báo
việc hoàn tất một lượt di chuyển dữ liệu bằng DMA chỉ
lập lịch cho tiến trình phục vụ ngắt Việc đánh thức tiến
trình gọi API di chuyển dữ liệu bằng DMA được thực
hiện bởi tiến trình phục vụ ngắt ở bối cảnh tiến trình
Kiến trúc khối phần mềm sử dụng API di chuyển dữ
liệu dùng DMA được thể hiện trong hình 7 Gồm hai tiến
trình con và hai danh sách liên kết “Danh sách yêu cầu
mã hóa” là nơi lưu trữ các yêu cầu từ “Tiến trình yêu cầu
mã hóa” và sẽ được một tiến trình khác đảm nhiệm
nhiệm vụ di chuyển dữ liệu sang card FPGA, mã hóa, di
chuyển dữ liệu đã mã hóa trở lại bộ nhớ chính
Hình 6 Sơ đồ kiến trúc phần mềm driver XDMA của Xilinx
Việc tách công việc mã hóa sang một tiến trình khác
giúp tổng thể quá trình thực hiện không bị phụ thuộc vào
ngữ cảnh (context), làm việc lập trình trở nên đơn giản
hơn Tương tự, “danh sách gọi callback” là nơi lưu trữ
các yêu cầu thực hiện hàm callback Do thời gian thực
hiện hàm callback có thể thay đổi và có thể sẽ mất thời
gian, việc thực hiện nó được chuyển riêng sang một tiến
trình khác để tối ưu hóa việc sử dụng card FPGA để mã
hóa
Hình 7 Mô hình kiến trúc phần mềm
V KẾTQUẢTHỰCHIỆN Trong phần này, chúng tôi sẽ thực hiện các bài kiểm tra để khảo sát tốc độ truyền nhận dữ liệu theo gói trên thực tế
Trước hết, hệ thống router của chúng tôi được chế tạo như trong hình 8 dưới đây để thực nghiệm, và đo đạc các kết quả Marvell ARM Cortex A9 được lựa chọn làm CPU cho Router với tần số hoạt động cao nhất
là 1.6 GHz Đối với khối mã hóa, chúng tôi sử dụng core FPGA XC7A200TFBG484 – 2 thuộc dòng Artix 7 của Xilinx Vùng nhớ RAM Inbound (bộ nhớ lưu trữ data mã hóa) và vùng nhớ RAM Outbound (bộ nhớ lưu trữ data đã mã hóa) có dung lượng 16KB, trong khi dung lượng của một gói data gửi xuống để mã hóa dưới 2KB [10] Như vậy, hệ thống sẽ không bị tăng quá mức tài nguyên khi tăng tốc độ mã hóa
Hình 8 Hệ thống router của chúng tôi chế tạo để thử nghiệm Bài kiểm tra được thực hiện với hai mô hình driver
để so sánh sự ảnh hưởng của thiết kế khối phần mềm đến tốc độ truyền nhận trên cả hai mô hình Lược bỏ đi quá trình khởi động mã hóa và chờ ngắt để di chuyển dữ liệu lên trên RAM của Host, bài kiểm tra này thể hiện tốc độ truyền nhận theo gói mà hai kiểu thiết kế đã nêu có thể đạt được nếu bỏ qua sự cồng kềnh trong giao thức bắt tay giữa phần mềm và khối thực hiện chức năng mã hóa
Trang 6Chúng tôi sẽ tính toán tốc độ khi cấu hình PCIe từ 1
làn đến 4 làn khi áp dụng trên cả 2 CPU là core i5 7500
và SoC Mavell Cortex A9 Chúng tôi sẽ sử dụng module
test để mô phỏng quá trình yêu cầu xử lý theo giao thức
IPsec Trong bài kiểm tra này, ta sẽ sử dụng 3 gói yêu
cầu mã hóa với 3 dung lượng khác nhau, lần lượt là 320
bytes, 1120 bytes, 1500 bytes Cách đo của module test
được thể hiện cụ thể qua các bước sau:
▪ Module test khởi tạo timer với thời gian 10 giây
▪ Thực hiện gửi gói yêu cầu mã hóa liên tục xuống
card FPGA
▪ Sau mỗi lần kết quả mã hóa được gửi từ driver lên
đến hàm callback của module test, biến đếm số gói
mã hóa sẽ tăng lên 1
▪ Quá trình này sẽ kết thúc sau 10 giây và in ra màn
hình số gói mã hóa được Từ số gói mã hóa, ta có
thể tính được tốc độ mã hóa hay thông lượng mã
hóa như sau:
𝑇ℎô𝑛𝑔 𝑙ượ𝑛𝑔 = 𝑆ố 𝑔ó𝑖 𝑡𝑟𝑢𝑦ề𝑛 đượ𝑐 × 𝑠ố 𝑏𝑦𝑡𝑒 𝑚ỗ𝑖 𝑔ó𝑖 × 8
𝑇ℎờ𝑖 𝑔𝑖𝑎𝑛 𝑡𝑟𝑢𝑦ề𝑛
Hình 9 Tốc độ truyền nhận theo gói XDMA IP PCIe 2.0
trên PC
Hình 10 Tốc độ truyền nhận theo gói XDMA IP PCIe 2.0 x1
trên Router Hình 9 cho thấy kết quả khi ta dùng FPGA giao tiếp
với PC thông qua PCIe, ta tính được tốc độ tăng dần khi
dung lượng mỗi lần gửi tăng lên và tốc độ với PCIe 4 làn
(432 Mbps) cao hơn tốc độ 1 làn (260 Mbps) Điều này
là dễ hiểu vì khi tăng dung lượng mỗi lần truyền/gửi thì
sự ảnh hưởng do độ trễ của phần mềm trở nên ít hơn
Mặc dù khi tăng cấu hình PCIe từ 1 làn lên 4 làn, tốc độ
về mặt lý thuyết sẽ phải tăng lên gấp 4, tuy nhiên trên
thực tế sự chênh lệch không lớn như vậy chỉ khoảng 1.6
lần Từ đây có thể suy ra nguyên nhân làm giảm tốc độ
truyền gửi phần lớn là do sự ảnh hưởng của phần mềm
(phản ứng chậm)
Trong bài kiểm tra trên Router, do board Router
chúng tôi sử dụng với 3 làn PCIe dùng cho mô-đun Wifi
và SFP, do đó khi gắn card FPGA với 1 làn PCI thì tốc
độ được thấy trong hình 10, ta thấy tốc độ cũng tăng dần khi dung lượng gói tăng
Từ bài kiểm tra tốc độ truyền dữ liệu khi chưa có hoạt động mã hóa, ta suy ra được nút thắt cổ chai trong
cả quá trình hiện tại là khối driver mã hóa Nguyên nhân
là do driver hoạt động chưa hiệu quả, quá trình bắt tay vẫn còn rườm rà Kênh truyền chưa được sử dụng triệt
để Do có thêm vấn đề xử lý các vấn đề liên quan đến việc mã hóa, tốc độ truyền nhận giảm từ 800Mbps còn 302Mbps trên router và từ 7000Mbps xuống còn 430Mbps trên PC – 4 làn
VI KẾTLUẬN Trong bài báo này, chúng tôi đã xây dựng mô hình
để thực hiện giao thức IPsec VPN với khả năng tăng tốc
do thực hiện việc mã hóa trên nền tảng FPGA qua giao tiếp PCIe Đồng thời, thiết kế driver cho thiết bị để khôi
mã hóa/giải mã có thể giao tiếp trực tiếp được với hệ thống cũng được đề xuất chi tiết Xét về yếu tố tốc độ kênh truyền, kết quả của bài báo đã cho thấy các quá trình xử lý ngắt, khởi tạo sẽ làm giảm tốc độ trên thiết bị
PC và cả trên thiết bị Router (so với tốc độ truyền nhận tối đa) Chi phí xử lý trên driver gây ra tác động rất lớn đối với thực hiện truyền nhận dữ liệu Và do vậy, các nghiên cứu chuyên sâu hơn không thể bỏ qua phần thiết
kế driver giao tiếp giữa các khối trong cùng một hệ thống
LỜICẢMƠN Nghiên cứu này được tài trợ bởi Bộ Khoa học và Công nghệ trong khuôn khổ đề tài mã số
KC.01.24/16-20 Chúng tôi xin cảm ơn Trường Đại học Bách Khoa, ĐHQG-HCM đã hỗ trợ thời gian, phương tiện và cơ sở vật chất cho nghiên cứu này
TÀILIỆUTHAMKHẢO [1] Craig A Shue, Minaxi Gupta, "IPsec: Performance Analysis
and Enhancement," IEEE International Conference on Communications, 2007
[2] O Morrison, "IPsec: Protocol Challenges and Performance Analysis and Enhancements," 2014
[3] IETF, RFC 2401: Security Architecture for the Internet Protocol
[4] R Friend, "Making the gigabit IPsec VPN architecture secure,"
2004, p Computer
[5] Alberto Ferrante, Vincenzo Piuri, and Jeff Owen, "IPsec
Hardware Resource Requirements," IEEE Conference Paper,
2005
[6] E Barker, Q Dang, S Frankel, K Scarfone and P Wouters,
"Guide to IPsec VPNs," NIST Special Pubication, 2020
[7] IETF, "RFC 2409: , The Internet Key Exchange (IKE)" [8] IETF, "RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)"
[9] I Corp, "White paper: Intel IPsec Acceleration," 2019 [10] N M Garcia, Mário M F., Paulo P M., “The Ethernet Frame Payload Size and Its Effect on IPv4 and IPv6 Traffic”, 2008