IPSec Processing
In this section, the processing of the IPSec packets, both inbound and outbound, is discussed briefly. The interactions between the kernel and the key management layer is discussed in the IPSec implementation chapter. The header processing, both IPv4 and IPv6, are discussed in the IPSec implementation chapter.
The IPSec processing is classified into outbound processing and inbound processing.
Outbound
In outbound processing, the transport layer packets flow in to IP layer. The IP layer consults the SPD to determine the security services afforded to this packet. The input into the SPD is the selectors defined in the previous section. The output of the SPD is one of the following:
Drop the packet, in which case the packet is not processed and dropped.
Bypass security, in which case the IP layer adds the IP header to the payload and dispatches the IP packet.
Apply security, in which case, if an SA is already established, the pointer to it is returned. If SA is not established, then IKE is invoked to establish the SA. If the SAs are already established, SPD has a pointer to the SA or the SA bundle, depending on the policy. If the output of the policy mandates applying IPSec to the packets, the packets are not transmitted until the SAs are established.
The IPSec implementation waits until the SAs for this packet are established, if they are not already established. After the SAs are established, it processes the packet by adding the appropriate AH and ESP headers. The SAs have all the pertinent information and are ordered so that the IPSec headers are constructed appropriately. For example, let us consider the network shown in the Figure 4.13.
Figure 4.13. Outbound IPSec processing.
In this case, the host is tunneling a packet to the gateway using ESP but is authenticating to the end host B. The correct header is shown in Figure 4.14.
Figure 4.14. Packet format.
In this case, IKE establishes four SAs two for sending and two for receiving. As we are discussing the outbound processing, we will ignore the SAs established for processing inbound packets. The two outbound SAs are SA1 and SA2, where SA1 is the SA between A and the gateway and SA2 is the SA between the host and the destination. The ordering of IPSec processing is very important. If SA2 is applied after SA1, the packet is formed incorrectly. It is very important to maintain ordering in the SA bundle so that IPSec processing is applied in the correct order for outbound packets.
This section gave a very brief overview of the processing of the outbound packets. There are lot of other issues with constructing the header in handling fields such as sequence numbers and insertion of headers that is deferred to the implementation chapter.
Inbound
The inbound processing differs from the outbound processing. On the receipt of the IP packet, if the packet does not contain any IPSec headers, the security layer checks the policy to determine how to process the packet. It indexes the SPD using the selector fields. The output of the policy will be one of three values discard, bypass, or apply. If the output of the policy is discard, the packet is dropped. If the output of the policy is apply, but SAs are not established, the packet is dropped. Otherwise, the packet is passed up to the next layer for further processing.
If the IP packet contains IPSec headers, the packet is processed by the IPSec layer. The IPSec layer extracts the SPI, the source addr, and the destination addr from the IP datagram. It indexes into the SADB using the tuple <SPI, dst, protocol> (additionally the source address is used, depending on the implementation). The protocol value is either AH or ESP. Depending on the protocol value, the packet is handled either by the AH or the ESP layer. After the protocol payload is processed, the policy is consulted to validate the payload. The selectors are used to retrieve the policy. The validation process consists of checking that the SA was used appropriately, that is, the source and destination in the SA corresponds to what the policy says and the SA is protecting the transport layer protocol it was supposed to protect. In case of tunneled packets, the source and destination selector fields are that of the inner header and not the outer header. Indexing into the SPD based on the outer source and destination values yields invalid results because the entry is constructed for the true source and destination and not the tunnel end point.
Let us consider the example where the gateway is tunneling a packet for host B to host A. On the host A, the policy says, packets arriving from B have tunneled ESP and the tunnel source will be the secure gateway. In this case, indexing into the SPD using the gateway as source instead of host B is incorrect.
Once the IPSec layer validates the policy, it strips off the IPSec header and passes the packet to the next layer for further processing. The next layer is either a transport layer or a network layer. For example, if the packet is IP[ESP[TCP]]], then the next layer is a transport layer. If the packet is IP[AH[ESP[TCP]]] the next layer will be the IPSec layer that belongs to the network layer. This process is repeated until the packet reaches the application layer where the data is delivered to the application.
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 |