From: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org> It is possible to include TFC padding into ESP-tunnel packets. Document usage of such padding according to RFC.
Signed-off-by: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@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: 0980001e33b4190133d478a0aa2e718fd1e3c164 ** Merge commit sha: e21e3f5f12faf7775b8d0e993a95dd377130f4c7 **/ include/odp/api/spec/ipsec.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h index d57815ed2..86803cecf 100644 --- a/include/odp/api/spec/ipsec.h +++ b/include/odp/api/spec/ipsec.h @@ -1228,6 +1228,10 @@ 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 for ESP tunnel + * mode. Application should handle this padding using payload length from IPv4 + * or IPv6 header. + * * Each successfully transformed packet has a valid value for these metadata * regardless of the inner packet parse configuration * (odp_ipsec_inbound_config_t): @@ -1293,6 +1297,10 @@ 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 for ESP-tunnel + * mode. It will be included into encrypted packet. Receiver side will skip + * this padding automatically. + * * Each successfully transformed packet has a valid value for these metadata: * - L3 offset: Offset to the first byte of the (outmost) IP header *
