IPsec support in Click Router

Click IPsec ESP Support

IPsec ESP support in click router is summarized in the following processing modules:

  • IPsecRouteTable: This routing table can be edited from user space as a typical Click IP routing table but (optionally) Security Parameters may be entered for each route. The security parameters are the SPI, 128bit Authentication key (for HMAC), 128bit Encryption Key, Replay start counter, Replay last sequence Replay Window size. Apart from the SPI the rest of the Security attributes are organized in a separate class called SADataTuple and the IPsecRouteTable just holds the SPI and a reference pointer to this class. This scheme is used so that the reference pointer can be directly passed to the next IPsec processing modules through the Click packet annotation mechanism. Moreover the SPI and SADataTuple instance are further associated in a hash table that forms the IPsec Security Association Database and is a private member of IPsecRouteTable. The IPsecRouteTable can be looked up, for the time being, using only RadixLookup algorithm. Support for the other lookup algorithms is a pending task.
  • ESPEncap: This module existed in the primary ipsec support for click and minor modifications have been made, so that this module instead of hardcoded parameters to use the annotation space reference to retrieve SPI and replay counter. Since encryption algorithms work on 8 or 16 byte blocks the final ESP packet size is padded to be a multiplier of 8 bytes. This calculation for padding does not include the HMAC message digest which will be added later to the packet because it does not get encrypted. Therefore in case a 16 byte block encryption algorithm is used 8 bytes of the message digest will get encrypted in case the ESP packet size is not a multiplier of 16 bytes.
  • ESPUncap: This module rips off the esp header. It existed in the primary implementation but it has been heavily changed to implement replay prevention check.
  • HMAC: The OpenSSL library HMAC SHA1 implementation is used in this module. The 20 byte message digest is appended in the packet.
  • IPsecEncap: This module encapsulates the esp packet into an IP packet. The source and destination addresses of the new IP header are the ones of the source and destination gateways. The address assignment takes place as follows. The destination gateway address can be retrieved from packet annotation space where it is placed by the IPsecRoutingTable module and the for the source IP address we use Click’s FixIPSource logic which is to set a special flag in the annotation space and when the packet enters the outgoing path of a specific interface then FixIPsource module edits the IP header and adds the outgoing interface address as the source IP.
  • 128-bit AES and 64-bit DES encryption: Both are derived and adapted from OpenSSL library. The DES version belongs to the primary click ipsec support and has been changed to use Security Parameter annotations.
  • Replay Prevention: (Derived from ipsec 0.5 documentation by John Ioannidis for the linux kernel). Replay Prevention is an unsigned 32 bit incrementing counter starting at a mutual agreed upon value and is enforced to be within a mutually negotiated window size. The key (K, as described in a later section) MUST be changed fre quently enough so that the counter is not allowed to return to the initial value; in other words, the key MUST be changed before 2^32 packets are transmitted using this key. For a given SPI, counter wrapping MUST be considered to be a replay attack. (While a wrap is a replay attack, there is always the possibility that a packet can get duplicated, so the presence of a single or small number of duplicate packets is not an absolute indication of a replay attack.) The receiver MUST verify that for a given SPI the packets received have non-repeating (non-duplicate) counter values. This can be implemented as a simple increasing count test or the receiver MAY choose to accept out-of-order packets as long as it is guaranteed that packets can be received only once. For example, an implementation can use a sliding receive window. If such a receive window is supported, the receiver MUST ensure that it will accept packets within the current window only once, and reject any packets it receives with a value that is less than the lower bound of the window. Negotiated window sizes of 1 and 32 are suggested and larger multiples of 32 are allowed. 1 indicates that only constantly increasing replay numbers are allowed and packets which have replay values less than the highest received are always rejected. 32 indicates that are within 32 of the highest received, and are guaranteed not to have been received before, are allowed. A window size of 1 MUST be supported. A value of 32 SHOULD be supported. If a value of 32 is negotiated, then the most recent 32 packets are allowed to arrive out of order. That is, these 32 packets can arrive in any sequence relative to each other except that these packets are guaranteed to arrive only once.
The IPsec Flow in Click router

When a packet reaches the IPsecRouteTable the following checks take place: If the packet is for this Router the IP protocol number is checked. If it is protocol number 50 this is an ESP packet, the SPI is read from the ESP data, is used to retrieve the corresponding Security Association attributes from the hash table, the packet annotations are set accordingly and, finally, it is directed to IPsec Incoming Path. If it is a packet for a prefix where the corresponding IPSec Entry has SPI > 0 then this packet should be directed to IPsec Outgoing Path.

IPsec Incoming Path

This path has the following processing stages: Remove external IP header -> Decrypt -> (Authenticate, Remove digest) -> (CheckReplay, Remove ESP) -> Retrieve new Route

IPsec Outgoing Path

This path has the following processing stages: (ESP encapsulation, Increment Replay)-> (Authenticate, add digest) -> Encrypt-> IP encapsulation -> Retrieve new Route --- Dimitris G. Syrivelis 2007/02/04 13:43

 
docs/ipsec-doc.txt · Last modified: 2007/02/04 13:47 by jsyr
 
Recent changes RSS feed Driven by DokuWiki