IPsec Standards

There are many different ways of implementing VPNs, as discussed in Chapter 1. For example, you could use an SSL VPN solution to protect data between two devices; however, the main limitation of SSL VPNs is that they primarily provide application layer protection, which typically is limited to web browser-based connections, and specific applications the vendor has written code for, to tunnel through the SSL VPN. Their advantage, however, is that they can use an existing web browser on the user's desktop.

IPsec, on the other hand, provides protection at the network layer; therefore, any IP traffic can be protected between peer devices. But IPsec is intrusive on the client (remote access) side; typically you need additional software installed on your device to provide the network-layer protection.

Note

Depending on the vendor's gateway product, you might be able use the Microsoft L2TP/IPsec VPN client, which is pre-installed on Microsoft Windows 2000 and XP desktops.

IPsec's framework is defined in RFC 2401; however, the implementation of IPsec is defined across quite a few different RFCs. As I mentioned in the chapter introduction, IPsec provides the following services:

The two main groupings of standards that IPsec uses are:

The following sections will provide an overview of the RFCs used by IPsec, including the standards mentioned in the above bullets. Specifically, they cover the following:

IETF RFCs

IPsec is a framework of standards defined in IETF RFCs. This section provides a quick overview of these RFCs:

Other RFCs are defined for IPsec, but these are the main and original ones, so the remaining subsections will focus on the RFCs listed above. The actual RFCs can be found on IETF's web site (www.ietf.org).

RFC 2401

RFC 2401 defines the framework of IPsec for both IPv4 and IPv6. It specifies the services for IP layer protection of one or more paths between two devices, which could be two end-stations, two VPN gateways, or an end-station and a VPN gateway. Because IPsec functions at the network layer, it protects traffic at Layer-3 and higher, including protocols such as TCP, UDP, ICMP, and tunneled IP packets, like GRE. The services IPsec provides for are access control, connectionless integrity, rejection of replayed packets, confidentiality, and data origin authentication.

IPsec uses two protocols to provide for data security: AH, defined in RFC 2402, and ESP, defined in RFC 2406. AH provides connectionless integrity, data origin authentication, and anti-replay services. ESP provides the same services, and also confidentiality via encryption, which is its main function. AH and ESP can be used individually to provide for protection, or they can be used in combination. Both support transport and tunnel mode protection. In transport mode, the upper layer protocols are protected, whereas in tunnel mode, an entire tunneled IP packet is protected. These modes are discussed in more depth later in the chapter in the "Connection Modes" section.

IPsec is flexible in that you can choose the protocols and types of protection to be used, custom-tailoring it to fit your specific environment or situation. You control what traffic is to be protected (for example, Telnet and HTTP traffic) and how it should be protected (for example, AH or ESP, MD5, 3DES, and so on).

Note

Protecting packets based on IP addresses or applications is vendor- or product-specific. For example, Cisco routers, and PIX and ASA security appliances, allow you to define this granularity on an application-by-application basis, but the VPN 3000 concentrators allow you to define these policies on only an address-by-address basis.

Because some of these security services require keys, such as HMAC functions and encryption algorithms, IPsec defines a set of processes for dynamically creating keying information that peers will use. The Internet Key Exchange (IKE) protocol, discussed in the "RFC 2409" section, defines the mechanics for both dynamic and manual distribution key methods. Even though all vendors today use IKE, IPsec allows for other dynamic key distribution techniques, such as Kerberos's Key Distribution Center and SKIP.

RFC 2402

RFC 2402 defines how to provide for connectionless packet integrity and data origin authentication for IP packets with the AH protocol, which is assigned an IP protocol number of 51. AH can also, optionally, detect and prevent packet replay attacks. AH provides for packet authentication services for most of the IP packet header, and for the upper-layer protocol. This is accomplished using an HMAC function.

Because some IP fields are mutable, they are not included in the input of the HMAC function. Mutable fields are fields that can change in transit, such as the time-to-live (TTL) and type-of-service (TOS) fields. AH is discussed in more depth in the "Security Protocols" section later in the chapter.

