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

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

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

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

Hardware Acceleration Modes Lookaside Protocol, Inline Crypto, Inline Protocol

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

Lookaside Protocol Acceleration (Ingress)

Lookaside Protocol Acceleration (Egress)

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

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.

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.

Inline Crypto Ingress Data Path

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

Inline Crypto Egress Data Path

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

Library Implementation Core features of the librte_security

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.

A multi-device API (Object Model)

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.

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

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.

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);

Control Path

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!

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.

Questions? <Akhil Goyal, Hemant Agrawal> <akhil.goyal@nxp.com, hemant.agrawal@nxp.com>