Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: improvement
Change-Id: I830f7a2ea3ac0aff5185698b9fa7a278c45116b0
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
We add the possibility to bind the destination UDP port of a Scapy SA
to the ESP layer in the IPsec tunnel protection tests, even if it is not
the default port for ESP (4500).
This allows to test IPSec tunnel protection with ports other than 4500
in the UDP header, without hardcoding them in the Scapy patch (ex: 4545)
Type: improvement
Change-Id: I1eea3d4660ed1b59d827250a419af6b7b41c4a72
Signed-off-by: Arthur de Kerhor <arthurdekerhor@gmail.com>
|
|
Type: feature
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I89dc3815eabfee135cd5b3c910dea5e2e2ef1333
|
|
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
|
|
Type: feature
thus allowing NAT traversal,
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: Ie8650ceeb5074f98c68d2d90f6adc2f18afeba08
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
Type: fix
Change-Id: I7e041b666dabd90df23a920a1f1d99db4c10ddfe
Signed-off-by: snaramre <snaramre@cisco.com>
|