ESP Processing
Processing of an IP packet with ESP depends partly on the mode in which ESP is being employed. In either case, though, one thing to remember is that with ESP, the cipher text is authenticated. The authenticated plaintext is not encrypted. What this means is that, for outbound packets encryption happens first and for inbound packets authentication happens first.
For interoperability purposes mandatory-to-implement algorithms have been defined for ESP. The must-implement authenticators are HMAC-MD5-96 and HMAC-SHA-96, RFC2403 and RFC2404, respectively. Originally the must-implement cipher was DES-CBC with an explicit IV, as defined in RFC2405 but after the IPSec documents advanced from Internet-Draft to RFC status a (relatively) low-cost DES cracker was built. This cracker, named Deep Crack, was able to determine a DES key in merely 56 hours. Several months later, at a conference in San Jose, California, DES was broken in just 22 hours! Because of this, the RFCs all have statements indicating the deprecated nature of DES and suggest using stronger cipher algorithms for ESP, such as AES. Deep Crack has no impact on the mandatory-to-implement authenticators and they are believed to be secure.
Outbound Processing
For transport mode application running over IPv4, the ESP header is inserted into an outbound IP packet immediately after the IP header (including any options the IP header may have). The protocol field of the IP header is copied into the next header field of the ESP header and the remaining fields of the ESP header are filled in the SPI field is assigned the SPI from the particular SA in the SADB used to process this packet, the sequence number field is filled with the next value in the sequence, the pad is inserted and its value assigned, and the pad length value is assigned. The protocol field of the IP header is then given the value of ESP, or 50.
The rules for IPv6 processing are similar to IPv4 processing except for the insertion of the header. The ESP header is inserted after any extension headers that may be modified en route.
For tunnel mode application, the ESP header is prepended to the IP packet. The next header field of the ESP header is assigned the value four (4) if it is encapsulating an IPv4 packet and a value 41 if it is encapsulating an IPv6 packet. The remaining fields are filled in in the same manner as in transport mode. Then a new IP header is prepended to the ESP header and the appropriate fields are filled in the source address is the device itself which is applying the ESP, the destination address is taken from the SA used to apply ESP, the protocol is set to fifty (50), and the rest are filled in according to local IP processing.
Regardless of mode, the next steps are identical. The packet, from the beginning of the payload data to the next header field, is encrypted using the cipher and encryption key in the appropriate SA. Then the packet, from the ESP header, through the encrypted ciphertext, to the ESP trailer, is authenticated using the authenticator and the authenticator key in the appropriate SA. The result of the authenticator is then inserted into the authentication data field of the ESP trailer.
The final step in outbound processing is to recompute the checksum of the IP header that precedes the ESP header.
Note that a fragmentation check need not be employed when adding the ESP header. If the resulting packet (after ESP has been employed) is larger than the MTU of the interface from which it is traveling, it will merely be fragmented. This is no different than if a whole, complete, ESP packet left the device and was fragmented somewhere in the network. We'll let the input processing deal with that.
Input Processing
Upon receipt of an ESP packet the receiver has no way of knowing whether the packet is in tunnel mode or transport mode without processing it. Based upon the SA used to process the packet, he'll know what it should be, but until it is decrypted there is practically no way to know what ESP is protecting. This is a good thing because any person doing traffic analysis would not know either!
If a received IPSec packet is a fragment, it must be retained until all fragments have been received. A fragmented IPSec packet cannot be processed because it would fail the first check made upon it a data integrity check.
The first thing the recipient of an ESP packet does is check whether an SA exists to process it this is a basic IPSec requirement and not particular to ESP. If there is no SA the packet must be dropped. Input processing can begin only if an SA exists.
Once a valid SA has been identified, it is used to process the packet. The sequence number is checked first. If the sequence number of the packet is valid that is, it is not a duplicate and is not to the right of the sequence number window contained in the SA processing proceeds. Since ESP authenticates ciphertext and not plaintext, the next thing to do is authenticate the packet. The entire ESP packet, minus the authentication data of course, is passed with the appropriate key to the authenticator algorithm from the SA. If the resulting digest matches the data contained in the Authentication Data field (taking into account any truncation that the authentication algorithm may require), the packet is authenticated. The next step is decryption. The ESP packet, from the beginning of the payload data to the next header field, is decrypted using the key and cipher algorithm from the SA. A simple check to determine whether decryption was successful is a check of the pad. Since the content of the pad is deterministic it's either a monotonically increasing number starting at one or it's dependent on the encryption algorithm verifying the contents of the pad will determine whether the packet has decrypted successfully.
There is a clever optimization that can be made in ESP input processing. The ciphertext is authenticated, not the other way around, so neither the decryption nor verification steps depend on each other. It is therefore easy to parallelize ESP input processing by giving a copy of the authenticated and encrypted packet to the verification engine and the decryption engine. One engine doesn't have to wait until the other engine is finished and the packet is processed more quickly.
After successfully passing both authentication and decryption checks, a preliminary validity check of the resulting packet can be made. If the SA used to process the packet dictates that only ESP packets in a particular mode either transport or tunnel mode can be processed, the packet must be checked for compliance. If the packet does not correspond to the required mode it must be dropped. In Chapter 7 we'll discuss how IKE can create IPSec SAs for an explicit mode.
The packet can now be rebuilt without the ESP header. For transport mode, the upper-layer protocol header is synced up with the IP header, the next header field from the ESP header is copied into the protocol field of the IP header, and a new IP checksum computed; for tunnel mode the outer IP header and the ESP header can merely be thrown away the decapsulated packet is what we need. At this point, regardless of the ESP mode, another validity check has to be made with the SPD entry that corresponds with the SA used to proces the packet. The SPD may require that packets protected by this SA be only for a particular host and/or for a particular port or protocol. If the packet does not correspond to the required address and/or port and/or protocol dictated by the SPD, it must be dropped.
A reconstructed and validated packet can now be forwarded for further processing. If it is a transport mode packet, it is given up to a higher layer like TCP or UDP for processing; if it is a tunnel mode packet, it is reinserted into the IP processing stream and forwarded on to its ultimate destination (which may be the same host).
If the reconstructed and validated packet is a fragment, it may be necessary to hold on to this packet until all fragments are received, reconstructed, and validated, and all the fragments have been reassembled. This would be necessary if IPSec was being applied by a network entity, in tunnel mode, on behalf of another host, and the SA that was used to process the packet(s) dictated that only packets for a particular port are allowed. Because any fragments would not have that information in them the only choice besides retaining fragments and reassembling a whole packet would be to forward all fragments on to the destination. Because the destination would not have the SA information, it would not know if the reconstructed packet was valid or not (from a security policy point of view). For processing speed reasons, it is recommended that network entities (such as routers) applying IPSec to transient traffic not retain decrypted and validated fragments if it is not required. Note that this case is different than receiving fragmented IPSec packets that must always be retained until a complete IPSec packet can be reassembled.
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 |