1. rte_security: A new crypto-offload framework in DPDK
Hemant Agrawal (NXP)
Akhil Goyal (NXP)
DPDK Summit - India- 2018

2. Agenda Introduction Acceleration enablement modes
Lookaside Security Protocol
Inline Crypto
Inline Security Protocol
Security Library Details
Summary & Future Work
Q&A

3. Introduction – rte_security
Framework for management and provisioning of hardware acceleration of security protocols.
Generic APIs to manage security sessions.
Net/Crypto device PMD initializes a security context which is used to access security operations on that particular device.
Rich capabilities discovery APIs
Currently IP Security (IPsec) protocol is supported.
Could support a wide variety of protocols/applications
Enterprise/SMB VPNs — IPsec
Wireless backhaul — IPsec, PDCP
Data-center — SSL
WLAN backhaul — CAPWAP/DTLS
Control-plane options for above — PKCS, RNG
Security Library
Net PMD
Crypto PMD

4. IPSEC - Encrypt Packet Processing
Packet Received
Flow and SPD/SA Lookup
Pre-Protocol Processing
Sequence Number
Random IV generation
Block Cipher Padding
Tunnel Header Preparations (TOS/ECN/DF etc)
Crypto Processing
Encryption
Authentication
Post-Protocol Processing
IP Header Addition
L2 process
and transmission

5. Hardware Acceleration Modes
Lookaside Protocol,
Inline Crypto,
Inline Protocol

6. Lookaside Protocol Acceleration
Packet is given to an accelerator for processing and then returned to the host after processing is complete.
Application provides session information to configure a security IPsec SA on the accelerator.
Crypto_op uses security session to enqueue/dequeue packets to/from crypto PMD.
Support full protocol (IPsec) processing on the accelerator. Including:
Add/remove protocol headers, including IP tunnel headers as well as IPsec (AH/ESP) headers.
Handling SA state information:
Sequence number overflow
Anti-replay window

7. Lookaside Protocol Acceleration (Ingress)

8. Lookaside Protocol Acceleration (Egress)

9. Lookaside Protocol Processing Example - IPsec ESP Tunnel Encrypt
Input Frame:
Payload
Lookaside Protocol Accelerator adds
ESP header
Initialization Vector (IV)
ESP trailer
Integrity check value (ICV)
Outer IP header/NAT-T header
Calculates IP header length
Calculate header checksum.
Crypto:
Class 1
Pad
Payload
padding N
Len
Encrypted
Pad
Payload
padding
Len N
Class 2
Opt
Pad
SPI
Seq#
Payload
padding N
Opt ESN IV
Len
Authenticate
Output Frame:
Opt
Pad
New IP Header
SPI
Seq#
Payload
padding N
ICV IV
Len
Esp
header

10. Inline Crypto Acceleration
IO based acceleration performed on the physical interface as packet ingress/egress.
No packet headers modifications* on the hardware, only encryption/decryption and authentication operations are performed.
Requires that Ethernet CRC is also offloaded to the physical interface.
*Hardware may support extra features like payload padding etc.

11. Inline Crypto Ingress Data Path
HW performs the following for matching (SIP, DIP, ESP)* packets:
Decryption and authentication processing – mark the result in metadata
Remove the ESP trailer*
PMD provides the following info per packet:
Crypto result – success/failure.
Inner ESP next protocol*
Packet without a trailer*
Application:
Check mbuf->ol_flags for PKT_RX_SEC_OFFLOAD / PKT_RX_SEC_OFFLOAD_FAILED
Read the inner ESP next protocol to remove the ESP header
* Support is hardware dependent, there may be some variation.

12. Inline Crypto Ingress Data Path

13. Inline Crypto Egress Data Path
Application:
Mark mbuf->ol_flags using PKT_TX_SEC_OFFLOAD
Marks packet with IPsec as ESP tunnel
Set all security metadata in mbuf as needed, including inner_esp_next_proto according to inner packet*
PMD can perform special processing on packets with the PKT_TX_SEC_OFFLOAD flag set, including:
Inner ESP next protocol*
Security Association Index for hardware*
Processing for LSO support*
HW performs the following for marked packets:
Add the ESP trailer if supported
Encryption and authentication
*Exact requirements, if any, are hardware dependent

14. Inline Crypto Egress Data Path

15. Inline Protocol Acceleration
IO based acceleration performed on the physical interface as the packet ingresses/egresses the platform.
Interface performs all crypto processing for the security protocol (e.g. IPsec) during transmission and reception.
Packet headers modification is performed on hardware including all state management and encryption/decryption and authentication operations.
Hardware may support extra features like padding of payload etc.
Application can retrieve the SA information stored in the userdata on the ingress side to identify the SA for which the packet is decrypted.
Requires that ARP entries for MAC headers are programmed along with the security action, as host may not know destination IP in case of a tunnel mode SA

16. Library Implementation
Core features of the librte_security

17. Library Features
Protocol agnostic session API to manage protocol state on underlying hardware.
Definitions of supported protocols, currently only IPsec, and the parameters for configuring the options. For IPsec this includes:
Acceleration type – inline crypto/lookaside protocol/inline protocol
Defining security association (SA) parameters such as Tunnel/Transport, ESP/AH.
Crypto configuration is reused from cryptodev i.e. crypto xforms.
Capabilities APIs to allow dynamic discovery of supported features of PMD.

