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

Nội dung text: 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

1. 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 overheads) có thể vượt trội so với chi phí cho IKE. Đối 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 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
2. 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
3. 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
4. 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
5. 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
6. 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," dung lượng mỗi lần gửi tăng lên và tốc độ với PCIe 4 làn 2004, p. Computer. (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. [6] E. Barker, Q. Dang, S. Frankel, K. Scarfone and P. Wouters, 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