28-10-2016, 02:22 PM
[attachment=74111]
Def: Internet Protocol security (IPSec) is a framework of open standards for protecting
communications over Internet Protocol (IP) networks through the use of cryptographic security services. IPSec supports network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and replay protection.
Need for IPSec
In Computer Emergency Response Team (CERT)’s 2001 annual report it listed 52,000 security incidents in which most serious types of attacks included IP spoofing, in which intruders create packets with false IP addresses and exploit applications that use authentication based on IP and various forms of eavesdropping and packet sniffing, in which attackers read transmitted information, including logon information and database contents. In response to these issues, the IAB included authentication and encryption as necessary security features in the next-generation IP i.e. IPv6.
Applications of IPSec
IPSec provides the capability to secure communications across a LAN, across private and public wide area networks (WAN’s), and across the Internet.
• Secure branch office connectivity over the Internet: A company can build a secure virtual private network over the Internet or over a public WAN. This enables a business to rely heavily on the Internet and reduce its need for private networks, saving costs and network management overhead.
• Secure remote access over the Internet: An end user whose system is equipped with IP
security protocols can make a local call to an Internet service provider (ISP) and gain secure access to a company network. This reduces the cost of toll charges for travelling employees and telecommuters.
• Establishing extranet and intranet connectivity with partners: IPSec can be used to
secure communication with other organizations, ensuring authentication and confidentiality and providing a key exchange mechanism.
• Enhancing electronic commerce security: Even though some Web and electronic commerce applications have built-in security protocols, the use of IPSec enhances that security.
The principal feature of IPSec enabling it to support varied applications is that it can encrypt and/or authenticate all traffic at IP level. Thus, all distributed applications, including remote logon, client/server, e-mail, file transfer, Web access, and so on, can be secured.
The following figure shows a typical scenario of IPSec usage. An organization maintains
LANs at dispersed locations. Non secure IP traffic is conducted on each LAN.
The IPSec protocols operate in networking devices, such as a router or firewall that connect each LAN to the outside world. The IPSec networking device will typically encrypt and compress all traffic going into the WAN, and decrypt and decompress traffic coming from the WAN; these operations are transparent to workstations and servers on the LAN. Secure transmission is also possible with individual users who dial into the WAN. Such user workstations must implement the IPSec protocols to provide security.
Benefits of IPSec
The benefits of IPSec are listed below:
• IPSec in a firewall/router provides strong security to all traffic crossing the perimeter
• IPSec in a firewall is resistant to bypass
• IPSec is below transport layer(TCP,UDP), hence transparent to applications
• IPSec can be transparent to end users
• IPSec can provide security for individual users if needed (useful for offsite workers and setting up a secure virtual subnetwork for sensitive applications)
Routing Applications
IPSec also plays a vital role in the routing architecture required for internetworking. It assures that:
• router advertisements come from authorized routers
• neighbor advertisements come from authorized routers
• redirect messages come from the router to which initial packet was sent
• A routing update is not forged
3
IP Security Architecture
To understand IP Security architecture, we examine IPSec documents first and then move on to IPSec services and Security Associations.
IPSec Documents
The IPSec specification consists of numerous documents. The most important of these, issued in November of 1998, are RFCs 2401, 2402, 2406, and 2408:
• RFC 2401: An overview of a security architecture
• RFC 2402: Description of a packet authentication extension to IPv4 and IPv6
• RFC 2406: Description of a packet encryption extension to IPv4 and IPv6
• RFC 2408: Specification of key management capabilities
Support for these features is mandatory for IPv6 and optional for IPv4. In both cases, the security features are implemented as extension headers that follow the main IP header. The extension header for authentication is known as the Authentication header; that for encryption is known as the Encapsulating Security Payload (ESP) header. In addition to these four RFCs, a number of additional drafts have been published by the IP Security Protocol Working Group set up by the IETF. The documents are divided into seven groups,
Architecture: Covers the general concepts, security requirements, definitions, and mechanisms defining IPSec technology
• Encapsulating Security Payload (ESP): Covers the packet format and general issues related to the use of the ESP for packet encryption and, optionally, authentication.
• Authentication Header (AH): Covers the packet format and general issues related to the use of
AH for packet authentication.
4
• Encryption Algorithm: A set of documents that describe how various encryption algorithms are used for ESP.
• Authentication Algorithm: A set of documents that describe how various authentication algorithms are used for AH and for the authentication option of ESP.
• Key Management: Documents that describe key management schemes.
• Domain of Interpretation (DOI): Contains values needed for the other documents to relate to each other. These include identifiers for approved encryption and authentication algorithms, as well as operational parameters such as key lifetime.
IPSec Services
IPSec architecture makes use of two major protocols (i.e., Authentication Header and ESP protocols) for providing security at IP level. This facilitates the system to beforehand choose an algorithm to be implemented, security protocols needed and any cryptographic keys required to provide requested services. The IPSec services are as follows:
Connectionless Integrity:- Data integrity service is provided by IPSec via AH which prevents the data from being altered during transmission.
Data Origin Authentication:- This IPSec service prevents the occurrence of replay attacks, address spoofing etc., which can be fatal
Access Control:- The cryptographic keys are distributed and the traffic flow is controlled
in both AH and ESP protocols, which is done to accomplish access control over the data transmission.
Confidentiality:- Confidentiality on the data packet is obtained by using an encryption
technique in which all the data packets are transformed into ciphertext packets which are unreadable and difficult to understand.
Limited Traffic Flow Confidentiality:- This facility or service provided by IPSec ensures that the confidentiality is maintained on the number of packets transferred or received. This can be done using padding in ESP.
Replay packets Rejection:- The duplicate or replay packets are identified and discarded using the sequence number field in both AH and ESP.
Security Associations
Since IPSEC is designed to be able to use various security protocols, it uses Security Associations (SA) to specify the protocols to be used. SA is a database record which specifies security parameters controlling security operations. They are referenced by the sending host and established by the receiving host. An index parameter called the Security Parameters Index (SPI) is used. SAs are in one direction only and a second SA must be established for the transmission to be bi-directional. A security association is uniquely identified by three parameters:
• Security Parameters Index (SPI): A bit string assigned to this SA and having local significance only. The SPI is carried in AH and ESP headers to enable the receiving system to select the SA under which a received packet will be processed.
• IP Destination Address: Currently, only unicast addresses are allowed; this is the address
of the destination endpoint of the SA, which may be an end user system or a network system such as a firewall or router.
• Security Protocol Identifier: This indicates whether the association is an AH or ESP
security association.
SA Parameters
In each IPSec implementation, there is a nominal Security Association Database that defines the parameters associated with each SA. A security association is normally defined by the following parameters:
• 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 (required for all implementations).
• 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 (required for AH implementations).
• ESP Information: Encryption and authentication algorithm, keys, initialization values, key lifetimes, and related parameters being used with ESP (required for ESP implementations).
• Lifetime of This Security Association: A time interval or byte count after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur (required for all implementations).
• IPSec Protocol Mode: Tunnel, transport, or wildcard (required for all implementations).
These modes are discussed later in this section.
• Path MTU: Any observed path maximum transmission unit (maximum size of a packet that can be transmitted without fragmentation) and aging variables (required for all implementations).
IP sec can be used (both AH packets and ESP packets) in two modes
• Transport mode: the IP sec header is inserted just after the IP header –this contains the security information, such as SA identifier, encryption, authentication
Typically used in end-to-end communication
IP header not protected
• Tunnel mode: the entire IP packet, header and all, is encapsulated in the body of a new
IP packet with a completely new IP header
Typically used in firewall-to-firewall communication
Provides protection for the whole IP packet
No routers along the way will be able (and will not need) to check the content of the packets
Authentication Header
The Authentication Header provides support for data integrity and authentication of IP packets. The data integrity feature ensures that undetected modification to a packet's content in transit is not possible. The authentication feature enables an end system or network device to authenticate the user or application and filter traffic accordingly; it also prevents the address spoofing attacks observed in today's Internet. The AH also guards against the replay attack. Authentication is based on the use of a message authentication code (MAC), hence the two parties must share a secret key. The Authentication Header consists of the following fields:
• Next Header (8 bits): Identifies the type of header immediately following this header.
• Payload Length (8 bits): Length of Authentication Header in 32-bit words, minus 2. For example, the default length of the authentication data field is 96 bits, or three 32-bit words. With a three-word fixed header, there are a total of six words in the header, and the Payload Length field has a value of 4.
• Reserved (16 bits): For future use.
• Security Parameters Index (32 bits): Identifies a security association.
• Sequence Number (32 bits): A monotonically increasing counter value, discussed later.
• Authentication Data (variable): A variable-length field (must be an integral number of
32-bit words) that contains the Integrity Check Value (ICV), or MAC, for this packet.
Anti-Replay Service
Anti-replay service is designed to overcome the problems faced due to replay attacks in which an intruder intervenes the packet being transferred, make one or more duplicate copies of that authenticated packet and then sends the packets to the desired destination, thereby causing inconvenient processing at the destination node. The Sequence Number field is designed to thwart such attacks.
8
When a new SA is established, the sender initializes a sequence number counter to
0. Each time that a packet is sent on this SA, the sender increments the counter and places the value in the Sequence Number field. Thus, the first value to be used is 1. This value goes on increasing with respect to the number of packets being transmitted. The sequence number field in each packet represents the value of this counter. The maximum value of the sequence number field can go up to 232-1. If the limit of 232-1 is reached, the sender should terminate this SA and negotiate a new SA with a new key.
The IPSec authentication document dictates that the receiver should implement a window of size W, with a default of W = 64. The right edge of the window represents the highest sequence number, N, so far received for a valid packet. For any packet with a sequence number in the range from N-W+1 to N that has been correctly received (i.e., properly authenticated), the corresponding slot in the window is marked as shown. Inbound processing proceeds as follows when a packet is received:
Integrity Check Value
ICV is the value present in the authenticated data field of ESP/AH, which is used to determine any undesired modifications made to the data during its transit. ICV can also be referred as MAC or part of MAC algorithm. MD5 hash code and SHA-1 hash code are implemented along with HMAC algorithms i.e.,
• HMAC-MD5-96
• HMAC-SHA-1-96
In both cases, the full HMAC value is calculated but then truncated by using the first 96 bits, which is the default length for the Authentication Data field. The MAC is calculated over
• IP header fields that either do not change in transit (immutable) or that are predictable in value upon arrival at the endpoint for the AH SA. Fields that may change in transit and whose value on arrival is unpredictable are set to zero for purposes of calculation at both source and destination.
• The AH header other than the Authentication Data field. The Authentication Data field is
set to zero for purposes of calculation at both source and destination.
• The entire upper-level protocol data, which is assumed to be immutable in transit (e.g., a TCP segment or an inner IP packet in tunnel mode).
Transport and Tunnel Modes
The following figure shows typical IPv4 and IPv6 packets. In this case, the IP payload is a
TCP segment; it could also be a data unit for any other protocol that uses IP, such as UDP or ICMP.
For transport mode AH using IPv4, the AH is inserted after the original IP header and before the IP payload (e.g., a TCP segment) shown below. Authentication covers the entire packet, excluding mutable fields in the IPv4 header that are set to zero for MAC calculation. In the context of IPv6, AH is viewed as an end-to-end payload; that is, it is not examined or processed by intermediate routers. Therefore, the AH 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 AH header, depending on the semantics desired. Again, authentication covers the entire packet, excluding mutable fields that are set to zero for MAC calculation.
For tunnel mode AH, the entire original IP packet is authenticated, and the AH is inserted between the original IP header and a new outer IP header. The inner IP header carries the ultimate source and destination addresses, while an outer IP header may contain different IP addresses (e.g., addresses of firewalls or other security gateways). With tunnel mode, the entire inner IP packet, including the entire inner IP header is protected by AH. The outer IP header (and in the case of IPv6, the outer IP extension headers) is protected except for mutable and unpredictable fields.
Encapsulating Security Payload
The Encapsulating Security Payload provides confidentiality services, including confidentiality of message contents and limited traffic flow confidentiality. As an optional
feature, ESP can also provide an authentication service
Security Parameters Index (32 bits): Identifies a security association.
• Sequence Number (32 bits): A monotonically increasing counter value; this provides an anti-replay function, as discussed for AH.
• Payload Data (variable): This is a transport-level segment (transport mode) or IP packet
(tunnel mode) that is protected by encryption.
• Padding (0-255 bytes): This field is used to make the length of the plaintext to be a multiple of some desired number of bytes. It is also added to provide confidentiality.
• Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.
• Next Header (8 bits): Identifies the type of data contained in the payload data field by identifying the first header in that payload (for example, an extension header in IPv6, or an upper-layer protocol such as TCP).
• Authentication Data (variable): A variable-length field (must be an integral number of
32-bit words) that contains the Integrity Check Value computed over the ESP packet minus the Authentication Data field.
Adding encryption makes ESP a bit more complicated because the encapsulation
surrounds the payload rather than precedes it as with AH: ESP includes header and trailer
12
fields to support the encryption and optional authentication. It also provides Tunnel and Transport modes. The IPSec RFCs don't insist upon any particular encryption algorithms, but we find DES, triple-DES, AES, and Blowfish in common use to shield the payload from prying eyes. The algorithm used for a particular connection is specified by the Security Association and this SA includes not only the algorithm, but the key used. Unlike AH, which provides a small header before the payload, ESP surrounds the payload it's protecting. The Security Parameters Index and Sequence Number serve the same purpose as in AH, but we find padding, the next header, and the optional Authentication Data at the end, in the ESP Trailer.
It's possible to use ESP without any actual encryption (to use a NULL algorithm), which nonetheless structures the packet the same way. This provides no confidentiality, and it only makes sense if combined with ESP authentication. Padding is provided to allow block- oriented encryption algorithms room for multiples of their block size, and the length of that padding is provided in the pad len field. The next hdr field gives the type (IP, TCP, UDP, etc.) of the payload in the usual way, though it can be thought of as pointing "backwards" into the packet rather than forward as we've seen in AH. In addition to encryption, ESP can also optionally provide authentication, with the same HMAC as found in AH. Unlike AH, however, this authentication is only for the ESP header and encrypted payload: it does not cover the full IP packet.
Transport Mode ESP
Transport mode ESP is used to encrypt and optionally authenticate the data carried by IP (e.g., a TCP segment). 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.
3. 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. This mode of operation is also reasonably efficient, adding little to the total length of the IP packet. One drawback to this mode is that it is possible to do traffic analysis on the transmitted packets.
Tunnel Mode ESP
In case of tunnel mode ESP, ESP header and the ESP trailer are attached before and after the IP packet respectively, then the complete IP packet which includes IP header, Transport header and data field along with the ESP trailer is encrypted. Tunnel mode ESP is used to protect against the traffic flow analysis. But if ESP header precedes the IP header, the routers cannot identify and process this packet as the routing information and other parameters needed are present in the IP header of the packet. To overcome this problem,
the complete structure which contains ESP header, encrypted text as well as authentication data are encapsulated in a new IP packet with a new IP header. This new IP header has enough routing information inorder to process the packet to the appropriate destination.
The transport mode is suitable for protecting connections between hosts that support the ESP feature and 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. Consider a case in which an external host wishes to communicate with a host on an internal network protected by a firewall, and in which ESP is implemented in the external host and the firewalls. The following steps occur for transfer of a transport-layer segment from the external host to the internal host:
1. The source prepares an inner IP packet with a destination address of the target internal host. This packet is prefixed by an ESP header; then the packet and ESP trailer are encrypted and Authentication Data may be added. The resulting block is encapsulated with a new IP header (base header plus optional extensions such as routing and hop-by- hop options for IPv6) whose destination address is the firewall; this forms the outer IP packet.
2. The outer packet is routed to the destination firewall. Each intermediate router needs to
examine and process the outer IP header plus any outer IP extension headers but does not need to examine the ciphertext.
3. The destination firewall examines and processes the outer IP header plus any outer 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 inner IP packet. This packet is then transmitted in the internal network.
4. The inner packet is routed through zero or more routers in the internal network to the
destination host.
15
Combining Security Associations
An individual SA can implement either the AH or ESP protocol but not both. Multiple SAs must be employed for traffic flow to achieve the desired IPSec services. The term security association bundle 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 endpoints. 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 tunnelling.
• Iterated tunnelling: Refers to the application of multiple layers of security protocols effected through IP tunnelling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPSec site along the path.
Authentication Plus Confidentiality
Encryption and authentication can be combined in order to transmit an IP packet that has both confidentiality and authentication between hosts. There are several approaches for this:
ESP with Authentication Option
In this approach, the encryption is carried out on a data packet prior to its authentication. This can be represented using the following two cases:
• Transport Mode ESP
• Tunnel Mode ESP
Transport Adjacency
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. The resulting packet consists of an IP header (and possibly IPv6 header extensions) followed by an ESP. AH is then applied in transport mode, so that authentication covers the ESP plus the original IP header (and extensions) except for mutable fields. The advantage of this approach over simply using a single ESP SA with the ESP authentication option is that the authentication covers more fields, including the source and destination IP addresses. The disadvantage is the overhead of two SAs versus one SA.
Transport-Tunnel Bundle
The use of authentication prior to encryption might be preferable for several reasons. First, because the authentication data are protected by encryption, it is impossible for anyone to intercept the message and alter the authentication data without detection. Second, it may be desirable to store the authentication information with the message at the destination for
16
later reference. It is more convenient to do this if the authentication information applies to the unencrypted message; otherwise the message would have to be reencrypted to verify the authentication information.
One approach to applying authentication before encryption between two hosts is to use a bundle consisting of an inner AH transport SA and an outer ESP tunnel SA. In this case, authentication is applied to the IP payload plus the IP header (and extensions) except for mutable fields. 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 (and extensions) is added.
Def: Internet Protocol security (IPSec) is a framework of open standards for protecting
communications over Internet Protocol (IP) networks through the use of cryptographic security services. IPSec supports network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and replay protection.
Need for IPSec
In Computer Emergency Response Team (CERT)’s 2001 annual report it listed 52,000 security incidents in which most serious types of attacks included IP spoofing, in which intruders create packets with false IP addresses and exploit applications that use authentication based on IP and various forms of eavesdropping and packet sniffing, in which attackers read transmitted information, including logon information and database contents. In response to these issues, the IAB included authentication and encryption as necessary security features in the next-generation IP i.e. IPv6.
Applications of IPSec
IPSec provides the capability to secure communications across a LAN, across private and public wide area networks (WAN’s), and across the Internet.
• Secure branch office connectivity over the Internet: A company can build a secure virtual private network over the Internet or over a public WAN. This enables a business to rely heavily on the Internet and reduce its need for private networks, saving costs and network management overhead.
• Secure remote access over the Internet: An end user whose system is equipped with IP
security protocols can make a local call to an Internet service provider (ISP) and gain secure access to a company network. This reduces the cost of toll charges for travelling employees and telecommuters.
• Establishing extranet and intranet connectivity with partners: IPSec can be used to
secure communication with other organizations, ensuring authentication and confidentiality and providing a key exchange mechanism.
• Enhancing electronic commerce security: Even though some Web and electronic commerce applications have built-in security protocols, the use of IPSec enhances that security.
The principal feature of IPSec enabling it to support varied applications is that it can encrypt and/or authenticate all traffic at IP level. Thus, all distributed applications, including remote logon, client/server, e-mail, file transfer, Web access, and so on, can be secured.
The following figure shows a typical scenario of IPSec usage. An organization maintains
LANs at dispersed locations. Non secure IP traffic is conducted on each LAN.
The IPSec protocols operate in networking devices, such as a router or firewall that connect each LAN to the outside world. The IPSec networking device will typically encrypt and compress all traffic going into the WAN, and decrypt and decompress traffic coming from the WAN; these operations are transparent to workstations and servers on the LAN. Secure transmission is also possible with individual users who dial into the WAN. Such user workstations must implement the IPSec protocols to provide security.
Benefits of IPSec
The benefits of IPSec are listed below:
• IPSec in a firewall/router provides strong security to all traffic crossing the perimeter
• IPSec in a firewall is resistant to bypass
• IPSec is below transport layer(TCP,UDP), hence transparent to applications
• IPSec can be transparent to end users
• IPSec can provide security for individual users if needed (useful for offsite workers and setting up a secure virtual subnetwork for sensitive applications)
Routing Applications
IPSec also plays a vital role in the routing architecture required for internetworking. It assures that:
• router advertisements come from authorized routers
• neighbor advertisements come from authorized routers
• redirect messages come from the router to which initial packet was sent
• A routing update is not forged
3
IP Security Architecture
To understand IP Security architecture, we examine IPSec documents first and then move on to IPSec services and Security Associations.
IPSec Documents
The IPSec specification consists of numerous documents. The most important of these, issued in November of 1998, are RFCs 2401, 2402, 2406, and 2408:
• RFC 2401: An overview of a security architecture
• RFC 2402: Description of a packet authentication extension to IPv4 and IPv6
• RFC 2406: Description of a packet encryption extension to IPv4 and IPv6
• RFC 2408: Specification of key management capabilities
Support for these features is mandatory for IPv6 and optional for IPv4. In both cases, the security features are implemented as extension headers that follow the main IP header. The extension header for authentication is known as the Authentication header; that for encryption is known as the Encapsulating Security Payload (ESP) header. In addition to these four RFCs, a number of additional drafts have been published by the IP Security Protocol Working Group set up by the IETF. The documents are divided into seven groups,
Architecture: Covers the general concepts, security requirements, definitions, and mechanisms defining IPSec technology
• Encapsulating Security Payload (ESP): Covers the packet format and general issues related to the use of the ESP for packet encryption and, optionally, authentication.
• Authentication Header (AH): Covers the packet format and general issues related to the use of
AH for packet authentication.
4
• Encryption Algorithm: A set of documents that describe how various encryption algorithms are used for ESP.
• Authentication Algorithm: A set of documents that describe how various authentication algorithms are used for AH and for the authentication option of ESP.
• Key Management: Documents that describe key management schemes.
• Domain of Interpretation (DOI): Contains values needed for the other documents to relate to each other. These include identifiers for approved encryption and authentication algorithms, as well as operational parameters such as key lifetime.
IPSec Services
IPSec architecture makes use of two major protocols (i.e., Authentication Header and ESP protocols) for providing security at IP level. This facilitates the system to beforehand choose an algorithm to be implemented, security protocols needed and any cryptographic keys required to provide requested services. The IPSec services are as follows:
Connectionless Integrity:- Data integrity service is provided by IPSec via AH which prevents the data from being altered during transmission.
Data Origin Authentication:- This IPSec service prevents the occurrence of replay attacks, address spoofing etc., which can be fatal
Access Control:- The cryptographic keys are distributed and the traffic flow is controlled
in both AH and ESP protocols, which is done to accomplish access control over the data transmission.
Confidentiality:- Confidentiality on the data packet is obtained by using an encryption
technique in which all the data packets are transformed into ciphertext packets which are unreadable and difficult to understand.
Limited Traffic Flow Confidentiality:- This facility or service provided by IPSec ensures that the confidentiality is maintained on the number of packets transferred or received. This can be done using padding in ESP.
Replay packets Rejection:- The duplicate or replay packets are identified and discarded using the sequence number field in both AH and ESP.
Security Associations
Since IPSEC is designed to be able to use various security protocols, it uses Security Associations (SA) to specify the protocols to be used. SA is a database record which specifies security parameters controlling security operations. They are referenced by the sending host and established by the receiving host. An index parameter called the Security Parameters Index (SPI) is used. SAs are in one direction only and a second SA must be established for the transmission to be bi-directional. A security association is uniquely identified by three parameters:
• Security Parameters Index (SPI): A bit string assigned to this SA and having local significance only. The SPI is carried in AH and ESP headers to enable the receiving system to select the SA under which a received packet will be processed.
• IP Destination Address: Currently, only unicast addresses are allowed; this is the address
of the destination endpoint of the SA, which may be an end user system or a network system such as a firewall or router.
• Security Protocol Identifier: This indicates whether the association is an AH or ESP
security association.
SA Parameters
In each IPSec implementation, there is a nominal Security Association Database that defines the parameters associated with each SA. A security association is normally defined by the following parameters:
• 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 (required for all implementations).
• 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 (required for AH implementations).
• ESP Information: Encryption and authentication algorithm, keys, initialization values, key lifetimes, and related parameters being used with ESP (required for ESP implementations).
• Lifetime of This Security Association: A time interval or byte count after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur (required for all implementations).
• IPSec Protocol Mode: Tunnel, transport, or wildcard (required for all implementations).
These modes are discussed later in this section.
• Path MTU: Any observed path maximum transmission unit (maximum size of a packet that can be transmitted without fragmentation) and aging variables (required for all implementations).
IP sec can be used (both AH packets and ESP packets) in two modes
• Transport mode: the IP sec header is inserted just after the IP header –this contains the security information, such as SA identifier, encryption, authentication
Typically used in end-to-end communication
IP header not protected
• Tunnel mode: the entire IP packet, header and all, is encapsulated in the body of a new
IP packet with a completely new IP header
Typically used in firewall-to-firewall communication
Provides protection for the whole IP packet
No routers along the way will be able (and will not need) to check the content of the packets
Authentication Header
The Authentication Header provides support for data integrity and authentication of IP packets. The data integrity feature ensures that undetected modification to a packet's content in transit is not possible. The authentication feature enables an end system or network device to authenticate the user or application and filter traffic accordingly; it also prevents the address spoofing attacks observed in today's Internet. The AH also guards against the replay attack. Authentication is based on the use of a message authentication code (MAC), hence the two parties must share a secret key. The Authentication Header consists of the following fields:
• Next Header (8 bits): Identifies the type of header immediately following this header.
• Payload Length (8 bits): Length of Authentication Header in 32-bit words, minus 2. For example, the default length of the authentication data field is 96 bits, or three 32-bit words. With a three-word fixed header, there are a total of six words in the header, and the Payload Length field has a value of 4.
• Reserved (16 bits): For future use.
• Security Parameters Index (32 bits): Identifies a security association.
• Sequence Number (32 bits): A monotonically increasing counter value, discussed later.
• Authentication Data (variable): A variable-length field (must be an integral number of
32-bit words) that contains the Integrity Check Value (ICV), or MAC, for this packet.
Anti-Replay Service
Anti-replay service is designed to overcome the problems faced due to replay attacks in which an intruder intervenes the packet being transferred, make one or more duplicate copies of that authenticated packet and then sends the packets to the desired destination, thereby causing inconvenient processing at the destination node. The Sequence Number field is designed to thwart such attacks.
8
When a new SA is established, the sender initializes a sequence number counter to
0. Each time that a packet is sent on this SA, the sender increments the counter and places the value in the Sequence Number field. Thus, the first value to be used is 1. This value goes on increasing with respect to the number of packets being transmitted. The sequence number field in each packet represents the value of this counter. The maximum value of the sequence number field can go up to 232-1. If the limit of 232-1 is reached, the sender should terminate this SA and negotiate a new SA with a new key.
The IPSec authentication document dictates that the receiver should implement a window of size W, with a default of W = 64. The right edge of the window represents the highest sequence number, N, so far received for a valid packet. For any packet with a sequence number in the range from N-W+1 to N that has been correctly received (i.e., properly authenticated), the corresponding slot in the window is marked as shown. Inbound processing proceeds as follows when a packet is received:
Integrity Check Value
ICV is the value present in the authenticated data field of ESP/AH, which is used to determine any undesired modifications made to the data during its transit. ICV can also be referred as MAC or part of MAC algorithm. MD5 hash code and SHA-1 hash code are implemented along with HMAC algorithms i.e.,
• HMAC-MD5-96
• HMAC-SHA-1-96
In both cases, the full HMAC value is calculated but then truncated by using the first 96 bits, which is the default length for the Authentication Data field. The MAC is calculated over
• IP header fields that either do not change in transit (immutable) or that are predictable in value upon arrival at the endpoint for the AH SA. Fields that may change in transit and whose value on arrival is unpredictable are set to zero for purposes of calculation at both source and destination.
• The AH header other than the Authentication Data field. The Authentication Data field is
set to zero for purposes of calculation at both source and destination.
• The entire upper-level protocol data, which is assumed to be immutable in transit (e.g., a TCP segment or an inner IP packet in tunnel mode).
Transport and Tunnel Modes
The following figure shows typical IPv4 and IPv6 packets. In this case, the IP payload is a
TCP segment; it could also be a data unit for any other protocol that uses IP, such as UDP or ICMP.
For transport mode AH using IPv4, the AH is inserted after the original IP header and before the IP payload (e.g., a TCP segment) shown below. Authentication covers the entire packet, excluding mutable fields in the IPv4 header that are set to zero for MAC calculation. In the context of IPv6, AH is viewed as an end-to-end payload; that is, it is not examined or processed by intermediate routers. Therefore, the AH 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 AH header, depending on the semantics desired. Again, authentication covers the entire packet, excluding mutable fields that are set to zero for MAC calculation.
For tunnel mode AH, the entire original IP packet is authenticated, and the AH is inserted between the original IP header and a new outer IP header. The inner IP header carries the ultimate source and destination addresses, while an outer IP header may contain different IP addresses (e.g., addresses of firewalls or other security gateways). With tunnel mode, the entire inner IP packet, including the entire inner IP header is protected by AH. The outer IP header (and in the case of IPv6, the outer IP extension headers) is protected except for mutable and unpredictable fields.
Encapsulating Security Payload
The Encapsulating Security Payload provides confidentiality services, including confidentiality of message contents and limited traffic flow confidentiality. As an optional
feature, ESP can also provide an authentication service
Security Parameters Index (32 bits): Identifies a security association.
• Sequence Number (32 bits): A monotonically increasing counter value; this provides an anti-replay function, as discussed for AH.
• Payload Data (variable): This is a transport-level segment (transport mode) or IP packet
(tunnel mode) that is protected by encryption.
• Padding (0-255 bytes): This field is used to make the length of the plaintext to be a multiple of some desired number of bytes. It is also added to provide confidentiality.
• Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.
• Next Header (8 bits): Identifies the type of data contained in the payload data field by identifying the first header in that payload (for example, an extension header in IPv6, or an upper-layer protocol such as TCP).
• Authentication Data (variable): A variable-length field (must be an integral number of
32-bit words) that contains the Integrity Check Value computed over the ESP packet minus the Authentication Data field.
Adding encryption makes ESP a bit more complicated because the encapsulation
surrounds the payload rather than precedes it as with AH: ESP includes header and trailer
12
fields to support the encryption and optional authentication. It also provides Tunnel and Transport modes. The IPSec RFCs don't insist upon any particular encryption algorithms, but we find DES, triple-DES, AES, and Blowfish in common use to shield the payload from prying eyes. The algorithm used for a particular connection is specified by the Security Association and this SA includes not only the algorithm, but the key used. Unlike AH, which provides a small header before the payload, ESP surrounds the payload it's protecting. The Security Parameters Index and Sequence Number serve the same purpose as in AH, but we find padding, the next header, and the optional Authentication Data at the end, in the ESP Trailer.
It's possible to use ESP without any actual encryption (to use a NULL algorithm), which nonetheless structures the packet the same way. This provides no confidentiality, and it only makes sense if combined with ESP authentication. Padding is provided to allow block- oriented encryption algorithms room for multiples of their block size, and the length of that padding is provided in the pad len field. The next hdr field gives the type (IP, TCP, UDP, etc.) of the payload in the usual way, though it can be thought of as pointing "backwards" into the packet rather than forward as we've seen in AH. In addition to encryption, ESP can also optionally provide authentication, with the same HMAC as found in AH. Unlike AH, however, this authentication is only for the ESP header and encrypted payload: it does not cover the full IP packet.
Transport Mode ESP
Transport mode ESP is used to encrypt and optionally authenticate the data carried by IP (e.g., a TCP segment). 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.
3. 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. This mode of operation is also reasonably efficient, adding little to the total length of the IP packet. One drawback to this mode is that it is possible to do traffic analysis on the transmitted packets.
Tunnel Mode ESP
In case of tunnel mode ESP, ESP header and the ESP trailer are attached before and after the IP packet respectively, then the complete IP packet which includes IP header, Transport header and data field along with the ESP trailer is encrypted. Tunnel mode ESP is used to protect against the traffic flow analysis. But if ESP header precedes the IP header, the routers cannot identify and process this packet as the routing information and other parameters needed are present in the IP header of the packet. To overcome this problem,
the complete structure which contains ESP header, encrypted text as well as authentication data are encapsulated in a new IP packet with a new IP header. This new IP header has enough routing information inorder to process the packet to the appropriate destination.
The transport mode is suitable for protecting connections between hosts that support the ESP feature and 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. Consider a case in which an external host wishes to communicate with a host on an internal network protected by a firewall, and in which ESP is implemented in the external host and the firewalls. The following steps occur for transfer of a transport-layer segment from the external host to the internal host:
1. The source prepares an inner IP packet with a destination address of the target internal host. This packet is prefixed by an ESP header; then the packet and ESP trailer are encrypted and Authentication Data may be added. The resulting block is encapsulated with a new IP header (base header plus optional extensions such as routing and hop-by- hop options for IPv6) whose destination address is the firewall; this forms the outer IP packet.
2. The outer packet is routed to the destination firewall. Each intermediate router needs to
examine and process the outer IP header plus any outer IP extension headers but does not need to examine the ciphertext.
3. The destination firewall examines and processes the outer IP header plus any outer 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 inner IP packet. This packet is then transmitted in the internal network.
4. The inner packet is routed through zero or more routers in the internal network to the
destination host.
15
Combining Security Associations
An individual SA can implement either the AH or ESP protocol but not both. Multiple SAs must be employed for traffic flow to achieve the desired IPSec services. The term security association bundle 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 endpoints. 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 tunnelling.
• Iterated tunnelling: Refers to the application of multiple layers of security protocols effected through IP tunnelling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPSec site along the path.
Authentication Plus Confidentiality
Encryption and authentication can be combined in order to transmit an IP packet that has both confidentiality and authentication between hosts. There are several approaches for this:
ESP with Authentication Option
In this approach, the encryption is carried out on a data packet prior to its authentication. This can be represented using the following two cases:
• Transport Mode ESP
• Tunnel Mode ESP
Transport Adjacency
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. The resulting packet consists of an IP header (and possibly IPv6 header extensions) followed by an ESP. AH is then applied in transport mode, so that authentication covers the ESP plus the original IP header (and extensions) except for mutable fields. The advantage of this approach over simply using a single ESP SA with the ESP authentication option is that the authentication covers more fields, including the source and destination IP addresses. The disadvantage is the overhead of two SAs versus one SA.
Transport-Tunnel Bundle
The use of authentication prior to encryption might be preferable for several reasons. First, because the authentication data are protected by encryption, it is impossible for anyone to intercept the message and alter the authentication data without detection. Second, it may be desirable to store the authentication information with the message at the destination for
16
later reference. It is more convenient to do this if the authentication information applies to the unencrypted message; otherwise the message would have to be reencrypted to verify the authentication information.
One approach to applying authentication before encryption between two hosts is to use a bundle consisting of an inner AH transport SA and an outer ESP tunnel SA. In this case, authentication is applied to the IP payload plus the IP header (and extensions) except for mutable fields. 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 (and extensions) is added.