Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: improvement
- collect all DP used variables onto 1st or 2nd cache line
- prefetch the 2nd cache line
- in encrypt prefetch the likely location of the trailer.
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I44d58f8d2d469ff71a4f4a71578e7cc1acaeba43
|
|
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: fix
Signed-off-by: Milan Lenco <milan.lenco@pantheon.tech>
Change-Id: Ic8db52b41d7e5af3425099f008984e50afb3da74
|
|
In case there is no free space in first buffer for ICV and footer,
additional buffer will be added, but esp_encrypt will stay in single
buffer mode.
The issue happens for the following payload sizes:
- TCP packets with payload 1992
- ICMP packets with payload 2004
This fix moves the single/chained buffer ops selection to after
esp_add_footer_and_icv call.
Type: fix
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Signed-off-by: PiotrX Kleski <piotrx.kleski@intel.com>
Change-Id: Ic5ceba418f738933f96edb3e489ca2d149033b79
|
|
Type: feature
the es4-encrypt and esp6-encrypt nodes need to be siblings so they both have the same edges for the DPO on which the tunnel mode SA stacks.
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I2126589135a1df6c95ee14503dfde9ff406df60a
|
|
Type: improvement
- inline some common encap fixup functions into the midchain
rewrite node so we don't incur the cost of the virtual function call
- change the copy 'guess' from ethernet_header (which will never happen) to an ip4 header
- add adj-midchain-tx to multiarch sources
- don't run adj-midchain-tx as a feature, instead put this node as the
adj's next and at the end of the feature arc.
- cache the feature arc config index (to save the cache miss going to fetch it)
- don't check if features are enabled when taking the arc (since we know they are)
the last two changes will also benefit normal adjacencies taking the arc (i.e. for NAT, ACLs, etc)
for IPSec:
- don't run esp_encrypt as a feature, instead when required insert this
node into the adj's next and into the end of the feature arc. this
implies that encrypt is always 'the last feature' run, which is
symmetric with decrypt always being the first.
- esp_encrpyt for tunnels has adj-midchain-tx as next node
Change-Id: Ida0af56a704302cf2d7797ded5f118a781e8acb7
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: feature
Signed-off-by: Damjan Marion <damarion@cisco.com>
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com>
Signed-off-by: Dariusz Kazimierski <dariuszx.kazimierski@intel.com>
Signed-off-by: Piotr Kleski <piotrx.kleski@intel.com>
Change-Id: I4c3fcccf55c36842b7b48aed260fef2802b5c54b
|
|
This fixes a special case when buffer chain enters decrypt node
and becomes a single buffer after decryption.
Type: fix
Change-Id: Id5da9e8a074f83ec3561949631ce613f35528312
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Now UDP enacapsulation doesn't work in transport mode with crypto
algorithms that have iv_sz=8 like AES GCM or 3DES CBC. That happens
because the inserted UDP header overlaps with the old IP header and
gets filled before the information from the old IP header can be
copied to a new IP header. The result is a broken packet:
00:03:39:620863: esp4-encrypt-tun
esp: sa-index 3 spi 3464048590 (0xce792fce) seq 31 sa-seq-hi 0
crypto aes-gcm-128 integrity none udp-encap-enabled
00:03:39:620867: adj-midchain-tx
...
00:03:39:620868: ip4-rewrite
...
00:03:39:620869: GigabitEthernet0/8/0-output
GigabitEthernet0/8/0
IP4: 08:00:27:a9:6b:d6 -> 08:00:27:5a:dd:0c
UDP: 10.255.0.10 -> 10.255.0.20
version 0, header length 0
tos 0x80, ttl 63, length 0, checksum 0x653e (should be 0xffff)
dscp CS4 ecn NON_ECN
fragment id 0x0000
UDP: 128 -> 0
length 0, checksum 0x0000
00:03:39:620870: GigabitEthernet0/8/0-tx
GigabitEthernet0/8/0 tx queue 0
...
IP4: 08:00:27:a9:6b:d6 -> 08:00:27:5a:dd:0c
UDP: 10.255.0.10 -> 10.255.0.20
version 0, header length 0
tos 0x80, ttl 63, length 0, checksum 0x653e (should be 0xffff)
dscp CS4 ecn NON_ECN
fragment id 0x0000
UDP: 128 -> 0
length 0, checksum 0x0000
With this commit, fill UDP header after copying the IP headers in
transport mode.
Type: fix
Change-Id: Ie9a6e562aa05a8378114329d6a9ff395189fa6a8
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
|
|
This reverts commit c2c1bfd9b72aec88526c06479b128725eb525866.
Reason for revert: Seems it's breaking ipsec esp tests
Type: fix
Change-Id: Iac590eee23cbf92a10c62dafa789aa9c3b2284dd
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
This fixes a special case when buffer chain enters decrypt node
and becomes a single buffer after decryption.
Type: fix
Change-Id: I1d4da029b952baa97400adb7173aa63fd97d916b
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Type: improvement
when using vlib_buffer_enqueue_to_next the 'nexts' parameter is an array
of u16, but vnet_feautre_next takes a u32. this is a simple wrapper to
address the impedence mismatch.
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I0fa86629e979e313344eb68442dc35a7b9537a8f
|
|
Type: feature
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: Iaba2ab11bfaa1c8db4023434e3043ac39500f938
|
|
Type: feature
Change-Id: Ie072a7c2bbb1e4a77f7001754f01897efd30fc53
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Type: fix
1 - big packets; chained buffers and those without enoguh space to add
ESP header
2 - IPv6 extension headers in packets that are encrypted/decrypted
3 - Interface protection with SAs that have null algorithms
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: Ie330861fb06a9b248d9dcd5c730e21326ac8e973
|
|
Type: fix
Change-Id: I5cb9a3845ddbc5f4de4eb4e9c481f606fe5cec9a
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
the sequence number increment and the anti-replay window
checks must be atomic. Given the vector nature of VPP we
can't simply use atomic increments for sequence numbers,
since a vector on thread 1 with lower sequence numbers could
be 'overtaken' by packets on thread 2 with higher sequence
numbers.
The anti-replay logic requires a critical section, not just
atomics, and we don't want that.
So when the SA see the first packet it is bound to that worker
all subsequent packets, that arrive on a different worker,
are subject to a handoff.
Type: feature
Change-Id: Ia20a8645fb50622ea6235ab015a537f033d531a4
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
This helps GCC understand the memcpy will not overflow pad_data. GCC-6
(default on Debian 9) in particular got confused.
Type: fix
Change-Id: I176eb01531b9d5c7ebec40f015e510b2d56e77c4
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
IPsec writes trailing data at the end of the buffer without checking
if there is enough space. If the packet length equals buffer size this
leads to rewiting of the next buffer header in the pool.
Type: fix
Change-Id: Iceb27bb724c7243863a4b532aad0808051b7d74c
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Type: feature
Change-Id: Ib2352ca4c7abf4645f21fa16aaaf27408890a2bf
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
Several Fixes:
1 - Anti-replay did not work with GCM becuase it overwrote the sequence
number in the ESP header. To fix i added the seq num to the per-packet
data so it is preserved
2 - The high sequence number was not byte swapped during ESP encrypt.
3 - openssl engine was the only one to return FAIL_DECRYPT for bad GCM
the others return BAD_HMAC. removed the former
4 - improved tracing to show the low and high seq numbers
5 - documented the anti-replay window checks
6 - fixed scapy patch for ESN support for GCM
7 - tests for anti-reply (w/ and w/o ESN) for each crypto algo
Change-Id: Id65d96b6d1d4dd821b2ab557e87468fff6d70e5b
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
If a tunnel interface has the crypto alg set on the outbound SA to
IPSEC_CRYPTO_ALG_NONE and packets are sent out that interface,
the attempt to write an ESP trailer on the packet occurs at the
wrong offset and the vnet buffer opaque data is corrupted, which
can result in a SEGV when a subsequent node attempts to use that
data.
When an outbound SA is set on a tunnel interface which has no crypto
alg set, add a node to the ip{4,6}-output feature arcs which drops all
packets leaving that interface instead of adding the node which would
try to encrypt the packets.
Change-Id: Ie0ac8d8fdc8a035ab8bb83b72b6a94161bebaa48
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
|
|
Print the SPI in hexadecimal and decimal.
Type: feature
Change-Id: I012e94f9147058064e06c6bb4622ab6b6507957d
Signed-off-by: Guillaume Solignac <gsoligna@cisco.com>
|
|
please consult the new tunnel proposal at:
https://wiki.fd.io/view/VPP/IPSec
Type: feature
Change-Id: I52857fc92ae068b85f59be08bdbea1bd5932e291
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
An SA can be used only for ESP or AH nver both, so it needs only one
coresponding DPO.
Type: refactor
Change-Id: I689060f795ee352245a0eaed0890a6b234c63d71
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
Fixes: c59b9a2
Change-Id: I6021e67196a4d31ab11d4e3cfbda34b678150701
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I2d7e873fca6ab266af75814fac5d4cb5cda93cef
Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com>
|
|
- nonce construction out of salt and iv is ipsec specific so it should be
handled in ipsec code
- fixes GCM unit tests
- GCM IV is constructed out of simple counter, per RFC4106 section 3.1
Change-Id: Ib7712cc9612830daa737f5171d8384f1d361bb61
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: If96f661d507305da4b96cac7b1a8f14ba90676ad
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ia3474e5bfea5764eae9b2987bf78296535df6778
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I8977100d7a22b50260858bd1ea9db419b53284ff
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Id2ddb77b4ec3dd543d6e638bc882923f2bac011d
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ie42b26e6d5cdb7b23f370ea2933c65079e8d1089
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
hard code IV and key lengths based on cipher.
Init IV from random data, use AES instruction to rotate.
Change-Id: I13a6507d12267b823c528660a903787baeba47a0
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
A plugin to use Intel IPSec MB library as a VPP crypto engine
This changes uses concepts from:
https://gerrit.fd.io/r/#/c/17301/
hence that author's work is acknowledge below
Change-Id: I2bf3beeb10f3c9706fa5efbdc9bc023e310f5a92
Signed-off-by: Neale Ranns <nranns@cisco.com>
Signed-off-by: Klement Sekera <ksekera@cisco.com>
|
|
Change-Id: Iff6f81a49b9cff5522fbb4914d47472423eac5db
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Idb661261c2191adda963a7815822fd7a27a9e7a0
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ic1b657794d23cb4d1664fc749ad2468339e376df
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I63741a22bc82f5f861e1c0f26a93b5569cc52061
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I2018d8367bb010e1ab30d9c7c23d9501fc38a2e5
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ib828ea5106f3ae280e4ce233f2462dee363580b7
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I4d3ba18ab5205317219989de55b6e50d3b1d8a79
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I6527e3fd8bbbca2d5f728621fc66b3856b39d505
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I81ecdf9fdcfcb017117b47dc031f93208e004d7c
Signed-off-by: Damjan Marion <damarion@cisco.com>
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ibe7f806b9d600994e83c9f1be526fdb0a1ef1833
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ie8986bd3652d25c4befe681cea77df95aba37ebc
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ibf320b3e7b054b686f3af9a55afd5d5bda9b1048
Signed-off-by: Damjan Marion <damarion@cisco.com>
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Change-Id: I1e431aa36a282ca7565c6618a940d591674b8cd2
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
ipsec_proto_main moved to ipsec.c
fix missing '\0' of backend name
Change-Id: I90760b3045973a46792c2f098d9b0b1b3d209ad0
Signed-off-by: Kingwel Xie <kingwel.xie@ericsson.com>
|
|
1) stats are accessed via the stat segment which is more condusive to
monitoring
2) stats are accurate in the presence of multiple threads. There's no
guarantee that an SA is access from only one worker.
Change-Id: Id5e217ea253ddfc9480aaedb0d008dea031b1148
Signed-off-by: Neale Ranns <nranns@cisco.com>
|