RFC 2403

AH and ESP can both provide data authentication and data integrity services. To implement these, HMAC functions are used. RFC 2104 defines the properties of an HMAC function, and RFC 1321 describes MD5. RFC 2403 describes how the MD5 HMAC function can be used by AH and ESP.

The data authentication and integrity services provided by AH and ESP take most of, or at least part of, the packet contents and a shared symmetric key, and run them through the HMAC-MD5 algorithm to provide a signature. This signature, along with the user data, is sent to the remote system. The remote system will verify the integrity of the packet with the same inputted data and the same symmetric key.

RFC 1321 describes the implementation of MD5, where the generated signature is 128 bits in length. IPsec uses RFC 2104 to truncate the digital signature to 96 bits. I described this possible process by a VPN implementation in Chapter 2, "VPN Technologies." One might think that by truncating the signature, it would be easier to forge a signature; however, the possibility of this is less likely than you winning your state lottery, mathematically speaking. The length of 96 bits was chosen because it is the length described in RFC 2402 for AH and meets the necessary security requirements outlined in RFC 2104.

RFC 2404

Like its sister (RFC 2403), RFC 2404 describes the use of an HMAC function for IPsec; in this instance, it's SHA-1. SHA-1 can be used by AH and ESP to provide for data authentication and data integrity services. Like RFC 2403, RFC 2404 truncates the digital signature. In SHA-1's case, it is truncated from 160 bits to 96 bits. The truncation process allows an easier implementation of AH and ESP because the signature field is the same length whether MD5 or SHA-1 is used.

Note

Of the two HMAC functions, SHA-1 is more secure, but is more process-intensive. Because HMAC functions are used to add a signature to every packet, you might want to consider the overhead that this might have if you choose SHA-1, which is more secure.

 

RFC 2405

RFC 2405 describes the use of the DES cipher algorithm as an encryption algorithm for ESP. Other encryption algorithms are supported by IPsec today, including 3DES and AES (128-bit, 192-bit, and 256-bit cipher blocks).

Tip

Because DES is breakable with today's computing power, and because 3DES is very computationally intensive in software, I recommend that you use AES to provide for confidentiality services in IPsec. Even though performing 3DES and AES encryption in hardware requires about the same amount of processing, AES is still a more secure protocol.

 

RFC 2406

The ESP protocol is defined in RFC 2046. It can be used stand-alone or in conjunction with AH. ESP's main service is to provide confidentiality through the use of encryption. Optionally, it can perform data origin authentication, connectionless data integrity, and anti-replay services.

Because AH doesn't provide for data confidentiality, ESP is more commonly used. One limitation of ESP, though, is that AH provides for a more secure solution with data origin authentication and integrity services than ESP. I'll discuss this in more depth later in the chapter in the "Security Protocols" section.

RFC 2407

RFC 2407 defines a framework for the management of protected connections, commonly called security associations, with the Internet Security Association and Key Management (ISAKMP) protocol. ISAKMP defines:

This RFC focuses on an overview of this process.

Note

A Security Association (SA) contains all of the information necessary for implementing the security services for a connection, such as the use of AH or ESP, the connection mode (tunnel or transport), the HMAC functions and encryption algorithms, the keys to use for these functions and algorithms, the lifetime of the SA, and many other items.

 

RFC 2408

RFC 2408 actually explains the mechanics of the interaction between two IPsec devices establishing, negotiating, modifying, and deleting security associationsin other words, how two peers talk to each other about using IPsec. ISAKMP is responsible for defining the payload (format of information) for exchanging keying and authentication information; however, this is a basic framework definition. ISAKMP actually doesn't define the mechanics for these processes, which allows the possibility for IPsec to use several methods for these processes. As you will see in RFC 2409, IKE is the component used today to implement keying and authentication services.

