- A router seeking to establish or maintain a neighbor relationship with a router in another routing domain is an authorized router.
- A redirect message comes from the router to which the initial IP packet was sent.
Without such security measures, an opponent can disrupt communications or divert some traffic. Routing protocols such as Open Shortest Path First (OSPF) should be run on top of security associations between routers that are defined by IPsec.
1.5 IPsec Documents
Architecture: Covers the general concepts, security requirements, definitions, and mechanisms defining IPsec technology. The current specification is RFC4301, Security Architecture for the Internet Protocol.
Authentication Header (AH): An extension header to provide message authentication. The current specification is RFC 4302, IP Authentication Header.
Encapsulating Security Payload (ESP): ESP Consists of an encapsulating header and trailer used to provide encryption or combined encryption/authentication. The current specification is RFC 4303, IP Encapsulating Security Payload (ESP).
Internet Key Exchange (IKE): A collection of documents describing the key management schemes for use with IPsec. The main specification is RFC 5996, Internet Key Exchange (IKEv2) Protocol, but there are a number of related RFCs.
Cryptographic algorithms: This category encompasses a large set of documents that define and describe cryptographic algorithms for encryption, message authentication, pseudorandom functions (PRFs), and cryptographic key exchange.
Other: There are a variety of other IPsec-related RFCs, including those dealing with security policy and management information base (MIB) content.
1.6 IPsec Services
IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services.
Two protocols are used to provide security: Authentication Header (AH) and Encapsulating Security Payload (ESP).
RFC 4301 lists the following services:
- Access control
- Connectionless integrity
- Data origin authentication
- Rejection of replayed packets (a form of partial sequence integrity) Confidentiality (encryption)
1.7 Transport and Tunnel Modes
Transport Mode provides protection primarily for upper-layer protocols. Examples include a TCP or UDP segment or an ICMP packet. Typically used for end-to-end communication between two hosts (e.g., a client and a server, or two workstations). ESP in transport mode encrypts and optionally authenticates the IP payload but not the IP header. AH in transport mode authenticates the IP payload and selected portions of the IP header.
Tunnel Mode provides protection to the entire IP packet. It is used when one or both ends of a security association (SA) are a security gateway, such as a firewall or router that implements IPsec. With tunnel mode, a number of hosts on networks behind firewalls may engage in secure communications without implementing IPsec. ESP in tunnel mode encrypts and optionally authenticates the entire inner IP packet, including the inner IP header. AH in tunnel mode authenticates the entire inner IP packet and selected portions of the outer IP header.
1.8 IP Security Policies
1.8.1 Security Association (SA)
An association is a one-way logical connection between a sender and a receiver that affords security services to the traffic carried on it . A security association is uniquely identified by three parameters. They are Security Parameters Index (SPI), IP Destination Address, and Security Protocol Identifier. In any IP packet, the SA is uniquely identified by the Destination Address in the IPv4 or IPv6 header and the SPI in the enclosed extension header (AH or ESP).
1.8.2 Security Association Database
Security Association Database that defines the parameters associated with each SA. A security association is normally defined by the following parameters in a SAD entry.
Security Parameter Index: A 32-bit value selected by receiving end of an SA to uniquely identify the SA.
Sequence Number Counter: A 32-bit value used to generate the Sequence Number field in AH or ESP headers.
Sequence Counter Overflow: A flag indicating whether overflow of the Sequence Number Counter should generate an auditable event and prevent further transmission of packets on this SA.
Anti-Replay Window: Used to determine whether an inbound AH or ESP packet is a replay.
AH Information: Authentication algorithm, keys, key lifetimes, and related parameters being used with AH.
ESP Information: Encryption and Authentication algorithm, keys, initialization values, key lifetimes, and related parameters being used with ESP.
Lifetime of this Security Association: A time interval or byte count after which an SA must be replaced with a new SA or terminated, plus an indication of which of these actions should occur.
IPsec Protocol Mode: Tunnel, transport, or wildcard.
Path MTU: Any observed path maximum transmission unit and aging variables.
1.8.3 Security Policy Database (SPD)
The means by which IP traffic is related to specific SAs is the nominal Security Policy Database (SPD). The SPD contains entries, each of which defines a subset of IP traffic and points to an SA for that traffic. In more complex environments, there may be multiple entries that potentially relate to a single SA or multiple SAs associated with a single SPD entry. Each SPD entry is defined by a set of IP and upper-layer protocol field values called selectors. These are used to filter outgoing traffic in order to map it into a particular SA. The following selectors determine an SPD entry:
Remote IP address: This may be a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address. The latter two are required to support more than one destination system sharing the same SA.
Local IP address: This may be a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address. The latter two are required to support more than one source system sharing the same SA.
Next layer protocol: The IP protocol header includes a field that designates the protocol operating over IP.
Name: A user identifier from the operating system. This is not a field in the IP or upper-layer headers but is available if IPsec is running on the same operating system as the user.
Local and remote ports: These may be individual TCP or UDP port values, an enumerated list of ports, or a wildcard port.
1.8.4 IP Traffic Processing
IPsec is executed on a packet-by-packet basis. When IPsec is implemented, each outbound IP packet is processed by the IPsec logic before transmission, and each inbound packet is processed by the IPsec logic after reception and before passing the packet contents on to the next higher layer.
following steps occur:
- IPsec searches the SPD for a match to this packet.
- If no match is found, then the packet is discarded and an error message is generated.
- If a match is found, further processing is determined by the first matching entry in the SPD. If the policy for this packet is DISCARD, then the packet is discarded. If the policy is BYPASS, then there is no further IPsec processing; the packet is forwarded to the network for transmission.
- If the policy is PROTECT, then a search is made of the SAD for a matching entry. If no entry is found, then IKE is invoked to create an SA with the appropriate keys and an entry is made in the SA.
- The matching entry in the SAD determines the processing for this packet. An encryption, authentication, or both can be performed, and either transport or tunnel mode can be used. The packet is then forwarded to the network for transmission.
1.9 Encapsulating Security Payload (ESP)
The ESP provides confidentiality services. As an optional feature, ESP can also provide authentication service. The format of ESP is as in Figure 1.4.
1.9.1 ESP Format:
SPI identifies a security association. Sequence number is similar to that of AH. These two 32-bit words are the head of ESP. Payload Data is a transport level segment (transport mode) or IP packet (tunnel mode) that is protected by encryption. The length of payload data is variable. The length of padding is between 0 to 255 bytes. The padding is used to satisfy the requirement of encryption function and the requirement of the alignment of the ESP format. Sometimes, padding also can be used to provide partial traffic flow confidentiality by concealing the actual length of the payload. Pad length (8 bites) indicates the number of pad bytes. Next header (8 bits) identifies the type of data contained in the payload data field (first header in that payload). The Authentication Data field contains the Integrity check value (ICV).
1.9.2 Encryption and Authentication Algorithms:
The algorithm is used to encrypt the Payload Data, Padding, Pad Length, and Next Header fields. If the algorithm requires cryptographic synchronization data then these data may be carried explicitly at the beginning of the Payload Data field. An optional ICV field is present only if the integrity service is selected and is provided by either a separate integrity algorithm or a combined mode algorithm that uses an ICV. ICV is computed after the encryption is performed. This order of processing facilitates reducing the impact of DoS attacks. Because the ICV is not protected by encryption, a keyed integrity algorithm must be employed to compute the ICV.
1.9.3 Padding:
The Padding field serves several purposes:
- If an encryption algorithm requires the plaintext to be a multiple of some number of bytes, the Padding field is used to expand the plaintext to the required length.
- Used to assure alignment of Pad Length and Next Header fields.
- Additional padding may be added to provide partial traffic-flow confidentiality by concealing the actual length of the payload.
1.9.4 Anti-Replay Service:
• A replay attack is one in which an attacker obtains a copy of an authenticated packet and later transmits it to the intended destination.
The receipt of duplicate, authenticated IP packets may disrupt service in some way or may have some other undesired consequence. The Sequence Number field is designed to thwart such attacks. First, we discuss sequence number generation by the sender, and then we look at how it is processed by the recipient.
1.9.5 Transport and Tunnel Modes:
Figure 1.6 shows two ways in which the IPsec ESP service can be used. In the upper part of the figure, encryption (and optionally authentication) is provided directly between two hosts. Figure 1.6b shows how tunnel mode operation can be used to set up a virtual private network. In this example, an organization has four private networks interconnected across the Internet. Hosts on the internal networks use the Internet for transport of data but do not interact with other Internet-based hosts. By terminating the tunnels at the security gateway to each internal network, the configuration allows the hosts to avoid implementing the security capability.
The former technique is supported by a transport mode SA, while the latter technique uses a tunnel mode SA. In this section, we look at the scope of ESP for the two modes. The considerations are somewhat different for IPv4 and IPv6. We use the packet formats of Figure 1.7a as a starting point.
1.9.5.1 Transport Mode ESP:
Transport mode ESP is used to encrypt and optionally authenticate the data carried by IP (e.g., a TCP segment), as shown in Figure 1.7b. For this mode using IPv4, the ESP header is inserted into the IP packet immediately prior to the transport-layer header (e.g., TCP, UDP, ICMP), and an ESP trailer (Padding, Pad Length, and Next Header fields) is placed after the IP packet. If authentication is selected, the ESP Authentication Data field is added after the ESP trailer. The entire transport-level segment plus the ESP trailer are encrypted. Authentication covers all of the ciphertext plus the ESP header.
In the context of IPv6, ESP is viewed as an end-to-end payload; that is, it is not examined or processed by intermediate routers. Therefore, the ESP header appears after the IPv6 base header and the hop-by-hop, routing, and fragment extension headers. The destination options extension header could appear before or after the ESP header, depending on the semantics desired. For IPv6, encryption covers the entire transport-level segment plus the ESP trailer plus the destination options extension header if it occurs after the ESP header.
Again, authentication covers the ciphertext plus the ESP header.
Transport mode operation may be summarized as follows.
1. At the source, the block of data consisting of the ESP trailer plus the entire transport-layer segment is encrypted and the plaintext of this block is replaced with its ciphertext to form the IP packet for transmission. Authentication is added if this option is selected.
2. The packet is then routed to the destination. Each intermediate router needs to examine and process the IP header plus any plaintext IP extension headers but does not need to examine the ciphertext.
- The destination node examines and processes the IP header plus any plaintext IP extension headers. Then, on the basis of the SPI in the ESP header, the destination node decrypts the remainder of the packet to recover the plaintext transport-layer segment.
Transport mode operation provides confidentiality for any application that uses it, thus avoiding the need to implement confidentiality in every individual application. One drawback to this mode is that it is possible to do traffic analysis on the transmitted packets.
1.9.5.1 Tunnel Mode ESP:
Tunnel mode ESP is used to encrypt an entire IP packet (Figure 1.7c). For this mode, the ESP header is prefixed to the packet and then the packet plus the ESP trailer is encrypted. This method can be used to counter traffic analysis. Because the IP header contains the destination address and possibly source routing directives and hop-by-hop option information, it is not possible simply to transmit the encrypted IP packet prefixed by the ESP header. Intermediate routers would be unable to process such a packet. Therefore, it is necessary to encapsulate the entire block (ESP header plus ciphertext plus Authentication Data, if present) with a new IP header that will contain sufficient information for routing but not for traffic analysis.
Whereas the transport mode is suitable for protecting connections between hosts that support the ESP feature, the tunnel mode is useful in a configuration that includes a firewall or other sort of security gateway that protects a trusted network from external networks. In this latter case, encryption occurs only between an external host and the security gateway or between two security gateways. This relieves hosts on the internal network of the processing burden of encryption and simplifies the key distribution task by reducing the number of needed keys. Further, it thwarts traffic analysis based on ultimate destination.
Fig 1.7 shows the protocol architecture for two modes.
1.10 Combining Security Associations
An individual SA can implement either the AH or ESP protocol but not both. Sometimes a particular traffic flow will call for the services provided by both AH and ESP.
- Security association bundle
It refers to a sequence of SAs through which traffic must be processed to provide a desired set of IPsec services. The SAs in a bundle may terminate at different endpoints or at the same endpoint.
- Security associations may be combined into bundles in two ways:
- Transport adjacency: Refers to applying more than one security protocol to the same IP packet without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit since the processing is performed at one IPsec instance: the (ultimate) destination.
- Iterated tunneling: Refers to the application of multiple layers of security protocols affected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec site along the path. The two approaches can be combined, for example, by having a transport SA between hosts travel part of the way through a tunnel SA between security gateways.
- – One interesting issue that arises when considering SA bundles is the order in which authentication and encryption may be applied between a given pair of endpoints and the ways of doing so.
1.10.1 Authentication and Confidentiality
Encryption and authentication can be combined in order to transmit an IP packet that has both confidentiality and authentication between hosts. We look at several approaches.
ESP with Authentication Option: In this approach, the first user applies ESP to the data to be protected and then appends the authentication data field.
- Transport mode ESP: Authentication and encryption apply to the IP payload delivered to the host, but the IP header is not protected.
- Tunnel mode ESP: Authentication applies to the entire IP packet delivered to the outer IP destination address (e.g., a firewall), and authentication is performed at that destination. The entire inner IP packet is protected by the privacy mechanism for delivery to the inner IP destination.
For both cases authentication applies to the cipher text rather than the plaintext.
Another way to apply authentication after encryption is to use two bundled transport SAs, with the inner being an ESP SA and the outer being an AH SA. In this case ESP is used without its authentication option. Because the inner SA is a transport SA, encryption is applied to the IP payload. AH is then applied in transport mode. The advantage of this approach is that the authentication covers more fields. The disadvantage is the overhead of two SAs versus one SA.
The use of authentication prior to encryption might be preferable for several reasons:
- It is impossible for anyone to intercept the message and alter the authentication data without detection.
- It may be desirable to store the authentication information with the message at the destination for later reference.
One approach is to use a bundle consisting of an inner AH transport SA and an outer ESP tunnel SA.
- Authentication is applied to the IP payload plus the IP header. The resulting IP packet is then processed in tunnel mode by ESP; the result is that the entire authenticated inner packet is encrypted and a new outer IP header is added.
- Basic Combinations of Security Associations
The IPsec Architecture document lists four examples of combinations of SAs that must be supported by compliant IPsec hosts (e.g., workstation, server) or security gateways (e.g., firewall, router). These are illustrated in Figure 1.8. The lower part of each case in the figure represents the physical connectivity of the elements; the upper part represents logical connectivity via one or more nested SAs. Each SA can be either AH or ESP. For host-to-host SAs, the mode may be either transport or tunnel; otherwise it must be tunnel mode.
Figure 1.8 Basic Combinations of Security
Associations 1.11 Internet Key Exchange
The key management portion of IPsec involves the determination and distribution of secret keys. A typical requirement is four keys for communication between two applications: transmit and receive pairs for both integrity and confidentiality. The IPsec Architecture document mandates support for two types of key management:
• Manual: A system administrator manually configures each system with its own keys and with the keys of other communicating systems. This is practical for small, relatively static environments.
• Automated: An automated system enables the on-demand creation of keys for SAs and facilitates the use of keys in a large distributed system with an evolving configuration.
The default automated key management protocol for IPsec is referred to as ISAKMP/Oakley and consists of the following elements:
- Oakley Key Determination Protocol: Oakley is a key exchange protocol based on the Diffie-Hellman algorithm but providing added security. Oakley is generic in that it does not dictate specific formats.
Internet Security Association and Key Management Protocol (ISAKMP):
ISAKMP provides a framework for Internet key management and provides the specific protocol support, including formats, for negotiation of security attributes.
1.11.1Features of IKE Key Determination
The IKE key determination algorithm is characterized by five important features:
- It employs a mechanism known as cookies to thwart clogging attacks.
- It enables the two parties to negotiate a group ; this, in essence, specifies the global parameters of the Diffie-Hellman key exchange.
- It uses nonces to ensure against replay attacks.
- It enables the exchange of Diffie-Hellman public key values.
- It authenticates the Diffie-Hellman exchange to thwart man-in-the-middle attacks.
Summary
- Understand the concept of Internetworking and Internet Protocols
- Learnt about IP Security Architecture
- Tunnel Mode and Transport Mode
- IPSec Services
you can view video on IP Security 
