aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/ipsec/esp_encrypt.c
AgeCommit message (Collapse)AuthorFilesLines
2023-03-23ipsec: make pre-shared keys harder to misuseBenoît Ganne1-11/+9
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-24/+38
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-26/+62
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-10-12misc: fix issues reported by clang-15Damjan Marion1-4/+2
Type: improvement Change-Id: I3fbbda0378b72843ecd39a7e8592dedc9757793a Signed-off-by: Damjan Marion <dmarion@me.com>
2022-08-19ipsec: enable UDP encap for IPv6 ESP tun protectMatthew Smith1-13/+11
Type: improvement If an SA protecting an IPv6 tunnel interface has UDP encapsulation enabled, the code in esp_encrypt_inline() inserts a UDP header but does not set the next protocol or the UDP payload length, so the peer that receives the packet drops it. Set the next protocol field and the UDP payload length correctly. The port(s) for UDP encapsulation of IPsec was not registered for IPv6. Add this registration for IPv6 SAs when UDP encapsulation is enabled. Add punt handling for IPv6 IKE on NAT-T port. Add registration of linux-cp for the new punt reason. Add unit tests of IPv6 ESP w/ UDP encapsulation on tun protect Signed-off-by: Matthew Smith <mgsmith@netgate.com> Change-Id: Ibb28e423ab8c7bcea2c1964782a788a0f4da5268
2022-08-11ipsec: Use .api declared error countersNeale Ranns1-45/+23
Type: improvement Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: Ica7de5a493389c6f53b7cf04e06939473a63d2b9
2022-03-10ipsec: remove the redundant codeMohsin Kazmi1-1/+0
Type: refactor Change-Id: I0a40e22e1439e13ffdbcbd6fd7cad40c8178418c Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2021-12-04ipsec: fix async buffer leakMatthew Smith1-1/+1
Type: fix Fixes: f16e9a5507 If an attempt to submit an async crypto frame fails, the buffers that were added to the frame are supposed to be dropped. This was not happening and they are leaking, resulting in buffer exhaustion. There are two issues: 1. The return value of esp_async_recycle_failed_submit() is used to figure out how many buffers should be dropped. That function calls vnet_crypto_async_reset_frame() and then returns f->n_elts. Resetting the frame sets n_elts to 0. So esp_async_recycle_failed_submit() always returns 0. It is safe to remove the call to reset the frame because esp_async_recycle_failed_submit() is called in 2 places and a call to reset the frame is made immediately afterwards in both cases - so it is currently unnecessary anyway. 2. An array and an index are passed to esp_async_recycle_failed_submit(). The index should indicate the position in the array where indices of the buffers contained in the frame should be written. Across multiple calls, the same index value (n_sync) is passed. This means each call may overwrite the same entries in the array with the buffer indices in the frame rather than appending them to the entries which were written earlier. Pass n_noop as the index instead of n_sync. Change-Id: I525ab3c466965446f6c116f4c8c5ebb678a66d84 Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2021-12-03ip: extension header parsing fails for fragment headerOle Troan1-3/+14
Refactor and improve boundary checking on IPv6 extension header handling. Limit parsing of IPv6 extension headers to a maximum of 4 headers and a depth of 256 bytes. Type: fix Signed-off-by: Ole Troan <ot@cisco.com> Change-Id: Ide40aaa2b482ceef7e92f02fa0caeadb3b8f7556 Signed-off-by: Ole Troan <ot@cisco.com>
2021-11-19fib: Don't use [midchain] adjacencies to change an interface's feature arcNeale Ranns1-125/+37
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-10-31ipsec: silence gcc-11 parentheses warningDamjan Marion1-1/+1
Type: fix This reverts commit 5ecda99d673298e5bf3c906e9bf6682fdcb57d83. Change-Id: I393c7d8a6b32aa4f178d6b6dac025038bbf10fe6 Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-07-15misc: replace CLIB_PREFETCH with clib_prefetch_{load,store}Damjan Marion1-3/+3
Type: refactor Change-Id: Id10cbf52e8f2dd809080a228d8fa282308be84ac Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-06-29ipsec: Fix setting the hi-sequence number for decryptNeale Ranns1-8/+8
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-06-15ipsec: fix length check when adding footer+icvBenoît Ganne1-1/+2
Length check must also take current_data into account. Type: fix Change-Id: I7a1b1752868892d40f59490d05452ef24565cca6 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2021-06-08ipsec: fix async crypto frame leakMatthew Smith1-20/+19
Type: fix If an async crypto frame is allocated during ESP encrypt/decrypt but a buffer/op is not subsequently added to the frame, the frame leaks. It is not submitted if the count of async ops is zero nor is it returned to the frame pool. This happens frequently if >= 2 worker threads are configured and a vector of buffers all have to be handed off to other threads. Wait until it is almost certain that the buffer will be added to the frame before allocating the frame to make it more unlikely that an allocated frame will not have any operations added to it. For encrypt this is sufficient to ressolve the leak. For decrypt there is still a chance that the buffer will fail to be added to the frame, so remove the counter of async ops and ensure that all frames that were allocated get either submitted or freed at the end. Change-Id: I4778c3265359b192d8a88ab9f8c53519d46285a2 Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2021-03-05ipsec: Support async mode per-SANeale Ranns1-85/+96
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-03-05ipsec: Submit fuller async framesNeale Ranns1-65/+58
Type: improvement In the current scheme an async frame is submitted each time the crypto op changes. thus happens each time a different SA is used and thus potentially many times per-node. thi can lead to the submision of many partially filled frames. change the scheme to construct as many full frames as possible in the node and submit them all at the end. the frame owner ship is passed to the user so that there can be more than one open frame per-op at any given time. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: Ic2305581d7b5aa26133f52115e0cd28ba956ed55
2021-02-26ipsec: move the IPSec SA pool out of ipsec_mainNeale Ranns1-1/+1
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-25ipsec: ipsec.h tidy upNeale Ranns1-0/+25
Type: refactor - remove the extern declaration of the nodes. keep the use of them to the files that declare them - remove duplicate declaration of ipsec_set_async_mode - remove unsued ipsec_add_feature Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: I6ce7bb4517b508a8f02b11f3bc819e1c5d539c02
2021-02-12ipsec: Store thread-index in buffer meta-data during SA handoffNeale Ranns1-0/+1
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-0/+1
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-1/+0
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-0/+1
support Type: feature Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: I6d4a9b187daa725d4b2cbb66e11616802d44d2d3
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>