Internet Protocol security (IPSec) is a protocol suite defined by the Internet Engineering Task Force (IETF) for securing Internet Protocol (IP) communication by authenticating and/or encrypting each IP packet of a communication session. Two communicating parties can encrypt data and/or authenticate the data originating at the IP layer to ensure data confidentiality, integrity and service availability.
Confidentiality is the security service that protects the disclosure of typically application level data, but also encompasses disclosure of communication which also can be a concern in some circumstances. Traffic flow confidentiality is the service that is applied to conceal source and destination addresses, message length, or frequency of communication.
IPSec supports two forms of integrity; connectionless and a form of partial sequence integrity. Connectionless integrity is a service that detects modification of an individual IP datagram, without regard to the ordering of the datagram in a stream of traffic. The form of partial sequence integrity offered in IPSec is referred to as anti-replay integrity, and it detects arrival of duplicate IP datagrams (within a constrained window). This is in contrast to connection-oriented integrity, which imposes more stringent sequencing requirements on traffic, e.g., to be able to detect lost or re-ordered messages. Although authentication and integrity services often are cited separately, in practice they are intimately connected and almost always offered in tandem.
Availability, when viewed as a security service, addresses the security concerns engendered by attacks against networks that deny or degrade service. For example, in the IPSec context, the use of anti-replay mechanisms in the underlying protocols, specifically AH and ESP, support availability to prevent attacks that malicious users initiate by resending captured packets.
IPSec uses two protocols to provide traffic security, Authentication Header (AH) and Encapsulating Security Payload (ESP). The IP Authentication Header (AH) provides connectionless integrity, data origin authentication, and an optional anti-replay service. The Encapsulating Security Payload (ESP) protocol may provide confidentiality (encryption), and limited traffic flow confidentiality.
ESP optionally provides confidentiality for traffic. The strength of the confidentiality service depends in part on the encryption algorithm employed, for which three main forms of encryption algorithm are possible. ESP may also optionally provide authentication, however the scope of the authentication offered by ESP is narrower than for AH since the external IP header (tunnel mode) and the ESP header is/are not protected under ESP authentication.
Data Encryption Standard with Cipher Block Chaining (DES-CBC) is a symmetric secret key algorithm that uses a key size of 64-bits, but is commonly known as a 56-bit key as the key has 56 significant bits; the least significant bit in every byte is the parity bit. Its use today is limited due to the capability for computational power to perform brute force attacks within a significantly limited time frame. Triple Data Encryption Standard (3DES) is a 168 bit encryption algorithm that involves an iteration of the DES process with the addition of an initialization vector (IV), a value used to disguise patterns in encrypted data to improve the overall confidentiality of data. The Advanced Encryption Standard (AES) supports up to 256 bit encryption employing again the CBC and IV for additional strength of encryption. As encryption becomes additionally more complex, so does the processing time needed to achieve encryption and decryption.
AH supports an MD5 algorithm that takes as input, a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of that input, while the SHA-1 produces a 160-bit message digest output. SHA-2 represents a next generation of authentication algorithms to extend security to authentication following discovery of certain weaknesses within SHA-1.
The term SHA-2 is not officially defined but is usually used to refer to the collection of the algorithms SHA-224, SHA-256, SHA-384, and SHA-512. VRP currently supported by the AR2200E however provides support only to SHA-256, SHA-384 and SHA-512, where the value represents the bit digest length.
A Security Association (SA) denotes a form of connection that is established in a single direction through which security services relevant to the traffic are defined. Security services are attributed to an SA in the form of either AH, or ESP, but not both. If both AH and ESP based protection is applied to a traffic stream, then two (or more) SAs are created to attribute protection to the traffic stream. In order to secure bi-directional communication between two hosts, or two security gateways as shown in the example, two Security Associations (one in each direction) are required.
IPSec SAs are established in either a manual mode or Internet Key Exchange (IKE) negotiation mode. Establishing SAs in manual mode requires all information such as those parameters displayed in the example, be configured manually. The SAs established in manual mode however will never age. Establishing SAs using IKE negotiation mode is simpler as IKE negotiation information needs to be configured only on two peers and SAs are created and maintained by means of IKE negotiation, for which the complexity exists mainly in the IKE automated negotiation process itself, and as such will not be covered in detail here. The SA established in IKE negotiation has a time-based or traffic-based lifetime. When the specified time or traffic volume is reached, an SA becomes invalid. When the SA is about to expire, IKE will negotiate a new SA.
A transport mode SA is a security association between two hosts. In IPv4, a transport mode security protocol header appears immediately after the IP header, any options, and before any higher layer protocols (e.g., TCP or UDP). In transport mode the protocols provide protection primarily for upper layer protocols. An AH or ESP header is inserted between the IP header and the transport layer protocol header. In the case of ESP, a transport mode SA provides security services only for these higher layer protocols, not for the IP header or any extension headers preceding the ESP header. In the case of AH, the protection is also extended to selected portions of the IP header, as well as selected options.
In the IPSec context, using ESP in tunnel mode, especially at a security gateway, can provide some level of traffic flow confidentiality. The outer IP header source address and destination address identify the endpoints of the tunnel. The inner IP header source and destination addresses identify the original sender and recipient of the datagram, (from the perspective of this tunnel), respectively.
The inner IP header is not changed except to decrement the TTL, and remains unchanged during its delivery to the tunnel exit point. No change occurs to IP options or extension headers in the inner header during delivery of the encapsulated datagram through the tunnel. An AH or ESP header is inserted before the original IP header, and a new IP header is inserted before the AH or ESP header.
The example given shows the IPSec tunnel mode during TCP based packet transmission. If AH is also applied to a packet, it is applied to the ESP header, Data Payload, ESP trailer, and ESP Authentication Data (ICV), if fields are present.
The implementation of an IPSec Virtual Private Network (VPN) requires that network layer reachability between the initiator and the recipient is verified to ensure non-IPSec communication is possible before building any IPSec VPN. Not all traffic is required to be subjected to rules of integrity or confidentiality, and therefore traffic filtering needs to be applied to the data flow to identify the interesting traffic for which IPSec will be responsible. A data flow is a collection of traffic and can be identified by the source address/mask, destination address/mask, protocol number, source port number, and destination port number. When using VRP, data flows are defined using ACL groups. A data flow can be a single TCP connection between two hosts or all traffic between two subnets. The first step to configure IPSec involves defining these data flows.
An IPSec proposal defines the security protocol, authentication algorithm, encryption algorithm, and encapsulation mode for the data flows to be protected. Security protocols AH and ESP can be used independently or together. AH supports MD5, SHA-1 and SHA-2 authentication algorithms. ESP supports three authentication algorithms (MD5, SHA-1 and SHA-2) and three encryption algorithms (DES, 3DES, and AES). IPSec also supports both transport and tunnel encapsulation modes. To Transmit the same data flow, peers on both ends of a security tunnel must use the same security protocol, authentication algorithm, encryption algorithm, and encapsulation mode. To implement IPSec between two gateways, it is advised to use tunnel mode to shield the actual source and destination IP addresses used in communication.
An IPSec policy defines the security protocol, authentication algorithm, encryption algorithm, and encapsulation mode for data flows by referencing an IPSec proposal. The name and sequence number uniquely identify an IPSec policy. IPSec policies are classified into IPSec policies used for manually establishing SAs, and IPSec policies used for establishing SAs through IKE negotiation.
To configure an IPSec policy used for manually establishing SAs, set parameters such as the key and SPI. If the tunnel mode is configured, the IP addresses for two endpoints of a security tunnel also must be set. When configuring an IPSec policy used for establishing SAs through IKE negotiation, parameters such as the key and SPI do not need to be set as they are generated through IKE negotiation automatically. IPSec policies of the same name but different sequence numbers comprise an IPSec policy group.
In an IPSec policy group, an IPSec policy with a smaller sequence number has a higher priority. After an IPSec policy group is applied to an interface, all IPSec policies in the group are applied to the interface. This enables different SAs to be used for different data flows.
Communication at the network layer represents the initial prerequisite of any IPsec VPN connection establishment. This is supported in this example through the creation of a static route pointing to the next hop address of RTB. It is necessary to implement static routes in both direction to ensure bidirectional communication between networks. An advanced ACL is created to identify the interesting traffic for which the IPsec VPN will be initiated, whereby the advanced ACL is capable of filtering based on specific parameters and will choose to either Discard, Bypass or Protect the filtered data.
The ipsec proposal command creates an IPSec proposal and enters the IPSec proposal view. When configuring an IPSec policy, it is necessary to reference an IPSec proposal for specifying the security protocol, encryption algorithm, authentication algorithm, and encapsulation mode used by both ends of the IPSec tunnel. A new IPSec proposal created using the ipsec proposal command by default uses the ESP protocol, DES encryption algorithm, MD5 authentication algorithm, and tunnel encapsulation mode. These can be redefined using various commands under the IPSec proposal view. The transform [ah | ah-esp | esp] will enable the current transform set to be altered, the encapsulation-mode {transport | tunnel } can alter the means used to encapsulate packets.
The authentication algorithm used by the ESP protocol can be set using the esp authentication-algorithm [md5 | sha1 | sha2-256 | sha2-384 | sha2-512 ] and esp encryption-algorithm [des | 3des | aes-128 | aes-192 | aes-256 ] for ESP encryption assignment. The AH protocol ah authentication-algorithm [md5 | sha1 | sha2-256 | sha2-384 | sha2-512 ] command enables AH based authentication to be set.
Verification of the parameters for the IPSec proposal can be achieved through the display ipsec proposal [name <proposal-name>] command. As a result it is possible to view select proposals or all proposals that have been created. The name defines the name given to the IPSec proposal created, while the encapsulation mode lists the current mode that is being used for this given proposal, which may either be transport or tunnel. Transform refers to the algorithms being applied where this may be AH, ESP or a combination of AH and ESP transforms. Depending on the transform defined, the associated algorithms will be listed.
The policy-name and seq-number parameters identify an IPSec policy. Multiple IPSec policies with the same IPSec policy name constitute an IPSec policy group. An IPSec policy group contains a maximum of 16 IPSec policies, and an IPSec policy with the smallest sequence number has the highest priority. After an IPSec policy group is applied to an interface, all IPSec policies in the group are applied to the interface to protect different data flows. Along with the policy-name and seqnumber, the policy must define the creation of SA either manually or through IKE negotiation.
If IKE negotiation is used, parameters must be set using the ipsec-policy-template command, while where set manually parameters are configured as shown in the example. The created ACL is bound with the policy along with the created proposal. The tunnel local and tunnel remote commands define the interface at which the IPSec tunnel will establish and terminate. A source parameter index (SPI) is defined both inbound and outbound.
The inbound SPI on the local end must be the same as the outbound SPI on the remote end. The outbound SPI on the local end must be the same as the inbound SPI on the remote end. This number is used to reference each SA, bearing in mind that an SA applies in only one direction therefore requiring SPI in both directions to be specified. Finally authentication keys must be defined again both inbound and outbound. The outbound authentication key on the local end must be the same as the inbound authentication key on the remote end. Where IKE negotiation is used, both the SPI and authentication keys are automatically negotiated.
Following the creation of a policy and the binding of the proposal and ACL to the policy, the policy itself can be applied to the physical interface upon which traffic will be subjected to IPSec processing. In the example given an IPSec tunnel is to be established between interface Gigabit Ethernet 0/0/1 of RTA and Gigabit Ethernet 0/0/1 of RTB. Under the interface view, the ipsec policy command is used to apply the created policy to the interface.
One interface can only use one IPSec policy group. To apply a new IPSec policy group to the interface, the previous policy group must be firstly removed. An IPSec policy group that establishes an SA through IKE negotiation can be applied to multiple interfaces, whereas an IPSec policy group that establishes an SA in manual mode can be applied only to one interface. When sending a packet from an interface, the AR2200 matches the packet with each IPSec policy in the IPSec policy group. If the packet matches an IPSec policy, the AR2200 encapsulates the packet according to the policy. If not, the packet is sent without encapsulation.
Using the display ipsec policy [brief | name policy-name [ seq-number ] ] command, a specific IPSec policy or all IPSec policies can be viewed. The parameters of the IPSec policy displayed include the policy name and the sequence number of the policy, typically used to distinguish the priority of policies in a group where a lower sequence number represents a higher priority. The policy bindings such as the name of the proposal and ACL that is used to filter the traffic in a policy is displayed along with the local and remote tunnel addresses for the IPSec policy
Specific parameter settings are also defined within the display ipsec policy command for SA in both the inbound and outbound directions. The SPI references the SA in each direction which can be used as part of the troubleshooting process to ensure that the SPI on the outbound local interface matches to that set for the inbound remote interface on the peer interface (that matches the tunnel remote address). The key string will also be defined for both the inbound and outbound SA to which the same local and remote configuration assessment can be performed.
A security association can be understood as a unidirectional connection or management construct that defines the services that will be used in order to negotiate the connection’s establishment. The connection relies on matching SA in both directions in order to successfully establish secure bidirectional communication.
All traffic that is destined to be forwarded via the outbound interface on which IPSec is established will firstly be subjected to filtering via a Security Policy Database (SPD). This is generally in the form of an ACL that will determine whether the traffic should be either dropped (Discard), forwarded normally (Bypass), or forwarded over a secure IPSec boundary (Protect).