Xem mẫu
- Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)
Thiế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 overheads) sẽ chiếm tỉ lệ lớn nhất trong tổng chi phí
thiết kế hệ thống và xây dựng driver giao tiếp giữa khối (overheads) [1]. Mặc dù giao thức ESP chỉ chiếm chi phí
trung tâm với khối mã hóa trên card PCIe – FPGA để có ít cho 1 gói nhưng khi xử lý một số lượng lớn các gói
tăng tốc IPsec VPN cũng như giảm tải các tác vụ liên quan trong cùng 1 kết nối thì chi phí cho việc xử lý ESP (ESP
đế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
overheads) có thể vượt trội so với chi phí cho IKE. Đối
thức Encapsulating Security (ESP) cũng như giai đoạn với một kết nối IPsec VPN có thời gian tồn tại đủ lâu,
trao đổi khóa Internet Key Exchange (IKE) ban đầu. Với việc thực hiện mã hóa đóng vai trò then chốt trong thời
những lợi ích và khả năng của hệ thống này, nó sẽ phù hợp gian xử lý gói ESP. Lựa chọn một thuật toán tối ưu cùng
để tích hợp với các thiết bị nhúng cỡ nhỏ hay các nút mạng việc sử dụng phần cứng tăng tốc cho việc mã hóa có thể
có năng lực xử lý không mạnh. 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
Từ khóa- Internet Protocol Security (IPsec), Peripheral IPsec và kiến trúc cũng như đưa ra những ứng dụng thực
Component Interconnect Express (PCIe), Driver giao tiếp
tế việc triển khai IPsec có thể tăng lên sự tiêu thụ tài
PCIe, OS Specific, Driver Specific.
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
I. GIỚI THIỆU thức mã hóa đã sử dụng. Hiện tại, các thuật toán thể hiện
Ngày nay, khi mà thời đại Internet phát triển rộng tốt nhất sự cân bằng giữa sự cung cấp bảo mật và hiệu
khắp, những dịch vụ như đào tạo từ xa, mua hàng trực năng là GCM-AES bởi vì nó cho phép việc triển khai
tuyến, tư vấn y tế trực tuyến đã trở nên khá phổ biến với trên phần cứng [2]. Với sự sẵn có của các sản phẩm
tất cả mọi người. Từ đó, người ta đã đưa ra mô hình mới thương mại hỗ trợ việc giảm tải IPsec, các giải pháp
nhằm thỏa mãn những yêu cầu trên mà vẫn tận dụng IPsec cung cấp sự đánh đổi giữa sự đơn giản của việc
được cơ sở hạ tầng mạng vốn có, đó chính là mạng riêng triển khai với sự phổ biến của việc thực thi bằng phần
ảo (Virtual Private Network-VPN). VPN cung cấp cơ mềm và tổng thể hiệu suất nền tảng có thể đạt với giải
chế mã hóa dữ liệu trên đường truyền tạo ra một đường pháp phần cứng. Các giải pháp dựa trên phần mềm là
ống (tunnel) bảo mật giữa nơi gửi và nơi nhận và IPsec được đề xuất như là một điểm bắt đầu mặc định. Khi chi
(Internet Protocol Security) chính là một trong những phí CPU cho việc xử lý lưu lượng IPsec là một vấn đề,
giao thức tạo nên cơ chế “đường ống bảo mật” cho VPN. hướng giải quyết bằng cách giảm tải phần cứng nên
IPsec là một bộ giao thức bổ sung bảo mật đối với thông được cân nhắc. Dựa trên những đánh giá của các nghiên
tin trao đổi ở lớp IP trong mô hình mạng TCP/IP. Đối cứu trong các bài báo và sách đã đề cập ở trên, ta đi đến
với một nút mạng điển hình, việc triển khai thực thi giao những đánh giá chung cho việc cải thiện tốc độ IPsec
thức IPsec được mặc định sử dụng phần mềm đơn thuần VPN nói chung cũng như hiệu năng của việc thực thi bộ
và ít nhiều đã gây ra giảm thông lượng mạng đi qua nút giao thức IPsec nói triêng. Ta thấy rằng việc thực thi xử
cũng như làm quá tải CPU của thiết bị đó. Khi tốc độ lý gói theo giao thức IPsec có thể làm tăng lên sự tiêu
mạng tăng lên, việc giảm thiểu chi phí xử lý (processing thụ tài nguyên của CPU một cách đáng kể và sự tiêu thụ
overheads) gói IPsec là yêu cầu tất yếu trong nhiều hệ tài nguyên CPU này phụ thuộc vào lưu lượng IPsec. Và
thống đặc biệt là những gateway, những thiết bị nhúng khi đó giải pháp dựa trên phần cứng tăng tốc mã hóa sẽ
cỡ nhỏ nhưng đồng thời cũng đặt ra nhiều thách thức cần đóng vai trò quan trọng trong việc đạt đến hiệu năng cao
phải đối mặt. ở trong hệ thống lớn cũng như là một cách tiếp cận hữu
Khi xây dựng hệ thống IPsec VPN có nhiều vấn đề ích trong việc làm giảm mức sử dụng CPU ở hệ thống
gặp phải. Khi kết nối VPN tồn tại trong một khoảng thời nhỏ và chậm.
gian ngắn, chi phí cho quá trình trao đổi khóa IKE (IKE
ISBN: 978-604-80-5076-4 202
- Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)
Trong 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 Tổng quan về kết nối IPsec VPN được thể hiện bởi
sẽ thực hiện trên nền tảng FPGA. Và để nâng cao hơn hình 2:
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 Hình 2. Tổng quan về kết nối IPsec
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. Mục đích của giao thức trao đổi khóa (IKE) là
Phần xây dựng bộ mã hóa và giải mã trên phần cứng sẽ thương lượng, tạo và quản lý các liên kết bảo mật (SA)
không được đề cập đến trong bài báo này. [7]. Liên kết bảo mật (SA) là một thuật ngữ chung cho
Phần còn lại của bài báo được tổ chức như sau: một tập hợp các giá trị xác định các tính năng và bảo vệ
Chúng tôi sẽ trình bày phương thức thực hiện của giao IPsec được áp dụng cho một kết nối. Các SA cũng có thể
thức IPsec VPN trong Phần II. Phần III sẽ đưa ra mô được tạo theo cách thủ công, sử dụng các giá trị được
hình để nâng cao hiệu suất trong việc triển khai IPsec thỏa thuận trước bởi cả hai bên, nhưng các SA này
VPN. Chúng tôi sẽ tiến hành thiết kế phần Device Driver không thể được cập nhật; phương pháp này không mở
cho mô hình đã được nêu bên trên trong phần IV. Phần rộng quy mô cho các VPN quy mô lớn trong đời thực
V sẽ cung cấp các kết quả của bài kiểm tra hệ thống để Trong IPsec, IKE được sử dụng để cung cấp một cơ chế
từ đó đưa ra các nhận xét về hiệu suất của mô hình đã đề an toàn để thiết lập các kết nối được bảo vệ bằng IPsec.
cập. Cuối cùng, chúng tôi kết luận bài báo trong phần Các phần sau mô tả năm loại trao đổi IKE (chế độ chính,
VI. 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.
II. GIAO THỨC BẢO MẬT INTERNET Để 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)
Giao thức bảo mật Internet, hay còn gọi là IPsec, là
nằm trên không gian người dùng (user space) là Internet
một tập hợp các giao thức hỗ trợ bảo vệ thông tin liên
Key Exchange (IKE) và mật mã trong IPsec. Để thiết lập
lạc qua mạng IP [3]. Các giao thức IPsec làm việc cùng
kết nối IPsec, ta cần phải thiết lập liên kết bảo mật (SA)
nhau theo nhiều cách kết hợp khác nhau để bảo vệ thông
với sự trợ giúp của các project ở không gian người dùng
tin liên lạc. IPsec là giao thức nằm ở lớp 3 – lớp Network
(userspace). Trong đó, địa chỉ nguồn và chỉ số tham số
trong mô hình OSI hay TCP/IP. Hai giao thức cốt lõi
bảo mật (SPI) (được gọi là trình khởi tạo và trình phản
trong IPsec, được thể hiện trong hình 1, là
hồi trong thuật ngữ IPsec) nên đồng ý về các tham số
Authentication Header (AH) và Encapsulating Security
như một khóa (hoặc nhiều hơn một khóa), xác thực, mã
Payload (ESP). Điều cần lưu ý để IPsec có thể hoạt động
hóa, tính toàn vẹn dữ liệu và các thuật toán trao đổi khóa
là mô hình phải có hỗ trợ trao đổi khóa (IKE) để giúp
và các tham số khác như thời gian tồn tại của khóa (chỉ
hai điểm trên mạng có thể trao đổi thông tin một cách
IKEv1). Trong nhân Linux, hầu hết API Crypto thực
bảo mật. IKE giúp máy tính có thể trao đổi khóa để mã
hiện các lệnh gọi đồng bộ. Có các triển khai không đồng
hóa, phương thức mã hóa được dùng cho IPsec qua môi
bộ cho tất cả các loại thuật toán. Rất nhiều bộ phần cứng
trường mạng không tin cậy mà vẫn giữ được tính bảo
tăng tốc sử dụng giao diện API mật mã (cryptography)
mật và điểm kết nối IPsec phải có hỗ trợ các bộ mã hóa,
không đồng bộ để giảm tải cho việc xử lý yêu cầu liên
hàm băm để hoạt động.
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
Hình 1. Giao thức cốt lõi của IPsec XFRM và thực hiện xử lý tương ứng theo chế độ và giao
thức.
ISBN: 978-604-80-5076-4 203
- Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)
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
Hình 3. Quá trình xử lý IPsec Outbound CPU.
Các gói tin từ lớp 4 (UDP,TCP) xuống lớp 3 là lớp Qua những đánh giá và phân tích về các giải pháp
IP. Khi bắt đầu ở lớp 3, các gói tin được chuển đến đích cho việc giảm tải các tác vụ liên quan đến IPsec được đề
bằng các tra bảng routing table, bước này gọi là IP cập ở trên, nhóm đề xuất giải pháp thiết kế hệ thống với
routing decision. Sau đó đến phần IP source address khối mã hóa theo trên card PCIe - FPGA để có thể tăng
selection, đây là bước quan trọng bởi vì khi tạo một gói tốc IPsec VPN cũng như giảm tải các tác vụ liên quan
tin IP, nó phải chọn địa chỉ IP nguồn để khi gửi đến bên đến IPsec. Với hệ thống này, nó sẽ được thiết kế theo
thu, bên phía thu mới biết được chính xác địa chỉ IP mà kiểu Look-aside và đảm nhận công việc yêu cầu tính
cần phải phản hồi về. Các bước tiếp theo sẽ xác định gói toán nhiều nhất - mã hóa và giải mã. Hệ thống mã hóa
đó có được mã hóa (ESP) hay xác thực (AH) không. Nếu này sẽ đòi hỏi ít độ phức tạp hơn khi không đảm nhận
có, gói tin sẽ chuyển đến phần mã hóa hoặc phần xác các giai đoạn khác trong giao thức ESP (ví dụ như giai
thực gói tin. Sau khi đã được mã hóa và xác thực, bước đoạn tra bảng SA) cũng như giai đoạn trao đổi khóa IKE
tiếp theo sẽ kiểm tra sự thay đổi về header của gói tin. (lúc thiết lập kết nối). Với những lợi ích và khả năng của
Do ESP có 2 chế độ là chế độ tunnel và chế độ transport. hệ thống này, nó sẽ phù hợp để tích hợp với các thiết bị
Chế độ tunnel sẽ mã hóa toàn bộ gói, bao gồm cả header nhúng cỡ nhỏ hay các nút mạng có năng lực xử lý không
gốc và thay vào đó là một header mới. Chế độ transport mạnh.
chỉ mã hóa phần data, giữ lại header gốc. Cuối cùng, gói IV. THIẾT KẾ DEVICE DRIVER GIAO TIẾP
tin IP sẽ chuyển đến lớp dưới. Tuy nhiên, nếu như ESP THIẾT BỊ CARD PCIE
ở 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). 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
III. MÔ HÌNH TRIỂN KHAI IPSEC tốc độ cao dùng để giao tiếp giữa các phần tử trong hệ
Hiện nay, có rất nhiều tùy chọn để nâng cao hiệu suất thống (giao tiếp giữa vi xử lý và ngoại vi hoặc giữa các
trong việc triển khai IPsec, từ triển khai phần mềm thuần ngoại vi). PCIe ra đời để đáp ứng nhu cầu về tốc độ khi
túy bằng cách sử dụng tập lệnh CPU (Instruction Set) tần số hoạt động ngày càng cao của vi xử lý cũng như
dành riêng cho việc mã hóa cho đến sử dụng một phần các ngoại vi. Điểm căn bản khác biệt để PCIe đạt được
cứng chuyên biệt cho việc giảm tải thời gian xử lý gói tốc độ cao hơn PCI là do PCI dùng kiểu giao tiếp song
IPsec. Thông thường, có 2 kiểu kiến trúc thiết kế là song còn PCIe dùng kiểu truyền nối tiếp.
Look-aside và Flow-through để giải quyết vấn đề trên.
ISBN: 978-604-80-5076-4 204
- Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)
Để 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 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
Hình 4. Tiến trình yêu cầu xử lý mã hóa 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
Khối Driver gồm hai phần là OS specific và phần chuyển tương ứng với các gói yêu cầu mã hóa. Những
Device specific. OS Specific giúp cung cấp cho hệ hành gói yêu cầu này có chứa các dữ liệu cần mã hóa phù hợp
các dịch vụ cơ bản của thiết bị (ví dụ như đọc, ghi vào với định dạng dữ liệu trên FPGA và tiến hành gửi gói
bộ nhớ của thiết bị) theo một chuẩn chung. Điều này yêu cầu vận chuyển xuống lớp xử lý device-specific
giúp việc phát triển hệ điều hành một cách độc lập mà driver.
không ảnh hưởng đến các driver cũ. Trong khi đó, device Sơ đồ hình 6 giải thích cách hoạt động của quá trình
specific có chức năng điều khiển thiết bị thực hiện đúng di chuyển dữ liệu qua lại giữa card FPGA và Host dùng
tính năng của nó. Lấy driver cho card mạng làm ví dụ: DMA qua PCIe. Trong đó: “Tiến trình sử dụng” và
Phần OS specific của driver sẽ đảm bảo việc giao tiếp “Tiến trình phục vụ ngắt” là các tiến trình bình thường
mạng với các module khác của hệ thống theo đúng và chạy ở bối cảnh tiến trình. “Trình phục vụ ngắt MSI”
chuẩn cũng như cung cấp các dịch vụ cho các hệ thống chạy ở bối cảnh ngắt.
khác trong nhân Linux. Phần Device specific nhận các Tiến trình gọi API để di chuyển dữ liệu dùng DMA
yêu cầu từ phần OS specific và thực hiện cấu hình, kiểm bị rơi vào trạng thái Sleep trong quá trình hoạt động. Do
soát quá trình hoạt động của card mạng và trả về kết quả đó, không thể gọi hàm này trong ngữ cảnh ngắt hoặc
cho lớp OS specific. Bottom Halves. Hàm ngắt phục vụ cho user_irq được
ISBN: 978-604-80-5076-4 205
- Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)
thự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 7. Mô hình kiến trúc phần mềm
V. KẾT QUẢ THỰC HIỆ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 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 Hình 8. Hệ thống router của chúng tôi chế tạo để thử nghiệm
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ữ Bài kiểm tra được thực hiện với hai mô hình driver
các yêu cầu thực hiện hàm callback. Do thời gian thực để so sánh sự ảnh hưởng của thiết kế khối phần mềm đến
hiện hàm callback có thể thay đổi và có thể sẽ mất thời tốc độ truyền nhận trên cả hai mô hình. Lược bỏ đi quá
gian, việc thực hiện nó được chuyển riêng sang một tiến trình khởi động mã hóa và chờ ngắt để di chuyển dữ liệu
trình khác để tối ưu hóa việc sử dụng card FPGA để mã lên trên RAM của Host, bài kiểm tra này thể hiện tốc độ
hóa. 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.
ISBN: 978-604-80-5076-4 206
- Hội nghị Quốc gia lần thứ 23 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2020)
Chúng tôi sẽ tính toán tốc độ khi cấu hình PCIe từ 1 và SFP, do đó khi gắn card FPGA với 1 làn PCI thì tốc
làn đến 4 làn khi áp dụng trên cả 2 CPU là core i5 7500 độ được thấy trong hình 10, ta thấy tốc độ cũng tăng dần
và SoC Mavell Cortex A9. Chúng tôi sẽ sử dụng module khi dung lượng gói tăng.
test để mô phỏng quá trình yêu cầu xử lý theo giao thức Từ bài kiểm tra tốc độ truyền dữ liệu khi chưa có
IPsec. Trong bài kiểm tra này, ta sẽ sử dụng 3 gói yêu hoạt động mã hóa, ta suy ra được nút thắt cổ chai trong
cầu mã hóa với 3 dung lượng khác nhau, lần lượt là 320 cả quá trình hiện tại là khối driver mã hóa. Nguyên nhân
bytes, 1120 bytes, 1500 bytes. Cách đo của module test là do driver hoạt động chưa hiệu quả, quá trình bắt tay
được thể hiện cụ thể qua các bước sau: vẫn còn rườm rà. Kênh truyền chưa được sử dụng triệt
▪ Module test khởi tạo timer với thời gian 10 giây để. Do có thêm vấn đề xử lý các vấn đề liên quan đến
▪ Thực hiện gửi gói yêu cầu mã hóa liên tục xuống việc mã hóa, tốc độ truyền nhận giảm từ 800Mbps còn
card FPGA 302Mbps trên router và từ 7000Mbps xuống còn
▪ Sau mỗi lần kết quả mã hóa được gửi từ driver lên 430Mbps trên PC – 4 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. VI. KẾT LUẬN
▪ Quá trình này sẽ kết thúc sau 10 giây và in ra màn Trong bài báo này, chúng tôi đã xây dựng mô hình
hình số gói mã hóa được. Từ số gói mã hóa, ta có để thực hiện giao thức IPsec VPN với khả năng tăng tốc
thể tính được tốc độ mã hóa hay thông lượng mã do thực hiện việc mã hóa trên nền tảng FPGA qua giao
hóa như sau: tiếp PCIe. Đồng thời, thiết kế driver cho thiết bị để khôi
𝑇ℎô𝑛𝑔 𝑙ượ𝑛𝑔 =
𝑆ố 𝑔ó𝑖 𝑡𝑟𝑢𝑦ề𝑛 đượ𝑐 × 𝑠ố 𝑏𝑦𝑡𝑒 𝑚ỗ𝑖 𝑔ó𝑖 × 8 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ỜI CẢM ƠN
Hình 9. Tốc độ truyền nhận theo gói XDMA IP PCIe 2.0 Nghiên cứu này được tài trợ bởi Bộ Khoa học và
trên PC 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ÀI LIỆU THAM KHẢO
[1] Craig A. Shue, Minaxi Gupta, "IPsec: Performance Analysis
and Enhancement," IEEE International Conference on
Communications, 2007.
Hình 10. Tốc độ truyền nhận theo gói XDMA IP PCIe 2.0 x1 [2] O. Morrison, "IPsec: Protocol Challenges and Performance
trên Router Analysis and Enhancements," 2014.
[3] IETF, RFC 2401: Security Architecture for the Internet
Hình 9 cho thấy kết quả khi ta dùng FPGA giao tiếp Protocol.
với PC thông qua PCIe, ta tính được tốc độ tăng dần khi [4] R. Friend, "Making the gigabit IPsec VPN architecture secure,"
2004, p. Computer.
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 [5] Alberto Ferrante, Vincenzo Piuri, and Jeff Owen, "IPsec
Hardware Resource Requirements," IEEE Conference Paper,
là dễ hiểu vì khi tăng dung lượng mỗi lần truyền/gửi thì 2005.
sự ảnh hưởng do độ trễ của phần mềm trở nên ít hơn. E. Barker, Q. Dang, S. Frankel, K. Scarfone and P. Wouters,
[6]
Mặc dù khi tăng cấu hình PCIe từ 1 làn lên 4 làn, tốc độ "Guide to IPsec VPNs," NIST Special Pubication, 2020.
về mặt lý thuyết sẽ phải tăng lên gấp 4, tuy nhiên trên [7] IETF, "RFC 2409: , The Internet Key Exchange (IKE)".
thực tế sự chênh lệch không lớn như vậy chỉ khoảng 1.6
[8] IETF, "RFC 4106: The Use of Galois/Counter Mode (GCM) in
lần. Từ đây có thể suy ra nguyên nhân làm giảm tốc độ IPsec Encapsulating Security Payload (ESP)".
truyền gửi phần lớn là do sự ảnh hưởng của phần mềm
[9] I. Corp, "White paper: Intel IPsec Acceleration," 2019.
(phản ứng chậm).
Trong bài kiểm tra trên Router, do board Router [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.
chúng tôi sử dụng với 3 làn PCIe dùng cho mô-đun Wifi
ISBN: 978-604-80-5076-4 207
nguon tai.lieu . vn