From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mellanox.co.il (mail-il-dmz.mellanox.com [193.47.165.129]) by dpdk.org (Postfix) with ESMTP id 9BEA02C39 for ; Sun, 17 Sep 2017 14:12:44 +0200 (CEST) Received: from Internal Mail-Server by MTLPINE1 (envelope-from borisp@mellanox.com) with ESMTPS (AES256-SHA encrypted); 17 Sep 2017 15:06:52 +0300 Received: from gen-l-vrt-098.mtl.labs.mlnx (gen-l-vrt-098.mtl.labs.mlnx [10.137.170.1]) by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id v8HC6oEi013909; Sun, 17 Sep 2017 15:06:52 +0300 From: Boris Pismenny To: dev@dpdk.org Cc: akhil.goyal@nxp.com, declan.doherty@intel.com, pablo.de.lara.guarch@intel.com, hemant.agrawal@nxp.com, radu.nicolau@intel.com, borisp@mellanox.com, aviadye@mellanox.com, thomas@monjalon.net, sandeep.malik@nxp.com, jerin.jacob@caviumnetworks.com, nelio.laranjeiro@6wind.com, liranl@mellanox.com Date: Sun, 17 Sep 2017 15:06:30 +0300 Message-Id: <1505649991-3463-2-git-send-email-borisp@mellanox.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1505649991-3463-1-git-send-email-borisp@mellanox.com> References: <1505649991-3463-1-git-send-email-borisp@mellanox.com> Subject: [dpdk-dev] [PATCH 1/2] doc: add details of rte_flow security actions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 12:12:45 -0000 Signed-off-by: Boris Pismenny --- 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