IPSec VPN Design [Electronic resources] نسخه متنی

IPSec and Fragmentation

A router fragments IP packets when the packet size exceeds the MTU of the outgoing interface. With IPSec, the addition of an IPSec header may cause IP fragmentation. IPSec RFCs state that this fragmentation, if needed, is performed after encryption for outbound processing. For inbound processing when an IPSec endpoint receives fragmented packets, the IPSec layer gets a reassembled packet from the IP layer before decryption.

Note

Fragmentation works in the Cisco Express Forwarding (CEF) switching path in all high-end routers such as the Cisco 7200, whereas reassembly of fragmented IP packets occurs in the IOS process switch path on all Cisco routers. Also, remember that reassembly of fragmented packets is performed only for packets that are destined to the router; fragmented packets that transit the routers are switched in the CEF path.

It is always desirable to avoid IP fragmentation between endpoints. Path MTU Discovery (PMTUD), stated in RFC 1191, was developed for this purpose. PMTUD dynamically determines the lowest MTU between two endpoints by using the Don't Fragment (DF) bit in the IP header to dynamically discover the PMTU of a path. The basic idea of PMTU is that a source initially assumes that the PMTU of a path is the (known) MTU of its first hop, and sends all packets on that path with the DF bit set. If any of the IP packets need to be fragmented by some router along the path, that router will discard the packet and send an ICMP Destination Unreachable message to the host with a code meaning "fragmentation needed and DF set." Upon receipt of such a message, the source host reduces its assumed PMTU for the path. PMTU is only supported for TCP, in which case the source host, upon reception of the ICMP unreachable message, sets the TCP maximum segment size (MSS). PMTU has some issues with IPSec, which will be explored in the next section.

IPSec and PMTUD

As described in RFC 1191, PMTU works on the premise that an ICMP unreachable packet informs the host with a code meaning "fragmentation needed and DF set." The amount of information that is returned in the ICMP message is limited, and with an IPSec packet this affects what selectors are available to identify security associations, originating hosts, and other aspects for use in further propagating the PMTU information. An ICMP PMTU may identify only the first (outermost) security association because the ICMP PMTU may contain only 64 bits of the "offending" packet beyond the IP header, which would capture only the first SPI from AH or ESP.

You can see this issue illustrated using Figure 3-6. Assume a host connected to subnet 10.0.68.0 is sending traffic to destination 10.1.1.0 with the DF bit set. IPSec policy on SPOKE-1-EAST encapsulates all traffic from this subnet to the destination subnet. The DF bit from the original IP packet is copied to the IPSec header. Also assume that the MTU of an intermediate router in the backbone requires fragmentation of the IPSec-encapsulated packet. The DF bit is set on this packet and therefore cannot be fragmented. It must be dropped by the backbone router and an ICMP unreachable (PMTU message) is sent back to the source. The source address in the PMTU message is that of the IPSec endpoint (SPOKE-1-EAST), because this router is the source of the IPSec-encapsulated packet. The ICMP PMTU message carries the SPI information, which points to the IPSec SA. In this case, a single SA is used for all hosts on the subnet. Therefore, the IPSec router has no way to figure out which host to send the Path MTU message to. To figure this out, you have two options:

The IPSec router sends the PMTU message to all hosts on this subnet.

The IPSec router stores the PMTU with the SPI and waits until the next packet(s) arrives from the originating host(s) for the relevant security association. If the packets are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the originating host(s) the ICMP message(s) about the problem. This involves a delay in notifying the originating host(s), but avoids the problems of the first bullet.

The second option is more feasible than the first and is, in fact, required by the IPSec RFCs. Cisco IOS behavior mimics this option. Example 3-8 shows how SPOKE-1-EAST reacts to change in PMTU by updating the SADB.

Example 3-8. Change in PMTU in the IPSec SA

