summaryrefslogtreecommitdiffstats
path: root/src/vnet/ipsec/esp_encrypt.c
AgeCommit message (Collapse)AuthorFilesLines
2021-02-08tunnel: support copying TTL and flow label from inner to outerNeale Ranns1-5/+4
Type: feature The added functionality is to support copying TTL and flow label from inner to outer. The .api was extened to support expressing this and also adding a common tunnel endpoint type. i find it best to make API changes in one patch so there are less versions of the API. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: I755c1e3f4c475058792af39c1abeda92129efb76
2021-02-05ipsec: add support for AES CTRBenoît Ganne1-71/+76
Type: feature Change-Id: I9f7742cb12ce30592b0b022c314b71c81fa7223a Signed-off-by: Benoît Ganne <bganne@cisco.com>
2021-02-04ipsec: one thread index per-SANeale Ranns1-3/+3
Type: improvement AN SA is uni-drectional therefore it can be used only for encrypt or decrypt, not both. So it only needs one thread ID. free up some space on the 1st cacheline. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: I21cb7cff70a763cbe2bffead860b574bc80b3136
2021-01-21ipsec: Tunnelled packets are locally generatedNeale Ranns1-0/+1
Type: fix this means we 1) don't decrement TTL and (for v6) can fragment. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: I0f718da7dcaba834ad495ae9242a9a58c9e7c184
2021-01-18ipsec: Support MPLS over IPSec[46] interfaceNeale Ranns1-37/+114
Type: feature Signed-off-by: Neale Ranns <nranns@cisco.com> Change-Id: I89dc3815eabfee135cd5b3c910dea5e2e2ef1333
2020-12-01ipsec: change predictionFan Zhang1-1/+1
Type: improvement This patch changes the prediction of the comparison between SA owner thread index and the current thread index. Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com> Change-Id: I48de0bb2c57dbb09cfab63925bf8dc96613d8bcf
2020-11-02ipsec: Tunnel SA DSCP behaviourNeale Ranns1-6/+33
Type: feature - use tunnel_encap_decap_flags to control the copying of DSCP/ECN/etc during IPSEC tunnel mode encap. - use DSCP value to have fixed encap value. Signed-off-by: Neale Ranns <nranns@cisco.com> Change-Id: If4f51fd4c1dcbb0422aac9bd078e5c14af5bf11f
2020-10-24ipsec: remove pending nodeFan Zhang1-58/+54
This patch removes esp-encrypt-pending and esp-decrypt-pending graph nodes from ipsec data-path. Type: improvement Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com> Change-Id: Icd90837eafdbfbfdf348681dcafb872593978980
2020-10-21misc: minimize dependencies on udp.hFlorin Coras1-1/+0
Type: improvement Signed-off-by: Florin Coras <fcoras@cisco.com> Change-Id: Id13f33843b230a1d169560742c4f7b2dc17d8718
2020-10-19ipsec: Layout and prefetching of SA structNeale Ranns1-0/+7
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
2020-09-07ipsec: fix padding/alignment for native IPsec encryptionChristian Hopps1-6/+6
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
2020-08-20ipsec: fix esp paddingMilan Lenco1-1/+1
Type: fix Signed-off-by: Milan Lenco <milan.lenco@pantheon.tech> Change-Id: Ic8db52b41d7e5af3425099f008984e50afb3da74
2020-05-24ipsec: fixed chaining ops after add footer and icvPiotrX Kleski1-8/+11
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
2020-05-13ipsec: Support 4o6 and 6o4 for SPD tunnel mode SAsNeale Ranns1-34/+42
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
2020-05-04fib: midchain adjacency optimisationsNeale Ranns1-68/+11
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>
2020-04-30crypto: introduce async crypto infraFan Zhang1-134/+537
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
2020-03-31ipsec: fix chained ESPFilip Tehlar1-14/+25
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>
2020-03-31ipsec: fix udp-encap in transport modeAlexander Chernavin1-1/+7
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>
2020-03-23ipsec: Revert "ipsec: fix chained ESP"Florin Coras1-25/+14
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>
2020-03-23ipsec: fix chained ESPFilip Tehlar1-14/+25
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>
2020-02-25feature: provide a u16 version of vnet_feature_nextNeale Ranns1-3/+1
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
2020-02-21ipsec: IPSec protection for multi-point tunnel interfacesNeale Ranns1-5/+6
Type: feature Signed-off-by: Neale Ranns <nranns@cisco.com> Change-Id: Iaba2ab11bfaa1c8db4023434e3043ac39500f938
2020-02-11ipsec: add support for chained buffersFilip Tehlar1-22/+161
Type: feature Change-Id: Ie072a7c2bbb1e4a77f7001754f01897efd30fc53 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2020-01-04ipsec: Targeted unit testingNeale Ranns1-11/+23
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
2019-12-23ipsec: Test and fix IPSec worker hand-offNeale Ranns1-2/+2
Type: fix Change-Id: I5cb9a3845ddbc5f4de4eb4e9c481f606fe5cec9a Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-12-17ipsec: bind an SA to a workerNeale Ranns1-11/+35
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>
2019-12-09ipsec: make sure pad_bytes does not exceed pad data sizeBenoît Ganne1-1/+5
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>
2019-11-22ipsec: fix trailing data overflowFilip Tehlar1-23/+21
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>
2019-09-27ipsec: support 4o6 and 6o4 for tunnel protectNeale Ranns1-0/+15
Type: feature Change-Id: Ib2352ca4c7abf4645f21fa16aaaf27408890a2bf Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-07-24ipsec: GCM, Anti-replay and ESN fixessNeale Ranns1-3/+6
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>
2019-07-12ipsec: drop outbound ESP when no crypto alg setMatthew Smith1-0/+131
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>
2019-06-25ipsec: print spi in hexadecimalGuillaume Solignac1-5/+6
Print the SPI in hexadecimal and decimal. Type: feature Change-Id: I012e94f9147058064e06c6bb4622ab6b6507957d Signed-off-by: Guillaume Solignac <gsoligna@cisco.com>
2019-06-18ipsec: ipsec-tun protectNeale Ranns1-6/+20
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>
2019-06-17ipsec: One DPO per SANeale Ranns1-1/+1
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>
2019-06-05ipsec: fix sa counters in esp-encryptDamjan Marion1-4/+7
Type: fix Fixes: c59b9a2 Change-Id: I6021e67196a4d31ab11d4e3cfbda34b678150701 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-05-01esp_encrypt: remove unnecessary codeZhiyong Yang1-1/+1
Change-Id: I2d7e873fca6ab266af75814fac5d4cb5cda93cef Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com>
2019-04-26crypto, ipsec: change GCM IV handlingDamjan Marion1-3/+20
- 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>
2019-04-25crypto: improve key handlingDamjan Marion1-3/+2
Change-Id: If96f661d507305da4b96cac7b1a8f14ba90676ad Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-04-19IPSEC: IPv6 ESP transport mode incorrect packet length and checksum (VPP-1654)Neale Ranns1-7/+14
Change-Id: Ia3474e5bfea5764eae9b2987bf78296535df6778 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-04-19IPSEC: ESP IPv6 transport mode payload length incorrect (VPP-1653)Neale Ranns1-1/+3
Change-Id: I8977100d7a22b50260858bd1ea9db419b53284ff Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-04-16IPSEC: support GCM in ESPNeale Ranns1-0/+15
Change-Id: Id2ddb77b4ec3dd543d6e638bc882923f2bac011d Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-04-11IPSEC: ESP with ESN tests and fixesNeale Ranns1-1/+1
Change-Id: Ie42b26e6d5cdb7b23f370ea2933c65079e8d1089 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-04-11IPSEC-MB: Use random & non-repeating IV (VPP-1642)Neale Ranns1-2/+0
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>
2019-04-10crypto: Intel IPSEC-MB engineNeale Ranns1-0/+2
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>
2019-04-07crypto: add support for AEAD and AES-GCMDamjan Marion1-7/+6
Change-Id: Iff6f81a49b9cff5522fbb4914d47472423eac5db Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-04-04ipsec: trunc_size -> icv_sizeDamjan Marion1-1/+1
Change-Id: Idb661261c2191adda963a7815822fd7a27a9e7a0 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-04-02IPSEC: remove pointless feature orderingNeale Ranns1-4/+2
Change-Id: Ic1b657794d23cb4d1664fc749ad2468339e376df Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-03-29IPSEC: tunnel fragmentationNeale Ranns1-0/+10
Change-Id: I63741a22bc82f5f861e1c0f26a93b5569cc52061 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-03-28crypto: add vnet_crypto_op_init (...)Damjan Marion1-3/+2
Change-Id: I2018d8367bb010e1ab30d9c7c23d9501fc38a2e5 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-03-28ipsec: USE_EXTENDED_SEQ_NUM -> USE_ESNDamjan Marion1-1/+1
Change-Id: Ib828ea5106f3ae280e4ce233f2462dee363580b7 Signed-off-by: Damjan Marion <damarion@cisco.com>