* [dpdk-dev] [PATCH 1/2] doc: add details of rte_flow security actions
2017-09-17 12:06 [dpdk-dev] [PATCH 0/2] Document rte_flow security action Boris Pismenny
@ 2017-09-17 12:06 ` Boris Pismenny
2017-09-18 11:14 ` Mcnamara, John
2017-09-17 12:06 ` [dpdk-dev] [PATCH 2/2] ethdev: update documentation for security action Boris Pismenny
1 sibling, 1 reply; 5+ messages in thread
From: Boris Pismenny @ 2017-09-17 12:06 UTC (permalink / raw)
To: dev
Cc: akhil.goyal, declan.doherty, pablo.de.lara.guarch,
hemant.agrawal, radu.nicolau, borisp, aviadye, thomas,
sandeep.malik, jerin.jacob, nelio.laranjeiro, liranl
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
---
doc/guides/prog_guide/rte_flow.rst | 83 +++++++++++++++++++++++++++++++++++++-
1 file changed, 81 insertions(+), 2 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 662a912..62da436 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -187,7 +187,7 @@ Pattern item
Pattern items fall in two categories:
- Matching protocol headers and packet data (ANY, RAW, ETH, VLAN, IPV4,
- IPV6, ICMP, UDP, TCP, SCTP, VXLAN, MPLS, GRE and so on), usually
+ IPV6, ICMP, UDP, TCP, SCTP, VXLAN, MPLS, GRE, ESP and so on), usually
associated with a specification structure.
- Matching meta-data or affecting pattern processing (END, VOID, INVERT, PF,
@@ -955,6 +955,14 @@ Usage example, fuzzy match a TCPv4 packets:
| 4 | END |
+-------+----------+
+Item: ``ESP``
+^^^^^^^^^^^^^
+
+Matches an ESP header.
+
+- ``hdr``: ESP header definition (``rte_esp.h``).
+- Default ``mask`` matches SPI only.
+
Actions
~~~~~~~
@@ -972,7 +980,7 @@ They fall in three categories:
additional processing by subsequent flow rules.
- Other non-terminating meta actions that do not affect the fate of packets
- (END, VOID, MARK, FLAG, COUNT).
+ (END, VOID, MARK, FLAG, COUNT, SECURITY).
When several actions are combined in a flow rule, they should all have
different types (e.g. dropping a packet twice is not possible).
@@ -1354,6 +1362,77 @@ rule or if packets are not addressed to a VF in the first place.
| ``vf`` | VF ID to redirect packets to |
+--------------+--------------------------------+
+Action: ``SECURITY``
+^^^^^^^^^^^^^^^^^^^^
+
+Perform the security action on flows matched by the pattern items
+according to the configuration of the security session.
+
+This action modifies the payload of matched flows. For INLINE_CRYPTO, the
+security protocol headers and IV are fully provided by the application as
+specified in the flow pattern. The payload of matching packets is
+encrypted on egress, and decrypted and authenticated on ingress.
+For INLINE_PROTOCOL, the security protocol is fully offloaded to HW,
+providing full encapsulation and decapsulation of packets in security
+protocols. The flow pattern specifies both the outer security header fields
+and the inner packet fields. The security session specified in the action
+must match the pattern parameters.
+
+The security session specified in the action 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.
+
+- Non-terminating by default.
+
+.. _table_rte_flow_action_security
+
+.. table:: SECURITY
+
+ +----------------------+--------------------------------------+
+ | Field | Value |
+ +======================+======================================+
+ | ``security_session`` | security session to apply |
+ +----------------------+--------------------------------------+
+
+Usage example, configure IPsec inline using INLINE_CRYPTO security session:
+
+The encryption algorithm, keys and salt are part of the opaque
+``rte_security_session``. The SA is identified according to the IP and ESP
+fields in the pattern items.
+
+.. _table_rte_flow_item_esp_inline_example:
+
+.. table:: IPsec inline crypto flow pattern items.
+
+ +-------+----------+
+ | Index | Item |
+ +=======+==========+
+ | 0 | Ethernet |
+ +-------+----------+
+ | 1 | IPv4 |
+ +-------+----------+
+ | 2 | ESP |
+ +-------+----------+
+ | 3 | END |
+ +-------+----------+
+
+.. _table_rte_flow_action_esp_inline_example:
+
+.. table:: IPsec inline flow actions.
+
+ +-------+----------+
+ | Index | Action |
+ +=======+==========+
+ | 0 | SECURITY |
+ +-------+----------+
+ | 1 | END |
+ +-------+----------+
+
Negative types
~~~~~~~~~~~~~~
--
1.8.3.1
^ permalink raw reply [flat|nested] 5+ messages in thread* [dpdk-dev] [PATCH 2/2] ethdev: update documentation for security action
2017-09-17 12:06 [dpdk-dev] [PATCH 0/2] Document rte_flow security action Boris Pismenny
2017-09-17 12:06 ` [dpdk-dev] [PATCH 1/2] doc: add details of rte_flow security actions Boris Pismenny
@ 2017-09-17 12:06 ` Boris Pismenny
2017-09-18 11:18 ` Mcnamara, John
1 sibling, 1 reply; 5+ messages in thread
From: Boris Pismenny @ 2017-09-17 12:06 UTC (permalink / raw)
To: dev
Cc: akhil.goyal, declan.doherty, pablo.de.lara.guarch,
hemant.agrawal, radu.nicolau, borisp, aviadye, thomas,
sandeep.malik, jerin.jacob, nelio.laranjeiro, liranl
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
---
lib/librte_ether/rte_flow.h | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index dce92ca..48d4fca 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -1043,19 +1043,27 @@ struct rte_flow_action_vf {
/**
* RTE_FLOW_ACTION_TYPE_SECURITY
*
- * Perform security action on define flow as specified by security session.
- * The security session specified in the action must be created on the same port
- * as the flow action that is being specified.
+ * Perform the security action on flows matched by the pattern items
+ * according to the configuration of the security session.
+ *
+ * This action modifies the payload of matched flows. For INLINE_CRYPTO, the
+ * security protocol headers and IV are fully provided by the application as
+ * specified in the flow pattern. The payload of matching packets is
+ * encrypted on egress, and decrypted and authenticated on ingress.
+ * For INLINE_PROTOCOL, the security protocol is fully offloaded to HW,
+ * providing full encapsulation and decapsulation of packets in security
+ * protocols. The flow pattern specifies both the outer security header fields
+ * and the inner packet fields. The security session specified in the action
+ * must match the pattern parameters.
+ *
+ * The security session specified in the action 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.
- *
+ * Multiple flows can be configured to use the same security session.
*
* Non-terminating by default.
*/
--
1.8.3.1
^ permalink raw reply [flat|nested] 5+ messages in thread