Thus, traffic received on an Unprotected or Protected port is consider
Inbound or Outbound respectively.
-The application also supports complete IPSec protocol offload to hardware
-(Look aside crypto accelarator or using ethernet device). It also support
+The application also supports complete IPsec protocol offload to hardware
+(Look aside crypto accelerator or using ethernet device). It also support
inline ipsec processing by the supported ethernet device during transmission.
These modes can be selected during the SA creation configuration.
* No IPv6 options headers.
* No AH mode.
-* Supported algorithms: AES-CBC, AES-CTR, AES-GCM, HMAC-SHA1 and NULL.
+* Supported algorithms: AES-CBC, AES-CTR, AES-GCM, 3DES-CBC, HMAC-SHA1 and NULL.
* Each SA must be handle by a unique lcore (*1 RX queue per port*).
* No chained mbufs.
To compile the sample application see :doc:`compiling`.
-The application is located in the ``rpsec-secgw`` sub-directory.
+The application is located in the ``ipsec-secgw`` sub-directory.
#. [Optional] Build the application for debugging:
This option adds some extra flags, disables compiler optimizations and
./build/ipsec-secgw [EAL options] --
-p PORTMASK -P -u PORTMASK -j FRAMESIZE
+ -l -w REPLAY_WINOW_SIZE -e -a
--config (port,queue,lcore)[,(port,queue,lcore]
--single-sa SAIDX
+ --rxoffload MASK
+ --txoffload MASK
-f CONFIG_FILE_PATH
Where:
specified as FRAMESIZE. If an invalid value is provided as FRAMESIZE
then the default value 9000 is used.
+* ``-l``: enables code-path that uses librte_ipsec.
+
+* ``-w REPLAY_WINOW_SIZE``: specifies the IPsec sequence number replay window
+ size for each Security Association (available only with librte_ipsec
+ code path).
+
+* ``-e``: enables Security Association extended sequence number processing
+ (available only with librte_ipsec code path).
+
+* ``-a``: enables Security Association sequence number atomic behavior
+ (available only with librte_ipsec code path).
+
* ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which queues
from which ports are mapped to which cores.
on both Inbound and Outbound. This option is meant for debugging/performance
purposes.
+* ``--rxoffload MASK``: RX HW offload capabilities to enable/use on this port
+ (bitmask of DEV_RX_OFFLOAD_* values). It is an optional parameter and
+ allows user to disable some of the RX HW offload capabilities.
+ By default all HW RX offloads are enabled.
+
+* ``--txoffload MASK``: TX HW offload capabilities to enable/use on this port
+ (bitmask of DEV_TX_OFFLOAD_* values). It is an optional parameter and
+ allows user to disable some of the TX HW offload capabilities.
+ By default all HW TX offloads are enabled.
+
* ``-f CONFIG_FILE_PATH``: the full path of text-based file containing all
configuration items for running the application (See Configuration file
syntax section below). ``-f CONFIG_FILE_PATH`` **must** be specified.
--------------
The following sections provide the syntax of configurations to initialize
-your SP, SA and Routing tables.
+your SP, SA, Routing and Neighbour tables.
Configurations shall be specified in the configuration file to be passed to
the application. The file is then parsed by the application. The successful
parsing will result in the appropriate rules being applied to the tables
Configuration File Syntax
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~
As mention in the overview, the Security Policies are ACL rules.
The application parsers the rules specified in the configuration file and
The parse treats one line in the configuration file as one configuration
item (unless the line concatenation symbol exists). Every configuration
-item shall follow the syntax of either SP, SA, or Routing rules specified
-below.
+item shall follow the syntax of either SP, SA, Routing or Neighbour
+rules specified below.
The configuration parser supports the following special symbols:
* *aes-128-cbc*: AES-CBC 128-bit algorithm
* *aes-256-cbc*: AES-CBC 256-bit algorithm
* *aes-128-ctr*: AES-CTR 128-bit algorithm
+ * *3des-cbc*: 3DES-CBC 192-bit algorithm
* Syntax: *cipher_algo <your algorithm>*
mode ipv4-tunnel src 172.16.1.5 dst 172.16.2.5 \
type lookaside-protocol-offload port_id 4
+ sa in 35 aead_algo aes-128-gcm \
+ aead_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+ mode ipv4-tunnel src 172.16.2.5 dst 172.16.1.5 \
+ type inline-crypto-offload port_id 0
+
Routing rule syntax
^^^^^^^^^^^^^^^^^^^
rt ipv4 dst 172.16.1.5/32 port 0
rt ipv6 dst 1111:1111:1111:1111:1111:1111:1111:5555/116 port 0
+
+Neighbour rule syntax
+^^^^^^^^^^^^^^^^^^^^^
+
+The Neighbour rule syntax is shown as follows:
+
+.. code-block:: console
+
+ neigh <port> <dst_mac>
+
+
+where each options means:
+
+``<port>``
+
+ * The output port id
+
+ * Optional: No
+
+ * Syntax: *port X*
+
+``<dst_mac>``
+
+ * The destination ethernet address to use for that port
+
+ * Optional: No
+
+ * Syntax:
+
+ * XX:XX:XX:XX:XX:XX
+
+Example Neighbour rules:
+
+.. code-block:: console
+
+ neigh port 0 DE:AD:BE:EF:01:02
+
+Test directory
+--------------
+
+The test directory contains scripts for testing the various encryption
+algorithms.
+
+The purpose of the scripts is to automate ipsec-secgw testing
+using another system running linux as a DUT.
+
+The user must setup the following environment variables:
+
+* ``SGW_PATH``: path to the ipsec-secgw binary to test.
+
+* ``REMOTE_HOST``: IP address/hostname of the DUT.
+
+* ``REMOTE_IFACE``: interface name for the test-port on the DUT.
+
+* ``ETH_DEV``: ethernet device to be used on the SUT by DPDK ('-w <pci-id>')
+
+Also the user can optionally setup:
+
+* ``SGW_LCORE``: lcore to run ipsec-secgw on (default value is 0)
+
+* ``CRYPTO_DEV``: crypto device to be used ('-w <pci-id>'). If none specified
+ appropriate vdevs will be created by the script
+
+Note that most of the tests require the appropriate crypto PMD/device to be
+available.
+
+Server configuration
+~~~~~~~~~~~~~~~~~~~~
+
+Two servers are required for the tests, SUT and DUT.
+
+Make sure the user from the SUT can ssh to the DUT without entering the password.
+To enable this feature keys must be setup on the DUT.
+
+``ssh-keygen`` will make a private & public key pair on the SUT.
+
+``ssh-copy-id`` <user name>@<target host name> on the SUT will copy the public
+key to the DUT. It will ask for credentials so that it can upload the public key.
+
+The SUT and DUT are connected through at least 2 NIC ports.
+
+One NIC port is expected to be managed by linux on both machines and will be
+used as a control path.
+
+The second NIC port (test-port) should be bound to DPDK on the SUT, and should
+be managed by linux on the DUT.
+
+The script starts ``ipsec-secgw`` with 2 NIC devices: ``test-port`` and
+``tap vdev``.
+
+It then configures the local tap interface and the remote interface and IPsec
+policies in the following way:
+
+Traffic going over the test-port in both directions has to be protected by IPsec.
+
+Traffic going over the TAP port in both directions does not have to be protected.
+
+i.e:
+
+DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT OS
+
+SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS
+
+It then tries to perform some data transfer using the scheme described above.
+
+usage
+~~~~~
+
+In the ipsec-secgw/test directory
+
+to run one test for IPv4 or IPv6
+
+/bin/bash linux_test(4|6).sh <ipsec_mode>
+
+to run all tests for IPv4 or IPv6
+
+/bin/bash run_test.sh -4|-6
+
+For the list of available modes please refer to run_test.sh.
projects / ceph.git / blobdiff