Fragmentation and PMTU
Generally, IPSec is not affected by fragmentation because the IP packets are fragmented after the IPSec processing and the fragments are reassembled before the IP layer invokes the IPSec layer for further processing. This is true for all implementations of IPSec host, routers, bump in the stack, or bump in the wire. The general exception to this rule is that IPSec implementations on gateways that have selectors on the granularity of port and protocol may have to assemble enough of the fragments to determine whether the reconstructed packet is permitted.
However, IPSec does affect PMTU. The hosts that generate a packet avoid fragmentation by setting the DF bit in the IP header. This indicates to a router to inform the host that originated the packet about its MTU. If a router gets a packet that is too big for its MTU, it sends an ICMP message to the host that originated the packet, indicating the MTU in the ICMP message. It is up to the host to interpret these ICMP messages and store them appropriately so that future packets generated on this connection should not need fragmentation. The host maintains this information either in the socket, or on a per route basis. It is preferable for the host to maintain PMTU information where possible because it leads to optimal use of bandwidth.
As the IPSec layer introduces extra headers, it should be involved in the PMTU processing. The involvement of IPSec varies, depending on host or router implementation.
Host Implementation
PMTU discovery can be initiated either by the transport layer or by the network layer in host implementations. As hosts do not maintain source routes, it is preferable to maintain the PMTU information at the transport layer. This enables PMTU to be maintained on an end-to-end basis.
When IPSec is enabled end to end, the IPSec implementation on the host should decrease the MTU that the network layer advertises to the transport layer for a particular connection. This value depends on the length and on the kind of IPSec processing afforded to the packet. The various parameters that affect the length are the IPSec protocols afforded to the connection, the transforms (different algorithms produce headers of different length), and the modes (tunnel mode adds an extra IP header).
Before the network layer passes up the MTU to the transport layer, the policy engine has to be consulted to determine the implication on the MTU because of IPSec. The MTU computation should also handle multiple tunnel cases. This computation involves invoking the policy engine multiple times to find the implication on the MTU for each tunnel header that is added. This computation is very expensive and complicated. Host implementations can optimize this process by pre-computing the length of the headers that IPSec protocols add to a packet. Consider the following example where packets from host A to host B are authenticated in transport mode and then tunneled (encrypted) from host A to router R. The host can pre-compute the length of the header from A and B and the length of the header from A to R and store this value packet destined from A to B. However, the implication of this is if the policy changes, the policy engine has to re-compute all the affected header lengths.
Router Implementation
The routers send an ICMP unreachable message to the originating host (this is the source address in the IP packet) with at least the first 64 bits of the packet data, if the DF bit is set and the packet length exceeds the MTU of the interface over which the packet is forwarded. This procedure is essential for PMTU discovery. However, tunneling poses a challenge to the PMTU discovery process.
Let us consider the following scenario shown in Figure 9.6.[4]
[4] In this diagram, each router is shown with two IP addresses. This is because each interface on the router has a different IP address. The packet comes over one interface and is forwarded over another interface as the router is forwarding packets between different subnets.
Figure 9.6. PMTU discovery.
There two hosts, A1 and A2, attached to the router RA. A1, A2, and RA are on a network whose MTU is 1518 (Ethernet). RA is connected to RB over Ethernet as well, and hence the MTU is 1518. RB is connected to RC over some other link layer whose MTU is, say, 700. RA has a policy that requires it to tunnel all packets destined to the network 4.4.4/24 to RC (3.3.3.2). Host A1 generates a packet destined to host B and sets the DF bit to prevent fragmentation of the packet. Let us say that the size of this packet is 680 bytes. When the packet reaches RA, RA checks its policy and determines that the packet should be tunneled to RC. Let us say that after adding the tunnel and IPSec header, the packet size increases to 720. RB receives the packet over its interface 2.2.2.2 and determines it has to forward the packet over the interface 3.3.3.1. RB cannot forward the packet because the interface over which the packet should be forwarded has an MTU of 700 and the current packet size exceeds that. It cannot fragment the packet as the DF bit is set. It sends an ICMP message with, say, 64 bits of data. The packet that caused the ICMP message and the ICMP error message packet are shown in Figure 9.7.
Figure 9.7. PMTU discovery packet format.
In the ICMP error packet, the first 64 bits of the data are the SPI and sequence number values of the ESP header. When RA receives the ICMP packet, it cannot determine the actual source because either A1 or A2 could have generated the packet. This is because the same SPI is used to secure all packets originating from network 1.1.1/24 and destined to 4.4.4/24.
The following guidelines can be used to handle PMTU messages.
If the routers cannot determine the source, they can use the SPI information to determine the source of the packet and forward the ICMP message to the host. The routers can use the SPI if they are using a different SPI for each host. In our example, if RA was using different SPIs for A1 and A2, it knows by looking at the SPI to whom to direct the PMTU message it receives.
In cases where the router cannot determine the source, it should remember the SPI and when it sees a packet matching the SPI, it should send the ICMP message indicating the MTU to the host.
The routers should provide the ability to set the DF bit if the DF bit of the inner header is set. However, in some cases, if the data length becomes too small, it may be more efficient to fragment the packet to make better use of the bandwidth. Hence, it may be important for this bit to be configurable in router implementations.
The BITS and the BITW implementation PMTU behavior are similar to the router implementation. As BITS is implemented as a shim, it cannot interact with the stack directly and has to process ICMP as a router. BITW implementations are specialized stand-alone security devices and hence their PMTU behavior is no different than that of a router.
Top IPSec (2nd Edition) ISBN: 013046189X
EAN: 2147483647 Year: 2004
Pages: 76 Authors: Naganand Doraswamy, Dan Harkins
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |