aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/ipsec
AgeCommit message (Collapse)AuthorFilesLines
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
2022-04-04vppinfra: make _vec_len() read-onlyDamjan Marion1-1/+1
Use of _vec_len() to set vector length breaks address sanitizer. Users should use vec_set_len(), vec_inc_len(), vec_dec_len () instead. Type: improvement Change-Id: I441ae948771eb21c23a61f3ff9163bdad74a2cb8 Signed-off-by: Damjan Marion <damarion@cisco.com>
2022-03-10ipsec: remove the redundant codeMohsin Kazmi1-1/+0
Type: refactor Change-Id: I0a40e22e1439e13ffdbcbd6fd7cad40c8178418c Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2022-03-08ipsec: input: drop by default for non-matching pktsZachary Leaf1-0/+14
As per IPSec RFC4301 [1], any non-matching packets should be dropped by default. This is handled correctly in ipsec_output.c, however in ipsec_input.c non-matching packets are allowed to pass as per a matched BYPASS rule. For full details, see: https://lists.fd.io/g/vpp-dev/topic/ipsec_input_output_default/84943480 It appears the ipsec6_input_node only matches PROTECT policies. Until this is extended to handle BYPASS + DISCARD, we may wish to not drop by default here, since all IPv6 traffic not matching a PROTECT policy will be dropped. [1]: https://datatracker.ietf.org/doc/html/rfc4301 Type: fix Signed-off-by: Zachary Leaf <zachary.leaf@arm.com> Change-Id: Iddbfd008dbe082486d1928f6a10ffbd83d859a20
2022-02-18ipsec: fix vector after remove entry in spdGabriel Oginski1-1/+1
Originally after remove the policy entry in spd, macro "vec_del1" can change localization of the last entry in vector and finally the entry list has not been sorted. This patch fixes this issue by change executed macro "vec_delete" instead of "vec_del1". Type: fix Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com> Change-Id: I396591cbbe17646e1d243aedb4cdc272ed4d5e25
2022-02-17ipsec: Improve the handling of NAT-T keepalive messagesNeale Ranns1-8/+21
Type: improvement Ethernet frames on the wire are a minimum of 64 bytes, so use the length in the UDP header to determine if the ESP payload is one bytes of the special SPI, rather than the buffer's size (which will include the ethernet header's padding). In the case of drop advance the packet back to the IP header so the ipx-drop node sees a sane packet. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: Ic3b75487919f0c77507d6f725bd11202bc5afee8
2022-01-17ipsec: IPSec interface correct drop w/ no protectionNeale Ranns3-8/+19
Type: improvement When an IPSec interface is first constructed, the end node of the feature arc is not changed, which means it is interface-output. This means that traffic directed into adjacencies on the link, that do not have protection (w/ an SA), drop like this: ... 00:00:01:111710: ip4-midchain tx_sw_if_index 4 dpo-idx 24 : ipv4 via 0.0.0.0 ipsec0: mtu:9000 next:6 flags:[] stacked-on: [@1]: dpo-drop ip4 flow hash: 0x00000000 00000000: 4500005c000100003f01cb8cac100202010101010800ecf40000000058585858 00000020: 58585858585858585858585858585858585858585858585858585858 00:00:01:111829: local0-output ipsec0 00000000: 4500005c000100003f01cb8cac100202010101010800ecf40000000058585858 00000020: 5858585858585858585858585858585858585858585858585858585858585858 00000040: 58585858585858585858585858585858585858585858585858585858c2cf08c0 00000060: 2a2c103cd0126bd8b03c4ec20ce2bd02dd77b3e3a4f49664 00:00:01:112017: error-drop rx:pg1 00:00:01:112034: drop local0-output: interface is down although that's a drop, no packets should go to local0, and we want all IPvX packets to go through ipX-drop. This change sets the interface's end-arc node to the appropriate drop node when the interface is created, and when the last protection is removed. The resulting drop is: ... 00:00:01:111504: ip4-midchain tx_sw_if_index 4 dpo-idx 24 : ipv4 via 0.0.0.0 ipsec0: mtu:9000 next:0 flags:[] stacked-on: [@1]: dpo-drop ip4 flow hash: 0x00000000 00000000: 4500005c000100003f01cb8cac100202010101010800ecf40000000058585858 00000020: 58585858585858585858585858585858585858585858585858585858 00:00:01:111533: ip4-drop ICMP: 172.16.2.2 -> 1.1.1.1 tos 0x00, ttl 63, length 92, checksum 0xcb8c dscp CS0 ecn NON_ECN fragment id 0x0001 ICMP echo_request checksum 0xecf4 id 0 00:00:01:111620: error-drop rx:pg1 00:00:01:111640: drop null-node: blackholed packets Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: I7e7de23c541d9f1210a05e6984a688f1f821a155
2021-12-14api: verify message size on receiptKlement Sekera1-0/+4
When a message is received, verify that it's sufficiently large to accomodate any VLAs within message. To do that, we need a way to calculate message size including any VLAs. This patch adds such funcionality to vppapigen and necessary C code to use those to validate message size on receipt. Drop messages which are malformed. Type: improvement Signed-off-by: Klement Sekera <ksekera@cisco.com> Change-Id: I2903aa21dee84be6822b064795ba314de46c18f4
2021-12-04ipsec: fix async buffer leakMatthew Smith3-3/+2
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 Ranns8-192/+123
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