summaryrefslogtreecommitdiffstats
path: root/doc/guides/prog_guide/rte_security.rst
blob: 0812abe77912dfcf31cfd600d58f333e052f5382 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
..  SPDX-License-Identifier: BSD-3-Clause
    Copyright 2017 NXP



Security Library
================

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.

Design Principles
-----------------

The security library provides an additional offload capability to an existing
crypto device and/or ethernet device.

.. code-block:: console

               +---------------+
               | rte_security  |
               +---------------+
                 \            /
        +-----------+    +--------------+
        |  NIC PMD  |    |  CRYPTO PMD  |
        +-----------+    +--------------+

.. note::

    Currently, the security library does not support the case of multi-process.
    It will be updated in the future releases.

The supported offload types are explained in the sections below.

Inline Crypto
~~~~~~~~~~~~~

RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
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.

Ingress Data path - The packet is decrypted in RX path and relevant
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),
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
crypto status sets additional flags in the rte_mbuf.ol_flags field.

.. note::

    The underlying device may not support crypto processing for all ingress packet
    matching to a particular flow (e.g. fragmented packets), such packets will
    be passed as encrypted packets. It is the responsibility of application to
    process such encrypted packets using other crypto driver instance.

Egress Data path - The software prepares the egress packet by adding
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.

.. note::

    The underlying device may support post encryption TSO.

.. code-block:: console

          Egress Data Path
                 |
        +--------|--------+
        |  egress IPsec   |
        |        |        |
        | +------V------+ |
        | | SADB lookup | |
        | +------|------+ |
        | +------V------+ |
        | |   Tunnel    | |   <------ Add tunnel header to packet
        | +------|------+ |
        | +------V------+ |
        | |     ESP     | |   <------ Add ESP header without trailer to packet
        | |             | |   <------ Mark packet to be offloaded, add trailer
        | +------|------+ |            meta-data to mbuf
        +--------V--------+
                 |
        +--------V--------+
        |    L2 Stack     |
        +--------|--------+
                 |
        +--------V--------+
        |                 |
        |     NIC PMD     |   <------ Set hw context for inline crypto offload
        |                 |
        +--------|--------+
                 |
        +--------|--------+
        |  HW ACCELERATED |   <------ Packet Encryption and
        |        NIC      |           Authentication happens inline
        |                 |
        +-----------------+


Inline protocol offload
~~~~~~~~~~~~~~~~~~~~~~~

RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
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.

Ingress Data path - The packet is decrypted in the RX path and relevant
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),
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.

.. 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.
    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.

Egress Data path - The software will send the plain packet without any
security protocol headers added to the packet. The driver will configure
the security index and other requirement in tx descriptors.
The hardware device will do security processing on the packet that includes
adding the relevant protocol headers and encrypting the data before sending
the packet out. The software should make sure that the buffer
has required head room and tail room for any protocol header addition. The
software may also do early fragmentation if the resultant packet is expected
to cross the MTU size.


.. 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
    packet, however the device shall provide indication when the sequence number
    is about to overflow. The underlying device may support post encryption TSO.

.. code-block:: console

         Egress Data Path
                 |
        +--------|--------+
        |  egress IPsec   |
        |        |        |
        | +------V------+ |
        | | SADB lookup | |
        | +------|------+ |
        | +------V------+ |
        | |   Desc      | |   <------ Mark packet to be offloaded
        | +------|------+ |
        +--------V--------+
                 |
        +--------V--------+
        |    L2 Stack     |
        +--------|--------+
                 |
        +--------V--------+
        |                 |
        |     NIC PMD     |   <------ Set hw context for inline crypto offload
        |                 |
        +--------|--------+
                 |
        +--------|--------+
        |  HW ACCELERATED |   <------ Add tunnel, ESP header etc header to
        |        NIC      |           packet. Packet Encryption and
        |                 |           Authentication happens inline.
        +-----------------+


Lookaside protocol offload
~~~~~~~~~~~~~~~~~~~~~~~~~~

RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL:
This extends librte_cryptodev to support the programming of IPsec
Security Association (SA) as part of a crypto session creation including
the definition. In addition to standard crypto processing, as defined by
the cryptodev, the security protocol processing is also offloaded to the
crypto device.

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
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.
    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.

