ipsec: fixed chaining ops after add footer and icv 85/26885/4
authorPiotrX Kleski <piotrx.kleski@intel.com>
Tue, 5 May 2020 12:14:22 +0000 (14:14 +0200)
committerNeale Ranns <nranns@cisco.com>
Sun, 24 May 2020 07:31:49 +0000 (07:31 +0000)
In case there is no free space in first buffer for ICV and footer,
additional buffer will be added, but esp_encrypt will stay in single
buffer mode.
The issue happens for the following payload sizes:
 - TCP packets with payload 1992
 - ICMP packets with payload 2004

This fix moves the single/chained buffer ops selection to after
esp_add_footer_and_icv call.

Type: fix

Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Signed-off-by: PiotrX Kleski <piotrx.kleski@intel.com>
Change-Id: Ic5ceba418f738933f96edb3e489ca2d149033b79

src/vnet/ipsec/esp_encrypt.c
test/test_ipsec_esp.py

index e9feb8b..e80f986 100644 (file)
@@ -695,18 +695,10 @@ esp_encrypt_inline (vlib_main_t * vm, vlib_node_runtime_t * node,
 
       if (n_bufs > 1)
        {
-         crypto_ops = &ptd->chained_crypto_ops;
-         integ_ops = &ptd->chained_integ_ops;
-
          /* find last buffer in the chain */
          while (lb->flags & VLIB_BUFFER_NEXT_PRESENT)
            lb = vlib_get_buffer (vm, lb->next_buffer);
        }
-      else
-       {
-         crypto_ops = &ptd->crypto_ops;
-         integ_ops = &ptd->integ_ops;
-       }
 
       if (PREDICT_FALSE (esp_seq_advance (sa0)))
        {
@@ -879,6 +871,17 @@ esp_encrypt_inline (vlib_main_t * vm, vlib_node_runtime_t * node,
          next[0] = ESP_ENCRYPT_NEXT_INTERFACE_OUTPUT;
        }
 
+      if (lb != b[0])
+       {
+         crypto_ops = &ptd->chained_crypto_ops;
+         integ_ops = &ptd->chained_integ_ops;
+       }
+      else
+       {
+         crypto_ops = &ptd->crypto_ops;
+         integ_ops = &ptd->integ_ops;
+       }
+
       esp->spi = spi;
       esp->seq = clib_net_to_host_u32 (sa0->seq);
 
index 036fbf3..7448df1 100644 (file)
@@ -585,6 +585,7 @@ class RunTestIpsecEspAll(ConfigIpsecESP,
         LARGE_PKT_SZ = [
             1970,  # results in 2 chained buffers entering decrypt node
                    # but leaving as simple buffer due to ICV removal (tra4)
+            2004,  # footer+ICV will be added to 2nd buffer (tun4)
             4010,  # ICV ends up splitted accross 2 buffers in esp_decrypt
                    # for transport4; transport6 takes normal path
             4020,  # same as above but tra4 and tra6 are switched