ISAKMP centralizes the management of SAs and thus reduces the amount of duplicated functionality with each security protocol. In other words, AH, ESP, and other IPsec protocols do not have to play a role in the negotiation process between peers. With IPsec, ISAKMP plays this centralized role and thereby reduces the setup time for establishing a connection by negotiating all services at one time.

RFC 2409

RFC 2409 defines the Internet Key Exchange (IKE) protocol, which is a hybrid protocol. IKE is responsible for negotiating, creating, and refreshing keying information to protect IPsec connections. ISAKMP defines the framework for this, but IKE defines the actual mechanics for the process. We refer to IKE as a hybrid protocol because it uses a subset of the mechanics from the Oakley and SKEME protocols. In other words, it doesn't use the complete processes defined by Oakley and SKEME, and therefore isn't 100 percent compatible with them. But IKE borrows some of their mechanics to deal with keying issues with IPsec.

Oakley uses a hybrid Diffie-Hellman process to create session keys on peer devices, implementing a unique feature called Perfect Forward Secrecy (PFS)the ability to create a shared secret key on two devices without having to "share" the actual key across the network between the two peers. Diffie-Hellman implements a similar process, which was discussed in Chapter 2. ISAKMP supports a subset of the Oakley key exchange modes and is implemented through the use of Diffie-Hellman.

Where Oakley and SKEME define modes for the actual exchange process, ISAKMP and IKE use phases. IKE operates much like the Oakley and SKEME mode process. With IKE, different exchanges occur in two separate phases. Phase 1 is where the two peers build a secure management connection between themselves. No data actually traverses this connection; instead, it is used for IPsec communication, including the negotiation of the secure data connections that are built in Phase 2. The "ISAKMP/IKE Phase 1" and "ISAKMP/IKE Phase 2" sections cover these two phases in more depth.

Note

In the industry, I commonly see people incorrectly use the terms ISAKMP, Oakley, SKEME, and IKE when referring to IPsec. Sometimes people will use an individual term to describe the process that is performed by all of these standards. Throughout the book, I'll use ISAKMP/IKE to refer to these standards.

 

RFC 2410

RFC 2410 allows ESP to not use confidentiality, that is, encryption, when protecting data connections. This is commonly referred to as "NULL encryption." In most cases, ESP is used because it has encryption, but for certain applications, encryption might not be necessary and AH might not be suitable; therefore, you can use ESP for data origin authentication, packet integrity checking, and anti-replay detection.

RFC 2411

The main goal of RFC 2411 is to help reduce the possible number of RFCs that might be created in the future to support new technologies that can be applied to IPsec to enhance security for a network. It focuses mainly on specifying guidelines in how new encryption algorithms and HMAC functions can be integrated into IPsec's AH and ESP protocols, and into key management protocol enhancements.

IPsec Connections

Now that you have had an introduction to some of the standards used by IPsec, let's take a look at the communication process to share data securely between two IPsec peers. Two peers will go through five basic steps during the lifetime of sharing data securely:

1.

Something needs to trigger the IPsec process. This is typically caused by one peer needing to send traffic destined to a destination peer that needs to be protected. Of course, an administrator or user could start this process manually from one of the two IPsec peers.

 

2.

If no VPN connection exists, IPsec will use ISAKMP/IKE Phase 1 to build a secure management connection. This management connection is used so that the two peers can communicate with each other securely, via IPsec, and can build secure data connections. Please note that this connection is not used to transmit any user data, such as files or e-mail messages. I like to refer to these Phase 1 connections as management connections because no user data traverses them.

 

3.

Across the secure management connection, the two IPsec peers will negotiate the security parameters that are used to build the secure data connections; these secure data connections are used to transmit user data, such as files, Telnets, e-mail messages, video, and voice. I like to refer to these connections as data connections because the users' actual data traverses these connections.

 

4.

Once the data connections are built, the IPsec devices can use them to share user data securely. If HMAC functions are used by the source to create signatures, the destination verifies these for data integrity and authentication; plus, if the data is encrypted by the source, the destination will decrypt the data.

 

