IPSEC Encryption Overhead

ROBERT THOMSON · ‎05-06-2010

I'm hoping someone can help me with the maths to reconcile what I've observed on

our routers on a tunnel interface. The maximum amount of data I can get across the tunnel is 1339 bytes, which seems just a little bit too small.

Background: we have two 3845 routers with IOS 12.4(3a) advanced ip services.

I have tunnel interfaces on both routers, interface configs are below.

crypto ipsec transform-set MY_TSET esp-3des esp-sha-hmac comp-lzs

crypto ipsec profile MY_VTI
set transform-set MY_TSET

interface Tunnel7
ip address 10.1.40.134 255.255.255.252

tunnel source 10.252.0.14
tunnel destination 10.252.0.18
tunnel mode ipsec ipv4
tunnel path-mtu-discovery
tunnel protection ipsec profile MY_VTI
end

interface Tunnel3
ip address 10.1.40.133 255.255.255.252

tunnel source 10.252.0.18
tunnel destination 10.252.0.14
tunnel mode ipsec ipv4
tunnel path-mtu-discovery
tunnel protection ipsec profile MY_VTI
end

When I test the mtu of the source destination interfaces I get 1500 bytes, as you would expect from an ethernet connection to a service providers MPLS network. See output below.

Router1#ping ip 10.252.0.18 df-bit size 1500

Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.252.0.18, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/33/36 ms
Router1#ping ip 10.252.0.18 df-bit size 1501

Type escape sequence to abort.
Sending 5, 1501-byte ICMP Echos to 10.252.0.18, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)

When I test the mtu of the tunnels I get 1339 bytes, see the output below.

router1#ping ip 10.1.40.133 df-bit size 1340

Type escape sequence to abort.
Sending 5, 1340-byte ICMP Echos to 10.1.40.133, timeout is 2 seconds:
Packet sent with the DF bit set
M.M.M
Success rate is 0 percent (0/5)

router1#ping ip 10.1.40.133 df-bit size 1339

Type escape sequence to abort.
Sending 5, 1339-byte ICMP Echos to 10.1.40.133, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/31/36 ms

Now when we do the maths on the packet size I get the following

20 bytes - IP header for ESP packet

8 bytes - ESP header

8 bytes - 3-DES IV

20 bytes - ip header for GRE encapsulation

4 bytes - GRE header

1339 bytes - original ip/icmp echo data

5 bytes - 3DES padding to make it a multiple of 8 bytes (20+4+1339+5)/8 = 171 8byte blocks

2 bytes - padding to ensure ESP trailer alignment ends on a 4 byte word

1 byte - ESP trailer pad length field

1 byte - ESP trailer next header field

12 bytes - ESP auth information as per RFC2404

That comes to a total of 1420, which is 80 bytes short of the mtu of the source/destination interface of the tunnel.

Can anyone help explain where things are going wrong, either with my maths or the router config.

Regards

Rob

IrmanGhaffar · ‎08-26-2011

Hi Robert,

Did you ever manage to find a solution to this problem? Iam facing a simmilar issue where the MTU's just don't add up.

Thanks In advance.

Irman.

ROBERT THOMSON · ‎08-27-2011

Hi Irman,

I am somewhat embarrassed that I forgot to reply back to the forum once we had a workaround. Thanks for giving me the opportunity to rectify that now.

We did eventually get a workaround and Cisco allocated bug ID CSCth31172 to the problem. The workaround is simply to specify the tunnel source by interface name rather than ip address.

I wrote a more complete description of my findings on my blog at http://networknerd.wordpress.com/2010/06/11/cisco-ipsec-mtu-bug/.

Hope that helps with your problem. The bug seems to effect a large number of IOS versions so I was a bit surprised that nobody had reported it before me.

Regards

Rob

support · ‎08-30-2011

Hi Robert,

I often forget to reply to forums its just difficult to keep track of problems when they are stretched out over a period of time. But thanks for the information. I will test this out and let you know how i get on.

Regards

Irman Ghaffar.

irman ghaffar · ‎09-23-2011

Hi,

Apologies for the late response here I have been keeping an eye on the Issue, seems to have been resolved in the latest IOS release, now running Version 15.2(1)GC. Up for > 2 weeks without major issues but it did stop responding at all traffic (including ssh). Would bea little cautious when updating.

Hope this helps!!!