18. A multi-device API (Object Model)

19. Protocols and actions
Select the session Protocol: “rte_security_session_protocol”
IPSEC, MACSEC, SSL, PDCP etc.
Select the Security Action Type: “rte_security_session_action_type”
RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO: Inline crypto processing as NIC offload during recv/transmit.
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL: Inline security protocol processing as NIC offload during recv/transmit.
RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL: Security protocol processing including crypto on a crypto accelerator.
Action type can be an input for the given application during SA creation
Based on the action type and other SA related information, application configures session parameters for security offload.

20. Security APIs Get device context
void *rte_cryptodev_get_sec_ctx(uint8_t dev_id)
void *rte_eth_dev_get_sec_ctx(uint8_t port_id)
Create Session
struct rte_security_session * rte_security_session_create(
struct rte_security_ctx *instance,
struct rte_security_session_conf *conf,
struct rte_mempool *mp);
Update (rte_security_session_update)
Destroy (rte_security_session_destroy)
Get Stats (rte_security_session_stats_get)
Get userdata (rte_security_get_userdata)
Set pkt metadata (rte_security_set_pkt_metadata)
Attach session with crypto_op (rte_security_attach_session)
/* Security context for crypto/eth devices */
struct rte_security_ctx {
void *device;
/**< Crypto/ethernet device attached */
const struct rte_security_ops *ops;
/**< Pointer to security ops for the device */
uint16_t sess_cnt;
/**< Number of sessions attached to this context */ };
/** security session configuration parameters */
struct rte_security_session_conf config = {
.action_type = RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO,
/**< Type of action to be performed on the session */
.protocol = RTE_SECURITY_PROTOCOL_IPSEC,
/**< Security protocol to be configured */
.ipsec = {
.spi = /**< Security Protocol Index */,
.salt = /** Salt value */,
.direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS,
.proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
.mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL },
/**< Configuration parameters for security session */
.crypto_xform = /** crypto transforms */
/**< Security Session Crypto Transformations */
.userdata = /** Application specific User data */
Session reuse

21. Security APIs contd.
struct rte_security_ipsec_xform {
uint32_t spi; /**< SA security parameter index */
uint32_t salt; /**< Salt */
struct rte_security_ipsec_sa_options options;
enum rte_security_ipsec_sa_direction dir;
/**< SA Direction Egress/Ingress */
enum rte_security_ipsec_sa_protocol proto;
/**< SA Protocol AH/ESP */
enum rte_security_ipsec_sa_mode mode;
/**< SA Mode Transport/Tunnel */
struct rte_security_ipsec_tunnel_param tunnel;
/**<
* SA Tunnel Parameter. Only applicable when SA is tunnel mode
* and offload type is either inline/lookaside protocol */ };
IPsec SA options include:
Extended Sequence Number Support
NAT/UDP encapsulation,
NAT-T L4 Checksum verify/update
Qos/TOS copy support (inner to outer - tunnel)
DF copy support (inner to outer - tunnel)
TTL decrement support
Address copy support (inner to outer for tunnel)
Trailer add support
Many parameters are applicable for Full Protocol Offload only
Once the session is initialized, application can attach the session with crypto_op or set pkt metadata depending on action_type.

22. Capabilities Example
struct rte_security_capability { enum rte_security_session_action_type action; /**< Security action type*/ enum rte_security_session_protocol protocol; /**< Security protocol */ union { struct { enum rte_security_ipsec_sa_protocol proto; /**< IPsec SA protocol */ enum rte_security_ipsec_sa_mode mode; /**< IPsec SA mode */ enum rte_security_ipsec_sa_direction direction; /**< IPsec SA direction */ struct rte_security_ipsec_sa_options options; /**< IPsec SA supported options */ } ipsec; /**< IPsec capability */ }; const struct rte_cryptodev_capabilities *crypto_capabilities; /**< Corresponding crypto capabilities for security capability */ uint32_t ol_flags; /**< Device offload flags */ { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */ .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, .protocol = RTE_SECURITY_PROTOCOL_IPSEC, .ipsec = { .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS, .options = { 0 } }, .crypto_capabilities = crypto_pmd_capabilities
Capabilities API allow user to get all the capabilities of the devices or to query a single capability
List of Capabilities
const struct rte_security_capability * rte_security_capabilities_get(
struct rte_security_ctx *instance);
Check on Specific Capability
const struct rte_security_capability *
rte_security_capability_get(
struct rte_security_ctx *instance,
struct rte_security_capability_idx *idx);

23. Control Path

24. Summary
Provides an abstraction for provisioning security hw accelerations, initially targeting IPsec.
Can be used with ethdev or cryptodev
Agnostic API to allow applications to use different security accelerations.
Since DPDK 17.11, IPsec Security Gateway Sample application is using rte_security to support inline crypto (on Intel’s IXGBE NET PMD) and lookaside protocol acceleration (on NXP’s DPAA/DPAA2 CRYPTO PMD).
Go try it out!

25. Future Work Multi process support Enable Event based security sessions
IPsec inline protocol offload
Further protocol enablement
MACsec, PDCP, DTLS, etc would fit under this model.
Software equivalent enablement
It could be possible to offer software equivalent processing under this API, may or may not be desirable depending on protocol and it’s processing overhead.

26. Questions? <Akhil Goyal, Hemant Agrawal>