diff mbox series

[API-NEXT,v9,1/2] api: ipsec: document TFC padding usage

Message ID 1516309265-14238-2-git-send-email-odpbot@yandex.ru
State Superseded
Headers show
Series [API-NEXT,v9,1/2] api: ipsec: document TFC padding usage | expand

Commit Message

Github ODP bot Jan. 18, 2018, 9:01 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: e77675624b9cfcd6ea83d11804ed0715b7fad2ec
 ** Merge commit sha: 826bb522f15d045761edd504aebd310a81b4b238
 **/
 include/odp/api/spec/ipsec.h | 22 +++++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)
diff mbox series

Patch

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index 4c3c498cd..bf278d73e 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):
@@ -1258,9 +1266,11 @@  int odp_ipsec_in(const odp_packet_t pkt_in[], int num_in,
  * - L3 offset: Offset to the first byte of the (outmost) IP header
  * - L4 offset: Offset to the L4 header if L4 checksum offload is requested
  *
- * Additionally, input IP packet length (odp_packet_len() minus
- * odp_packet_l3_offset()) must match values in protocol headers. Otherwise
- * results are undefined.
+ * Additionally, input L3 packet length (odp_packet_len() minus
+ * odp_packet_l3_offset()) must not be smaller than the IP packet lenght
+ * indicated by the IP header. Otherwise results are undefined. If the input L3
+ * packet length is bigger than the IP packet length, the additional packet
+ * data is used as TFC padding.
  *
  * Packets are processed in the input order. Packet order is maintained from
  * input 'pkt' array to output 'pkt' array. Packet order is not guaranteed
@@ -1271,6 +1281,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
  *