5.

Both the management and data connections have a lifetime associated with them. This ensures that keying information is regenerated to provide for better security in case someone is trying to break your security keys. Once the lifetime of a connection is reached, it is torn down. Of course, if you still need to send data, the connection will be rebuilt dynamically.

 

Note

Cisco, and many other networking vendors, sometimes tend to use IPsec terms poorly to describe Phase 1 and Phase 2. For example, some vendors commonly use the term "ISAKMP" to describe Phase 1 and "IPsec" to describe Phase 2. I've never really liked the use of these terms because more than one standard is used in Phase 1, and IPsec, used by most people in the industry, refers to the grouping of all standards for the VPN, including ISAKMP and IKE! Therefore, when I teach classes on IPsec, I like refer to the ISAKMP/IKE Phase 1 connections as IPsec management connections and the ISAKMP/IKE Phase 2 connection as IPsec data connections because these definitions make more sense.

A security association (SA) basically groups all of the necessary security components to successfully communicate with an IPsec peer. In other words, once all the parameters have been negotiated and the keying information is generated, the peers have an SA they can use to communicate with each other securely.

There are many components involved in protecting both management and data connections. For example, some of the components you'll find in an SA are:

There are many more components to an SA, but the above are the main ones.

Looking at the preceding five steps in building an IPsec session to a remote peer, it seems that IPsec is a simple process; however, I've summarized the basic steps that take place. In reality, there are a lot of things occurring by various IPsec standards to implement these five basic steps. For example, to set up and maintain secure connections with a remote peer, minimally, the following will have to be done:

1.

You'll need to determine what traffic should be protected. Sometimes this is done statically and sometimes dynamically. For instance, on a site-to-site session on a Cisco router or PIX, you can configure this with a crypto access control list (crypto ACL). For a site-to-site connection on a 3000 series concentrator, this is commonly done with network lists. For remote access sessions, this policy is defined on the VPN gateway the client is making a connection to.

 

2.

You'll need to determine how the management connection is protected by asking the following questions (note that there might be many other items if the IPsec VPN is remote access):

 

- How should device authentication be performed?

- Which encryption algorithm and HMAC function should be used?

- Which mode should be used: main or aggressive?

- Which Diffie-Hellman key group should be used?

- What is the lifetime of the connection?

3.

You'll need to determine how the data connections are to be protected:

 

- Which security protocol is used: AH and/or ESP?

- For ESP, what encryption algorithm and/or HMAC function is used?

- For AH, what HMAC function is used?

- For AH and ESP, what mode will they operate in: tunnel or transport?

- What are the lifetimes of the data connections?

- Should the management connection be used for sharing keying material or should Diffie-Hellman be used instead (referred to as perfect forward secrecy)?

4.

The IPsec devices will need to keep track of all of this information to enforce the manually configured or negotiated security policies.

 

As you can see from this list, IPsec is not a simple process no matter what kind of device you'll be using. Because of this complexity, I want to ensure that you know all of the proper steps IPsec goes through in setting up an IPsec session between peers: this will greatly assist you when IPsec sessions fail and you must troubleshoot the problem or problems.

IPsec Intricacies

When I was first exposed to IPsec a handful of years ago, I was completely confused about how to set it up. I was setting up a "simple" site-to-site session between two Cisco 7500 routers. I used a configuration example from the Cisco site to assist in the setup, since I knew, at that time, very little about IPsec. Of course, when I finished the configuration and tried to bring up the session, it wouldn't come up. It took me two days to troubleshoot the problem to an address translation issue, which caused IPsec to break. Back then, I didn't have the luxury of using features like IPsec over UDP or NAT-T. It took me another five days to get public addresses for both routers and make them exceptions to the address translation process. From this experience, I sat down and started reading a lot about IPsec and its implementation, because I knew I would have to do this many more times in the future. And when I teach Cisco VPN material in various Cisco courses, I stress the importance of understanding how IPsec works, because it is a complicated process. By going through how an IPsec session is established, you'll have a better understanding on how to configure IPsec on Cisco devices, and how to troubleshoot problems with peers that fail to bring up an IPsec session.

 

