Uploaded image for project: 'vpp'
  1. vpp
  2. VPP-1928

GCM padding is incorrect with native ipsec encryption

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: High High
    • None
    • None
    • IPsec
    • None

      Please see: https://tools.ietf.org/html/rfc4106#page-6

      The code currently has GCM block_size set to 16 (see ipsec_init). This value is solely used to determine padding in esp_add_footer_and_icv using:

      ```

      u16 min_length = total_len + sizeof (esp_footer_t);
      u16 new_length = round_pow2 (min_length, block_size);
      u8 pad_bytes = new_length - min_length;

      ```

      This is incorrectly padding packets according to RFC4106. A good example of how this is broken is if a user tries to send a 1442-1446 len IP packet the resulting pad will cause this ESP IP packet to be 1508 octets rather than 1500 (and thus be dropped under common MTU conditions).

      Scapy (used by the unit test framework) is also wrong in this regard and there is an open issue for that as well https://github.com/secdev/scapy/issues/2322

      The way to fix this (for both vpp and scapy) is to set the block size to 1 for GCM.

      DPDK ipsec uses the correct values, so perhaps consult algos_init() to fix things (they may be broken for other algorithms as well), look at the boundary value which is used as a mask (after subtracting 1) for determining padding.

       

            nranns Neale Ranns
            chopps Christian Hopps
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: