summaryrefslogtreecommitdiffstats
path: root/src/vnet/ipsec
AgeCommit message (Collapse)AuthorFilesLines
2023-12-12ipsec: allow receiving encrypted IP packets with TFC paddingArthur de Kerhor1-4/+42
Type: feature Change-Id: I7b29c71d3d053af9a53931aa333484bf43a424ca Signed-off-by: Arthur de Kerhor <arthurdekerhor@gmail.com> Signed-off-by: Benoît Ganne <bganne@cisco.com>
2023-12-01ipsec: should use praddr_ instead of pladdr_Dengfeng Liu1-1/+1
Type: fix Change-Id: I982ef624226807d7c263e3ff83c108f7d31f61f1 Signed-off-by: Dengfeng Liu <liudf0716@gmail.com>
2023-11-17ipsec: keep esp encrypt pointer and index syncedMatthew Smith1-1/+1
Type: fix In esp_encrypt_inline(), an index and pointer to the last processed SA are stored. If the next packet uses the same SA, we defer on updating counters until a different SA is encountered. The pointer was being retrieved, then the SA was checked to see if the packet should be dropped due to no crypto/integ algs, then the index was updated. If the check failed, we would skip further processing and now the pointer refers to a different SA than the index. When you have a batch of packets that are encrypted using an SA followed by a packet which is dropped for no algs and then more packets to be encrypted using the original SA, the packets that arrive after the one that was dropped end up being processed using a pointer that refers to the wrong SA data. This can result in a segv. Update the current_sa_index at the same time that the sa0 pointer is updated. Signed-off-by: Matthew Smith <mgsmith@netgate.com> Change-Id: I65f1511a37475b4f737f5e1b51749c0a30e88806
2023-11-09ipsec: IPsec fix constant propagationMaxime Peim1-2/+3
In some anti-replay, some functions weren't using the boolean telling if the window was huge or not. Hence, limiting the constant propagation at compilation. Type: fix Change-Id: Ie5f2dda38339bb32113c6f7b2b82c82135fc92a8 Signed-off-by: Maxime Peim <mpeim@cisco.com>
2023-11-06ipsec: delete redundant codeDengfeng Liu1-4/+0
Type: fix Change-Id: I0de1c51455b0d3958c75ab5626a318ac656adbe7 Signed-off-by: Dengfeng Liu <liudf0716@gmail.com>
2023-10-31ipsec: separate UDP and UDP-encapsulated ESP packet processingvinay tripathi1-8/+33
This fix differentiates UDP and UDP-encapsulated ESP packets processing. While UDP-encapsulated ESP traffic is processed as IPsec traffic, UDP as other plain-text protocols is NOT dispatched against SPD policies. Key logic is taken from RFC 3948, and is based on the fact that the checksum of UDP packet encapsulating ESP packet must be zero. Type: fix Signed-off-by: vinay tripathi <vinayx.tripathi@intel.com> Change-Id: Ib1b4d240eea8e89f2daf17ec833905f26cdb31bd
2023-10-31ipsec: move udp/esp packet processing in the inline function ↵vinay tripathi1-174/+181
ipsec_esp_packet_process This inline function is introduced to simplify code readability and allows to splitting of UDP and ESP processing in the next step. Type: improvement Change-Id: Ida4d6abbed141ac74d4d285900777778eb8a5a1d Signed-off-by: Vinay Tripathi <vinayx.tripathi@intel.com>
2023-10-30ipsec: huge anti-replay window supportMaxime Peim10-168/+680
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-09-12ipsec: improve fast path policy searching performanceXiaoming Jiang2-35/+59
Type: improvement Signed-off-by: Xiaoming Jiang <jiangxiaoming@outlook.com> Change-Id: Ib8bb300f5b62648f6b634046415742bdf5365982
2023-09-07ipsec: clear L4-cksum flags when decap'ing packetsFrédéric Perrin2-1/+5
Type: fix Signed-off-by: Frédéric Perrin <fred@fperrin.net> Change-Id: I45191b7316c88038bcd57d62aeb07bb109cf4a4d
2023-08-08ipsec: add support for RFC-4543 ENCR_NULL_AUTH_AES_GMACBenoît Ganne6-3/+70
Type: improvement Change-Id: I830f7a2ea3ac0aff5185698b9fa7a278c45116b0 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2023-07-31ipsec: fix IPv6 IPsec tunnel puntingSylvain Cadilhac1-0/+1
Type: fix Buffer needs to be rewinded before being passed to punt-dispatch node. Change-Id: I43d103515d372e425f4c3b08ca1779398f1fced4 Signed-off-by: Sylvain Cadilhac <sylvain.cadilhac@freepro.com>
2023-07-27ipsec: fix sa bind cliMaxime Peim1-1/+1
Small mistake was made, reported by coverty scan. Type: fix Change-Id: I98ca16c0275a94b2def99831f9353d4ff3fe93a9 Signed-off-by: Maxime Peim <mpeim@cisco.com>
2023-07-21ipsec: fix logic in ext_hdr_is_pre_espPiotr Bronowski1-3/+3
When _VEC128 instructions are not enabled logic is buggy. The function always returned 1. Type: fix Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I603200637e8d65813f4e49ef15d798e74b79b9cf
2023-07-06api: ipsec - Mark old message versions as deprecatedOndrej Fabry1-0/+12
List of changed messages: - ipsec_sad_entry_add_del_v2 - ipsec_sad_entry_add_del_v2_reply - ipsec_sa_v2_dump - ipsec_sa_v2_details This change is part of VPP API cleanup initiative. Type: fix Signed-off-by: Ondrej Fabry <ofabry@cisco.com> Change-Id: I8fd6906e9684ef7ebc0688dc8b0637ae2dc8d0a2
2023-06-23ipsec: manually binding an SA to a workerMaxime Peim6-6/+272
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-06-08crypto: use fixed crypto frame poolgaoginskx3-0/+31
The async frames pool may be resized once drained. This will cause 2 problems: original pool pointer is invalidated and pool size changed, both problems will confuse the crypto infra user graph nodes (like IPsec and Wireguard) and crypto engines if they expect the pool pointers always valid and the pool size never changed (for performance reason). This patch introduces fixed size of the async frames pool. This helps zeroing surprise to the components shown above and avoiding segmentation fault when pool resizing happened. In addition, the crypto engine may take advantage of the feature to sync its own pool/vector with crypto infra. Type: improvement Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com> Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I2a71783b90149fa376848b9c4f84ce8c6c034bef
2023-06-01crypto: make crypto-dispatch node working in adaptive modeXiaoming Jiang3-29/+3
This patch can make crypto dispatch node adaptively switching between pooling and interrupt mode, and improve vpp overall performance. Type: improvement Signed-off-by: Xiaoming Jiang <jiangxiaoming@outlook.com> Change-Id: I845ed1d29ba9f3c507ea95a337f6dca7f8d6e24e
2023-05-29ipsec: fix ipsec_set_next_index set with wrong sa index when async frame ↵Xiaoming Jiang3-27/+39
commit failed Type: fix Signed-off-by: Xiaoming Jiang <jiangxiaoming@outlook.com> Change-Id: Ib4c61906a9cbb3eea1214394d164ecffb38fd36d
2023-03-23ipsec: make pre-shared keys harder to misuseBenoît Ganne8-137/+122
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 Kerhor11-115/+337
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-03-20ipsec: set fast path 5tuple ip addresses based on sa traffic selector valuesPiotr Bronowski1-4/+35
Previously, even if sa defined traffic selectors esp packet src and dst have been used for fast path inbound spd matching. This patch provides a fix for that issue. Type: fix Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: Ibd3ca224b155cc9e0c6aedd0f36aff489b7af5b8
2023-02-08ipsec: fix AES CBC IV generation (CVE-2022-46397)Benoît Ganne2-27/+63
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>
2023-02-06ipsec: fix async crypto linked keys memory leakBenoît Ganne1-1/+6
Type: fix Change-Id: I7bd2696541c8b3824837e187de096fdde19b2c44 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2023-01-16ipsec: fix transpose local ip range position with remote ip range in fast ↵Piotr Bronowski2-13/+13
path implementation In fast path implementation of spd policy lookup opposite convention to the original implementation has been applied and local ip range has been interchanged with the remote ip range. This fix addresses this issue. Type: fix Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I0b6cccc80bf52b34524e98cfd1f1d542008bb7d0
2022-12-16ipsec: new api for sa ips and ports updatesArthur de Kerhor5-0/+186
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-11-29ipsec: use correct reply messageVratko Polak2-1/+2
Type: fix Fixes: 815c6a4fbcbb636ce3b4dc98446ad205a30670a6 Ticket: VPP-2068 Change-Id: I42d678b0e28ac4d0b524dfc2dbd01bbad020cf24 Signed-off-by: Vratko Polak <vrpolak@cisco.com>
2022-11-28ipsec: remove redundant policy array in fast path spdPiotr Bronowski3-90/+178
Fast path spd was explicitely storing array of policy id vectors. This information was redundand, as this inofrmation is already stored in bihash table. This additional array was affecting performance when adding and removing fast path policies. The other place that needed refactoring after removing this array was cli command showing fast path policies. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I78d45653f71539e7ba90ff5d2834451f83ead4be
2022-11-21ipsec: improve ipsec policy adding performanceXiaoming Jiang1-19/+15
Type: improvement Signed-off-by: jiangxiaoming <jiangxiaoming@outlook.com> Change-Id: I91ba1ff4c1085f4aca60ca111cbbaf14a3b4d761
2022-11-18ipsec: Failure at the start of the batch should not invalidate the rest of ↵Neale Ranns1-1/+1
the batch Type: fix Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: Icd1e43a5764496784c355c93066273435f16dd35
2022-10-12misc: fix issues reported by clang-15Damjan Marion2-6/+3
Type: improvement Change-Id: I3fbbda0378b72843ecd39a7e8592dedc9757793a Signed-off-by: Damjan Marion <dmarion@me.com>
2022-09-21ipsec: introduce fast path ipv6 inbound matchingPiotr Bronowski4-55/+197
This patch introduces fast path matching for inbound traffic ipv6. Fast path uses bihash tables in order to find matching policy. Adding and removing policies in fast path is much faster than in current implementation. It is still new feature and further work needs and can be done in order to improve the perfromance. Type: feature Change-Id: Iaef6638033666ad6eb028ffe0c8a4f4374451753 Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com>
2022-09-14ipsec: make chacha20-poly1305 available via APIVladimir Ratnikov4-14/+27
Type: feature Signed-off-by: Vladimir Ratnikov <vratnikov@netgate.com> Change-Id: I4e03f60f34acd7809ddc5a743650bedbb95b2e98
2022-09-12ipsec: introduce fast path ipv4 inbound matchingPiotr Bronowski9-164/+628
This patch introduces fast path matching for inbound traffic ipv4. Fast path uses bihash tables in order to find matching policy. Adding and removing policies in fast path is much faster than in current implementation. It is still new feature and further work needs and can be done in order to improve perfromance. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: Ifbd5bfecc21b76ddf8363f5dc089d77595196675
2022-08-31ipsec: fix coverity 249212Andrew Yourtchenko1-2/+2
zero-initialize the variables Type: fix Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com> Change-Id: I51c3856865eab037f646a0d184e82ecb3b5b3216
2022-08-24ipsec: fix coverity 249204Andrew Yourtchenko1-1/+1
Zero-initialize the temporary struct, else coverity complains about a bunch of uninitialized fields. Type: fix Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com> Change-Id: I45dc42134f06917a7459d615804f978a175bec0f
2022-08-19ipsec: enable UDP encap for IPv6 ESP tun protectMatthew Smith7-49/+95
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 Ranns6-179/+336
Type: improvement Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: Ica7de5a493389c6f53b7cf04e06939473a63d2b9
2022-08-02ipsec: fix coverity warnings found in fast path implementationPiotr Bronowski2-14/+15
This patch fixes followig coverity issues: CID 274739 Out-of-bounds read CID 274746 Out-of-bounds access CID 274748 Out-of-bounds read Type: fix Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I9bb6741f100a9414a5a15278ffa49b31ccd7994f
2022-07-15ipsec: fast path outbound policy matching implementation for ipv6Piotr Bronowski8-171/+227
With this patch fast path for ipv6 policy lookup is enabled. This impelentation scales and outperforms original implementation when the number of defined flows is higher thatn 100k. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I9364b5b8db4fc708790d48c538add272c7cea400
2022-06-29ipsec: show fast path flag in cliFan Zhang1-8/+27
This patch updates the "show ipsec spd" cli to display policies maintained by fast path bihash table. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I58b9f92f3132dc9809b50786dc912e09c4b84d81
2022-06-29ipsec: add fast path configuration parserPiotr Bronowski1-2/+19
Parser can be configured from the level of startup.conf file: fast path can be enabled and disabled. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: Ifab83ddcb75bc44c8165e7fa87a1a56d047732a1
2022-06-29ipsec: add spd fast path matchingPiotr Bronowski3-0/+584
This patch adds matching functionality for spd fast path policy matching. Fast path matching has been introduced for outbound traffic only. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I03d5edf7d7fbc03bf3e6edbe33cb15bc965f9d4e
2022-06-29ipsec: make match function inlinePiotr Bronowski2-145/+171
This patch introduces ipsec_output.h file. Matching implementation is moved there. The reason behind is the possibility of unit testing matching mechanism. Therefore we need to have functions that are in scope of our intrest there and since these are inline their implementation needs to be moved to the header file as well. Type: improvement Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: Id7c605375d1f3be146abf96ef70d336a5d156444
2022-06-29ipsec: add/delete ipsec fast path policyPiotr Bronowski6-59/+717
This patch introduces functions to add and delete fast path policies. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I3f1f1323148080c9dac531fbe9fa33bad4efe814
2022-06-28ipsec: introduce spd fast path typesPiotr Bronowski1-0/+63
This patch introdcues basic types supporting fast path lookup. Fast path performs policy matching with use of hash lookup (particularly bihash tries has been used for that purpose). Fast path lookup addresses situation where huge number of policies is created (~100k or more). In such scenario adding/removing a policy and policy matching is not efficient and poorly scales (for example adding 500k policies takes a few hours. Also lookup time increases significantly). With fast path adding and matching up to 1M flows scales up linearly (adding 1M of policies takes about 150s on the test machine vs many hours in case of original implementation, also matching time is significantly improved). Fast path will not deal well with a huge number of policies that are spanning large ip/port ranges. Large range will be masked out almost entirely leaving only a few bits for calculating the hash key. Such keys will tend to gather much more policies than other keys and hash will match most of the packets anihilating advantages of hashing. Having said that we also think that it is not the real life scenario. Type: feature Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I600dae5111a37768ed4b23aa18426e66bbf7b529
2022-06-28ipsec: change wildcard value for any protocol of spd policyPiotr Bronowski8-58/+300
Currently 0 has been used as the wildcard representing ANY type of protocol. However 0 is valid value of ip protocol (HOPOPT) and therefore it should not be used as a wildcard. Instead 255 is used which is guaranteed by IANA to be reserved and not used as a protocol id. Type: improvement Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Change-Id: I2320bae6fe380cb999dc5a9187beb68fda2d31eb
2022-05-13vlib: process startup config exec scripts line by lineDamjan Marion1-1/+1
This fixes long standing annoyance that CLIs with optional args cannot be executed from file, as they cannot distinguish between valid optional args and next line in the file. Multiline statements can be provided simply by using backslash before \n. Also comments are supported - everything after # is ignored up to the end of the line. Example: # multiline cli using backslash show version \ verbose # end of line comment packet-generator new { \ name x \ limit 5 \ # comment inside cmultiline cli \ size 128-128 \ interface local0 \ node null-node \ data { \ incrementing 30 \ } \ } Type: fix Change-Id: Ia6d588169bae14e6e3f18effe94820d05ace1dbf Signed-off-by: Damjan Marion <damarion@cisco.com>
2022-05-03ipsec: support per next-header next-nodesBenoît Ganne3-36/+100
Type: feature Change-Id: I940b6c9d206e407f3e17d66c97233cd658984e61 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2022-04-14ipsec: perf improvement of ipsec4_input_node using flow cacheZachary Leaf8-54/+311
Adding flow cache support to improve inbound IPv4/IPSec Security Policy Database (SPD) lookup performance. By enabling the flow cache in startup conf, this replaces a linear O(N) SPD search, with an O(1) hash table search. This patch is the ipsec4_input_node counterpart to https://gerrit.fd.io/r/c/vpp/+/31694, and shares much of the same code, theory and mechanism of action. Details about the flow cache: Mechanism: 1. First packet of a flow will undergo linear search in SPD table. Once a policy match is found, a new entry will be added into the flow cache. From 2nd packet onwards, the policy lookup will happen in flow cache. 2. The flow cache is implemented using a hash table without collision handling. This will avoid the logic to age out or recycle the old flows in flow cache. Whenever a collision occurs, the old entry will be overwritten by the new entry. Worst case is when all the 256 packets in a batch result in collision, falling back to linear search. Average and best case will be O(1). 3. The size of flow cache is fixed and decided based on the number of flows to be supported. The default is set to 1 million flows, but is configurable by a startup.conf option. 4. Whenever a SPD rule is added/deleted by the control plane, all current flow cache entries will be invalidated. As the SPD API is not mp-safe, the data plane will wait for the control plane operation to complete. Cache invalidation is via an epoch counter that is incremented on policy add/del and stored with each entry in the flow cache. If the epoch counter in the flow cache does not match the current count, the entry is considered stale, and we fall back to linear search. The following configurable options are available through startup conf under the ipsec{} entry: 1. ipv4-inbound-spd-flow-cache on/off - enable SPD flow cache (default off) 2. ipv4-inbound-spd-hash-buckets %d - set number of hash buckets (default 4,194,304: ~1 million flows with 25% load factor) Performance with 1 core, 1 ESP Tunnel, null-decrypt then bypass, 94B (null encrypted packet) for different SPD policy matching indices: SPD Policy index : 2 10 100 1000 Throughput : Mbps/Mbps Mbps/Mbps Mbps/Mbps Mbps/Mbps (Baseline/Optimized) ARM TX2 : 300/290 230/290 70/290 8.5/290 Type: improvement Signed-off-by: Zachary Leaf <zachary.leaf@arm.com> Signed-off-by: mgovind <govindarajan.Mohandoss@arm.com> Tested-by: Jieqiang Wang <jieqiang.wang@arm.com> Change-Id: I8be2ad4715accbb335c38cd933904119db75827b