aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/ipsec/ipsec_sa.h
AgeCommit message (Collapse)AuthorFilesLines
2023-10-30ipsec: huge anti-replay window supportMaxime Peim1-101/+278
Type: improvement Since RFC4303 does not specify the anti-replay window size, VPP should support multiple window size. It is done through a clib_bitmap. Signed-off-by: Maxime Peim <mpeim@cisco.com> Change-Id: I3dfe30efd20018e345418bef298ec7cec19b1cfc
2023-08-08ipsec: add support for RFC-4543 ENCR_NULL_AUTH_AES_GMACBenoît Ganne1-2/+11
Type: improvement Change-Id: I830f7a2ea3ac0aff5185698b9fa7a278c45116b0 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2023-06-23ipsec: manually binding an SA to a workerMaxime Peim1-0/+1
An SA is normally bound to the first thread using it. However, one could want to manually bind an SA to a specific worker. Type: improvement Signed-off-by: Maxime Peim <mpeim@cisco.com> Change-Id: I05cbbf753e44a01d9964ee47812c964db9bbb488
2023-03-23ipsec: make pre-shared keys harder to misuseBenoît Ganne1-57/+34
Using pre-shared keys is usually a bad idea, one should use eg. IKEv2 instead, but one does not always have the choice. For AES-CBC, the IV must be unpredictable (see NIST SP800-38a Appendix C) whereas for AES-CTR or AES-GCM, the IV should never be reused with the same key material (see NIST SP800-38a Appendix B and NIST SP800-38d section 8). If one uses pre-shared keys and VPP is restarted, the IV counter restarts at 0 and the same IVs are generated with the same pre-shared keys materials. To fix those issues we follow the recommendation from NIST SP800-38a and NIST SP800-38d: - we use a PRNG (not cryptographically secured) to generate IVs to avoid generating the same IV sequence between VPP restarts. The PRNG is chosen so that there is a low chance of generating the same sequence - for AES-CBC, the generated IV is encrypted as part of the message. This makes the (predictable) PRNG-generated IV unpredictable as it is encrypted with the secret key - for AES-CTR and GCM, we use the IV as-is as predictable IVs are fine Most of the changes in this patch are caused by the need to shoehorn an additional state of 2 u64 for the PRNG in the 1st cacheline of the SA object. Type: improvement Change-Id: I2af89c21ae4b2c4c33dd21aeffcfb79c13c9d84c Signed-off-by: Benoît Ganne <bganne@cisco.com>
2023-03-23ipsec: add per-SA error countersArthur de Kerhor1-1/+30
Error counters are added on a per-node basis. In Ipsec, it is useful to also track the errors that occured per SA. Type: feature Change-Id: Iabcdcb439f67ad3c6c202b36ffc44ab39abac1bc Signed-off-by: Arthur de Kerhor <arthurdekerhor@gmail.com>
2023-02-08ipsec: fix AES CBC IV generation (CVE-2022-46397)Benoît Ganne1-1/+1
For AES-CBC, the IV must be unpredictable (see NIST SP800-38a Appendix C). Chaining IVs like is done by ipsecmb and native backends for the VNET_CRYPTO_OP_FLAG_INIT_IV is fully predictable. Encrypt a counter as part of the message, making the (predictable) counter-generated IV unpredictable. Fixes: VPP-2037 Type: fix Change-Id: If4f192d62bf97dda553e7573331c75efa11822ae Signed-off-by: Benoît Ganne <bganne@cisco.com>
2022-12-16ipsec: new api for sa ips and ports updatesArthur de Kerhor1-0/+2
Useful to update the tunnel paramaters and udp ports (NAT-T) of an SA without having to rekey. Could be done by deleting and re-adding the SA but it would not preserve the anti-replay window if there is one. Use case: a nat update/reboot between the 2 endpoints of the tunnel. Type: feature Change-Id: Icf5c0aac218603e8aa9a008ed6f614e4a6db59a0 Signed-off-by: Arthur de Kerhor <arthurdekerhor@gmail.com>
2022-09-14ipsec: make chacha20-poly1305 available via APIVladimir Ratnikov1-13/+17
Type: feature Signed-off-by: Vladimir Ratnikov <vratnikov@netgate.com> Change-Id: I4e03f60f34acd7809ddc5a743650bedbb95b2e98
2021-11-19fib: Don't use [midchain] adjacencies to change an interface's feature arcNeale Ranns1-1/+2
Type: fix Using the adjacency to modify the interface's feature arc doesn't work, since there are potentially more than one adj per-interface. Instead have the interface, when it is created, register what the end node of the feature arc is. This end node is then also used as the interface's tx node (i.e. it is used as the adjacency's next-node). rename adj-midhcain-tx as 'tunnel-output', that's a bit more intuitive. There's also a fix in config string handling to: 1- prevent false sharing of strings when the end node of the arc is different. 2- call registered listeners when the end node is changed For IPSec the consequences are that one cannot provide per-adjacency behaviour using different end-nodes - this was previously done for the no-SA and an SA with no protection. These cases are no handled in the esp-encrypt node. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: If3a83d03a3000f28820d9a9cb4101d244803d084
2021-09-29ipsec: Record the number of packets lost from an SANeale Ranns1-14/+52
Type: feature Gaps in the sequence numbers received on an SA indicate packets that were lost. Gaps are identified using the anti-replay window that records the sequences seen. Publish the number of lost packets in the stats segment at /net/ipsec/sa/lost Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: I8af1c09b7b25a705e18bf82e1623b3ce19e5a74d
2021-06-29ipsec: Fix setting the hi-sequence number for decryptNeale Ranns1-46/+132
Type: fix two problems; 1 - just because anti-reply is not enabled doesn't mean the high sequence number should not be used. - fix, there needs to be some means to detect a wrapped packet, so we use a window size of 2^30. 2 - The SA object was used as a scratch pad for the high-sequence number used during decryption. That means that once the batch has been processed the high-sequence number used is lost. This means it is not possible to distinguish this case: if (seq < IPSEC_SA_ANTI_REPLAY_WINDOW_LOWER_BOUND (tl)) { ... if (post_decrypt) { if (hi_seq_used == sa->seq_hi) /* the high sequence number used to succesfully decrypt this * packet is the same as the last-sequnence number of the SA. * that means this packet did not cause a wrap. * this packet is thus out of window and should be dropped */ return 1; else /* The packet decrypted with a different high sequence number * to the SA, that means it is the wrap packet and should be * accepted */ return 0; } - fix: don't use the SA as a scratch pad, use the 'packet_data' - the same place that is used as the scratch pad for the low sequence number. other consequences: - An SA doesn't have seq and last_seq, it has only seq; the sequence numnber of the last packet tx'd or rx'd. - there's 64bits of space available on the SA's first cache line. move the AES CTR mode IV there. - test the ESN/AR combinations to catch the bugs this fixes. This doubles the amount of tests, but without AR on they only run for 2 seconds. In the AR tests, the time taken to wait for packets that won't arrive is dropped from 1 to 0.2 seconds thus reducing the runtime of these tests from 10-15 to about 5 sceonds. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: Iaac78905289a272dc01930d70decd8109cf5e7a5
2021-03-05ipsec: Support async mode per-SANeale Ranns1-1/+2
Type: feature This feautre only applies to ESP not AH SAs. As well as the gobal switch for ayncs mode, allow individual SAs to be async. If global async is on, all SAs are async. If global async mode is off, then if then an SA can be individually set to async. This preserves the global switch behaviour. the stratergy in the esp encrypt.decrypt nodes is to separate the frame into, 1) sync buffers, 2) async buffers and 3) no-op buffers. Sync buffer will undergo a cyrpto/ath operation, no-op will not, they are dropped or handed-off. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: Ifc15b10b870b19413ad030ce7f92ed56275d6791
2021-02-26ipsec: move the IPSec SA pool out of ipsec_mainNeale Ranns1-0/+12
Type: refactor this allows the ipsec_sa_get funtion to be moved from ipsec.h to ipsec_sa.h where it belongs. Also use ipsec_sa_get throughout the code base. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: I2dce726c4f7052b5507dd8dcfead0ed5604357df
2021-02-12ipsec: Store thread-index in buffer meta-data during SA handoffNeale Ranns1-0/+8
Type: improvement negates the need to load the SA in the handoff node. don't prefetch the packet data, it's not needed. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: I340472dc437f050cc1c3c11dfeb47ab09c609624
2021-02-10ipsec: Use the new tunnel API types to add flow label and TTL copyNeale Ranns1-23/+8
support Type: feature attmpet 2. this includes changes in ah_encrypt that don't use uninitialised memory when doing tunnel mode fixups. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: Ie3cb776f5c415c93b8a5ee22f22586fd0181110d
2021-02-09Revert "ipsec: Use the new tunnel API types to add flow label and TTL copy"Matthew Smith1-8/+23
This reverts commit c7eaa711f3e25580687df0618e9ca80d3dc85e5f. Reason for revert: The jenkins job named 'vpp-merge-master-ubuntu1804-x86_64' had 2 IPv6 AH tests fail after the change was merged. Those 2 tests also failed the next time that job ran after an unrelated change was merged. Change-Id: I0e2c3ee895114029066c82624e79807af575b6c0 Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2021-02-08ipsec: Use the new tunnel API types to add flow label and TTL copyNeale Ranns1-23/+8
support Type: feature Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: I6d4a9b187daa725d4b2cbb66e11616802d44d2d3
2021-02-05ipsec: add support for AES CTRBenoît Ganne1-16/+25
Type: feature Change-Id: I9f7742cb12ce30592b0b022c314b71c81fa7223a Signed-off-by: Benoît Ganne <bganne@cisco.com>
2021-02-04ipsec: one thread index per-SANeale Ranns1-2/+2
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
2020-11-02ipsec: Tunnel SA DSCP behaviourNeale Ranns1-1/+6
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-19ipsec: Layout and prefetching of SA structNeale Ranns1-26/+34
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-1/+1
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-05-05ipsec: User can choose the UDP source portNeale Ranns1-1/+1
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>
2020-04-30crypto: introduce async crypto infraFan Zhang1-3/+43
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-21ikev2: add support for custom ipsec-over-udp portFilip Tehlar1-1/+4
Type: feature Change-Id: Ifee2b3dca85ea915067b9285e3636802bf0c19a8 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2019-12-17ipsec: bind an SA to a workerNeale Ranns1-0/+14
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-11-08ipsec: remove dedicated IPSec tunnelsNeale Ranns1-0/+1
APIs for dedicated IPSec tunnels will remain in this release and are used to programme the IPIP tunnel protect. APIs will be removed in a future release. see: https://wiki.fd.io/view/VPP/IPSec Type: feature Change-Id: I0f01f597946fdd15dfa5cae3643104d5a9c83089 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-07-31ipsec: Typo in flag nameNeale Ranns1-1/+1
Type: fix Change-Id: I0c9353598d3c9b7ea587ea8a2b6e1faa5454843d Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-07-24ipsec: GCM, Anti-replay and ESN fixessNeale Ranns1-26/+103
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: Reference count the SAsNeale Ranns1-18/+16
- this remove the need to iterate through all state when deleting an SA - and ensures that if the SA is deleted by the client is remains for use in any state until that state is also removed. Type: feature Change-Id: I438cb67588cb65c701e49a7a9518f88641925419 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-06-18ipsec: ipsec-tun protectNeale Ranns1-1/+9
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-4/+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-07ipsec: remove the set_key APINeale Ranns1-2/+0
there's no use case to just change the key of an SA. instead the SA should be renegociated and the new SA applied to the existing SPD entry or tunnel. the set_key functions were untested. Type: refactor Change-Id: Ib096eebaafb20be7b5501ece5a24aea038373002 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-05-14IPSEC: remove unecessary pass by reference of sequence numberNeale Ranns1-2/+2
Change-Id: Id406eb8c69a89c57305d8f138e8e6730037aa799 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-04-26crypto, ipsec: change GCM IV handlingDamjan Marion1-0/+1
- 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-25IPSEC; dpdk backend for tunnel interface encryptionNeale Ranns1-1/+0
Change-Id: Ide2a9df18db371c8428855d7f12f246006d7c04c Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-04-25crypto: improve key handlingDamjan Marion1-3/+7
Change-Id: If96f661d507305da4b96cac7b1a8f14ba90676ad Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-04-17IPSEC: Pass the algorithm salt (used in GCM) over the APINeale Ranns1-2/+2
Change-Id: Ia8cea13f7b937294e6a080a55fb2ceff30063acf Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-04-16IPSEC: support GCM in ESPNeale Ranns1-0/+7
Change-Id: Id2ddb77b4ec3dd543d6e638bc882923f2bac011d Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-04-07crypto: add support for AEAD and AES-GCMDamjan Marion1-3/+3
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: tunnel scaling - don't stack the inbould SANeale Ranns1-0/+1
Change-Id: I0b47590400aebea09aa1b27de753be638e1ba870 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-03-29IPSEC-GRE: fixes and API update to common types.Neale Ranns1-0/+1
Change-Id: Icdcbac7453baa837a9c0c4a2401dff4a6aa6cba0 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-03-28ipsec: USE_EXTENDED_SEQ_NUM -> USE_ESNDamjan Marion1-3/+3
Change-Id: Ib828ea5106f3ae280e4ce233f2462dee363580b7 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-03-28ipsec: anti-replay code cleanupDamjan Marion1-1/+129
Change-Id: Ib73352d6be26d639a7f9d47ca0570a1248bff04a Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-03-27ipsec: compress ipsec_sa_t so data used by dataplane code fits in cachelineDamjan Marion1-23/+51
Change-Id: I81ecdf9fdcfcb017117b47dc031f93208e004d7c Signed-off-by: Damjan Marion <damarion@cisco.com> Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-03-26ipsec: esp-encrypt reworkDamjan Marion1-0/+3
Change-Id: Ibe7f806b9d600994e83c9f1be526fdb0a1ef1833 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-03-20ipsec: keep crypto data inside SADamjan Marion1-0/+10
Change-Id: Ie8986bd3652d25c4befe681cea77df95aba37ebc Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-02-18IPSEC: move SA counters into the stats segmentNeale Ranns1-3/+7
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>
2019-02-13IPSEC: restack SAs on backend changeNeale Ranns1-0/+4
Change-Id: I5852ca02d684fa9d59e1690efcaca06371c5faff Signed-off-by: Neale Ranns <nranns@cisco.com>