From: Dmitry Eremin-Solenikov <[email protected]> It is possible to include TFC padding into ESP packets. Document usage of such padding according to RFC.
Signed-off-by: Dmitry Eremin-Solenikov <[email protected]> --- /** 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 --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 *
