Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: improvement
Change-Id: I252951d3ec01497c049ca0ffb7cb42aaf2efb965
Signed-off-by: Dau Do <daudo@yahoo.com>
|
|
Type: fix
Change-Id: Ic015b37e18a43c49c3fb3dbff284a17fa2c5fd99
Signed-off-by: Fan Zhang <fanzhang.oss@gmail.com>
Signed-off-by: Kai Ji <kai.ji@intel.com>
|
|
Type: improvement
Change-Id: Icac31a8a3da71334e2b877f3b8e5d5a7cc5e76b8
Signed-off-by: Fan Zhang <fanzhang.oss@gmail.com>
|
|
Type: refactor
Change-Id: I5235bf3e9aff58af6ba2c14e8c6529c4fc9ec86c
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Type: feature
Change-Id: I7b29c71d3d053af9a53931aa333484bf43a424ca
Signed-off-by: Arthur de Kerhor <arthurdekerhor@gmail.com>
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
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
|
|
Type: fix
Signed-off-by: Frédéric Perrin <fred@fperrin.net>
Change-Id: I45191b7316c88038bcd57d62aeb07bb109cf4a4d
|
|
Type: improvement
Change-Id: I830f7a2ea3ac0aff5185698b9fa7a278c45116b0
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
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
|
|
commit failed
Type: fix
Signed-off-by: Xiaoming Jiang <jiangxiaoming@outlook.com>
Change-Id: Ib4c61906a9cbb3eea1214394d164ecffb38fd36d
|
|
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>
|
|
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>
|
|
the batch
Type: fix
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: Icd1e43a5764496784c355c93066273435f16dd35
|
|
Type: improvement
Change-Id: I3fbbda0378b72843ecd39a7e8592dedc9757793a
Signed-off-by: Damjan Marion <dmarion@me.com>
|
|
Type: improvement
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: Ica7de5a493389c6f53b7cf04e06939473a63d2b9
|
|
Type: feature
Change-Id: I940b6c9d206e407f3e17d66c97233cd658984e61
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
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>
|
|
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
|
|
Type: refactor
Change-Id: Id10cbf52e8f2dd809080a228d8fa282308be84ac
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
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
|
|
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>
|
|
When both chained and non-chained buffers are processed in the same
vector, make sure the non-chained buffers are processed as non-chained
crypto ops.
Type: fix
Change-Id: I19fc02c25a0d5e2e8a1342e2b88bbae3fe92862f
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
The crypto op flags must be reset to frame flags minus invalid values
depending of the operation, instead of forcing them to specific values.
Type: fix
Change-Id: Ib02c2a738bbca6962394b3c03088d516d0da56a0
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
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
|
|
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
|
|
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
|
|
Type: test
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: Iabc8f2b09ee10a82aacebd36acfe8648cf69b7d7
|
|
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
|
|
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
|
|
Type: feature
Change-Id: I9f7742cb12ce30592b0b022c314b71c81fa7223a
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
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
|
|
Type: feature
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I89dc3815eabfee135cd5b3c910dea5e2e2ef1333
|
|
Type: fix
This change makes esp_move_icv() update pd->current_length if the first
buffer's length is updated.
In case that ICV is split over two buffers, esp_move_icv() copies ICV
to last buffer, it also updates the before_last buffer's current_length.
However, in esp_decrypt_post_crypto(), pd->current_lenght is used to update
first buffer lenght, but pd is not updated in esp_move_icv()
and the total pkt lenght ends up incorrect.
This only happens in tunnel mode when ICV is split between 1st and 2nd buffers.
Signed-off-by: PiotrX Kleski <piotrx.kleski@intel.com>
Change-Id: Ic39d87454ec0d022c050775acb64c5c25ccf7f13
|
|
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
|
|
Type: improvement
also clean up GRE includes across the code base.
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I90928b0da3927b7ca1a23683aa80d4b53bbf63fd
|
|
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
|
|
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
|
|
The issue is not easily hit. When GRE_teb packets are received the post
crypto processing adjusts the l2.l2_len value in the vnet_buffer opaque
data. This is overwriting the ipsec opaque data. Later the trace code
fetches the sa_index from the ipsec opaque data. It's just an accident
that this currently works, if the ipsec data is changed so that the
sa_index moves around it will be overwritten by the l2_len modification.
Indeed, this was found b/c local development changes had moved the
sa_index so it was over-lapping with the l2_len memory space, and the UT
failed.
Type: fix
Change-Id: Iaecfa750cf0b36653fd9e75b4d799f323a14d932
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
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
|
|
Type: fix
Change-Id: I0f12c19b79df19b692f18ac13d6c32341853b764
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
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>
|
|
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>
|
|
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>
|
|
Type: fix
Change-Id: I1ba921503a41ca37ce5c920682893617740571a9
Signed-off-by: Rajesh Goel <rajegoel@cisco.com>
|
|
Type: feature
Change-Id: Ie072a7c2bbb1e4a77f7001754f01897efd30fc53
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Type: fix
Ticket: VPP-1831
Signed-off-by: John Lo <loj@cisco.com>
Change-Id: I655964b22021ac38cbced577091a1156286d4fd6
|
|
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
|
|
Type: fix
Change-Id: I5cb9a3845ddbc5f4de4eb4e9c481f606fe5cec9a
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
in transport mode the header sequence is:
MAC - IP (tun) - ESP - GRE - L2
so popping the GRE header is done in the ESP decrypt node.
Change-Id: Ia125eb65b9300368617d2bffca09683851e43be0
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
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>
|