spoke-1-east# show cry ipsec sa
interface: Serial0/0
Crypto map tag: vpn, local addr. 9.1.1.146
local ident  (addr/mask/prot/port): (10.0.68.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
current_peer: 9.1.1.35:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
local crypto endpt.: 9.1.1.146, remote crypto endpt.: 9.1.1.35
path mtu 1500, media mtu 1500
current outbound spi: BBB91DFA
inbound esp sas:
spi: 0x99E52DE4(2581933540)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607999/3589)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xBBB91DFA(3149471226)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2001, flow_id: 2, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607999/3589)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
spoke-1-east#
ICMP: dst (9.1.1.146) frag. needed and DF set unreachable rcv from 9.1.1.145
ipsec(adjust_mtu): adjusting path mtu from 1500 to 1400,
(identity) local= 9.1.1.146, remote= 9.1.1.35,
local_proxy= 10.0.68.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4)
ICMP: dst (10.1.1.10) frag. needed and DF set unreachable sent to 10.0.68.5
ICMP: dst (10.1.1.10) frag. needed and DF set unreachable sent to 10.0.68.5
spoke-1-east# show cry ipsec sa
interface: Serial0/0
Crypto map tag: vpn, local addr. 9.1.1.146
local ident (addr/mask/prot/port): (10.0.68.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
current_peer: 9.1.1.35:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 35, #pkts encrypt: 35, #pkts digest 35
#pkts decaps: 39, #pkts decrypt: 39, #pkts verify 39
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
local crypto endpt.: 9.1.1.146, remote crypto endpt.: 9.1.1.35
path mtu 1400, media mtu 1500
current outbound spi: BBB91DFA
inbound esp sas:
spi: 0x99E52DE4(2581933540)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607987/3020)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xBBB91DFA(3149471226)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2001, flow_id: 2, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607986/3020)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:

Note

Another option to deal with PMTU for TCP packets is to configure the TCP MSS size on the interface facing the host using the command ip tcp mss adjust <value>. This option still will not solve the PMTU if an intermediate router along the path needs to fragment the IPSec packet.

One of the assumptions for PMTU to work is that the ICMP unreachables can reach the source. It is possible that firewalls may block ICMP messages from reaching the sources, which will break PMTUD. A workaround for this situation is to override the DF bit using the following IOS command:

Spoke-1-east(config)# crypto ipsec df-bit [clear | set | copy]

In the first case, with the DF bit clear option, no path MTU is performed and the DF bit in the IPSec header is set to 0 and fragmented if required. The default behavior is to copy the DF bit from the IP packet to the IPSec header.

Look Ahead Fragmentation

The IPSec RFCs state that IP fragmentation for IPSec-encapsulated packet should happen after encryption. It would be immensely helpful if the encrypting router looks ahead and knows that after encryption and addition of the IPSec header, the resulting packet will exceed the MTU of the outbound interface and would need fragmentation. By looking ahead, the packet can be fragmented before encryption, which saves the decrypting IPSec router from the CPU-intensive job of reassembling the IPSec fragments. Reassembly of the IP packet is off-loaded to the end host. The Cisco IOS feature that performs this function is known as Look Ahead Fragmentation. The feature is quite intuitively simple; a packet arriving into an IPSec gateway will have its length plus IPSec encapsulation overhead compared to the encrypting interface's MTU. If the expected packet size is larger than the MTU of the outbound interface, the IPSec gateway will fragment the IP packet prior to encryption. Otherwise, the packet is forwarded with encryption without fragmentation.

Example 3-9 shows the configuration of this feature. It can be configured on an interface or globally.

Example 3-9. Look Ahead Fragmentation Configuration

vpn-spoke1-east
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 9.1.1.34
crypto isakmp keepalive 60 3
crypto ipsec fragmentation before-encryption                                          

Look Ahead Fragmentation configuration works for IP traffic using IPSec tunnel mode only, and will not work in case of transport mode. The reason is that in transport mode, the IP header of the original packet is used in each of the fragments, which results in the More Fragment bit set in the first fragment's IP header and the fragment offset in the subsequent fragments. The receiving IPSec peer has no way of knowing whether an individual packet was fragmented before encryption or after encryption. Therefore, in case of transport mode, the fragments are reassembled before decryption.