Ipsec: tcpdump vs pmtu 1446 (Tunnel 3des/md5-96) lost of 4 Bytes !

[osgpcqosg]

Hi,
I'm trying to understand why the MTU in my test tunnel is 1446, between a cisco and a linux. (I have the same between two ciscos).
I  have done tcpdump -E and use RFCs to identify each byte in the trace, so  can't understand why the pmtu is 4 bytes lower than I expect.

(I see on the net lot of differents valors but without any explainations).

The  3des seems to use an IV size of simple DES, I do a lot of dump to  verify the identification of padding (size of the ping), switch to aes  to verify the bytes identifications.

Does the tcpdump -E erase the Auth Pad, a another thing, I'm must miss something but what ????

My interpretation: (Mode Tunnel: 3des/md5-96)
    MTU     IP SPI SN  IV  Data   Pad PL  NH  AUTH
   1500    -20 -4 -4 -( 8    x )  -0  -1  -1  -12  = 1450

The PMTU from a "ping -M do -s 1472" give me 1446, why !?

(And no i don't use GRE).

Best regards

Vincent Tamet.
OSG[PCQ]

PS:
-----------------------------------------------------------------------------
* ping 192.168.3.1 -c 1 -s 2
17:25:56.555463  00:06:5b:8a:a4:2b > 00:24:14:d9:f1:90, ethertype IPv4 (0x0800),  length 44: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1),  length 30)
    192.168.2.5 > 192.168.3.1: ICMP echo request, id 46448, seq 1, length 10
        0x0000:  4500 001e 0000 4000 4001 b488 c0a8 0205  E.....@.@.......
        0x0010:  c0a8 0301 0800 428d b570 0001 0001       ......B..p....
-----------------------------------------------------------------------------
16:25:59.221603  08:1f:f3:e7:0e:65 > 00:23:7d:fd:bb:04, ethertype IPv4 (0x0800),  length 94: (tos 0x0, ttl 253, id 1992, offset 0, flags [DF], proto ESP  (50), length 80) xx.xx.1.136 > 10.0.0.2: ESP(spi=0xdb14b228,seq=0x8),  length 60
        0x0000:  4500 0050 07c8 4000 fd32 19cc 505e 0188  E..P..@..2..P^..
        0x0010:  0a00 0002 db14 b228 0000 0008 5957 445a  .......(....YWDZ
        0x0020:  5dcd 42b4 4500 001e 0000 4000 3f01 b588  ].B.E.....@.?...
        0x0030:  c0a8 0205 c0a8 0301 0800 428d b570 0001  ..........B..p..
        0x0040:  0001 0004 58c2 f376 69fa ede5 2584 f199  ....X..vi...%...
-----------------------------------------------------------------------------

[andrew.prince]

What about your tcp/udp header?

[wzhang · Accepted solution]

Hi,

I think you may be overlooking the padding boundary conditions. This is the encryption overhead breakdown for data payloads of 1446 bytes and 1447 bytes.

1446 bytes

========

20 bytes new IP header

4 bytes SPI

4 bytes Sequence

8 byte IV

0 byte pad

1 byte Pad length

1 byte Next Header

12 bytes ESP SHA

----------

Total 1496 bytes < 1500

1447 bytes

========

20 bytes IPsec header (tunnel mode)

4 bytes SPI (ESP header)

4 bytes Sequence (ESP Header)

8 byte IV (IOS ESP-DES/3DES)

7 byte pad (ESP-DES/3DES 64 bit)

1 byte Pad length (ESP Trailer)

1 byte Next Header (ESP Trailer)

12 bytes ESP SHA 96 digest

----------

Total 1504 bytes > 1500

Note with cisco's IPSec implementation, we use 0-7 bytes padding.

Hope this helps,

Thanks,

Wen

[osgpcqosg]

• Thanks you, sure this help a lot, I'll do the test soon. You're explication is full of sense, and the default fragmentation in the tunnel must have confuse me once again. I'll explain you the result. Thanks you once again. I need use the Iv size for my calcul !

[osgpcqosg]

Thanks you very much !

I can't done the last tcpdump because have a frag problem, explained rapidly in the bottom.

I test with a ping -c 1 -s 1418 192.168.2.5

Encapsulating Security Payload (Tunnel Mode)
 IP Tunnel header                                           20
 ESP Header
    Security Parameters Index   [SPI]                        4
    Sequence Number                                          4
 Payload data                                 (variable)
    Initialization Vector       [IV]  IOS ESP-DES-3DES       8
    Data                                      (Variable)  1446
         IP Origin header                                               20
         ICMP Header                                                     8
         Data                                                         1418
    Padding Encrypt     IOS ESP-DES-3DES (variable 0->7)     0
 ESP Trailer
    Pad Length                               8 bits          1
    Next Header                              8 bits          1
 ESP Authentication Data                   (Variable x4?)
    Integrity Check Value       [ICV] ESP MD5 96 digest     12
    Padding Auth                              0
                                                         -------
                                                          1496 < 1500

I  use this to compute the pad:

8+(1446)+1+1= 1456
1456/8 = 182.00
1456-(182*8) = 0 so without padding

If we calcul for a ping -c 1 -s 1419 192.168.2.5

Encapsulating Security Payload (Tunnel Mode)
 IP Tunnel header                                           20
 ESP Header
    Security Parameters Index   [SPI]                        4
    Sequence Number                                          4
 Payload data                                 (variable)
    Initialization Vector       [IV]  IOS ESP-DES-3DES       8
    Data                                      (Variable)  1447
         IP Origin header                                               20
         ICMP Header                                                     8
         Data                                                         1419
    Padding Encrypt     IOS ESP-DES-3DES (variable 0->7)     7
 ESP Trailer
    Pad Length                               8 bits          1
    Next Header                              8 bits          1
 ESP Authentication Data                   (Variable x4?)
    Integrity Check Value       [ICV] ESP MD5 96 digest     12
    Padding Auth                              0
                                                         -------
                                                          1504 > 1500

And for the pad:

8+(1447)+1+1= 1457
1457/8 = 182.12
1457-(182*8) = 1 If not =0 we need to calcul the padding
8-1=7

Don't know why but always had problem with the 8 magic lost bytes in cisco 8xx product !!!

I have a another discution with a opened tiquet to cisco support for an  another lost of 8 bytes: https://supportforums.cisco.com/thread/2058182 (Edit: this one is a real Bug)

Still have some problem with fragmentation in cisco, so I not  be able to confirm this with tcpdump because the cisco start to fragment  my paquet before the 1418 limit size of data, and for now not fragment  for 1410 bytes of data but yes do frag for 1411 bytes paquet size: https://supportforums.cisco.com/thread/2075689  (Edit: Seem to be a problem with our providor).

And this one is a 8 bytes problem too about a frag problem: https://supportforums.cisco.com/thread/2066638 (Edit: Seem to be a problem with our providor).

Best regards.