Cryptography and Network Security

After reading chapter 20, analyze how a VPN is used for telework and how it helps to keep data safe. You must use at least two scholarly resources.

-posting must be properly APA formatted.

-intext citations

-0 plagiarism

Cryptography and Network Security: Principles and Practice

Eighth Edition

Chapter 20

IP Security

Lecture slides prepared for “Cryptography and Network Security”, 8/e, by William Stallings, Chapter 20 – “IP Security”.

There are application-specific security mechanisms for a number of application areas, including electronic mail (S/MIME, PGP), client/server (Kerberos), Web access (Secure Sockets Layer), and others. However, users have security concerns that cut across protocol layers. For example, an enterprise can run a secure, private IP network by disallowing links to untrusted sites, encrypting packets that leave the premises, and authenticating packets that enter the premises. By implementing security at the IP level, an organization can ensure secure networking not only for applications that have security mechanisms but also for the many security-ignorant applications.

IP-level security encompasses three functional areas: authentication, confidentiality, and key management. The authentication mechanism assures that a received packet was, in fact, transmitted by the party identified as the source in the packet header. In addition, this mechanism assures that the packet has not been altered in transit. The confidentiality facility enables communicating nodes to encrypt messages to prevent eavesdropping by third parties. The key management facility is concerned with the secure exchange of keys.

We begin this chapter with an overview of IP security (IPsec) and an introduction to the IPsec architecture. We then look at each of the three functional areas in detail.

Learning Objectives

Present an overview of IP security (IPsec).

Explain the difference between transport mode and tunnel mode.

Understand the concept of security association.

Explain the difference between the security association database and the security policy database.

Summarize the traffic processing functions performed by IPsec for outbound packets and for inbound packets.

Present an overview of Encapsulating Security Payload.

Discuss the alternatives for combining security associations.

Present an overview of Internet Key Exchange.

Summarize the alternative cryptographic suites approved for use with IPsec.

IP Security Overview

RFC 1636

“Security in the Internet Architecture”

Issued in 1994 by the Internet Architecture Board (I A B)

Identifies key areas for security mechanisms

Need to secure the network infrastructure from unauthorized monitoring and control of network traffic

Need to secure end-user-to-end-user traffic using authentication and encryption mechanisms

I A B included authentication and encryption as necessary security features in the next generation I P (I P v 6)

The IPsec specification now exists as a set of Internet standards

In 1994, the Internet Architecture Board (IAB) issued a report titled “Security in the Internet Architecture” (RFC 1636). The report identified key areas for security mechanisms. Among these were the need to secure the network infrastructure from

unauthorized monitoring and control of network traffic and the need to secure end-user-to-end-user traffic using authentication and encryption mechanisms.

To provide security, the IAB included authentication and encryption as necessary security features in the next-generation IP, which has been issued as IPv6. Fortunately, these security capabilities were designed to be usable with both versions currently in use: IPv4 and IPv6. This means that vendors can begin offering these features now, and many vendors now do have some IPsec capability in their products. The IPsec specification now exists as a set of Internet standards.

IPsec Documents (1 of 2)

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)

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)

IPsec encompasses three functional areas: authentication, confidentiality, and key management. The totality of the IPsec specification is scattered across dozens of RFCs and draft IETF documents, making this the most complex and difficult to grasp of all IETF specifications. The best way to grasp the scope of IPsec is to consult the latest version of the IPsec document roadmap, which as of this writing is RFC 6071 [IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap, February 2011]. The documents can be categorized into the following groups.

■ Architecture: Covers the general concepts, security requirements, definitions, and mechanisms defining IPsec technology. The current specification is RFC 4301, Security Architecture for the Internet Protocol.

■ Authentication Header (AH): AH is an extension header to provide message authentication. The current specification is RFC 4302, IP Authentication Header. Because message authentication is provided by ESP, the use of AH is deprecated. It is included in IPsecv3 for backward compatibility but should not be used in new applications. We do not discuss AH in this chapter.

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): This is a collection of documents describing the key management schemes for use with IPsec. The main specification is RFC 7296, Internet Key Exchange (IKEv2) Protocol, but there are a number of related RFCs.

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.

IPsec Documents (2 of 2)

Internet Key Exchange (IKE)

A collection of documents describing the key management schemes for use with IPsec

The main specification is RFC 7296, Internet Key Exchange (IKEv2) Protocol, but there are a number of related RFCs

