diff mbox series

[API-NEXT,v8,1/3] api: ipsec: document TFC padding usage

Message ID 1516125627-32748-2-git-send-email-odpbot@yandex.ru
State New
Headers show
Series [API-NEXT,v8,1/3] api: ipsec: document TFC padding usage | expand

Commit Message

Github ODP bot Jan. 16, 2018, 6 p.m. UTC
From: Dmitry Eremin-Solenikov <dmitry.ereminsolenikov@linaro.org>


It is possible to include TFC padding into ESP packets. Document usage
of such padding according to RFC.

Signed-off-by: Dmitry Eremin-Solenikov <dmitry.ereminsolenikov@linaro.org>

---
/** Email created from pull request 329 (lumag:ipsec-tfc)
 ** https://github.com/Linaro/odp/pull/329
 ** Patch: https://github.com/Linaro/odp/pull/329.patch
 ** Base sha: 0c7741d067d9b96e14e420b53a256a1b93096e16
 ** Merge commit sha: d31d322b1d7ec8d2b9fc3694df5dd0843b52de1c
 **/
 include/odp/api/spec/ipsec.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
diff mbox series

Patch

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index 4c3c498cd..738dd65ae 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -1206,6 +1206,14 @@  typedef struct odp_ipsec_status_t {
  * restored. The amount and content of packet data before the IP header is
  * undefined.
  *
+ * Additional TFC padding might be present after packet contents unless IKEv2
+ * ESP_TFC_PADDING_NOT_SUPPORTED notification was used. The resulting ODP
+ * packet will extend beyond the end of the IP packet it contains or the
+ * resulting IP packet will extend beyond the end of the IP payload protocol
+ * (for tunnel or transport cases respectively).  An ODP application can detect
+ * and remove such padding by inspecting the length fields of the relevant
+ * protocol headers in the result packet.
+ *
  * Each successfully transformed packet has a valid value for these metadata
  * regardless of the inner packet parse configuration
  * (odp_ipsec_inbound_config_t):
@@ -1271,6 +1279,12 @@  int odp_ipsec_in(const odp_packet_t pkt_in[], int num_in,
  * with IPSEC, etc headers constructed according to the standards. The amount
  * and content of packet data before the IP header is undefined.
  *
+ * Additional TFC padding might be present after packet payload (see RFC 4303
+ * section 2.7 for the list of requirements) unless
+ * ESP_TFC_PADDING_NOT_SUPPORTED notification was used. Such padding should be
+ * filled by application before submitting packet to ODP. Such padding will be
+ * included into encrypted packet. Receiver side will skip this padding.
+ *
  * Each successfully transformed packet has a valid value for these metadata:
  * - L3 offset: Offset to the first byte of the (outmost) IP header
  *