Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
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: improvement
Change-Id: I830f7a2ea3ac0aff5185698b9fa7a278c45116b0
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
Type: feature
Signed-off-by: Vladimir Ratnikov <vratnikov@netgate.com>
Change-Id: I4e03f60f34acd7809ddc5a743650bedbb95b2e98
|
|
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
|
|
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: 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: 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: 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: 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
|
|
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
|
|
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>
|
|
support
Type: feature
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: I6d4a9b187daa725d4b2cbb66e11616802d44d2d3
|
|
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
- 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
|
|
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
|
|
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
|
|
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>
|
|
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: feature
Change-Id: Ifee2b3dca85ea915067b9285e3636802bf0c19a8
Signed-off-by: Filip Tehlar <ftehlar@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>
|
|
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>
|
|
Type: fix
Change-Id: I0c9353598d3c9b7ea587ea8a2b6e1faa5454843d
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
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>
|
|
- 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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Id406eb8c69a89c57305d8f138e8e6730037aa799
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
- 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>
|
|
Change-Id: Ide2a9df18db371c8428855d7f12f246006d7c04c
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: If96f661d507305da4b96cac7b1a8f14ba90676ad
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ia8cea13f7b937294e6a080a55fb2ceff30063acf
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Id2ddb77b4ec3dd543d6e638bc882923f2bac011d
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Iff6f81a49b9cff5522fbb4914d47472423eac5db
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Idb661261c2191adda963a7815822fd7a27a9e7a0
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I0b47590400aebea09aa1b27de753be638e1ba870
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Icdcbac7453baa837a9c0c4a2401dff4a6aa6cba0
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ib828ea5106f3ae280e4ce233f2462dee363580b7
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ib73352d6be26d639a7f9d47ca0570a1248bff04a
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I81ecdf9fdcfcb017117b47dc031f93208e004d7c
Signed-off-by: Damjan Marion <damarion@cisco.com>
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ibe7f806b9d600994e83c9f1be526fdb0a1ef1833
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ie8986bd3652d25c4befe681cea77df95aba37ebc
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
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>
|