Cryptographic algorithms

Other

There are a variety of other IPsec-related RFCs, including those dealing with security policy and management information base (MIB) content

■ Other: There are a variety of other IPsec-related RFCs, including those dealing with security policy and management information base (MIB) content.

Applications of IPsec

IPsec provides the capability to secure communications across a L A N, private and public W A N s, and the Internet

Examples include:

Secure branch office connectivity over the Internet

Secure remote access over the Internet

Establishing extranet and intranet connectivity with partners

Enhancing electronic commerce security

Principal feature of I Psec is that it can encrypt and/or authenticate all traffic at the I P level

Thus all distributed applications (remote logon, client/server, e-mail, file transfer, Web access) can be secured

IPsec provides the capability to secure communications across a LAN, across private and public WANs, and across the Internet. Examples of its use include:

■ 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 traveling 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. IPsec guarantees that all traffic designated by the net- work administrator is both encrypted and authenticated, adding an additional layer of security to whatever is provided at the application layer.

The principal feature of IPsec that enables it to support these varied applications is that it can encrypt and/or authenticate all traffic at the IP level. Thus, all distributed applications (including remote logon, client/server, email, file transfer, Web access, and so on) can be secured.

I Psec 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)

Put in place any cryptographic keys required to provide the requested services

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)

Limited traffic flow confidentiality

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 in an SAD entry.

■ Security Parameter Index: A 32-bit value selected by the receiving end of an SA to uniquely identify the SA. In an SAD entry for an outbound SA, the SPI is used to construct the packet’s AH or ESP header. In an SAD entry for an inbound SA, the SPI is used to map traffic to the appropriate SA.

■ Sequence Number Counter: A 32-bit value used to generate the Sequence Number field in AH or ESP headers, described in Section 20.3 (required for all implementations).

■ 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, described in Section 20.3 (required for all implementations).

■ 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.

■ 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).

The key management mechanism that is used to distribute keys is coupled to the authentication and privacy mechanisms only by way of the Security Parameters Index (SPI). Hence, authentication and privacy have been specified independent of any specific key management mechanism.

IPsec provides the user with considerable flexibility in the way in which IPsec services are applied to IP traffic. As we will see later, SAs can be combined in a number of ways to yield the desired user configuration. Furthermore, IPsec provides a high degree of granularity in discriminating between traffic that is afforded IPsec protection and traffic that is allowed to bypass IPsec, as in the former case relating IP traffic to specific SAs.

Figure 20.1 IPsec Architecture

Fundamental to the operation of IPsec is the concept of a security policy applied to each IP packet that transits from a source to a destination. IPsec policy is determined primarily by the interaction of two databases, the security association database (SAD) and the security policy database (SPD). This section provides an overview of these two databases and then summarizes their use during IPsec operation. Figure 20.1 illustrates the relevant relationships.

Security Association (S A)

A one-way logical connection between a sender and a receiver that affords security services to the traffic carried on it

In any I P packet, the S A is uniquely identified by the Destination Address in the I P v 4 or I P v 6 header and the S P I in the enclosed extension header (A H or E S P)

Uniquely identified by three parameters:

Security Parameters Index (SPI)

A 32-bit unsigned integer assigned to this SA and having local significance only

IP Destination Address

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

Indicates whether the association is an AH or ESP security association

A key concept that appears in both the authentication and confidentiality mechanisms for IP is the 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. If a peer relationship is needed for two-way secure exchange, then two security associations are required.

A security association is uniquely identified by three parameters.

■ Security Parameters Index (SPI): A 32-bit unsigned integer 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: 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 field from the outer IP header indicates whether the association is an AH or ESP security association.

Hence, in any IP packet, the security association is uniquely identified by the Destination Address in the IPv4 or IPv6 header and the SPI in the enclosed extension header (AH or ESP).

Security Association Database (S A D)

Defines the parameters associated with each S A

Normally defined by the following parameters in a S A D entry:

Security parameter index

Sequence number counter

Sequence counter overflow

Anti-replay window

A H information

E S P information

Lifetime of this security association

I Psec protocol mode

Path M T U

■ Sequence Number Counter: A 32-bit value used to generate the Sequence Number field in AH or ESP headers, described in Section 20.3 (required for all implementations).

■ Anti-Replay Window: Used to determine whether an inbound AH or ESP packet is a replay, described in Section 20.3 (required for all implementations).

