tree 2590e834f09c2d936f83d9bc766af99e084a522f
parent dce44e4e2302042890dc8b579d4ff6f99509ae7a
author Christian Hopps <chopps@labn.net> 1572782535 -0500
committer Damjan Marion <dmarion@me.com> 1599471807 +0000

ipsec: fix padding/alignment for native IPsec encryption

Not all ESP crypto algorithms require padding/alignment to be the same
as AES block/IV size. CCM, CTR and GCM all have no padding/alignment
requirements, and the RFCs indicate that no padding (beyond ESPs 4 octet
alignment requirement) should be used unless TFC (traffic flow
confidentiality) has been requested.

  CTR: https://tools.ietf.org/html/rfc3686#section-3.2
  GCM: https://tools.ietf.org/html/rfc4106#section-3.2
  CCM: https://tools.ietf.org/html/rfc4309#section-3.2

- VPP is incorrectly using the IV/AES block size to pad CTR and GCM.
These modes do not require padding (beyond ESPs 4 octet requirement), as
a result packets will have unnecessary padding, which will waste
bandwidth at least and possibly fail certain network configurations that
have finely tuned MTU configurations at worst.

Fix this as well as changing the field names from ".*block_size" to
".*block_align" to better represent their actual (and only) use. Rename
"block_sz" in esp_encrypt to "esp_align" and set it correctly as well.

test: ipsec: Add unit-test to test for RFC correct padding/alignment

test: patch scapy to not incorrectly pad ccm, ctr, gcm modes as well

- Scapy is also incorrectly using the AES block size of 16 to pad CCM,
CTR, and GCM cipher modes. A bug report has been opened with the
and acknowledged with the upstream scapy project as well:

  https://github.com/secdev/scapy/issues/2322

Ticket: VPP-1928
Type: fix
Signed-off-by: Christian Hopps <chopps@labn.net>
Change-Id: Iaa4d6a325a2e99fdcb2c375a3395bcfe7947770e