summaryrefslogtreecommitdiffstats
path: root/src/vnet
diff options
context:
space:
mode:
authorNeale Ranns <nranns@cisco.com>2019-08-01 04:45:15 -0700
committerDave Barach <openvpp@barachs.net>2019-08-01 18:04:42 +0000
commit3b9374fa57218c72306d372167724e88ef7d57be (patch)
tree5387c6d7f191671e180041ad081510da6601b2a4 /src/vnet
parent55c68c9521d98005ce850ee54a40c7579d88928b (diff)
ipsec: Redo the anit-replay check post decrypt
Type: fix Change-Id: I1fa8c5326d6f22cfb8dd40e97d8a22d11a716922 Signed-off-by: Neale Ranns <nranns@cisco.com>
Diffstat (limited to 'src/vnet')
-rw-r--r--src/vnet/ipsec/ah_decrypt.c7
-rw-r--r--src/vnet/ipsec/esp_decrypt.c29
2 files changed, 36 insertions, 0 deletions
diff --git a/src/vnet/ipsec/ah_decrypt.c b/src/vnet/ipsec/ah_decrypt.c
index bc6b5c4ec9d..bbe6b647c52 100644
--- a/src/vnet/ipsec/ah_decrypt.c
+++ b/src/vnet/ipsec/ah_decrypt.c
@@ -303,6 +303,13 @@ ah_decrypt_inline (vlib_main_t * vm,
if (PREDICT_TRUE (sa0->integ_alg != IPSEC_INTEG_ALG_NONE))
{
+ /* redo the anit-reply check. see esp_decrypt for details */
+ if (ipsec_sa_anti_replay_check (sa0, pd->seq))
+ {
+ b[0]->error = node->errors[AH_DECRYPT_ERROR_REPLAY];
+ next[0] = AH_DECRYPT_NEXT_DROP;
+ goto trace;
+ }
ipsec_sa_anti_replay_advance (sa0, pd->seq);
}
diff --git a/src/vnet/ipsec/esp_decrypt.c b/src/vnet/ipsec/esp_decrypt.c
index c2b9bf4dc0c..986ac94676c 100644
--- a/src/vnet/ipsec/esp_decrypt.c
+++ b/src/vnet/ipsec/esp_decrypt.c
@@ -376,6 +376,35 @@ esp_decrypt_inline (vlib_main_t * vm,
sa0 = vec_elt_at_index (im->sad, pd->sa_index);
+ /*
+ * redo the anti-reply check
+ * in this frame say we have sequence numbers, s, s+1, s+1, s+1
+ * and s and s+1 are in the window. When we did the anti-replay
+ * check above we did so against the state of the window (W),
+ * after packet s-1. So each of the packets in the sequence will be
+ * accepted.
+ * This time s will be cheked against Ws-1, s+1 chceked against Ws
+ * (i.e. the window state is updated/advnaced)
+ * so this time the successive s+! packet will be dropped.
+ * This is a consequence of batching the decrypts. If the
+ * check-dcrypt-advance process was done for each packet it would
+ * be fine. But we batch the decrypts because it's much more efficient
+ * to do so in SW and if we offload to HW and the process is async.
+ *
+ * You're probably thinking, but this means an attacker can send the
+ * above sequence and cause VPP to perform decrpyts that will fail,
+ * and that's true. But if the attacker can determine s (a valid
+ * sequence number in the window) which is non-trivial, it can generate
+ * a sequence s, s+1, s+2, s+3, ... s+n and nothing will prevent any
+ * implementation, sequential or batching, from decrypting these.
+ */
+ if (ipsec_sa_anti_replay_check (sa0, pd->seq))
+ {
+ b[0]->error = node->errors[ESP_DECRYPT_ERROR_REPLAY];
+ next[0] = ESP_DECRYPT_NEXT_DROP;
+ goto trace;
+ }
+
ipsec_sa_anti_replay_advance (sa0, pd->seq);
esp_footer_t *f = (esp_footer_t *) (b[0]->data + pd->current_data +