Encryption: The software will submit the packet to cryptodev as usual
for encryption, the hardware device in this case will also add the relevant
security protocol header along with encrypting the packet. The software
should make sure that the buffer has required head room and tail room
for any protocol header addition.

.. note::

    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.

.. code-block:: console

          Egress Data Path
                 |
        +--------|--------+
        |  egress IPsec   |
        |        |        |
        | +------V------+ |
        | | SADB lookup | |   <------ SA maps to cryptodev session
        | +------|------+ |
        | +------|------+ |
        | |      \--------------------\
        | |    Crypto   | |           |  <- Crypto processing through
        | |      /----------------\   |     inline crypto PMD
        | +------|------+ |       |   |
        +--------V--------+       |   |
                 |                |   |
        +--------V--------+       |   |  create   <-- SA is added to hw
        |    L2 Stack     |       |   |  inline       using existing create
        +--------|--------+       |   |  session      sym session APIs
                 |                |   |    |
        +--------V--------+   +---|---|----V---+
        |                 |   |   \---/    |   | <--- Add tunnel, ESP header etc
        |     NIC PMD     |   |   INLINE   |   |      header to packet.Packet
        |                 |   | CRYPTO PMD |   |      Encryption/Decryption and
        +--------|--------+   +----------------+      Authentication happens
                 |                                    inline.
        +--------|--------+
        |       NIC       |
        +--------|--------+
                 V

Device Features and Capabilities
---------------------------------

Device Capabilities For Security Operations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The device (crypto or ethernet) capabilities which support security operations,
are defined by the security action type, security protocol, protocol
capabilities and corresponding crypto capabilities for security. For the full
scope of the Security capability see definition of rte_security_capability
structure in the *DPDK API Reference*.

.. code-block:: c

   struct rte_security_capability;

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.

.. code-block:: c

    static const struct rte_security_capability pmd_security_capabilities[] = {
        { /* IPsec Lookaside Protocol offload ESP Tunnel Egress */
                .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_EGRESS,
                        .options = { 0 }
                },
                .crypto_capabilities = pmd_capabilities
        },
        { /* 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 = pmd_capabilities
        },
        {
                .action = RTE_SECURITY_ACTION_TYPE_NONE
        }
    };
    static const struct rte_cryptodev_capabilities pmd_capabilities[] = {
        {    /* SHA1 HMAC */
            .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
            .sym = {
                .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
                .auth = {
                    .algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
                    .block_size = 64,
                    .key_size = {
                        .min = 64,
                        .max = 64,
                        .increment = 0
                    },
                    .digest_size = {
                        .min = 12,
                        .max = 12,
                        .increment = 0
                    },
                    .aad_size = { 0 },
                    .iv_size = { 0 }
                }
            }
        },
        {    /* AES CBC */
            .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
            .sym = {
                .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
                .cipher = {
                    .algo = RTE_CRYPTO_CIPHER_AES_CBC,
                    .block_size = 16,
                    .key_size = {
                        .min = 16,
                        .max = 32,
                        .increment = 8
                    },
                    .iv_size = {
                        .min = 16,
                        .max = 16,
                        .increment = 0
                    }
                }
            }
        }
    }


Capabilities Discovery
~~~~~~~~~~~~~~~~~~~~~~

Discovering the features and capabilities of a driver (crypto/ethernet)
is achieved through the ``rte_security_capabilities_get()`` function.

.. code-block:: c

   const struct rte_security_capability *rte_security_capabilities_get(uint16_t id);

This allows the user to query a specific driver and get all device
security capabilities. It returns an array of ``rte_security_capability`` structures
which contains all the capabilities for that device.

Security Session Create/Free
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Security Sessions are created to store the immutable fields of a particular Security
Association for a particular protocol which is defined by a security session
configuration structure which is used in the operation processing of a packet flow.
Sessions are used to manage protocol specific information as well as crypto parameters.
Security sessions cache this immutable data in a optimal way for the underlying PMD
and this allows further acceleration of the offload of Crypto workloads.

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.

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.

Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet
security ops. This parameter can be retrieved using the APIs
``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx``
(for ethernet port).

Sessions already created can be updated with ``rte_security_session_update()``.

When a session is no longer used, the user must call ``rte_security_session_destroy()``
to free the driver private session data and return the memory back to the mempool.

