.. SPDX-License-Identifier: BSD-3-Clause
- Copyright 2017 NXP
+ Copyright 2017,2020 NXP
of security protocol operations offloaded to hardware based devices. The
library defines generic APIs to create and free security sessions which can
support full protocol offload as well as inline crypto operation with
-NIC or crypto devices. The framework currently only supports the IPSec protocol
-and associated operations, other protocols will be added in future.
+NIC or crypto devices. The framework currently only supports the IPsec, PDCP
+and DOCSIS protocols and associated operations, other protocols will be added
+in the future.
Design Principles
-----------------
~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
-The crypto processing for security protocol (e.g. IPSec) is processed
+The crypto processing for security protocol (e.g. IPsec) is processed
inline during receive and transmission on NIC port. The flow based
security action should be configured on the port.
crypto status is set in Rx descriptors. After the successful inline
crypto processing the packet is presented to host as a regular Rx packet
however all security protocol related headers are still attached to the
-packet. e.g. In case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. In case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will remain in the packet but the received packet
contains the decrypted data where the encrypted data was when the packet
-arrived. The driver Rx path check the descriptors and and based on the
+arrived. The driver Rx path check the descriptors and based on the
crypto status sets additional flags in the rte_mbuf.ol_flags field.
.. note::
relevant security protocol headers. Only the data will not be
encrypted by the software. The driver will accordingly configure the
tx descriptors. The hardware device will encrypt the data before sending the
-the packet out.
+packet out.
.. note::
~~~~~~~~~~~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-The crypto and protocol processing for security protocol (e.g. IPSec)
+The crypto and protocol processing for security protocol (e.g. IPsec)
is processed inline during receive and transmission. The flow based
security action should be configured on the port.
crypto status is set in the Rx descriptors. After the successful inline
crypto processing the packet is presented to the host as a regular Rx packet
but all security protocol related headers are optionally removed from the
-packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. in the case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will be removed from the packet and the received packet
will contains the decrypted packet only. The driver Rx path checks the
descriptors and based on the crypto status sets additional flags in
``rte_mbuf.ol_flags`` field. The driver would also set device-specific
-metadata in ``rte_mbuf.udata64`` field. This will allow the application
-to identify the security processing done on the packet.
+metadata in ``RTE_SECURITY_DYNFIELD_NAME`` field.
+This will allow the application to identify the security processing
+done on the packet.
.. note::
The underlying device in this case is stateful. It is expected that
the device shall support crypto processing for all kind of packets matching
to a given flow, this includes fragmented packets (post reassembly).
- E.g. in case of IPSec the device may internally manage anti-replay etc.
+ E.g. in case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in the descriptor.
.. note::
The underlying device will manage state information required for egress
- processing. E.g. in case of IPSec, the seq number will be added to the
+ processing. E.g. in case of IPsec, the seq number will be added to the
packet, however the device shall provide indication when the sequence number
is about to overflow. The underlying device may support post encryption TSO.
Decryption: The packet is sent to the crypto device for security
protocol processing. The device will decrypt the packet and it will also
optionally remove additional security headers from the packet.
-E.g. in case of IPSec, IPSec tunnel headers (if any), ESP/AH headers
+E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers
will be removed from the packet and the decrypted packet may contain
plain data only.
.. note::
- In case of IPSec the device may internally manage anti-replay etc.
+ In case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in descriptor.
.. note::
- In the case of IPSec, the seq number will be added to the packet,
+ In the case of IPsec, the seq number will be added to the packet,
It shall provide an indication when the sequence number is about to
overflow.
+--------|--------+
V
+PDCP Flow Diagram
+~~~~~~~~~~~~~~~~~
+
+Based on 3GPP TS 36.323 Evolved Universal Terrestrial Radio Access (E-UTRA);
+Packet Data Convergence Protocol (PDCP) specification
+
+.. code-block:: c
+
+ Transmitting PDCP Entity Receiving PDCP Entity
+ | ^
+ | +-----------|-----------+
+ V | In order delivery and |
+ +---------|----------+ | Duplicate detection |
+ | Sequence Numbering | | (Data Plane only) |
+ +---------|----------+ +-----------|-----------+
+ | |
+ +---------|----------+ +-----------|----------+
+ | Header Compression*| | Header Decompression*|
+ | (Data-Plane only) | | (Data Plane only) |
+ +---------|----------+ +-----------|----------+
+ | |
+ +---------|-----------+ +-----------|----------+
+ | Integrity Protection| |Integrity Verification|
+ | (Control Plane only)| | (Control Plane only) |
+ +---------|-----------+ +-----------|----------+
+ +---------|-----------+ +----------|----------+
+ | Ciphering | | Deciphering |
+ +---------|-----------+ +----------|----------+
+ +---------|-----------+ +----------|----------+
+ | Add PDCP header | | Remove PDCP Header |
+ +---------|-----------+ +----------|----------+
+ | |
+ +----------------->>----------------+
+
+
+.. note::
+
+ * Header Compression and decompression are not supported currently.
+
+Just like IPsec, in case of PDCP also header addition/deletion, cipher/
+de-cipher, integrity protection/verification is done based on the action
+type chosen.
+
+DOCSIS Protocol
+~~~~~~~~~~~~~~~
+
+The Data Over Cable Service Interface Specification (DOCSIS) support comprises
+the combination of encryption/decryption and CRC generation/verification, for
+use in a DOCSIS-MAC pipeline.
+
+.. code-block:: c
+
+
+ Downlink Uplink
+ -------- ------
+
+ Ethernet frame Ethernet frame
+ from core network to core network
+ | ^
+ ~ |
+ | ~ ----+
+ V | |
+ +---------|----------+ +----------|---------+ |
+ | CRC generation | | CRC verification | |
+ +---------|----------+ +----------|---------+ | combined
+ | | > Crypto + CRC
+ +---------|----------+ +----------|---------+ |
+ | Encryption | | Decryption | |
+ +---------|----------+ +----------|---------+ |
+ | ^ |
+ ~ | ----+
+ | ~
+ V |
+ DOCSIS frame DOCSIS frame
+ to Cable Modem from Cable Modem
+
+The encryption/decryption is a combination of CBC and CFB modes using either AES
+or DES algorithms as specified in the DOCSIS Security Specification (from DPDK
+lib_rtecryptodev perspective, these are RTE_CRYPTO_CIPHER_AES_DOCSISBPI and
+RTE_CRYPTO_CIPHER_DES_DOCSISBPI).
+
+The CRC is Ethernet CRC-32 as specified in Ethernet/[ISO/IEC 8802-3].
+
+.. note::
+
+ * The offset and length of data for which CRC needs to be computed are
+ specified via the auth offset and length fields of the rte_crypto_sym_op.
+ * Other DOCSIS protocol functionality such as Header Checksum (HCS)
+ calculation may be added in the future.
+
Device Features and Capabilities
---------------------------------
Each driver (crypto or ethernet) defines its own private array of capabilities
for the operations it supports. Below is an example of the capabilities for a
-PMD which supports the IPSec protocol.
+PMD which supports the IPsec and PDCP protocol.
.. code-block:: c
},
.crypto_capabilities = pmd_capabilities
},
+ { /* PDCP Lookaside Protocol offload Data Plane */
+ .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
+ .protocol = RTE_SECURITY_PROTOCOL_PDCP,
+ .pdcp = {
+ .domain = RTE_SECURITY_PDCP_MODE_DATA,
+ .capa_flags = 0
+ },
+ .crypto_capabilities = pmd_capabilities
+ },
+ { /* PDCP Lookaside Protocol offload Control */
+ .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
+ .protocol = RTE_SECURITY_PROTOCOL_PDCP,
+ .pdcp = {
+ .domain = RTE_SECURITY_PDCP_MODE_CONTROL,
+ .capa_flags = 0
+ },
+ .crypto_capabilities = pmd_capabilities
+ },
{
.action = RTE_SECURITY_ACTION_TYPE_NONE
}
}
}
+Below is an example of the capabilities for a PMD which supports the DOCSIS
+protocol.
+
+.. code-block:: c
+
+ static const struct rte_security_capability pmd_security_capabilities[] = {
+ { /* DOCSIS Uplink */
+ .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
+ .protocol = RTE_SECURITY_PROTOCOL_DOCSIS,
+ .docsis = {
+ .direction = RTE_SECURITY_DOCSIS_UPLINK
+ },
+ .crypto_capabilities = pmd_capabilities
+ },
+ { /* DOCSIS Downlink */
+ .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
+ .protocol = RTE_SECURITY_PROTOCOL_DOCSIS,
+ .docsis = {
+ .direction = RTE_SECURITY_DOCSIS_DOWNLINK
+ },
+ .crypto_capabilities = pmd_capabilities
+ },
+ {
+ .action = RTE_SECURITY_ACTION_TYPE_NONE
+ }
+ };
+ static const struct rte_cryptodev_capabilities pmd_capabilities[] = {
+ { /* AES DOCSIS BPI */
+ .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+ .sym = {
+ .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
+ .cipher = {
+ .algo = RTE_CRYPTO_CIPHER_AES_DOCSISBPI,
+ .block_size = 16,
+ .key_size = {
+ .min = 16,
+ .max = 32,
+ .increment = 16
+ },
+ .iv_size = {
+ .min = 16,
+ .max = 16,
+ .increment = 0
+ }
+ }
+ }
+ },
+
+ RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
+ };
Capabilities Discovery
~~~~~~~~~~~~~~~~~~~~~~
The Security framework provides APIs to create and free sessions for crypto/ethernet
devices, where sessions are mempool objects. It is the application's responsibility
-to create and manage the session mempools. The mempool object size should be able to
-accommodate the driver's private data of security session.
+to create and manage two session mempools - one for session and other for session
+private data. The private session data mempool object size should be able to
+accommodate the driver's private data of security session. The application can get
+the size of session private data using API ``rte_security_session_get_size``.
+And the session mempool object size should be enough to accommodate
+``rte_security_session``.
Once the session mempools have been created, ``rte_security_session_create()``
is used to allocate and initialize a session for the required crypto/ethernet device.
.. note::
- In case of inline processed packets, ``rte_mbuf.udata64`` field would be
- used by the driver to relay information on the security processing
+ In case of inline processed packets, ``RTE_SECURITY_DYNFIELD_NAME`` field
+ would be used by the driver to relay information on the security processing
associated with the packet. In ingress, the driver would set this in Rx
path while in egress, ``rte_security_set_pkt_metadata()`` would perform a
similar operation. The application is expected not to modify the field
union {
struct rte_security_ipsec_xform ipsec;
struct rte_security_macsec_xform macsec;
+ struct rte_security_pdcp_xform pdcp;
+ struct rte_security_docsis_xform docsis;
};
/**< Configuration parameters for security session */
struct rte_crypto_sym_xform *crypto_xform;
/**< No security actions */
RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO,
/**< Crypto processing for security protocol is processed inline
- * during transmission */
+ * during transmission
+ */
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL,
/**< All security protocol processing is performed inline during
- * transmission */
- RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
+ * transmission
+ */
+ RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
/**< All security protocol processing including crypto is performed
- * on a lookaside accelerator */
+ * on a lookaside accelerator
+ */
+ RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO
+ /**< Similar to ACTION_TYPE_NONE but crypto processing for security
+ * protocol is processed synchronously by a CPU.
+ */
};
The ``rte_security_session_protocol`` is defined as
.. code-block:: c
enum rte_security_session_protocol {
- RTE_SECURITY_PROTOCOL_IPSEC,
+ RTE_SECURITY_PROTOCOL_IPSEC = 1,
/**< IPsec Protocol */
RTE_SECURITY_PROTOCOL_MACSEC,
/**< MACSec Protocol */
+ RTE_SECURITY_PROTOCOL_PDCP,
+ /**< PDCP Protocol */
+ RTE_SECURITY_PROTOCOL_DOCSIS,
+ /**< DOCSIS Protocol */
};
-Currently the library defines configuration parameters for IPSec only. For other
-protocols like MACSec, structures and enums are defined as place holders which
-will be updated in the future.
+Currently the library defines configuration parameters for IPsec and PDCP only.
+For other protocols like MACSec, structures and enums are defined as place holders
+which will be updated in the future.
IPsec related configuration parameters are defined in ``rte_security_ipsec_xform``
-.. code-block:: c
+PDCP related configuration parameters are defined in ``rte_security_pdcp_xform``
- struct rte_security_ipsec_xform {
- uint32_t spi;
- /**< SA security parameter index */
- uint32_t salt;
- /**< SA salt */
- struct rte_security_ipsec_sa_options options;
- /**< various SA options */
- enum rte_security_ipsec_sa_direction direction;
- /**< IPSec SA Direction - Egress/Ingress */
- enum rte_security_ipsec_sa_protocol proto;
- /**< IPsec SA Protocol - AH/ESP */
- enum rte_security_ipsec_sa_mode mode;
- /**< IPsec SA Mode - transport/tunnel */
- struct rte_security_ipsec_tunnel_param tunnel;
- /**< Tunnel parameters, NULL for transport mode */
- };
+DOCSIS related configuration parameters are defined in ``rte_security_docsis_xform``
Security API
git.droids-corp.org / dpdk.git / blobdiff