ipsec: Redo the anit-replay check post decrypt

Type: fix

Change-Id: I1fa8c5326d6f22cfb8dd40e97d8a22d11a716922
Signed-off-by: Neale Ranns <nranns@cisco.com>

3 files changed, 51 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 +
diff --git a/test/template_ipsec.py b/test/template_ipsec.py
index 773531fe038..c3fc8bd434f 100644
--- a/test/template_ipsec.py
+++ b/test/template_ipsec.py
@@ -318,6 +318,21 @@ class IpsecTra4(object):
         self.assert_error_counter_equal(replay_node_name, replay_count)
 
         #
+        # now send a batch of packets all with the same sequence number
+        # the first packet in the batch is legitimate, the rest bogus
+        #
+        pkts = (Ether(src=self.tra_if.remote_mac,
+                      dst=self.tra_if.local_mac) /
+                p.scapy_tra_sa.encrypt(IP(src=self.tra_if.remote_ip4,
+                                          dst=self.tra_if.local_ip4) /
+                                       ICMP(),
+                                       seq_num=35))
+        recv_pkts = self.send_and_expect(self.tra_if, pkts * 8,
+                                         self.tra_if, n_rx=1)
+        replay_count += 7
+        self.assert_error_counter_equal(replay_node_name, replay_count)
+
+        #
         # now move the window over to 257 (more than one byte) and into Case A
         #
         pkt = (Ether(src=self.tra_if.remote_mac,