For look aside protocol offload to hardware crypto device, the ``rte_crypto_op``
created by the application is attached to the security session by the API
``rte_security_attach_session()``.

For Inline Crypto and Inline protocol offload, device specific defined metadata is
updated in the mbuf using ``rte_security_set_pkt_metadata()`` if
``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set.

For inline protocol offloaded ingress traffic, the application can register a
pointer, ``userdata`` , in the security session. When the packet is received,
``rte_security_get_userdata()`` would return the userdata registered for the
security session which processed the packet.

.. note::

    In case of inline processed packets, ``rte_mbuf.udata64`` 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
    when it has relevant info. For ingress, this device-specific 64 bit value
    is required to derive other information (like userdata), required for
    identifying the security processing done on the packet.

Security session configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Security Session configuration structure is defined as ``rte_security_session_conf``

.. code-block:: c

    struct rte_security_session_conf {
        enum rte_security_session_action_type action_type;
        /**< Type of action to be performed on the session */
        enum rte_security_session_protocol protocol;
        /**< Security protocol to be configured */
        union {
                struct rte_security_ipsec_xform ipsec;
                struct rte_security_macsec_xform macsec;
        };
        /**< Configuration parameters for security session */
        struct rte_crypto_sym_xform *crypto_xform;
        /**< Security Session Crypto Transformations */
        void *userdata;
        /**< Application specific userdata to be saved with session */
    };

The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related
configuration. The ``rte_security_session_action_type`` struct is used to specify whether the
session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol
Offload.

.. code-block:: c

    enum rte_security_session_action_type {
        RTE_SECURITY_ACTION_TYPE_NONE,
        /**< No security actions */
        RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO,
        /**< Crypto processing for security protocol is processed inline
         * during transmission */
        RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL,
        /**< All security protocol processing is performed inline during
         * transmission */
        RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
        /**< All security protocol processing including crypto is performed
         * on a lookaside accelerator */
    };

The ``rte_security_session_protocol`` is defined as

.. code-block:: c

    enum rte_security_session_protocol {
        RTE_SECURITY_PROTOCOL_IPSEC,
        /**< IPsec Protocol */
        RTE_SECURITY_PROTOCOL_MACSEC,
        /**< MACSec 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.

IPsec related configuration parameters are defined in ``rte_security_ipsec_xform``

.. code-block:: c

    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 */
    };


Security API
~~~~~~~~~~~~

The rte_security Library API is described in the *DPDK API Reference* document.

Flow based Security Session
~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the case of NIC based offloads, the security session specified in the
'rte_flow_action_security' must be created on the same port as the
flow action that is being specified.

The ingress/egress flow attribute should match that specified in the security
session if the security session supports the definition of the direction.

Multiple flows can be configured to use the same security session. For
example if the security session specifies an egress IPsec SA, then multiple
flows can be specified to that SA. In the case of an ingress IPsec SA then
it is only valid to have a single flow to map to that security session.

.. code-block:: console

         Configuration Path
                 |
        +--------|--------+
        |    Add/Remove   |
        |     IPsec SA    |   <------ Build security flow action of
        |        |        |           ipsec transform
        |--------|--------|
                 |
        +--------V--------+
        |   Flow API      |
        +--------|--------+
                 |
        +--------V--------+
        |                 |
        |     NIC PMD     |   <------ Add/Remove SA to/from hw context
        |                 |
        +--------|--------+
                 |
        +--------|--------+
        |  HW ACCELERATED |
        |        NIC      |
        |                 |
        +--------|--------+

* Add/Delete SA flow:
  To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP
  using the SA selectors and the ``rte_crypto_ipsec_xform`` as the ``rte_flow_action``.
  Note that any rte_flow_items may be empty, which means it is not checked.

.. code-block:: console

    In its most basic form, IPsec flow specification is as follows:
        +-------+     +----------+    +--------+    +-----+
        |  Eth  | ->  |   IP4/6  | -> |   ESP  | -> | END |
        +-------+     +----------+    +--------+    +-----+

    However, the API can represent, IPsec crypto offload with any encapsulation:
        +-------+            +--------+    +-----+
        |  Eth  | ->  ... -> |   ESP  | -> | END |
        +-------+            +--------+    +-----+