■ 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).

■ IPsec Protocol Mode: Tunnel, transport, or wildcard.

■ 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).

Security Policy Database (S P D)

The means by which I P traffic is related to specific S A s

Contains entries, each of which defines a subset of I P traffic and points to an S A for that traffic

In more complex environments, there may be multiple entries that potentially relate to a single S A or multiple SAs associated with a single S P D entry

Each S P D entry is defined by a set of I P and upper-layer protocol field values called selectors

These are used to filter outgoing traffic in order to map it into a particular S A

The means by which IP traffic is related to specific SAs (or no SA in the case of traffic allowed to bypass IPsec) is the nominal Security Policy Database (SPD). In its simplest form, an 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. The reader is referred to the relevant IPsec documents for a full discussion.

Each SPD entry is defined by a set of IP and upper-layer protocol field values, called selectors. In effect, these selectors are used to filter outgoing traffic in order to map it into a particular SA. Outbound processing obeys the following general sequence for each IP packet.

1. Compare the values of the appropriate fields in the packet (the selector fields) against the SPD to find a matching SPD entry, which will point to zero or more SAs.

2. Determine the SA if any for this packet and its associated SPI.

Do the required IPsec processing (i.e., AH or ESP processing).

SPD Entries (1 of 2)

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

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 (e.g., behind a firewall).

■ 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 (e.g., behind a firewall).

■ Next Layer Protocol: The IP protocol header (IPv4, IPv6, or IPv6 Extension) includes a field (Protocol for IPv4, Next Header for IPv6 or IPv6 Extension) that designates the protocol operating over IP. This is an individual protocol number, ANY, or for IPv6 only, OPAQUE. If AH or ESP is used, then this IP protocol header immediately precedes the AH or ESP header in the packet.

■ 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.

SPD Entries (2 of 2)

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

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

The following selectors determine an SPD entry:

■ 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.

Table 20.1 Host S P D Example

Protocol	Local IP	Port	Remote IP	Port	Action	Comment
UDP	1.2.3.101	500	*	500	BYPASS	IKE
ICMP	1.2.3.101	*	*	*	BYPASS	Error messages
*	1.2.3.101	*	1.2.3.0/24	*	PROTECT: ESP intransport-mode	Encrypt intranet traffic
TCP	1.2.3.101	*	1.2.4.10	80	PROTECT: ESP intransport-mode	Encrypt to server
TCP	1.2.3.101	*	1.2.4.10	443	BYPASS	TLS: avoid double encryption
*	1.2.3.101	*	1.2.4.0/24	*	DISCARD	Others in DMZ
*	1.2.3.101	*	*	*	BYPASS	Internet

Table 20.1 provides an example of an SPD on a host system (as opposed to a network system such as a firewall or router). This table reflects the following configuration: A local network configuration consists of two networks. The basic corporate network configuration has the IP network number 1.2.3.0/24. The local configuration also includes a secure LAN, often known as a DMZ, that is identified as 1.2.4.0/24. The DMZ is protected from both the outside world and the rest of the corporate LAN by firewalls. The host in this example has the IP address 1.2.3.10, and it is authorized to connect to the server 1.2.4.10 in the DMZ.

The entries in the SPD should be self-explanatory. For example, UDP port 500 is the designated port for IKE. Any traffic from the local host to a remote host for purposes of an IKE exchange bypasses the IPsec processing.

Figure 20.2 Processing Model for Outbound Packets

Figure 20.2 highlights the main elements of IPsec processing for outbound traffic. A block of data from a higher layer, such as TCP, is passed down to the IP layer and an IP packet is formed, consisting of an IP header and an IP body. Then the following steps occur:

1. IPsec searches the SPD for a match to this packet.

2. If no match is found, then the packet is discarded and an error message is generated.

3. 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.

4. 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.

5. The matching entry in the SAD determines the processing for this packet. Either 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.

Figure 20.3 Processing Model for Inbound Packets

Figure 20.3 highlights the main elements of IPsec processing for inbound traffic. An incoming IP packet triggers the IPsec processing. The following steps occur:

1. IPsec determines whether this is an unsecured IP packet or one that has ESP or AH headers/trailers, by examining the IP Protocol field (IPv4) or Next Header field (IPv6).