Basic Process of Building Connections

I believe it is very important to understand how IPsec works when you decide to use it as a VPN implementation. Cisco offers a lot of tools, such as Security Device Manager (SDM) for the routers, the PIX Device Manager (PDM) for the PIXs (pre-7.0), and the Adaptive Security Device Manager (ASDM) for PIXs and ASAs running 7.0 that support configuration wizards, greatly simplifying the setup of IPsec VPNs. However, not everything in these tools is wizard-based for setting up VPN sessions, and not every session will work the first time you set it up. Moreover, some IPsec features on Cisco devices might require you to configure or troubleshoot them from a CLI. Therefore, having an intimate understanding of the workings of IPsec is essential.

There are two possible processes that will take place in building an IPsec session, depending on whether it's a site-to-site or remote access IPsec session. For a site-to-site session, the following process will be performed:

1.

One VPN gateway peer initiates a session to the remote VPN gateway peer.

 

2.

ISAKMP/IKE Phase 1 begins when the peers negotiate how the management connection will be protected.

 

3.

Diffie-Hellman is used to share the keys securely for encryption algorithms and HMAC functions of the management connection.

 

4.

Device authentication is performed across the secure management connection.

 

5.

ISAKMP/IKE Phase 1 ends and Phase 2 begins: the peers negotiate the parameters and the keying information to protect the data connections (this is done across the secure management connection or, optionally, by using Diffie-Hellman again).

 

6.

The data connections are established and Phase 2 ends: the VPN gateways can now protect user traffic across the data connections.

 

7.

Eventually the management and data connections will expire and will have to be rebuilt.

 

Remote access VPN connections are more complicated than site-to-site connections because you might want to perform user authentication and push session policies from the VPN gateway to the client. This is complicated, because vendors might use proprietary methods to implement some of these steps. I'll focus only on Cisco implementation, because this is a book on Cisco VPNs.

Here is the process that will occur with Cisco remote access IPsec VPNs:

1.

The remote access client initiates a connection to the remote VPN gateway.

 

2.

IKE Phase 1 begins when the client and VPN gateway negotiate how the management connection will be protected.

 

3.

Diffie-Hellman is used to share the keys securely for encryption algorithms and HMAC functions for the management connection.

 

4.

Device authentication is performed across the secure management connection.

 

5.

Optionally, user authentication is performed. With IPsec, this is done with the XAUTH standard. With XAUTH, the VPN gateway will challenge the user for a username and password.

 

6.

Most IPsec remote access implementations by vendors will then push policy information to the client. In the Cisco realm, this is commonly referred to as either IKE Mode Config or IKE Client Config. This process is done in a somewhat proprietary fashion by each vendor; so, for example, a non-Cisco client might not understand the information being pushed to it by a Cisco VPN gateway. With Cisco implementation, the client can be assigned an internal IP address, a domain name, DNS and WINS server addresses, split tunneling policies, firewall policies, and other connection policies.

 

7.

Optionally (in Cisco remote access VPNs), reverse route injection (RRI) can take place. This is where the client can optionally advertise routing information, via the IPsec management connection, to the VPN gateway. The VPN gateway can advertise this routing information to the internal network.

 

8.

ISAKMP/IKE Phase 1 ends and Phase 2 begins: the client and VPN gateway negotiate the parameters and the keying information to protect the data connections (this is done across the secure management connection).

 

Note

IKE Mode Config and other assorted Cisco-proprietary protocols or processes used for building and maintaining remote access IPsec sessions are referred to as "Easy VPN."

9.

The data connections are established and Phase 2 ends: the VPN gateways can now protect user traffic across the data connections.

 

10.

Eventually the lifetimes associated with the management and data connections will expire and these connections will have to be rebuilt.

 
Related

Категории