IPSec Protocol Processing
The IPSec processing is broadly classified into outbound versus inbound processing and AH versus ESP and their variants thereof. Although the interface to the various components of IPSec remains the same, the packet processing is different between input and output processing. The protocol processing can be classified into SPD processing, SA processing, header, and transform processing. The SPD and SA processing are the same for both AH and ESP. The transform and header processing is different between AH and ESP.
Outbound Processing
In most TCP/IP implementations, the transport layer invokes the IP layer to send a packet by calling a function ip_output. One of the parameters to the function will be a pointer to an IP structure that has the elements such as source address and destination address that enables the IP layer to construct the IP header. The transport layer also passes the value of the protocol that IP layer puts in its next header field in its header and a flags field that gives IP layer to support various socket options. It makes most sense to perform SPD processing (i.e., decide if the packet needs any security) at this entry to ip_output.
Let us consider the example network diagram shown in Figure 9.3.[3]
[3] In this diagram, we show the IP address for only one of the interfaces for each router. This is the interface exposed to the outside world.
Figure 9.3. Example of IPSec processing.
For outbound processing, we will consider an HTTP packet (TCP, port 80) generated by host A destined to host B (a Web server) traversing routers RA and RB. The policy on A for packets destined to host B mandates usage of AH in transport mode using HMAC-MD5. The policy on router RA mandates that all packets destined to the network 2.2.2/24 be encrypted with ESP using 3DES and tunneled to RB.
SPD Processing
At the entry point into the ip_output, the policy engine is consulted to determine the security services afforded to a packet. The input to the policy engine will be the selectors from the transport header and the source and the destination address. In our example, the input to the policy engine will be the tuple <1.1.1.1, 2.2.2.2, TCP, 80> (the source port is a wild card). The policy engine determines the security services and performs the following functions:
If the policy indicates the packet needs to be dropped, it returns to the ip_output function indicating that the packet has to be dropped. The ip_output function is expected to discard the packet.
If the policy indicates that this packet can be transmitted without any extra security processing, the policy engine returns with an indication that the packet can be transmitted in clear. The ip_output function transmits the packet in clear at this point.
If the policy indicates that the packet needs security, the policy engine checks if the SAs are already established. If the SAs are already established, the SA or SA bundle is passed to the IP output function. If the SAs are not yet established, the policy engine indicates security processing is required but the SAs are not established yet and notifies IKE to establish the required SA(s). At this point, it is up to the ip_output function to decide whether to queue the packet until the SAs are established or to drop the packet.
In our example, the policy engine determines that the packet needs to be secured using transport mode AH HMAC-MD5. The policy engine also determines that the SA is already established and hence does not invoke IKE to establish a new SA.
IKE Processing
IKE requires special processing. It is a requirement that all implementations recognize IKE packets that are locally generated and locally destined, and process them without securing them. Otherwise, we will end up having a chicken and egg problem. As IKE is used to establish the SAs, if the IP layer does not recognize IKE packets and instead "retriggers" IKE to establish SAs for the destination, no packets that require security will ever leave the node!
This is true even after IPSec SAs are established. This is possible as IKE always uses a well-known port (500) and a well-known protocol (UDP).
SA Processing
The next step in the outbound packet processing is the SA processing. This particular SA is fetched from the SADB. In our example, the SAA->B is fetched from the SADB on host. The SA is processed as follows:
If the SA is using the number of bytes as its lifetime, then the number of bytes fields is increased depending on the size of the payload (not including the padding). For ESP, it will be the number of bytes that are encrypted and not the number of bytes on which we have calculated the hash.
If the SAs soft lifetime has expired, then invoke IKE to establish a new SA.
If the SAs hard lifetime has expired, then delete the SA.
Increment the sequence number field. The sequence number is always incremented before it is copied into the IPSec header. It is initialized to 0 during the SA setup and the first IPSec packet should have a sequence number of value 1. If the sequence number field overflows, it is audited. If the SA was not established using manual keying, IKE is invoked to negotiate a new SA.
After SA processing, the protocol specific component is invoked. Let us consider both cases transport mode and tunnel mode for both AH and ESP.
Transport Mode Header Processing
So far, we have not distinguished between IPv4 and IPv6. However, the header construction differs between IPv4 and IPv6. This is inevitable because of the format of the headers. There are also some differences between AH and ESP header construction.
In earlier chapters it was mentioned that AH in transport mode protects some parts of IP headers whereas ESP protects only the transport payload. This requires the construction of the AH header after the construction of the partial IP header. We say partial because the length field in the IP header will change once the AH header is added to the payload and this implies that the checksum has to be recalculated. In IPv4, some fields such the TTL and checksum are modified during the flow. In IPv6, hop-by-hop options change. If the hash is calculated over these fields, the authentication will fail at the destination. In order to avoid this, AH zeros out all these fields when it calculates the hash. The rules for calculating the AH were described in the AH chapter.
ESP Processing
The transport mode ESP involves encrypting the transport payload and calculating the hash. As was mentioned while describing ESP, either the encryption or the authentication can be NULL. This is specified in the SA. The transport mode ESP header is constructed before the IP header is added to the payload. This simplifies the implementation because it is not necessary to insert any headers in the middle of a buffer. After the ESP transform is applied to the transport payload and the ESP header is added, the ESP packet is forwarded to the IP layer for IP processing.
AH Processing
AH processing is not as clean as ESP because it expects part of the IP header to be constructed before it calculates the hash. The AH header has to be inserted in the middle of a packet and this leads to inefficient implementations because this involves buffer traversals and potential memory copies that can be very expensive.
The rules for calculating the AH header were described in Chapter 6. Unlike ESP, AH processing cannot be performed at the entry of the ip_output function because it requires part of the IP header be constructed before it can calculate the hash. The ideal place to perform AH processing is just before the fragmentation check is performed. In most IP implementations, the IP header with the mandatory fields for AH calculation is constructed by this point.
Tunnel Mode Processing
Tunnel mode processing involves construction of an extra IP header. Also, tunnels can be nested and can be of any depth as long as they are nested properly. In this section, tunnel implementation when the nesting is only one level deep is discussed.
In our example, when router RA receives the packet, the output of the policy lookup is a pointer to the SARA->RB. The SA indicates that the packet should be protected by a tunnel mode ESP with 3DES. The source and destination fields in the SA record are the source and the destination values in the outer IP header. The router RA constructs a tunnel mode ESP header and forwards the packet to the IP layer for IP processing. The rules for building the IP header follow.
Tunnel mode processing on the hosts is different from that of the router because the host needs to add two IP headers and not one. One possible solution is to perform IPSec processing just before IP fragmentation. It is important to perform IPSec tunnel mode processing before fragmentation. After IPSec processing, the packet is passed back to the IP layer (i.e., call ip_output()). However, this time this function is called with a different destination address. The policy lookup for the tunneled destination indicates that the packets be forwarded without any additional processing. The packet is forwarded to the data link layer after the IP layer adds the IP header.
IPv4 Tunnel Header
The IPv4 tunnel header can carry either an IPv4 or an IPv6 packet. The outer header fields are constructed as follows:
Version: The value of this field is 4.
Header length: This value depends on what options are configured on the route. The options are never copied from the inner IP header to the outer IP header.
TOS: This value is always copied from the inner IP header. If the inner IP header is the IPv6 header, then the class value is mapped to the IPv4 TOS value. The class values for the IPv6 are not standardized. The IETF is in the process of redefining the usage of the TOS byte. Depending on what is standardized at the IETF, in future, the inner TOS byte may not be copied in its entirety.
Length: This value is constructed for the header after the entire datagram is constructed.
Identification: This field is constructed.
Flags: The value for the DF bit is determined based on the configuration. This is dependent on whether the PMTU is turned on or not. The value of MF depends on whether this datagram needs to be fragmented.
Fragment offset: This field is constructed as is normally done to construct an IP datagram.
TTL: If a node is forwarding a packet, then the TTL value of the inner header is decremented before the outer header is added. The TTL value of the outer header depends on the configuration for packets going over a particular interface.
Protocol: This value is the next immediate protocol IP is carrying. If the tunneled header is constructed to secure a packet, the probable values are 51 for AH or 50 for ESP.
Checksum: This field is constructed.
Source address: This is specified in the SA.
Destination address: This is specified in the SA.
Options: The options are never copied from the inner header to the outer header.
IPv6 Tunnel Header
The IPv6 tunnel header can carry either an IPv4 or IPv6 packet. The IPv6 tunnel header fields are derived as follows:
Version: This value is 6 (this represents IP version 6).
Class: This value is copied from the inner header if the inner header is IPv6, or the TOS byte is mapped to the class value if the inner header is IPv4.
Flow id: The flow id is copied from the inner header if the inner header is IPv6. If not, a configured value is copied into this field.
Length: This field is constructed after the packet has been constructed.
Next header: This value is the next immediate protocol IP is carrying. If the tunneled header is constructed to secure a packet, the probable values are AH or ESP. However, the tunneled header can be constructed to carry non-IPSec traffic as well. In this case the value will be a network protocol, such as routing header or IP header.
Hop limit: If a node is forwarding a packet, then the TTL value of the inner header is decremented before the outer header is added. The TTL value of the outer header depends on the configuration for packets going over a particular interface.
Source address: This is either specified in the SA or it is the interface over which the tunneled packet is sent out.
Destination address: This is specified in the SA.
Extension headers: The extension headers are never copied.
Multiple Header Processing
Multiple header processing is fairly complicated if multiple tunnels have to be constructed from the same node. Consider the example shown in Figure 9.4. Let us say that in order for host A to send a packet to the destination D, it has to authenticate it to firewall RC and send it encrypted to firewall RB.
Figure 9.4. Nested IPSec tunnel headers.
If all these rules are to be represented in a single policy, the construction of the headers gets fairly complicated. One solution to this problem is to limit the number of tunnels to just one in each policy. In this example, the policy indicates that for the host A to send a packet to the host D, it has to first authenticate to the router RC. The IPSec layer builds a tunneled AH packet to the router RC. After constructing the AH header, the IP layer is invoked to add the tunnel header. It uses the router RC address (2.2.3.3.) as the destination address in the selector field. The policy indicates that the packet has to be encrypted and tunneled to RB (6.6.6.6). IPSec processes the IP packet destined to 2.2.3.3, adding the ESP header and encrypting the payload. It then invokes the IP layer to add an additional header. It uses the router RB address (6.6.6.6) as the destination. At the entry, the IP layer checks the policy for the destination 6.6.6.6. The policy engine indicates that the packet can be sent in clear and this packet with multiple tunnels is dispatched.
The disadvantage of this approach is that the ability to have a policy on a per destination for nested tunnels is lost. For example, if there are two hosts behind router RC, it is not possible to have per host encryption policy from A to D. This is because the policy lookup for encryption is based on the destination address that is RC and not the true destination. Since this information is lost, it will not be possible to define per host encryption from A to D in our example. However, adding support for this increases the complexity of the implementation without providing too much capability.
Inbound Processing
Inbound processing is simpler than outbound processing mainly because header construction is more complicated than header checking. There is also no interaction with the key management system during inbound processing. The focus is more on the generic processingãthings that are common to both AH and ESP. In terms of AH and ESP processing, there is not much difference except for the transforms and header processing.
The IP layer is invoked by the layer 2 to process the packet that was received over an interface. This packet is the start of the IP payload and has the IP header at the start. The IP layer processes the packet (reassembly) and invokes the function that handles the input for a particular protocol. Most implementations have a function for each protocol that the IP layer can call to process the packet.
The IPSec layer registers with the IP layer indicating the function that the IP layer has to invoke for both AH and ESP. An implementation may register different functions for AH and ESP or register the same function and perform AH or ESP specific processing in the same function. The IP layer strips the IP header and invokes the IPSec layer with either an AH or ESP header at the beginning of the packet.
The following is the sequence of steps performed by the IPSec layer. Let us continue with the same example we considered for outbound processing. Let us consider the network shown in Figure 9.3. However, this time we will discuss from the perspective of inbound processing. In Figure 9.5, the SADB and the SPD for the receivers are also shown (note that the SPD entries are symmetric). We will first walk through the processing at the host B, a non-tunneled case.
The IPSec layer extracts the SPI from the AH or the ESP header, and the source and the destination IP addresses and protocol from the IP header. In our example, the AH header has an SPI value of 10 with source and destination being 1.1.1.1 and 2.2.2.2 respectively.
The IPSec component then fetches the SA from the SADB using the destination (2.2.2.2), protocol (AH), and SPI (10).
If the SADB does not find the SA, an error is logged and the packet is dropped.
If the SADB returns the SA, which is true in our example, the IPSec layer processes the packet according to the rules defined in AH and ESP chapters.
The policy corresponding to the packet is checked to determine if the IPSec processing is applied appropriately. The policy is obtained either by a pointer in the SA or by querying the SPD using the selectors. In the example, the SPD has an entry that specifies that any packets from 1.1.1.1 should have AH in transport mode using HMAC-MD5. The policy engine checks if this is true. In this case, the security afforded to the packet is what was specified in the policy and hence the packet is accepted.
Figure 9.5. Inbound IPSec processing.
The following failures are possible. In all these cases, the packet is dropped.
The antireplay option is turned on and the packet fails the replay check.
The authentication fails.
The length is incorrect.
The lifetime for the SA has expired.
The packet is decrypted but the protocol field contains an invalid value, or if there is a pad, the padding is incorrect.
If the packet is authenticated and/or decrypted correctly and antireplay is enabled, the replay window is updated.
In case of tunneling, the IPSec layer has to perform an extra check to determine if the SA that was used to process the packet was in fact established to process the packet from the actual source. This is achieved by using the inner-header destination address for SPD lookup. This check is extremely important. If this check is not performed it is possible to induce a recipient to process and/or forward spoofed packets that may be in violation of its local security policy. IPSec invokes the upper layer to process the packet. In case of tunneled packets, the upper layer is the IP layer itself.
Let us consider the tunneled processing at the router RB. RB receives a tunneled packet from RA. The processing of the packet is the same as the non-tunneled case until the policy is invoked. In our example, RB receives a packet from source 5.5.5.5 with tunneled ESP using 3DES using an SPI value of 11. The lookup in the SADB yields an SA pointer. However, when the policy engine is invoked, the source and the destination address will be that of the inner IP header. The values in this case are 1.1.1.1 and 2.2.2.2. The lookup in the SPD matches the entry whose from and to fields are network prefixes 2.2.2/24 and 1.1.1/24. They also indicate that the packet was tunneled by 5.5.5.5 that is also live in this case. As the security services afforded to the packet match to that in the SPD, the packet is forwarded to the actual destination.
For non-IPSec packets, the processing is limited to confirming that the packet without any security can in fact be admitted. This requires a lookup into the SPD to determine if the policy requires the packet to be secure.
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 |