2. If the packet is unsecured, IPsec searches the SPD for a match to this packet. If the first matching entry has a policy of BYPASS, the IP header is processed and stripped off and the packet body is delivered to the next higher layer, such as TCP. If the first matching entry has a policy of PROTECT or DISCARD, or if there is no matching entry, the packet is discarded.

3. For a secured packet, IPsec searches the SAD. If no match is found, the packet is discarded. Otherwise, IPsec applies the appropriate ESP or AH processing. Then, the IP header is processed and stripped off and the packet body is delivered to the next higher layer, such as TCP.

Figure 20.4 E S P Packet Format

Figure 20.4a shows the top-level format of an ESP packet. It contains the following fields.

■ 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): The purpose of this field is discussed later.

■ 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 (e.g., an extension header in IPv6, or an upper-layer protocol such as TCP).

■ Integrity Check Value (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.

When any combined mode algorithm is employed, the algorithm itself is expected to return both decrypted plaintext and a pass/fail indication for the integrity check. For combined mode algorithms, the ICV that would normally appear at the end of the ESP packet (when integrity is selected) may be omitted. When the ICV is omitted and integrity is selected, it is the responsibility of the combined mode algorithm to encode within the Payload Data an ICV-equivalent means of verifying the integrity of the packet.

Two additional fields may be present in the payload (Figure 20.4b). An initialization value (IV), or nonce, is present if this is required by the encryption or authenticated encryption algorithm used for ESP. If tunnel mode is being used, then the IPsec implementation may add traffic flow confidentiality (TFC) padding after the Payload Data and before the Padding field, as explained subsequently.

Encapsulating Security Payload (E S P) (1 of 2)

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 I C V 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 I C V

I C V is computed after the encryption is performed

This order of processing facilitates reducing the impact of DoS attacks

Because the I C V is not protected by encryption, a keyed integrity algorithm must be employed to compute the I C V

The Payload Data, Padding, Pad Length, and Next Header fields are encrypted by the ESP service. If the algorithm used to encrypt the payload requires cryptographic synchronization data, such as an initialization vector (IV), then these data may be carried explicitly at the beginning of the Payload Data field. If included, an IV is usually not encrypted, although it is often referred to as being part of the ciphertext.

The ICV field is optional. It 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. The ICV is computed after the encryption is performed. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver prior to decrypting the packet, hence potentially reducing the impact of denial of service (DoS) attacks. It also allows for the possibility of parallel processing of packets at the receiver that is decryption can take place in parallel with integrity checking. Note that because the ICV is not protected by encryption, a keyed integrity algorithm must be employed to compute the ICV.

The Padding field serves several purposes:

■ If an encryption algorithm requires the plaintext to be a multiple of some number of bytes (e.g., the multiple of a single block for a block cipher), the Padding field is used to expand the plaintext (consisting of the Payload Data, Padding, Pad Length, and Next Header fields) to the required length.

■ The ESP format requires that the Pad Length and Next Header fields be right aligned within a 32-bit word. Equivalently, the ciphertext must be an integer multiple of 32 bits. The Padding field is used to assure this alignment.

■ Additional padding may be added to provide partial traffic-flow confidentiality by concealing the actual length of the payload.

Encapsulating Security Payload (E S P) (2 of 2)

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

The Padding field serves several purposes:

■ Additional padding may be added to provide partial traffic-flow confidentiality by concealing the actual length of the payload.

Figure 20.5 Anti-replay Mechanism

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.

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. If anti-replay is enabled (the default), the sender must not allow the sequence number to cycle past 232 – 1 back to zero. Otherwise, there would

be multiple valid packets with the same sequence number. If the limit of 232 – 1 is reached, the sender should terminate this SA and negotiate a new SA with a new key.

Because IP is a connectionless, unreliable service, the protocol does not guarantee that packets will be delivered in order and does not guarantee that all packets will be delivered. Therefore, 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 (Figure 20.5). Inbound processing proceeds as follows when a packet is received:

1. If the received packet falls within the window and is new, the MAC is checked. If the packet is authenticated, the corresponding slot in the window is marked.

2. If the received packet is to the right of the window and is new, the MAC is checked. If the packet is authenticated, the window is advanced so that this sequence number is the right edge of the window, and the corresponding slot in the window is marked.

3. If the received packet is to the left of the window or if authentication fails, the packet is discarded; this is an auditable event.

Figure 20.6 Scope of ESP Encryption and Authentication

Both AH and ESP support two modes of use: transport and tunnel mode. The operation of these two modes is best understood in the context of a description of ESP, which is more widely used than AH. In what follows, we look at the scope of ESP for the two modes. The former technique is supported by a transport mode SA, while the latter technique uses a tunnel mode SA.

The considerations are somewhat different for IPv4 and IPv6. We use the packet formats of Figure 20.6a as a starting point.

Figure 20.7 End-to-end IPsec Transport-Mode Encryption

Transport mode provides protection primarily for upper-layer protocols. That is, transport mode protection extends to the payload of an IP packet.

Examples include a TCP or UDP segment or an ICMP packet, all of which operate directly above IP in a host protocol stack. Typically, transport mode is used for end-to-end communication between two hosts (e.g., a client and a server, or two workstations; see Figure 20.7). When a host runs AH or ESP over IPv4, the payload is the data that normally follow the IP header. For IPv6, the payload is the data that normally follow both the IP header and any IPv6 extensions headers that are present, with the possible exception of the destination options header, which may be included in the protection. Transport mode ESP is used to encrypt and optionally authenticate the data carried by IP (e.g., a TCP segment), as shown in Figure 20.6b. 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 (1 of 2)

Transport mode operation may be summarized as follows:

At the source, the block of data consisting of the E S P trailer plus the entire transport-layer segment is encrypted and the plaintext of this block is replaced with its ciphertext to form the I P packet for transmission. Authentication is added if this option is selected

The packet is then routed to the destination. Each intermediate router needs to examine and process the I P header plus any plaintext I P extension headers but does not need to examine the ciphertext

The destination node examines and processes the I P header plus any plaintext I P extension headers. Then, on the basis of the S P I in the E S P header, the destination node decrypts the remainder of the packet to recover the plaintext transport-layer segment

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 (2 of 2)

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

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.

Tunnel Mode (1 of 3)

Tunnel mode provides protection to the I P packet

To achieve this, after the A H or E S P fields are added to the I P packet, the entire packet plus security fields is treated as the payload of new outer I P packet with a new outer I P header

The entire original, inner, packet travels through a tunnel from one point of an I P network to another; no routers along the way are able to examine the inner I P header

Because the original packet is encapsulated, the new, larger packet may have totally different source and destination addresses, adding to the security

Tunnel mode provides protection to the entire IP packet (Figure 20.6c). To achieve this, after the AH or ESP fields are added to the IP packet, the entire packet plus security fields is treated as the payload of new outer IP packet with a new outer IP header. The entire original, inner, packet travels through a tunnel from one point of an IP network to another; no routers along the way are able to examine the inner IP header. Because the original packet is encapsulated, the new, larger packet may have totally different source and destination addresses, adding to the security. Tunnel mode 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. The unprotected packets generated by such hosts are tunneled through external networks by tunnel mode SAs set up by the IPsec software in the firewall or secure router at the boundary of the local network.

Tunnel Mode (2 of 3)

Tunnel mode is used when one or both ends of a security association (S A) are a security gateway, such as a firewall or router that implements I Psec

With tunnel mode, a number of hosts on networks behind firewalls may engage in secure communications without implementing IPsec

The unprotected packets generated by such hosts are tunneled through external networks by tunnel mode S As set up by the IPsec software in the firewall or secure router at the boundary of the local network

Tunnel Mode (3 of 3)

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

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

It thwarts traffic analysis based on ultimate destination

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.

V P N

Tunnel mode can be used to implement a secure virtual private network

A virtual private network (V P N) is a private network that is configured within a public network in order to take advantage of the economies of scale and management facilities of large networks

V P N s are widely used by enterprises to create wide area networks that span large geographic areas, to provide site-to-site connections to branch offices, and to allow mobile users to dial up their company L A N s

The pubic network facility is shared by many customers, with the traffic of each customer segregated from other traffic

Traffic designated as V P N traffic can only go from a V P N source to a destination in the same V P N

It is often the case that encryption and authentication facilities are provided for the V P N

Tunnel mode can be used to implement a secure virtual private network. A virtual private network (VPN) is a private network that is configured within a public network (a carrier’s network or the Internet) in order to take advantage of the economies of scale and management facilities of large networks. VPNs are widely used by enterprises to create wide area networks that span large geographic areas, to provide site-to-site connections to branch offices, and to allow mobile users to dial up their company LANs. From the point of view of the provider, the pubic network facility is shared by many customers, with the traffic of each customer segregated from other traffic. Traffic designated as VPN traffic can only go from a VPN source to a destination in the same VPN. It is often the case that encryption and authentication facilities are provided for the VPN.

Figure 20.8 Example of Virtual Private Network Implemented with IPsec Tunnel Mode

Figure 20.8 shows a typical scenario of IPsec tunnel mode for implementing a VPN. An organization maintains LANs at dispersed locations. Nonsecure IP traffic is conducted on each LAN. For traffic offsite, through some sort of private or public network, IPsec protocols are used. These 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 Internet or other network and decrypt and decompress traffic coming from the network; these operations are transparent to workstations and servers on the LAN. Secure transmission is also possible with individual users who connect to the Internet or other network. Such user workstations must implement the IPsec protocols to provide security.

Table 20.2 Tunnel Mode and Transport Mode Functionality

Blank	Transport Mode S A	Tunnel Mode S A
A H	Authenticates I P payload and selected portions of I P header and IPv6 extension headers.	Authenticates entire inner I P packet (inner header plus I P payload) plus selected portions of outer I P header and outer I P v 6 extension headers.
E S P	Encrypts I P payload and any IPv6 extension headers following the ESP header.	Encrypts entire inner I P packet.
E S P with Authentication	Encrypts I P payload and any IPv6 extension headers following the E S P header. Authenticates I P payload but not I P header.	Encrypts entire inner I P packet. Authenticates inner I P packet.

Table 20.2 summarizes transport and tunnel mode functionality.

Figure 20.9 Protocol Operation for E S P

Figure 20.9 shows the protocol architecture for the transport and tunnel modes.

Combining Security Associations

An individual SA can implement either the AH or ESP protocol but not both

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 endpoint

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 allows for only one level of combination

Iterated tunneling

Refers to the application of multiple layers of security protocols effected through IP tunneling

This approach allows for multiple levels of nesting

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. Further, a particular traffic flow may require IPsec services between hosts and, for that same flow, separate services between security gateways, such as firewalls. In all of these cases, multiple SAs must be employed for the same 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 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 effected 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 end- points and the ways of doing so. We examine that issue next. Then we look at combinations of SAs that involve at least one tunnel.

E S P with Authentication Option

In this approach, the first user applies E S P to the data to be protected and then appends the authentication data field

Transport mode E S P

Authentication and encryption apply to the I P payload delivered to the host, but the I P header is not protected

Tunnel mode E S P

Authentication applies to the entire I P packet delivered to the outer I P destination address and authentication is performed at that destination

The entire inner I P packet is protected by the privacy mechanism for delivery to the inner I P destination

For both cases authentication applies to the ciphertext rather than the plaintext

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

This approach is illustrated in Figure 20.6. In this approach, the user first applies ESP to the data to be protected and then appends the authentication data field. There are actually two subcases:

■ 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 ciphertext rather than the plaintext.

Transport Adjacency

Another way to apply authentication after encryption is to use two bundled transport S A s, with the inner being an E S P S A and the outer being an A H S A

In this case E S P is used without its authentication option

Encryption is applied to the I P payload

A H is then applied in transport mode

Advantage of this approach is that the authentication covers more fields

Disadvantage is the overhead of two S A s versus one S A

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:

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 A H transport S A and an outer E S P tunnel S A

Authentication is applied to the I P payload plus the I P header

The resulting I P packet is then processed in tunnel mode by E S P

The result is that the entire authenticated inner packet is encrypted and a new outer I P header is added

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 later reference. It is more convenient to do this if the authentication information applies to the un- encrypted 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.

Figure 20.10 Basic Combinations of Security Associations

Internet Key Exchange

The key management portion of I Psec 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 I Psec 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

Enables the on-demand creation of keys for S A s and facilitates the use of keys in a large distributed system with an evolving configuration

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.

I S A K M P/Oakley

The default automated key management protocol of IPsec

Consists of:

Oakley Key Determination Protocol

A key exchange protocol based on the Diffie-Hellman algorithm but providing added security

Generic in that it does not dictate specific formats

Internet Security Association and Key Management Protocol (I S A K M P)

Provides a framework for Internet key management and provides the specific protocol support, including formats, for negotiation of security attributes

Consists of a set of message types that enable the use of a variety of key exchange algorithms

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.

ISAKMP by itself does not dictate a specific key exchange algorithm; rather, ISAKMP consists of a set of message types that enable the use of a variety of key exchange algorithms. Oakley is the specific key exchange algorithm mandated for use with the initial version of ISAKMP.

In IKEv2, the terms Oakley and ISAKMP are no longer used, and there are significant differences from the use of Oakley and ISAKMP in IKEv1. Nevertheless, the basic functionality is the same. In this section, we describe the IKEv2 specification.

Features of I K E 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

The IKE key determination algorithm is characterized by five important features:

1. It employs a mechanism known as cookies to thwart clogging attacks.

2. It enables the two parties to negotiate a group; this, in essence, specifies the global parameters of the Diffie-Hellman key exchange.

3. It uses nonces to ensure against replay attacks.

4. It enables the exchange of Diffie-Hellman public key values.

5. It authenticates the Diffie-Hellman exchange to thwart man-in-the-middle attacks.

Figure 20.11 IKEv2 Exchanges

The IKEv2 protocol involves the exchange of messages in pairs. The first two pairs of exchanges are referred to as the initial exchanges (Figure 20.11a). In the first exchange, the two peers exchange information concerning cryptographic algorithms and other security parameters they are willing to use along with nonces and Diffie–Hellman (DH) values. The result of this exchange is to set up a special SA called the IKE SA (see Figure 20.1). This SA defines parameters for a secure channel between the peers over which subsequent message exchanges take place. Thus, all subsequent IKE message exchanges are protected by encryption and message authentication. In the second exchange, the two parties authenticate one another and set up a first IPsec SA to be placed in the SADB and used for protecting ordinary (i.e. non-IKE) communications between the peers. Thus, four messages are needed to establish the first SA for general use.

The CREATE_CHILD_SA exchange can be used to establish further SAs for protecting traffic. The informational exchange is used to exchange management information, IKEv2 error messages, and other notifications.

The CREATE_CHILD_SA exchange can be used to establish further SAs

for protecting traffic. The informational exchange is used to exchange management

information, IKEv2 error messages, and other notifications.

Figure 20.12 I K E Formats

An IKE message consists of an IKE header followed by one or more payloads. All of this is carried in a transport protocol. The specification dictates that implementations must support the use of UDP for the transport protocol.

Figure 20.12a shows the header format for an IKE message. It consists of the following fields.

■ Initiator SPI (64 bits): A value chosen by the initiator to identify a unique IKE security association (SA).

■ Responder SPI (64 bits): A value chosen by the responder to identify a unique IKE SA.

■ Next Payload (8 bits): Indicates the type of the first payload in the message; payloads are discussed in the next subsection.

■ Major Version (4 bits): Indicates major version of IKE in use.

■ Minor Version (4 bits): Indicates minor version in use.

■ Exchange Type (8 bits): Indicates the type of exchange; these are discussed later in this section.

■ Flags (8 bits): Indicates specific options set for this IKE exchange. Three bits are defined so far. The initiator bit indicates whether this packet is sent by the SA initiator. The version bit indicates whether the transmitter is capable of using a higher major version number than the one currently indicated. The response bit indicates whether this is a response to a message containing the same message ID.

■ Message ID (32 bits): Used to control retransmission of lost packets and matching of requests and responses.

■ Length (32 bits): Length of total message (header plus all payloads) in octets.

All IKE payloads begin with the same generic payload header shown in Figure 20.12b. The Next Payload field has a value of 0 if this is the last pay- load in the message; otherwise its value is the type of the next payload. The Payload Length field indicates the length in octets of this payload, including the generic pay- load header.

The critical bit is 0 if the sender wants the recipient to skip this payload if it does not understand the payload type code in the Next Payload field of the previous payload. It is set to 1 if the sender wants the recipient to reject this entire message if it does not understand the payload type.

Table 20.3 IKE Payload Types

Type	Parameters
Security Association	Proposals
Key Exchange	DH Group #, Key Exchange Data
Identification	ID Type, ID Data
Certificate	Cert Encoding, Certificate Data
Certificate Request	Cert Encoding, Certification Authority
Authentication	Auth Method, Authentication Data
Nonce	Nonce Data
Notify	Protocol-ID, SPI Size, Notify Message Type, SPI, Notification Data
Delete	Protocol-ID, SPI Size, # of SPIs, SPI (one or more)
Vendor ID	Vendor ID
Traffic Selector	Number of TSs, Traffic Selectors
Encrypted	IV, Encrypted IKE payloads, Padding, Pad Length, ICV
Configuration	CFG Type, Configuration Attributes
Extensible Authentication Protocol	EAP Message

Table 20.3 summarizes the payload types defined for IKE and lists the fields, or parameters, that are part of each payload. The SA payload is used to begin the establishment of an SA. The payload has a complex, hierarchical structure. The payload may contain multiple proposals. Each proposal may contain multiple protocols. Each protocol may contain multiple transforms. And each transform may contain multiple attributes. These elements are formatted as substructures within the payload as follows.

■ Proposal: This substructure includes a proposal number, a protocol ID (AH, ESP, or IKE), an indicator of the number of transforms, and then a transform substructure. If more than one protocol is to be included in a proposal, then there is a subsequent proposal substructure with the same proposal number.

■ Transform: Different protocols support different transform types. The transforms are used primarily to define cryptographic algorithms to be used with a particular protocol.

■ Attribute: Each transform may include attributes that modify or complete the specification of the transform. An example is key length.

The Key Exchange payload can be used for a variety of key exchange techniques, including Oakley, Diffie–Hellman, and the RSA-based key exchange used by PGP. The Key Exchange data field contains the data required to generate a session key and is dependent on the key exchange algorithm used.

The Identification payload is used to determine the identity of communicating peers and may be used for determining authenticity of information. Typically the ID Data field will contain an IPv4 or IPv6 address.

The Certificate payload transfers a public-key certificate. The Certificate Encoding field indicates the type of certificate or certificate-related information. At any point in an IKE exchange, the sender may include a Certificate

Request payload to request the certificate of the other communicating entity. The payload may list more than one certificate type that is acceptable and more than one certificate authority that is acceptable.

The Authentication payload contains data used for message authentication purposes. The authentication method types so far defined are RSA digital signature, shared-key message integrity code, and DSS digital signature.

The Nonce payload contains random data used to guarantee liveness during an exchange and to protect against replay attacks.

The Notify payload contains either error or status information associated with this SA or this SA negotiation.

The Delete payload indicates one or more SAs that the sender has deleted from its database and that therefore are no longer valid.

The Vendor ID payload contains a vendor-defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backward compatibility.

The Traffic Selector payload allows peers to identify packet flows for processing by IPsec services.

The Encrypted payload contains other payloads in encrypted form. The encrypted payload format is similar to that of ESP. It may include an IV if the encryption algorithm requires it and an ICV if authentication is selected.

The Configuration payload is used to exchange configuration information between IKE peers.

The Extensible Authentication Protocol (EAP) payload allows IKE SAs to be authenticated using EAP.

Summary

Present an overview of I P security (I Psec)

Explain the difference between transport mode and tunnel mode

Understand the concept of security association

Explain the difference between the security association database and the security policy database

Present an overview of Encapsulating Security Payload

Summarize the traffic processing functions performed by I Psec for out- bound packets and for inbound packets

Discuss the alternatives for combining security associations

Present an overview of Internet Key Exchange

Summarize the alternative cryptographic suites approved for use with IPsec

Chapter 20 summary.

This work is protected by United States copyright laws and is provided solely for the use of instructors in teaching their courses and assessing student learning. Dissemination or sale of any part of this work (including on the World Wide Web) will destroy the integrity of the work and is not permitted. The work and materials from it should never be made available to students except by instructors using the accompanying text in their classes. All recipients of this work are expected to abide by these restrictions and to honor the intended pedagogical purposes and the needs of other instructors who rely on these materials.

.MsftOfcThm_Text1_Fill { fill:#000000; } .MsftOfcThm_MainDark1_Stroke { stroke:#000000; }

What Students Are Saying About Us

.......... Customer ID: 12*** | Rating: ⭐⭐⭐⭐⭐
"Honestly, I was afraid to send my paper to you, but splendidwritings.com proved they are a trustworthy service. My essay was done in less than a day, and I received a brilliant piece. I didn’t even believe it was my essay at first 🙂 Great job, thank you!"

.......... Customer ID: 14***| Rating: ⭐⭐⭐⭐⭐
"The company has some nice prices and good content. I ordered a term paper here and got a very good one. I'll keep ordering from this website."

What Students Are Saying About Us

"Order a Custom Paper on Similar Assignment! No Plagiarism! Enjoy 20% Discount"

Related posts: