[1/3] security: support pdcp protocol
Checks
Commit Message
From: Akhil Goyal <akhil.goyal@nxp.com>
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
---
doc/guides/prog_guide/rte_security.rst | 90 ++++++++++++++++++++++++--
lib/librte_security/rte_security.c | 4 ++
lib/librte_security/rte_security.h | 62 ++++++++++++++++++
3 files changed, 149 insertions(+), 7 deletions(-)
Comments
Hi Akhil,
Please see inline.
Thanks,
Anoob
On 28-08-2018 18:31, akhil.goyal@nxp.com wrote:
> External Email
>
> From: Akhil Goyal <akhil.goyal@nxp.com>
>
> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
> ---
> doc/guides/prog_guide/rte_security.rst | 90 ++++++++++++++++++++++++--
> lib/librte_security/rte_security.c | 4 ++
> lib/librte_security/rte_security.h | 62 ++++++++++++++++++
> 3 files changed, 149 insertions(+), 7 deletions(-)
>
> diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
> index 0812abe77..412fff016 100644
> --- a/doc/guides/prog_guide/rte_security.rst
> +++ b/doc/guides/prog_guide/rte_security.rst
> @@ -10,8 +10,8 @@ The security library provides a framework for management and provisioning
> 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 and PDCP
> +protocol and associated operations, other protocols will be added in future.
>
> Design Principles
> -----------------
> @@ -253,6 +253,46 @@ for any protocol header addition.
> +--------|--------+
> V
>
> +PDCP Flow Diagram
> +~~~~~~~~~~~~~~~~~
> +
> +.. 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 |
> + +---------|-----------+ +----------|----------+
> + | |
> + +----------------->>----------------+
> +
[Anoob] Which PDCP specification revision is this based on? In the 5G
specification, even data-plane may undergo integrity protection.
> +
> +.. 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.
> +
> Device Features and Capabilities
> ---------------------------------
>
> @@ -271,7 +311,7 @@ structure in the *DPDK API Reference*.
>
> 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
>
> @@ -298,6 +338,22 @@ PMD which supports the IPSec protocol.
> },
> .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,
> + },
> + .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,
> + },
> + .crypto_capabilities = pmd_capabilities
> + },
> {
> .action = RTE_SECURITY_ACTION_TYPE_NONE
> }
> @@ -429,6 +485,7 @@ Security Session configuration structure is defined as ``rte_security_session_co
> union {
> struct rte_security_ipsec_xform ipsec;
> struct rte_security_macsec_xform macsec;
> + struct rte_security_pdcp_xform pdcp;
> };
> /**< Configuration parameters for security session */
> struct rte_crypto_sym_xform *crypto_xform;
> @@ -463,15 +520,17 @@ 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 */
> };
>
> -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``
>
> @@ -494,6 +553,23 @@ IPsec related configuration parameters are defined in ``rte_security_ipsec_xform
> /**< Tunnel parameters, NULL for transport mode */
> };
>
> +PDCP related configuration parameters are defined in ``rte_security_pdcp_xform``
> +
> +.. code-block:: c
> +
> + struct rte_security_pdcp_xform {
> + int8_t bearer; /**< PDCP bearer ID */
> + enum rte_security_pdcp_domain domain;
> + /** < PDCP mode of operation: Control or data */
> + enum rte_security_pdcp_direction pkt_dir;
> + /**< PDCP Frame Direction 0:UL 1:DL */
> + enum rte_security_pdcp_sn_size sn_size;
> + /**< Sequence number size, 5/7/12/15 */
> + int8_t hfn_ovd; /**< Overwrite HFN per operation */
> + uint32_t hfn; /**< Hyper Frame Number */
> + uint32_t hfn_threshold; /**< HFN Threashold for key renegotiation */
> + };
> +
[Anoob] PDCP packet ordering should be both a capability and a setting.
HFN will be incremented overtime and starts at 0. So why is it part of
the xform?
Also the hfn_ovd is per operation. So why is it part of xform? Is it a
boolean value? If so, where does the HFN for each operation come from?
>
> Security API
> ~~~~~~~~~~~~
> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
> index 1954960a5..c6355de95 100644
> --- a/lib/librte_security/rte_security.c
> +++ b/lib/librte_security/rte_security.c
> @@ -131,6 +131,10 @@ rte_security_capability_get(struct rte_security_ctx *instance,
> capability->ipsec.direction ==
> idx->ipsec.direction)
> return capability;
> + } else if (idx->protocol == RTE_SECURITY_PROTOCOL_PDCP) {
> + if (capability->pdcp.domain ==
> + idx->pdcp.domain)
> + return capability;
> }
> }
> }
> diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
> index b0d1b97ee..e625bc656 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -206,6 +206,52 @@ struct rte_security_macsec_xform {
> int dummy;
> };
>
> +/**
> + * PDCP Mode of session
> + */
> +enum rte_security_pdcp_domain {
> + RTE_SECURITY_PDCP_MODE_CONTROL, /**< PDCP control plane */
> + RTE_SECURITY_PDCP_MODE_DATA, /**< PDCP data plane */
> +};
> +
> +/** PDCP Frame direction */
> +enum rte_security_pdcp_direction {
> + RTE_SECURITY_PDCP_UPLINK, /**< Uplink */
> + RTE_SECURITY_PDCP_DOWNLINK, /**< Downlink */
> +};
> +
> +/**
> + * PDCP Sequence Number Size selectors
> + * @PDCP_SN_SIZE_5: 5bit sequence number
> + * @PDCP_SN_SIZE_7: 7bit sequence number
> + * @PDCP_SN_SIZE_12: 12bit sequence number
> + * @PDCP_SN_SIZE_15: 15bit sequence number
> + */
> +enum rte_security_pdcp_sn_size {
> + RTE_SECURITY_PDCP_SN_SIZE_5 = 5,
> + RTE_SECURITY_PDCP_SN_SIZE_7 = 7,
> + RTE_SECURITY_PDCP_SN_SIZE_12 = 12,
> + RTE_SECURITY_PDCP_SN_SIZE_15 = 15
> +};
[Anoob] SN size 18 is also possible
> +
> +/**
> + * PDCP security association configuration data.
> + *
> + * This structure contains data required to create a PDCP security session.
> + */
> +struct rte_security_pdcp_xform {
> + int8_t bearer; /**< PDCP bearer ID */
> + enum rte_security_pdcp_domain domain;
> + /** < PDCP mode of operation: Control or data */
> + enum rte_security_pdcp_direction pkt_dir;
> + /**< PDCP Frame Direction 0:UL 1:DL */
> + enum rte_security_pdcp_sn_size sn_size;
> + /**< Sequence number size, 5/7/12/15 */
> + int8_t hfn_ovd; /**< Overwrite HFN per operation */
> + uint32_t hfn; /**< Hyper Frame Number */
> + uint32_t hfn_threshold; /**< HFN Threashold for key renegotiation */
> +};
> +
> /**
> * Security session action type.
> */
> @@ -232,6 +278,8 @@ enum rte_security_session_protocol {
> /**< IPsec Protocol */
> RTE_SECURITY_PROTOCOL_MACSEC,
> /**< MACSec Protocol */
> + RTE_SECURITY_PROTOCOL_PDCP,
> + /**< PDCP Protocol */
> };
>
> /**
> @@ -246,6 +294,7 @@ struct rte_security_session_conf {
> union {
> struct rte_security_ipsec_xform ipsec;
> struct rte_security_macsec_xform macsec;
> + struct rte_security_pdcp_xform pdcp;
> };
> /**< Configuration parameters for security session */
> struct rte_crypto_sym_xform *crypto_xform;
> @@ -413,6 +462,10 @@ struct rte_security_ipsec_stats {
>
> };
>
> +struct rte_security_pdcp_stats {
> + uint64_t reserved;
> +};
> +
> struct rte_security_stats {
> enum rte_security_session_protocol protocol;
> /**< Security protocol to be configured */
> @@ -421,6 +474,7 @@ struct rte_security_stats {
> union {
> struct rte_security_macsec_stats macsec;
> struct rte_security_ipsec_stats ipsec;
> + struct rte_security_pdcp_stats pdcp;
> };
> };
>
> @@ -465,6 +519,11 @@ struct rte_security_capability {
> int dummy;
> } macsec;
> /**< MACsec capability */
> + struct {
> + enum rte_security_pdcp_domain domain;
> + /** < PDCP mode of operation: Control or data */
> + } pdcp;
> + /**< PDCP capability */
> };
>
> const struct rte_cryptodev_capabilities *crypto_capabilities;
> @@ -506,6 +565,9 @@ struct rte_security_capability_idx {
> enum rte_security_ipsec_sa_mode mode;
> enum rte_security_ipsec_sa_direction direction;
> } ipsec;
> + struct {
> + enum rte_security_pdcp_domain domain;
> + } pdcp;
> };
> };
>
> --
> 2.17.1
>
On 9/6/2018 9:45 AM, Joseph, Anoob wrote:
> Hi Akhil,
Hi Anoob,
Thanks for the comments.
> Please see inline.
> Thanks,
> Anoob
> On 28-08-2018 18:31, akhil.goyal@nxp.com wrote:
>> External Email
>> From: Akhil Goyal <akhil.goyal@nxp.com>
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
>> ---
>> doc/guides/prog_guide/rte_security.rst | 90 ++++++++++++++++++++++++--
>> lib/librte_security/rte_security.c | 4 ++
>> lib/librte_security/rte_security.h | 62 ++++++++++++++++++
>> 3 files changed, 149 insertions(+), 7 deletions(-)
>> diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
>> index 0812abe77..412fff016 100644
>> --- a/doc/guides/prog_guide/rte_security.rst
>> +++ b/doc/guides/prog_guide/rte_security.rst
>> @@ -10,8 +10,8 @@ The security library provides a framework for management and provisioning
>> 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 and PDCP
>> +protocol and associated operations, other protocols will be added in future.
>> Design Principles
>> -----------------
>> @@ -253,6 +253,46 @@ for any protocol header addition.
>> +--------|--------+
>> V
>> +PDCP Flow Diagram
>> +~~~~~~~~~~~~~~~~~
>> +
>> +.. 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 |
>> + +---------|-----------+ +----------|----------+
>> + | |
>> + +----------------->>----------------+
>> +
> [Anoob] Which PDCP specification revision is this based on? In the 5G
> specification, even data-plane may undergo integrity protection.
This patchset is based on LTE-PDCP - 3GPP TS 36.323 v15.1.0 (2018-09).
5G changes are not added in this patchset. It will be added in future.
>> +.. 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.
>> +
>> Device Features and Capabilities
>> ---------------------------------
>> @@ -271,7 +311,7 @@ structure in the *DPDK API Reference*.
>> 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
>> @@ -298,6 +338,22 @@ PMD which supports the IPSec protocol.
>> },
>> .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,
>> + },
>> + .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,
>> + },
>> + .crypto_capabilities = pmd_capabilities
>> + },
>> {
>> .action = RTE_SECURITY_ACTION_TYPE_NONE
>> }
>> @@ -429,6 +485,7 @@ Security Session configuration structure is defined as ``rte_security_session_co
>> union {
>> struct rte_security_ipsec_xform ipsec;
>> struct rte_security_macsec_xform macsec;
>> + struct rte_security_pdcp_xform pdcp;
>> };
>> /**< Configuration parameters for security session */
>> struct rte_crypto_sym_xform *crypto_xform;
>> @@ -463,15 +520,17 @@ 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 */
>> };
>> -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``
>> @@ -494,6 +553,23 @@ IPsec related configuration parameters are defined in ``rte_security_ipsec_xform
>> /**< Tunnel parameters, NULL for transport mode */
>> };
>> +PDCP related configuration parameters are defined in ``rte_security_pdcp_xform``
>> +
>> +.. code-block:: c
>> +
>> + struct rte_security_pdcp_xform {
>> + int8_t bearer; /**< PDCP bearer ID */
>> + enum rte_security_pdcp_domain domain;
>> + /** < PDCP mode of operation: Control or data */
>> + enum rte_security_pdcp_direction pkt_dir;
>> + /**< PDCP Frame Direction 0:UL 1:DL */
>> + enum rte_security_pdcp_sn_size sn_size;
>> + /**< Sequence number size, 5/7/12/15 */
>> + int8_t hfn_ovd; /**< Overwrite HFN per operation */
>> + uint32_t hfn; /**< Hyper Frame Number */
>> + uint32_t hfn_threshold; /**< HFN Threashold for key renegotiation */
>> + };
>> +
> [Anoob] PDCP packet ordering should be both a capability and a setting.
> HFN will be incremented overtime and starts at 0. So why is it part of
> the xform?
The Security accelerators may assume packet in order. Latest PDCP TS
suggest to do de-Ciphering before re-Ordering the Rx PDCP PDUs. In this
situation, the accelerator may use wrong HFN value. The PDCP application
can provide the appropriate HFN value along with PDU to the security
accelerator.
> Also the hfn_ovd is per operation. So why is it part of xform? Is it a
> boolean value? If so, where does the HFN for each operation come from?
The HFN Override is a boolean. If this is set, the Accelerator shall use
the HFN value provided by the PDCP Application to construct the IV for
deciphering instead of deriving it from the state variables. I will
remove this from the patch as of now, we need to define an appropriate
way to pass the per operation HFN for each packet.
>> Security API
>> ~~~~~~~~~~~~
>> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
>> index 1954960a5..c6355de95 100644
>> --- a/lib/librte_security/rte_security.c
>> +++ b/lib/librte_security/rte_security.c
>> @@ -131,6 +131,10 @@ rte_security_capability_get(struct rte_security_ctx *instance,
>> capability->ipsec.direction ==
>> idx->ipsec.direction)
>> return capability;
>> + } else if (idx->protocol == RTE_SECURITY_PROTOCOL_PDCP) {
>> + if (capability->pdcp.domain ==
>> + idx->pdcp.domain)
>> + return capability;
>> }
>> }
>> }
>> diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
>> index b0d1b97ee..e625bc656 100644
>> --- a/lib/librte_security/rte_security.h
>> +++ b/lib/librte_security/rte_security.h
>> @@ -206,6 +206,52 @@ struct rte_security_macsec_xform {
>> int dummy;
>> };
>> +/**
>> + * PDCP Mode of session
>> + */
>> +enum rte_security_pdcp_domain {
>> + RTE_SECURITY_PDCP_MODE_CONTROL, /**< PDCP control plane */
>> + RTE_SECURITY_PDCP_MODE_DATA, /**< PDCP data plane */
>> +};
>> +
>> +/** PDCP Frame direction */
>> +enum rte_security_pdcp_direction {
>> + RTE_SECURITY_PDCP_UPLINK, /**< Uplink */
>> + RTE_SECURITY_PDCP_DOWNLINK, /**< Downlink */
>> +};
>> +
>> +/**
>> + * PDCP Sequence Number Size selectors
>> + * @PDCP_SN_SIZE_5: 5bit sequence number
>> + * @PDCP_SN_SIZE_7: 7bit sequence number
>> + * @PDCP_SN_SIZE_12: 12bit sequence number
>> + * @PDCP_SN_SIZE_15: 15bit sequence number
>> + */
>> +enum rte_security_pdcp_sn_size {
>> + RTE_SECURITY_PDCP_SN_SIZE_5 = 5,
>> + RTE_SECURITY_PDCP_SN_SIZE_7 = 7,
>> + RTE_SECURITY_PDCP_SN_SIZE_12 = 12,
>> + RTE_SECURITY_PDCP_SN_SIZE_15 = 15
>> +};
> [Anoob] SN size 18 is also possible
Will add this.
-Akhil
Hi Akhil,
Please see inline.
Thanks,
Anoob
On 05-10-2018 17:35, Akhil Goyal wrote:
> External Email
>
> On 9/6/2018 9:45 AM, Joseph, Anoob wrote:
>
>> Hi Akhil,
>
> Hi Anoob,
>
> Thanks for the comments.
>
>> Please see inline.
>> Thanks,
>> Anoob
>> On 28-08-2018 18:31, akhil.goyal@nxp.com wrote:
>>> External Email
>>> From: Akhil Goyal <akhil.goyal@nxp.com>
>>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>>> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
>>> ---
>>> doc/guides/prog_guide/rte_security.rst | 90
>>> ++++++++++++++++++++++++--
>>> lib/librte_security/rte_security.c | 4 ++
>>> lib/librte_security/rte_security.h | 62 ++++++++++++++++++
>>> 3 files changed, 149 insertions(+), 7 deletions(-)
>>> diff --git a/doc/guides/prog_guide/rte_security.rst
>>> b/doc/guides/prog_guide/rte_security.rst
>>> index 0812abe77..412fff016 100644
>>> --- a/doc/guides/prog_guide/rte_security.rst
>>> +++ b/doc/guides/prog_guide/rte_security.rst
>>> @@ -10,8 +10,8 @@ The security library provides a framework for
>>> management and provisioning
>>> 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 and PDCP
>>> +protocol and associated operations, other protocols will be added
>>> in future.
>>> Design Principles
>>> -----------------
>>> @@ -253,6 +253,46 @@ for any protocol header addition.
>>> +--------|--------+
>>> V
>>> +PDCP Flow Diagram
>>> +~~~~~~~~~~~~~~~~~
>>> +
>>> +.. 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 |
>>> + +---------|-----------+ +----------|----------+
>>> + | |
>>> + +----------------->>----------------+
>>> +
>> [Anoob] Which PDCP specification revision is this based on? In the 5G
>> specification, even data-plane may undergo integrity protection.
>
> This patchset is based on LTE-PDCP - 3GPP TS 36.323 v15.1.0 (2018-09).
> 5G changes are not added in this patchset. It will be added in future.
>
>>> +.. 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.
>>> +
>>> Device Features and Capabilities
>>> ---------------------------------
>>> @@ -271,7 +311,7 @@ structure in the *DPDK API Reference*.
>>> 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
>>> @@ -298,6 +338,22 @@ PMD which supports the IPSec protocol.
>>> },
>>> .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,
>>> + },
>>> + .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,
>>> + },
>>> + .crypto_capabilities = pmd_capabilities
>>> + },
>>> {
>>> .action = RTE_SECURITY_ACTION_TYPE_NONE
>>> }
>>> @@ -429,6 +485,7 @@ Security Session configuration structure is
>>> defined as ``rte_security_session_co
>>> union {
>>> struct rte_security_ipsec_xform ipsec;
>>> struct rte_security_macsec_xform macsec;
>>> + struct rte_security_pdcp_xform pdcp;
>>> };
>>> /**< Configuration parameters for security session */
>>> struct rte_crypto_sym_xform *crypto_xform;
>>> @@ -463,15 +520,17 @@ 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 */
>>> };
>>> -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``
>>> @@ -494,6 +553,23 @@ IPsec related configuration parameters are
>>> defined in ``rte_security_ipsec_xform
>>> /**< Tunnel parameters, NULL for transport mode */
>>> };
>>> +PDCP related configuration parameters are defined in
>>> ``rte_security_pdcp_xform``
>>> +
>>> +.. code-block:: c
>>> +
>>> + struct rte_security_pdcp_xform {
>>> + int8_t bearer; /**< PDCP bearer ID */
>>> + enum rte_security_pdcp_domain domain;
>>> + /** < PDCP mode of operation: Control or data */
>>> + enum rte_security_pdcp_direction pkt_dir;
>>> + /**< PDCP Frame Direction 0:UL 1:DL */
>>> + enum rte_security_pdcp_sn_size sn_size;
>>> + /**< Sequence number size, 5/7/12/15 */
>>> + int8_t hfn_ovd; /**< Overwrite HFN per operation */
>>> + uint32_t hfn; /**< Hyper Frame Number */
>>> + uint32_t hfn_threshold; /**< HFN Threashold for key
>>> renegotiation */
>>> + };
>>> +
>> [Anoob] PDCP packet ordering should be both a capability and a setting.
>> HFN will be incremented overtime and starts at 0. So why is it part of
>> the xform?
>
> The Security accelerators may assume packet in order. Latest PDCP TS
> suggest to do de-Ciphering before re-Ordering the Rx PDCP PDUs. In this
> situation, the accelerator may use wrong HFN value. The PDCP application
> can provide the appropriate HFN value along with PDU to the security
> accelerator.
>
So what is the expectation with regards to ordering? Would PDCP know the
order or is it unaware of the order?
If implementation of this Spec knows the order of packets(which is
implied by the "In order delivery and Duplicate detection
Sequence Numbering" statement in the PDCP flow diagram), then there
should be no need to override the
HFN. If the implementation does not know the order of packets, then the
flow diagram should be corrected.
Also, is implementation expected to support ordered delivery and
duplicate detection. Perhaps it should be
a capability or 2.
>> Also the hfn_ovd is per operation. So why is it part of xform? Is it a
>> boolean value? If so, where does the HFN for each operation come from?
>
> The HFN Override is a boolean. If this is set, the Accelerator shall use
> the HFN value provided by the PDCP Application to construct the IV for
> deciphering instead of deriving it from the state variables. I will
> remove this from the patch as of now, we need to define an appropriate
> way to pass the per operation HFN for each packet.
>
>>> Security API
>>> ~~~~~~~~~~~~
>>> diff --git a/lib/librte_security/rte_security.c
>>> b/lib/librte_security/rte_security.c
>>> index 1954960a5..c6355de95 100644
>>> --- a/lib/librte_security/rte_security.c
>>> +++ b/lib/librte_security/rte_security.c
>>> @@ -131,6 +131,10 @@ rte_security_capability_get(struct
>>> rte_security_ctx *instance,
>>> capability->ipsec.direction ==
>>> idx->ipsec.direction)
>>> return capability;
>>> + } else if (idx->protocol ==
>>> RTE_SECURITY_PROTOCOL_PDCP) {
>>> + if (capability->pdcp.domain ==
>>> + idx->pdcp.domain)
>>> + return capability;
>>> }
>>> }
>>> }
>>> diff --git a/lib/librte_security/rte_security.h
>>> b/lib/librte_security/rte_security.h
>>> index b0d1b97ee..e625bc656 100644
>>> --- a/lib/librte_security/rte_security.h
>>> +++ b/lib/librte_security/rte_security.h
>>> @@ -206,6 +206,52 @@ struct rte_security_macsec_xform {
>>> int dummy;
>>> };
>>> +/**
>>> + * PDCP Mode of session
>>> + */
>>> +enum rte_security_pdcp_domain {
>>> + RTE_SECURITY_PDCP_MODE_CONTROL, /**< PDCP control plane */
>>> + RTE_SECURITY_PDCP_MODE_DATA, /**< PDCP data plane */
>>> +};
>>> +
>>> +/** PDCP Frame direction */
>>> +enum rte_security_pdcp_direction {
>>> + RTE_SECURITY_PDCP_UPLINK, /**< Uplink */
>>> + RTE_SECURITY_PDCP_DOWNLINK, /**< Downlink */
>>> +};
>>> +
>>> +/**
>>> + * PDCP Sequence Number Size selectors
>>> + * @PDCP_SN_SIZE_5: 5bit sequence number
>>> + * @PDCP_SN_SIZE_7: 7bit sequence number
>>> + * @PDCP_SN_SIZE_12: 12bit sequence number
>>> + * @PDCP_SN_SIZE_15: 15bit sequence number
>>> + */
>>> +enum rte_security_pdcp_sn_size {
>>> + RTE_SECURITY_PDCP_SN_SIZE_5 = 5,
>>> + RTE_SECURITY_PDCP_SN_SIZE_7 = 7,
>>> + RTE_SECURITY_PDCP_SN_SIZE_12 = 12,
>>> + RTE_SECURITY_PDCP_SN_SIZE_15 = 15
>>> +};
>> [Anoob] SN size 18 is also possible
> Will add this.
>
>
> -Akhil
Hi Anoob,
>>>> @@ -494,6 +553,23 @@ IPsec related configuration parameters are
>>>> defined in ``rte_security_ipsec_xform
>>>> /**< Tunnel parameters, NULL for transport mode */
>>>> };
>>>> +PDCP related configuration parameters are defined in
>>>> ``rte_security_pdcp_xform``
>>>> +
>>>> +.. code-block:: c
>>>> +
>>>> + struct rte_security_pdcp_xform {
>>>> + int8_t bearer; /**< PDCP bearer ID */
>>>> + enum rte_security_pdcp_domain domain;
>>>> + /** < PDCP mode of operation: Control or data */
>>>> + enum rte_security_pdcp_direction pkt_dir;
>>>> + /**< PDCP Frame Direction 0:UL 1:DL */
>>>> + enum rte_security_pdcp_sn_size sn_size;
>>>> + /**< Sequence number size, 5/7/12/15 */
>>>> + int8_t hfn_ovd; /**< Overwrite HFN per operation */
>>>> + uint32_t hfn; /**< Hyper Frame Number */
>>>> + uint32_t hfn_threshold; /**< HFN Threashold for key
>>>> renegotiation */
>>>> + };
>>>> +
>>> [Anoob] PDCP packet ordering should be both a capability and a setting.
>>> HFN will be incremented overtime and starts at 0. So why is it part of
>>> the xform?
>>
>> The Security accelerators may assume packet in order. Latest PDCP TS
>> suggest to do de-Ciphering before re-Ordering the Rx PDCP PDUs. In this
>> situation, the accelerator may use wrong HFN value. The PDCP application
>> can provide the appropriate HFN value along with PDU to the security
>> accelerator.
>>
> So what is the expectation with regards to ordering? Would PDCP know
> the order or is it unaware of the order?
> If implementation of this Spec knows the order of packets(which is
> implied by the "In order delivery and Duplicate detection
> Sequence Numbering" statement in the PDCP flow diagram), then there
> should be no need to override the
> HFN. If the implementation does not know the order of packets, then
> the flow diagram should be corrected.
> Also, is implementation expected to support ordered delivery and
> duplicate detection. Perhaps it should be
> a capability or 2.
This patchset is basically talking about full protocol offload with look
aside accelerators.
And when we are talking about full protocol offload, all protocol
related stuff like ordering, headers etc.
needs to be handled by the HW/driver.
So the expectation is driver/HW should be able to perform in order
delivery and detect duplicates.
If somebody have support for PDCP in the hardware, we can add
capabilities as per the specific requirements.
In v2/v3 I have removed the hfn_override. Will add it later when it will
be supported.
Thanks,
Akhil
Hi Akhil,
Please see inline.
Thanks,
Anoob
On 08-10-2018 15:19, Akhil Goyal wrote:
> External Email
>
> Hi Anoob,
>>>>> @@ -494,6 +553,23 @@ IPsec related configuration parameters are
>>>>> defined in ``rte_security_ipsec_xform
>>>>> /**< Tunnel parameters, NULL for transport mode */
>>>>> };
>>>>> +PDCP related configuration parameters are defined in
>>>>> ``rte_security_pdcp_xform``
>>>>> +
>>>>> +.. code-block:: c
>>>>> +
>>>>> + struct rte_security_pdcp_xform {
>>>>> + int8_t bearer; /**< PDCP bearer ID */
>>>>> + enum rte_security_pdcp_domain domain;
>>>>> + /** < PDCP mode of operation: Control or data */
>>>>> + enum rte_security_pdcp_direction pkt_dir;
>>>>> + /**< PDCP Frame Direction 0:UL 1:DL */
>>>>> + enum rte_security_pdcp_sn_size sn_size;
>>>>> + /**< Sequence number size, 5/7/12/15 */
>>>>> + int8_t hfn_ovd; /**< Overwrite HFN per operation */
>>>>> + uint32_t hfn; /**< Hyper Frame Number */
>>>>> + uint32_t hfn_threshold; /**< HFN Threashold for key
>>>>> renegotiation */
>>>>> + };
>>>>> +
>>>> [Anoob] PDCP packet ordering should be both a capability and a
>>>> setting.
>>>> HFN will be incremented overtime and starts at 0. So why is it part of
>>>> the xform?
>>>
>>> The Security accelerators may assume packet in order. Latest PDCP TS
>>> suggest to do de-Ciphering before re-Ordering the Rx PDCP PDUs. In this
>>> situation, the accelerator may use wrong HFN value. The PDCP
>>> application
>>> can provide the appropriate HFN value along with PDU to the security
>>> accelerator.
>>>
>> So what is the expectation with regards to ordering? Would PDCP know
>> the order or is it unaware of the order?
>> If implementation of this Spec knows the order of packets(which is
>> implied by the "In order delivery and Duplicate detection
>> Sequence Numbering" statement in the PDCP flow diagram), then there
>> should be no need to override the
>> HFN. If the implementation does not know the order of packets, then
>> the flow diagram should be corrected.
>> Also, is implementation expected to support ordered delivery and
>> duplicate detection. Perhaps it should be
>> a capability or 2.
> This patchset is basically talking about full protocol offload with look
> aside accelerators.
> And when we are talking about full protocol offload, all protocol
> related stuff like ordering, headers etc.
> needs to be handled by the HW/driver.
> So the expectation is driver/HW should be able to perform in order
> delivery and detect duplicates.
How will errors in these situations be reported to the application - if
packets are not in order or if a duplicate is detected - how should
driver report it?
Is the driver/HW expected to correct the order OR is the behaviour
limited to detection of out-of-order? In order to correct the order, the
driver/HW will need to accumulate packets. Is that really the
expectation of this specification
> If somebody have support for PDCP in the hardware, we can add
> capabilities as per the specific requirements.
> In v2/v3 I have removed the hfn_override. Will add it later when it will
> be supported.
>
>
> Thanks,
> Akhil
On 10/9/2018 5:08 PM, Joseph, Anoob wrote:
> Hi Akhil,
>
> Please see inline.
>
> Thanks,
> Anoob
> On 08-10-2018 15:19, Akhil Goyal wrote:
>> External Email
>>
>> Hi Anoob,
>>>>>> @@ -494,6 +553,23 @@ IPsec related configuration parameters are
>>>>>> defined in ``rte_security_ipsec_xform
>>>>>> /**< Tunnel parameters, NULL for transport mode */
>>>>>> };
>>>>>> +PDCP related configuration parameters are defined in
>>>>>> ``rte_security_pdcp_xform``
>>>>>> +
>>>>>> +.. code-block:: c
>>>>>> +
>>>>>> + struct rte_security_pdcp_xform {
>>>>>> + int8_t bearer; /**< PDCP bearer ID */
>>>>>> + enum rte_security_pdcp_domain domain;
>>>>>> + /** < PDCP mode of operation: Control or data */
>>>>>> + enum rte_security_pdcp_direction pkt_dir;
>>>>>> + /**< PDCP Frame Direction 0:UL 1:DL */
>>>>>> + enum rte_security_pdcp_sn_size sn_size;
>>>>>> + /**< Sequence number size, 5/7/12/15 */
>>>>>> + int8_t hfn_ovd; /**< Overwrite HFN per operation */
>>>>>> + uint32_t hfn; /**< Hyper Frame Number */
>>>>>> + uint32_t hfn_threshold; /**< HFN Threashold for key
>>>>>> renegotiation */
>>>>>> + };
>>>>>> +
>>>>> [Anoob] PDCP packet ordering should be both a capability and a
>>>>> setting.
>>>>> HFN will be incremented overtime and starts at 0. So why is it
>>>>> part of
>>>>> the xform?
>>>>
>>>> The Security accelerators may assume packet in order. Latest PDCP TS
>>>> suggest to do de-Ciphering before re-Ordering the Rx PDCP PDUs. In
>>>> this
>>>> situation, the accelerator may use wrong HFN value. The PDCP
>>>> application
>>>> can provide the appropriate HFN value along with PDU to the security
>>>> accelerator.
>>>>
>>> So what is the expectation with regards to ordering? Would PDCP know
>>> the order or is it unaware of the order?
>>> If implementation of this Spec knows the order of packets(which is
>>> implied by the "In order delivery and Duplicate detection
>>> Sequence Numbering" statement in the PDCP flow diagram), then there
>>> should be no need to override the
>>> HFN. If the implementation does not know the order of packets, then
>>> the flow diagram should be corrected.
>>> Also, is implementation expected to support ordered delivery and
>>> duplicate detection. Perhaps it should be
>>> a capability or 2.
>> This patchset is basically talking about full protocol offload with look
>> aside accelerators.
>> And when we are talking about full protocol offload, all protocol
>> related stuff like ordering, headers etc.
>> needs to be handled by the HW/driver.
>> So the expectation is driver/HW should be able to perform in order
>> delivery and detect duplicates.
> How will errors in these situations be reported to the application -
> if packets are not in order or if a duplicate is detected - how should
> driver report it?
> Is the driver/HW expected to correct the order OR is the behaviour
> limited to detection of out-of-order? In order to correct the order,
> the driver/HW will need to accumulate packets. Is that really the
> expectation of this specification
I have added a setting in xform and capability for in-order and
duplicate packet detection.
So if the capability is there in hardware to do such processing then it
will do that and report error
in crypto status and if the capability is not there then application
will be responsible for handling such cases.
I hope this would answer your query.
>> If somebody have support for PDCP in the hardware, we can add
>> capabilities as per the specific requirements.
>> In v2/v3 I have removed the hfn_override. Will add it later when it will
>> be supported.
>>
>>
>> Thanks,
>> Akhil
>
Hi Akhil,
On 15-10-2018 18:33, Akhil Goyal wrote:
> External Email
>
> On 10/9/2018 5:08 PM, Joseph, Anoob wrote:
>> Hi Akhil,
>>
>> Please see inline.
>>
>> Thanks,
>> Anoob
>> On 08-10-2018 15:19, Akhil Goyal wrote:
>>> External Email
>>>
>>> Hi Anoob,
>>>>>>> @@ -494,6 +553,23 @@ IPsec related configuration parameters are
>>>>>>> defined in ``rte_security_ipsec_xform
>>>>>>> /**< Tunnel parameters, NULL for transport mode */
>>>>>>> };
>>>>>>> +PDCP related configuration parameters are defined in
>>>>>>> ``rte_security_pdcp_xform``
>>>>>>> +
>>>>>>> +.. code-block:: c
>>>>>>> +
>>>>>>> + struct rte_security_pdcp_xform {
>>>>>>> + int8_t bearer; /**< PDCP bearer ID */
>>>>>>> + enum rte_security_pdcp_domain domain;
>>>>>>> + /** < PDCP mode of operation: Control or data */
>>>>>>> + enum rte_security_pdcp_direction pkt_dir;
>>>>>>> + /**< PDCP Frame Direction 0:UL 1:DL */
>>>>>>> + enum rte_security_pdcp_sn_size sn_size;
>>>>>>> + /**< Sequence number size, 5/7/12/15 */
>>>>>>> + int8_t hfn_ovd; /**< Overwrite HFN per operation */
>>>>>>> + uint32_t hfn; /**< Hyper Frame Number */
>>>>>>> + uint32_t hfn_threshold; /**< HFN Threashold for key
>>>>>>> renegotiation */
>>>>>>> + };
>>>>>>> +
>>>>>> [Anoob] PDCP packet ordering should be both a capability and a
>>>>>> setting.
>>>>>> HFN will be incremented overtime and starts at 0. So why is it
>>>>>> part of
>>>>>> the xform?
>>>>>
>>>>> The Security accelerators may assume packet in order. Latest PDCP TS
>>>>> suggest to do de-Ciphering before re-Ordering the Rx PDCP PDUs. In
>>>>> this
>>>>> situation, the accelerator may use wrong HFN value. The PDCP
>>>>> application
>>>>> can provide the appropriate HFN value along with PDU to the security
>>>>> accelerator.
>>>>>
>>>> So what is the expectation with regards to ordering? Would PDCP know
>>>> the order or is it unaware of the order?
>>>> If implementation of this Spec knows the order of packets(which is
>>>> implied by the "In order delivery and Duplicate detection
>>>> Sequence Numbering" statement in the PDCP flow diagram), then there
>>>> should be no need to override the
>>>> HFN. If the implementation does not know the order of packets, then
>>>> the flow diagram should be corrected.
>>>> Also, is implementation expected to support ordered delivery and
>>>> duplicate detection. Perhaps it should be
>>>> a capability or 2.
>>> This patchset is basically talking about full protocol offload with
>>> look
>>> aside accelerators.
>>> And when we are talking about full protocol offload, all protocol
>>> related stuff like ordering, headers etc.
>>> needs to be handled by the HW/driver.
>>> So the expectation is driver/HW should be able to perform in order
>>> delivery and detect duplicates.
>> How will errors in these situations be reported to the application -
>> if packets are not in order or if a duplicate is detected - how should
>> driver report it?
>> Is the driver/HW expected to correct the order OR is the behaviour
>> limited to detection of out-of-order? In order to correct the order,
>> the driver/HW will need to accumulate packets. Is that really the
>> expectation of this specification
> I have added a setting in xform and capability for in-order and
> duplicate packet detection.
> So if the capability is there in hardware to do such processing then it
> will do that and report error
> in crypto status and if the capability is not there then application
> will be responsible for handling such cases.
> I hope this would answer your query.
Seems good.
>
>>> If somebody have support for PDCP in the hardware, we can add
>>> capabilities as per the specific requirements.
>>> In v2/v3 I have removed the hfn_override. Will add it later when it
>>> will
>>> be supported.
>>>
>>>
>>> Thanks,
>>> Akhil
>>
>
@@ -10,8 +10,8 @@ The security library provides a framework for management and provisioning
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 and PDCP
+protocol and associated operations, other protocols will be added in future.
Design Principles
-----------------
@@ -253,6 +253,46 @@ for any protocol header addition.
+--------|--------+
V
+PDCP Flow Diagram
+~~~~~~~~~~~~~~~~~
+
+.. 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.
+
Device Features and Capabilities
---------------------------------
@@ -271,7 +311,7 @@ structure in the *DPDK API Reference*.
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
@@ -298,6 +338,22 @@ PMD which supports the IPSec protocol.
},
.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,
+ },
+ .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,
+ },
+ .crypto_capabilities = pmd_capabilities
+ },
{
.action = RTE_SECURITY_ACTION_TYPE_NONE
}
@@ -429,6 +485,7 @@ Security Session configuration structure is defined as ``rte_security_session_co
union {
struct rte_security_ipsec_xform ipsec;
struct rte_security_macsec_xform macsec;
+ struct rte_security_pdcp_xform pdcp;
};
/**< Configuration parameters for security session */
struct rte_crypto_sym_xform *crypto_xform;
@@ -463,15 +520,17 @@ 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 */
};
-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``
@@ -494,6 +553,23 @@ IPsec related configuration parameters are defined in ``rte_security_ipsec_xform
/**< Tunnel parameters, NULL for transport mode */
};
+PDCP related configuration parameters are defined in ``rte_security_pdcp_xform``
+
+.. code-block:: c
+
+ struct rte_security_pdcp_xform {
+ int8_t bearer; /**< PDCP bearer ID */
+ enum rte_security_pdcp_domain domain;
+ /** < PDCP mode of operation: Control or data */
+ enum rte_security_pdcp_direction pkt_dir;
+ /**< PDCP Frame Direction 0:UL 1:DL */
+ enum rte_security_pdcp_sn_size sn_size;
+ /**< Sequence number size, 5/7/12/15 */
+ int8_t hfn_ovd; /**< Overwrite HFN per operation */
+ uint32_t hfn; /**< Hyper Frame Number */
+ uint32_t hfn_threshold; /**< HFN Threashold for key renegotiation */
+ };
+
Security API
~~~~~~~~~~~~
@@ -131,6 +131,10 @@ rte_security_capability_get(struct rte_security_ctx *instance,
capability->ipsec.direction ==
idx->ipsec.direction)
return capability;
+ } else if (idx->protocol == RTE_SECURITY_PROTOCOL_PDCP) {
+ if (capability->pdcp.domain ==
+ idx->pdcp.domain)
+ return capability;
}
}
}
@@ -206,6 +206,52 @@ struct rte_security_macsec_xform {
int dummy;
};
+/**
+ * PDCP Mode of session
+ */
+enum rte_security_pdcp_domain {
+ RTE_SECURITY_PDCP_MODE_CONTROL, /**< PDCP control plane */
+ RTE_SECURITY_PDCP_MODE_DATA, /**< PDCP data plane */
+};
+
+/** PDCP Frame direction */
+enum rte_security_pdcp_direction {
+ RTE_SECURITY_PDCP_UPLINK, /**< Uplink */
+ RTE_SECURITY_PDCP_DOWNLINK, /**< Downlink */
+};
+
+/**
+ * PDCP Sequence Number Size selectors
+ * @PDCP_SN_SIZE_5: 5bit sequence number
+ * @PDCP_SN_SIZE_7: 7bit sequence number
+ * @PDCP_SN_SIZE_12: 12bit sequence number
+ * @PDCP_SN_SIZE_15: 15bit sequence number
+ */
+enum rte_security_pdcp_sn_size {
+ RTE_SECURITY_PDCP_SN_SIZE_5 = 5,
+ RTE_SECURITY_PDCP_SN_SIZE_7 = 7,
+ RTE_SECURITY_PDCP_SN_SIZE_12 = 12,
+ RTE_SECURITY_PDCP_SN_SIZE_15 = 15
+};
+
+/**
+ * PDCP security association configuration data.
+ *
+ * This structure contains data required to create a PDCP security session.
+ */
+struct rte_security_pdcp_xform {
+ int8_t bearer; /**< PDCP bearer ID */
+ enum rte_security_pdcp_domain domain;
+ /** < PDCP mode of operation: Control or data */
+ enum rte_security_pdcp_direction pkt_dir;
+ /**< PDCP Frame Direction 0:UL 1:DL */
+ enum rte_security_pdcp_sn_size sn_size;
+ /**< Sequence number size, 5/7/12/15 */
+ int8_t hfn_ovd; /**< Overwrite HFN per operation */
+ uint32_t hfn; /**< Hyper Frame Number */
+ uint32_t hfn_threshold; /**< HFN Threashold for key renegotiation */
+};
+
/**
* Security session action type.
*/
@@ -232,6 +278,8 @@ enum rte_security_session_protocol {
/**< IPsec Protocol */
RTE_SECURITY_PROTOCOL_MACSEC,
/**< MACSec Protocol */
+ RTE_SECURITY_PROTOCOL_PDCP,
+ /**< PDCP Protocol */
};
/**
@@ -246,6 +294,7 @@ struct rte_security_session_conf {
union {
struct rte_security_ipsec_xform ipsec;
struct rte_security_macsec_xform macsec;
+ struct rte_security_pdcp_xform pdcp;
};
/**< Configuration parameters for security session */
struct rte_crypto_sym_xform *crypto_xform;
@@ -413,6 +462,10 @@ struct rte_security_ipsec_stats {
};
+struct rte_security_pdcp_stats {
+ uint64_t reserved;
+};
+
struct rte_security_stats {
enum rte_security_session_protocol protocol;
/**< Security protocol to be configured */
@@ -421,6 +474,7 @@ struct rte_security_stats {
union {
struct rte_security_macsec_stats macsec;
struct rte_security_ipsec_stats ipsec;
+ struct rte_security_pdcp_stats pdcp;
};
};
@@ -465,6 +519,11 @@ struct rte_security_capability {
int dummy;
} macsec;
/**< MACsec capability */
+ struct {
+ enum rte_security_pdcp_domain domain;
+ /** < PDCP mode of operation: Control or data */
+ } pdcp;
+ /**< PDCP capability */
};
const struct rte_cryptodev_capabilities *crypto_capabilities;
@@ -506,6 +565,9 @@ struct rte_security_capability_idx {
enum rte_security_ipsec_sa_mode mode;
enum rte_security_ipsec_sa_direction direction;
} ipsec;
+ struct {
+ enum rte_security_pdcp_domain domain;
+ } pdcp;
};
};