Implementing IPSec: Strategies for Making Network and VPN Security Work


How do you secure your IP network without destroying it? The IPsec protocols are the only viable standard for secure, network-layer transmission on IP, yet they can wreak havoc on critical applications and other enhanced network services. Interoperability problems between vendors, as well as limitations in the basic technology, can cause problems that range from annoying to disastrous. This book tells you how IPsec works (or doesn't work) with other technologies, describes how to select products that will meet ...
See more details below
Available through our Marketplace sellers.
Other sellers (Hardcover)
  • All (15) from $1.99   
  • New (3) from $39.35   
  • Used (12) from $1.99   
Sort by
Page 1 of 1
Showing 1 – 2 of 3
Note: Marketplace items are not eligible for any coupons and promotions
Seller since 2014

Feedback rating:



New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

Brand New Item.

Ships from: Chatham, NJ

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Seller since 2014

Feedback rating:


Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing 1 – 2 of 3
Sort by
Sending request ...


How do you secure your IP network without destroying it? The IPsec protocols are the only viable standard for secure, network-layer transmission on IP, yet they can wreak havoc on critical applications and other enhanced network services. Interoperability problems between vendors, as well as limitations in the basic technology, can cause problems that range from annoying to disastrous. This book tells you how IPsec works (or doesn't work) with other technologies, describes how to select products that will meet your needs, and discusses legal issues critical to IPsec deployment.

This hands-on guide will help you to:
* Analyze how and why IPsec may break existing networks
* Combine IPsec with other enhanced IP services and applications
* Determine the causes of IPsec performance problems and protocol conflicts
* Understand how existing laws and regulatory trends may impact your use of IPsec products
* Understand the basic technological components of IPsec
* Evaluate IPsec vendors and products

Networking council

Networking Council Books put technology into perspective for decision-makers who need an implementation strategy, a vendor and outsourcing strategy, and a product and design strategy. Series advisors are four of the most influential leaders of the networking community:

Lyman Chapin-Chief Scientist at BBN/GTE and founding trustee of the Internet Society

Scott Bradner-Director of the Harvard University Network Device Test Lab, trustee of the Internet Society, and ISOC VP of Standards

Vinton Cerf-Senior Vice President at MCI/WorldCom and current chair of the Internet Society

Ed Kozel- Senior VP for Corporate Development at Cisco Systems and member of the Board of Directors

Visit our Web site at:

Visit the Networking Council web site at:

"...includes a brief tutorial on IPSec functionalities... plus IPSec services (VPNs, remote access), diagnostics & troubleshooting, related technologies (cryptography, firewalls & tunnelling methods), & recent IP advances."

Read More Show Less

Product Details

  • ISBN-13: 9780471344674
  • Publisher: Wiley, John & Sons, Incorporated
  • Publication date: 9/10/1999
  • Series: Networking Council Series , #10
  • Edition number: 1
  • Pages: 271
  • Product dimensions: 7.81 (w) x 9.59 (h) x 0.88 (d)

Meet the Author

Elizabeth Kaufman is the Senior Director and General Manager for Security Products and Technologies at Cisco Systems.

Andrew Newman is the Senior Systems Analyst for Yale University.

Read More Show Less

Read an Excerpt

Chapter 8: What Won't Work with IPsec: Other Network Services and Technologies

No one builds a network for the sole purpose of securing it, just as no one buys a goldfish for the sole purpose of flushing it down the toilet. Network security professionals have always had to implement security while mindful of antithetical requirements: open connectivity and transparent data access. The most common network security product today is a firewall, which performs packet-by-packet analysis at the WAN perimeter. IPsec introduces a new level of complexity. By adding headers, and signing or encrypting either the payload or the entire datagram, it becomes difficult to layer additional services onto a secure traffic flow. In the world of enhanced IP networks, network managers must address a technical challenge with no easy answers. That is, "How can I aggregate a collection of dissimilar higher level protocols onto a wire, and into a datagram, without causing the protocols to eliminate the useful properties of one another, or to break the higher level applications?" Since traffic that demands high security is often a candidate for other special handling, IPsec makes that challenge more acute.

This chapter discusses common technologies that often do not combine well with IPsec. We start by describing the root causes of conflict to provide an analytical basis for predicting problems in advance. In the second part of the chapter, we break IPsec performance claims into several measurable components. Next, we provide a hit list of protocols to consider exempting from your IPsec policy configurations, and then present a brief examination of operational issues for a range of technologies. Forthe sake of convenience, we have arranged these technologies into several functional categories: bandwidth optimization, packet classification, network infrastructure, network monitoring, network management, and voice and video. In the next-to-last section, we provide an interoperability reference matrix. The wrap-up cautions against despair.

A Moving Target

This chapter is not a guide to evaluating or deploying network services other than IPsec, but it is designed to point out operational problems you may inadvertently create on your network from the interactions between it and other technologies. Bear in mind that many of the technologies we discuss here were still changing as this book went to print. We expect that both IPsec and other emerging technologies such as Voice over IP will continue to evolve for the next several years, at least in part because of the challenges we describe in this chapter. It is probably more important, therefore, that you understand generally why things may not work well with IPsec than specifically which things did not work well when we wrote this book.

IPsec Design Objectives

As we discussed in Chapter 4, "Enter IPsec," the designers of IPsec were motivated to provide a next generation security infrastructure for IPv6, and to create a set of protocols to address the lack of security services in IPv4. It's a reasonable if somewhat over-simplified claim that the current IPsec standards focus primarily on solving security problems that come from the physical, link, and network layers, rather than on offering security services up the network stack to other protocols, or directly to applications.

The standardization of a general-purpose secure transmission mechanism for IP has several advantages. It is very consistent with the overall layered design of the Internet, where protocols are intended to integrate without overt reference to or dependencies on one another. IPsec also does not overly constrain the security choices available to application designers, security professionals, or Information Systems (IS) managers. The drawbacks to this design focus are most evident where network managers want to pre-empt the generic effects of IP's layered, connectionless, stateless design to configure network functions differently for various individuals and applications. IPsec also faces significant scaling challenges, and is not optimized to support multi-point, real-time applications and services.

Ugly Outcomes of IPsec Design

In complex environments, IPsec can be the wild child of network technologies. A functional IPsec infrastructure needs careful forethought, and must respect the topological and operational characteristics of other deployed or planned services. Otherwise, it can swamp compressed WAN links, degrade delay-sensitive applications, and complicate certain uses of enhanced IP services such as Quality of Service (QoS). The better you understand the interplay between IPsec and other network technologies, the better you can plan to minimize or avoid problems. At best, you will need to plan carefully as you deploy IPsec, in order not to impede or eliminate your ability to use other network technologies. At worst, you will need to identify and resolve areas of outright conflict where you must choose between IPsec and other important capabilities. If you skipped the network mapping discussion in Chapter 5, "Laying the Groundwork for Security," you may need to go back to it. You must have a good understanding of your physical and logical topology to plan around the operational characteristics of IPsec.

Predicting Problems

There are two common underlying causes for most operational problems with IPsec: limited processing power of shared gateways (often at or near the WAN edge) or end hosts, and order of operations conflicts with other technologies. Certain topologies, especially those that rely on shared gateways, may encounter both obstacles.

Order of operations problems arise when IPsec and other services or technologies are applied to the same traffic. Processor overload can occur even where you apply services to different traffic, if shared hosts or gateways cannot handle the incremental load. In general, it is easier to plan around difficulties with processing power than it is to resolve order of operation conflicts. The former is often, in the end, a matter of investment, while the latter may force a choice between technologies.


Network technologies can interact in subtle and not-so-subtle ways. A subtle interaction might cause periodic, imperceptible (to a human user) packet loss and retransmission, resulting in overall lower performance. A not-so-subtle interaction, on the other hand, could cause abrupt application failure or dramatically degraded connectivity. IPsec, when combined with other technologies, may cause either, both, or, if you plan carefully and aren't too adventurous, neither of these interactions.

Integration glitches are not, of course, the exclusive domain of IPsec or of security technologies. Network managers have always had to consider potential integration problems as they add new functionality. For example, many people saw both subtle degradation and outright failures when they first began tunneling LAN protocols such as IPX over IP. IPX requires that packets be delivered in the exact order in which they were sent, while the IP datagrams carrying those packets routinely arrived out of order, causing the higher-layer applications to drop the packets. Tunneling technology needed to evolve to support the more fragile LAN protocols. Multiprotocol tunnels over IP still cannot take full advantage of the resilience of the underlying network.

Limits on Processing Power

Large IP networks tend to be complex entities supporting many types and generations of applications and operating systems. Even where Microsoft Windows is a de facto standard for new client stations, there may be hundreds of other devices that will continue to run other software indefinitely. Although many of these end hosts have sufficient CPU to support an IPsec client, the cost and effort to upgrade them can be prohibitive. A common strategy for an initial technology deployment, therefore, is to begin with an appliance or WAN gateway implementation (see Chapter 9, "IPsec Design Considerations" for more on design). This option does not enable end host authentication or confidentiality, but can provide these services for a network or subnet across the wide area. In this scenario, a network manager would enable IPsec AH or AH+ESP in tunnel mode either on a standalone ( bump in the wire) device on the interior of the WAN edge router, or on the edge router itself.

The Curse of the Edge Gateway

Ironically, the edge router is generally a low-end device with little excess processing power. IPsec functions like SA negotiation, key generation, and bulk encryption are compute intensive, and can overwhelm a general purpose CPU unless they have specialized hardware support. Even with hardware support, IPsec (usually IKE) still can cause delay. Transport mode IPsec can also add latency, depending on the available CPU power in the end host. Generally speaking, however, the average PC has more cycles to spare for IPsec than the average edge gateway. Whether you elect to implement IPsec on a router, a standalone gateway, or your end hosts, you will need to evaluate the relative performance capabilities of various products and platforms.

Evaluating IPsec Performance Claims

The discussion that follows may make you think that there is no such thing as an honest performance figure, and that all IPsec vendors are evil, money-sucking entities that exist only to foist shoddy, ill-specified product on their unsuspecting customers. A more moderate response would be to ensure that you understand the test process that produced any given performance number, and to verify that comparisons among platforms are based on comparable measurements. Performance numbers for networking products have always been variable. IPsec introduces a couple of additional twists.

What Is Performance?

Performance is a catch-all term for several operating characteristics of an IPsec platform, including supported data rate, connection density, compute delay for SA negotiation or key generation, and data encryption speed. Most current commercial IPsec products are software implementations on a general purpose CPU with some hardware components to accelerate cryptographic operations. Software products have the advantage of being relatively easy to modify, but they can encounter memory constraints, processor restrictions, and arbitrary-seeming configuration limitations.

What Does Wire Speed Mean?

Performance is generally a significant part of an IPsec purchase decision. It is one of the deciding factors in how well a given product will scale to meet the needs of your network and network users. It is not always straightforward, however, to convert a number from a marketing brochure into a real predictive measure for a platform's performance on your network. Most vendors, for example, will assert wire speed performance for different media types. Wire speed IPsec would seem to imply that a device is capable of encrypting and decrypting any packet size at the maximum data rate supported by its connected media (for example, 100 Megabits per second for a fast Ethernet device), but it rarely does mean that. Marketing numbers generally do not reflect operational expectations of a device. Performance testing of IPsec devices is also a variable thing. Many factors will dramatically improve a marketing claim without reflecting how a platform will perform in your environment. A device advertised to run at Ethernet speeds may perform at less than half that rate on your network. It is important to ask for details if you need to predict actual performance...
Read More Show Less

Table of Contents


Laying the Groundwork for Security.

Security Principles and Practices.

Encrypting within the Law.


The Risks of IP Networking.

Cryptographic Protocols and Techniques.

The Basics of IPsec and Public Key Infrastructures.


What Won't Work with IPsec: Other Network Services and Technologies.

IPsec and PKI Rollout Considerations.


Evaluating Vendors.

What to Ask Your Vendors.





Read More Show Less

First Chapter

The Basics of IPsec and Public Key Infrastructures

Note: Some of the Figures and/or Tables mentioned in this sample chapter do not appear on the Web.

As the designers of IPsec began their work, many Internet engineers shared a sense of impending doom about the viability of IPv4 and were deeply involved in the design and prototyping of IPv6. IPsec is thus a hybrid: It is both a retrofit to the many flaws in IPv4 and a pre-emptive strike against insecurity in IPv6. Like many hybrids, it has some unexpected quirks. (We discuss the impact of those quirks in Chapter 8, "What Won't Work with IPsec.") Even so, IPsec is the only broadly accepted standard for secure network-layer transport on IP. It is more versatile and less expensive than both application and link-layer encryption technologies.

IPsec is a very complex set of protocols and mechanisms. Although you do not need to be an expert to make it work, it is important to understand its fundamental components and the ways they relate to one another. This chapter is an introduction to IPsec components, with a focus on how they integrate into IPv4.

The Anatomy of IPsec

IPsec was designed to have an open, modular architecture. This modularity allows it to evolve to address new requirements, new cryptographic technologies, and newly identified problems with existing security mechanisms. The following sections discuss the elements of IPsec that were Internet standards as this book went to press.

Two Security Protocols

IPsec has two basic security protocols: the Authentication Header (AH) and the Encapsulating Security Payload (ESP). AH is an authenticating protocol that uses a hash signature in the packet header to validate the integrity of the packet data and the authenticity of the sender. ESP is an authenticating and encrypting protocol that uses cryptographic mechanisms to provide integrity, source authentication, and confidentiality services. We describe both protocols in some detail in the sections that follow (Kent 1998a, 1998b).

Two Modes of Operation

Each protocol can operate in one of two modes: transport mode, in which the protocol operates primarily on the payload of the original datagram, and tunnel mode, in which the protocol encapsulates the original datagram in a new one, treating the original as the data payload. In tunnel mode, the source and destination IP address are often, but not always, different from those in the header of the original datagram.

The Implementation Options

IPsec can operate on an end host (a single or multiuser host or server) or in a gateway (a network element that is neither the originator nor the ultimate recipient of the IP traffic). End-host and gateway products come in several common flavors:

End Host

A native stack. Many OS vendors integrate tunnel-and transport-mode IPsec directly into their bundled IP stacks.

A replacement stack. A third-party vendor may write an entire drop-in replacement for the original stack. Although this approach may simplify the work of supporting IPsec, it is a nontrivial effort to reproduce the full functionality of the native IP stack and to evolve the new stack in parallel with the operating system.

A bump in the stack. Most third-party vendors try to insert their IPsec implementations into the native stack, either by writing to a known API or by reverse-engineering a released version of the stack. Tunnel mode is easier to implement in this way than transport mode, since the IPsec operation only needs to intervene before the network interface card (NIC) driver has inserted the data-gram into a link-layer frame. For transport mode, the third party needs to go deeper into the guts of the stack.


A bump in the wire. Many IPsec gateways are dual-interface boxes with no other integrated network functionality. Such devices are referred to as bumps in the wire because they are simple encrypting units that remain largely transparent to other network devices.

An integrated gateway. In other cases, the IPsec gateway is an enhancement to an IP router or firewall.

Security Associations

The security association (SA) is a critical component of the IPsec architecture. An SA is a record of the information an IPsec entity needs in order to support one direction (outbound traffic or inbound traffic) of an IPsec protocol connection. Its contents will vary for each connection, and can include authentication and encryption keys, specific algorithms and modes, key lifetimes, initialization vectors (IVs), and source IP addresses. The SA tells an IPsec device how to process incoming IPsec packets and how to generate outbound IPsec packets. Multiple SAs will exist for any exchange. IPsec devices embed a value called the security parameter index (SPI) in the IPsec header to associate a given datagram with its appropriate SA on the receiving host. It is vital, of course, that each host or gateway apply the correct SA to each IPsec datagram. The standards define a rigorous mechanism for ensuring that each SA is unique. IPsec devices store these SAs in a security association database (SAD) (Kent 1998c).

The Authentication Header (AH)

The AH protocol can detect packet corruption or tampering and can authenticate the identity of a sender by end user or by source IP address. Currently, the IPsec peers (communicating parties) in AH may use either MD5 or SHA-1 to create a hash signature using a secret component of the SA, the packet data payload, and several parts of the packet header (Madson 1998a, 1998b).

The AH Packet Header

Figure 7.1 shows a typical authentication header. The AH header has five essential fields:

  • The next header, which usually describes the layer 4 header (TCP/ UDP/ ICMP) for an IPv4 datagram
  • The length of the hash signature (note that this value will be constant for each hashing algorithm, since each has a fixed-length output)
  • The security parameter index (SPI)
  • The anti-replay sequence number field (this prevents an attacker from replaying [resending] a packet as part of an attack)
  • The hash signature itself
Sending an AH Packet

To transmit an AH packet, the IPsec host or gateway must do the following:

  • Identify the appropriate SA, SPI, algorithm (MD5 or SHA-1), and secret key.
  • Increment the anti-replay counter (anti-replay is on by default).
  • Assemble the data to be hashed in a fashion appropriate to the specific standard in force.
  • Set the time to live (TTL), type of service (ToS, now known as the differentiated services or DS byte), and header checksum fields to zero. This operation allows these fields to be modified in flight without altering the hash signature. (Note that for IPv6, you also need to zero out the hop limit field in the base header and all fields whose OPTION TYPE bit is set to indicate a mutable value.) Calculate the hash value and the other packet header fields.
  • Insert the AH header directly between the IP header and the layer 4 header. In tunnel mode, the entire original datagram is the packet payload, so the AH header goes between the newly created outer IP header and the original datagram. (Note that for IPv6, the AH header belongs after all hop-by-hop headers.)
Receiving an AH Packet

A receiving host or gateway reverses the transmission process described in the previous section and discards any datagrams whose recalculated hash value doesn't match the original. If the relevant SA specifies anti-replay, the sequence number must fall within the proper window (range) of numbers, and must not be a duplicate of any prior packet. Figure 7.2 shows detail of an authentication header.

The Encapsulating Security Payload (ESP)

The ESP protocol can provide confidentiality, authenticity, and integrity services. Tunnel-mode ESP also offers traffic-flow confidentiality. Early drafts of the ESP protocol focused on confidentiality, but the final standard also includes a great deal of functionality from AH.

The ESP standards currently support two transforms, or operations: DES and 3DES (described in Chapter 6, "Cryptographic Protocols and Techniques"). The two transforms are very similar, and DES support is mandatory. Of course, the ESP standard will eventually support transforms for many other encryption algorithms (Madson 1998b).

The ESP Packet Header

Like AH, the ESP header contains the following:

  • The security parameter index (SPI)
  • The anti-replay sequence number field

Unlike AH, the ESP header also includes the next header field as part of the packet trailer. The packet payload may include padding to conform to the specific cryptographic transform and to ensure that the next header field ends on a 4-byte boundary. The trailer may also contain a variable amount of authentication data.

Sending an ESP Packet

To transmit an ESP packet, the sending host or gateway must do as follows:

  • Identify the appropriate SA and associated SPI. If the SA indicates integrity/ authenticity, the host or gateway must also locate the correct hash algorithm and secret key. If the SA indicates confidentiality, the host or gateway must locate the appropriate cryptographic transform and secret key.
  • Increment the anti-replay counter (if appropriate).
  • Assemble the ESP payload and add padding, if necessary. In tunnel mode, the entire original datagram becomes the ESP payload, and the sender creates a new outer IP header that precedes the original packet.
  • If specified, encrypt the ESP payload with the appropriate cryptographic algorithm.
  • If specified, calculate the integrity check value (ICV) over the headers and payload (minus the authentication data itself), using the correct hash algorithm.
  • Insert the ESP header, payload, and trailer (plus authentication/ integrity data) directly after the IP header. (Note that in IPv6, the ESP data belongs after all of the hop-by-hop headers.)
Receiving an ESP Packet

A receiving host or gateway reverses the sending procedure described in the previous section. If the SA specifies authentication services, that check essentially mirrors the hash check for AH: The host or gateway must discard any packet that fails the integrity check. If the SA specifies the anti-replay option, the host or gateway must also discard any packets that are repeats or that fall outside the receiver's window. The last step is to decrypt the packet payload.

Figure 7.3 shows an ESP-transformed datagram. In this example the datagram contains an optional ICV that provides authenticity and integrity. If the ICV were not present, IPsec would not detect modification to the payload, but the decryption would probably produce gibberish. An ICV generally provides a more positive mechanism for discarding modified data with minimal overhead.

Why Bother with AH?

Since the final standard for ESP supports both authentication and integrity, you may be wondering why anyone would bother to implement AH. There are, however, both practical and historical reasons to use it for certain services.

  • A standards-compliant ESP implementation must support DES encryption, even if the host or gateway never uses it. Under certain strict regulatory regimes, AH may be the only IPsec protocol legal to use, since cryptography for the purposes of authentication (as opposed to confidentiality) is usually acceptable. See Chapter 4, "Encrypting within the Law," for details on the regulatory issues for IPsec.
  • AH also provides a higher assurance of authenticity and content integrity, since it operates on the IP payload plus all immutable (and all predictable) fields in the outer IP header.
Authentication Header (AH) and Encapsulating Security Payload (ESP)

AH and ESP can operate on the same datagram. Figure 7.4 shows AH and ESP headers together. Although it is possible for an end host or gateway to apply both protocols to the same connection, that scenario is not the most common. In a more typical combination, the end host generates transport-mode ESP datagrams, while an intermediate security gateway (SG) encapsulates those ESP packets into tunnel-mode AH. A mirror-image configuration at the other end of the connection (an SG de-encapsulates, and an end host decrypts) would provide end-to-end confidentiality and a strong defense against tampering across the WAN. The inverse configuration– in which the end host uses AH and the gateway tunnels ESP– would also make sense for many VPN topologies.

IPsec Authentication: Defining a PKI

As we discussed in Chapter 6, confidentiality is not generally useful without prior authentication. The AH and ESP standards do not require automated key management, and they do not mandate any particular authentication mechanism. Preshared secrets, however, can get you only so far before you're liable to fall to the floor with hash signatures frothing from your ears, nose, and mouth. Most large IPsec installations use a PKI for authentication. Windows 2000 users also have the option of authenticating with a Kerberos KDC (see Chapter 6 for a brief description of Kerberos).

A CA functions as a sort of electronic notary public: It is a trusted electronic entity that vouches for the authenticity and credibility of individuals, applications, entities, and (sometimes) data. APKI is built around the concept of an embedded CA hierarchy that can establish potentially complex trust relationships among users, applications, hosts, and network elements.

Whose Key Is It?

The attributes of a public/ private key pair are most powerful if those keys are strongly bound to the identity of the person or thing they purport to represent. There are two basic questions that confront anyone deploying a PKI:

  • What other nonprivate information needs to be associated with any given public key to establish a unique, unambiguous credential? For example, if two James L. Smiths work in the same department, what is a meaningful way to distinguish them?
  • What process is used to authenticate a person or object to the PKI before obtaining a credential? The strength of the PKI is highly dependent on the certainty of each initial authentication.
X. 509 Certificates

The International Organization for Standardization (ISO) X. 500 standards suite defines a complex basis for registering and retrieving information about people, places, and objects. This set of standards was designed to have a potentially unlimited scope, and its identifiers are hierarchical to simplify the unique characterization of objects. The X. 509 standard provides a mechanism to associate a public key with a collection of subcomponents sufficient to uniquely authenticate the claimed owner of the object. These subcomponents are collectively known as a distinguished name (DN). The signed association of a DN with a public key is known as an X. 509 digital certificate.

X. 509 certificates are organized in a hierarchical structure in which a certification authority (CA) signs each certificate. The root or most trusted CA signs its own key and those of other CAs to form an inverted tree structure. Although this structure scales well, the root is very vulnerable. In addition, CA hierarchies are not optimized to support nonhierarchical trust models, such as introducer-based relationships.

The Basics of IPsec and Public Key Infrastructures 87

The Public-Key Infrastructure (X. 509) (PKIX) Initiative For true IPsec interoperability, there must be a standard mechanism to establish trust relationships among arbitrary IPsec peers. Not only must those IPsec peers interoperate at a protocol level; they must also be able to authenticate one another in a reliable, standard way. The mission of the IETF Public-Key Infrastructure (X. 509) (PKIX) working group is to create standards that enable a flexible, interoperable X. 509 PKI optimized for Internet protocols, applications, and end users. Many applications, some of which predate IPsec, require an X. 509 PKI to operate correctly; these include privacy enhanced mail (PEM), SSL, and Secure Multipurpose Internet Mail Extensions (S/ MIME). Figure 7.5 shows some PKI entities.

PKIX Standards Focus

PKIX has a very broad charter. It has focused on several specific areas:

  • Certificate and CRL profiles
  • Management protocols
  • Operational protocols
  • Policy templates and guidelines
PKIX X. 509 v3 Certificate Profile

The PKIX working group has specified an Internet X. 509 v3 certificate profile that is designed to provide flexible functionality and local control (see RFC 2459). The format permits two main conditions:

  • A root can be either local or global. Several companies have built commercial service offerings that provide CA and certificate services to end users and corporations. Name constraints are not fixed by a global hierarchical model and subordinate to the CA tree above any given end entity (EE), as with prior standards. Any necessary naming constraints are identified in X. 509 v3 name constraint extensions in the certificate itself.
  • An extension field also identifies certificate policies and a related certification practices statement (CPS). Since the CPS is identified by reference, the base document can be updated as necessary. See Chapter 10, "Evaluating Vendors," for a discussion of the CPS.

The X. 509 hierarchical model poses a major challenge for a world that depends on many nonhierarchical trust relationships. In its purest form, it presents a metaphysical conundrum: Either there are individuals never permitted to trust one another, or there must be a fixed, single root CA in the sky whose trust characteristics are uniform, universal, and absolute– an infallible and incorruptible root whose trust is implicit and fundamental to all.

One workaround has been to have individuals participate in multiple trust trees, since trust can exist only within a given hierarchy. PKIX outlines an alternative called cross-certification, which allows hierarchies (or pieces of them) to trust one another. (See Figure 7.6.) Essentially, a CA in one hierarchy signs another CA's public key (and other certificate request components) after validating the authenticity of the key/ subject relationship. After this new certificate is created, a validation path in the signer's trust structure exists for all certificates signed by the subject of the certificate.

PKIX has also defined a policy-mapping extension for the X. 509 v3 certificate that allows certificate policies from one trust structure to be mapped onto certificate policies in another at the time of cross-certification (see RFC 2459). This mechanism extends a simple trust relationship to potentially complex trust policy between organizations.

C Country
SP State or Province
L Location
O Organization
OU Organizational Unit
CN Common Name

Figure 7. 6 Example of cross-certification.

Attributes of an X. 509 Certificate

For IPsec, the most common credential is an X. 509 digital certificate. These certificates can be dauntingly complex, but how you choose to use them can have significant implications for the long-term usefulness and flexibility of your PKI. The following sections discuss some critical elements of an X. 509 certificate. See Figure 7.7 for a sample certificate. The X. 509 certificate contains several required attributes. How you assign these attributes will impact the value and functionality of your PKI.

What's in a Distinguished Name (DN)?

A public/ private key pair is supposed to be mathematically unique. A DN is supposed to be both globally unique and socially meaningful. The contents of a DN are, according to the ISO standard, potentially open-ended. Needless to say, the effort to standardize the structure and content of a DN remains contentious. The issues may seem wildly overblown if you are simply trying to bootstrap a CA to support 10 VPN routers. Consider, however, that the X. 509 certificate could become a ubiquitous authentication mechanism for employees, partners, customers, and even telephones. Given that once they're issued, certificates are difficult to take back, it makes sense to spend some time thinking through what your PKI must support over time and how you can ensure that the credentials it issues are particular and meaningful.

Structure of a DN

ADN consists of multiple hierarchical subcomponents. The early X. 509 definitions enumerated a small set of attributes that could be assembled into globally unique identifiers. We describe those sub-components in the following sections. Note that not all DNs include all subcomponents. Depending on the required scope of the name, a country and organizational name might be sufficient to ensure uniqueness. The SP and L components add additional specificity. The OU component may be included if an internal organizational unit needs global visibility.

C, SP, and L: Geopolitical Location

The original X. 509 hierarchy was structured along geopolitical boundaries. The first set of subcomponents, therefore, identifies the country, state or province, and location. These might appear as follows:

C= US, SP= New York, L= New York City O and OU: Organizational Entity

The O and OU fields describe an organization and a unit within that organization. In principle, the O field identifies the organization in some official way, such as the name under which it was incorporated. The organizational unit should be unique within the organization and should have a label that identifies it unambiguously. These might appear as in the following:

O= Wiley Computer Publishing, OU= Food Services CN and SubjectAltName: Common and
Alternate Names

A final and valuable subcomponent is the CN, or common name. The common name provides uniqueness within the organization or organizational unit. A common name should be the full name of the certificate owner, such as

CN= Gregory Efimovich Rasputin

Unfortunately, it has become common to use the CN field to identify the fully qualified domain name (fqdn) or alias of the machine or service that stores the certificate, as in the following:

CN= mailer. rodent. edu

This practice arose because earlier versions of the X. 509 certificate format did not have separate fields for that purpose. PKIX has officially rejected this practice in favor of the subject alternate name (subjectAltName) field, which is a sequence of one or more of the following:

DNSName. The fqdn or alias.
IPaddress. The IP address.
rfc822Name. A name whose format resembles an Internet standard email form of person@ domain (such as nobody@ wiley. com).

URI. A uniform resource identifier (URI). Note that a World Wide Web uniform resource locator (URL) is one type of URI that identifies a resource available on a Web server. "URI" is a more generic identifier. The two are often used interchangeably, but "URI" is the specific tag name used by the PKIX subjectAltName sequence.

For terminal certificates (ones that will never belong to a CA), the subjectAltName field can take the place of a CN field. The preferred mechanism for identifying certificates belonging to Web servers, for example, is to omit the CN field and include a subjectAltName field containing only a dNSName element. In some events (particularly when the CN is that of a device), the subjectAltName sequence includes an rfc822Name field that identifies the real human being responsible for the certificate (and the person presumed to have access to the private key).

The Issuer and the Subject

ADN identifies both the owner of the certificate and the signer of the certificate. These two fields are known respectively as the subject and the issuer. Since the issuer of a certificate will appear as the subject of his own certificate, it is appropriate that both of these fields be represented in DN form.

The Serial Number

Just as those who manufacture products often place unique serial numbers on a series of otherwise identical items, X. 509 certificates are also distinguished by serial numbers. A certificate issuer must attach a unique number to each and every certificate that he produces. This mechanism enables a unique reference to any given certificate using the combination of issuer DN and serial number. This unique reference can be critical if, for example, a subject's status changes and the CA needs to revoke a certificate.

Validity Range

Two fields contain dates that bound the validity of the certificate. Outside this date range, the certificate is invalid. There are many reasons to place boundaries on the validity of a certificate. The subject's DN might become irrelevant over time (for example, if a person leaves the company), or the organization might not want too much sensitive data protected by a single public key pair. For a wide range of reasons, certificates eventually expire and must be renewed. The renewal process usually requires a new key pair, but it is possible to issue a new certificate with a new validity range that retains the old public (and thus private) key.

PKI planning

Before beginning to issue certificates, it helps to make a few decisions:

  • Which will be your root CA?
  • How many other CAs will participate in your hierarchy, and which keys will they be authorized to sign?
  • How will you authenticate people, applications, or devices before issuing a certificate?
  • What will be the default validity period for your certificates?
  • Will you reuse the public/ private key pair when you renew a certificate?
  • Which fields of the DN will be required, and how will you standardize their contents?
Certificate Revocation

Granting certificates raises some serious issues, and taking them away can also pose a major challenge. The original issuer of a certificate is the only entity that can revoke that certificate. The X. 509 certificate mechanism allows a CA to issue a certificate revocation list (CRL) containing invalid certificate serial numbers. Each CRL also contains a NextUpdate field to a

  • ounce the date or time for the next CRL.

In theory, devices or services that authenticate using certificates must retrieve a current CRL before enabling access or establishing communication. There is, however, a huge potential scaling problem if, for example, 10,000 IPsec end hosts must retrieve a CRL before establishing IPsec connections with one another. If the CRL lives on a CA inside the enterprise and the end host is co

  • ecting from outside the security perimeter, there may be a security challenge as well. Revoking a CA's certificate is even more difficult, and can pose huge operational challenges. Needless to say, different commercial CAs and IPsec products handle CRLs differently.

    Key Escrow

See Chapter 4 for a discussion of IPsec and key escrow.

IPsec Encryption Key Management

Consistent with IPsec's open architecture, the IPsec security protocols (AH and ESP) are designed to be agnostic with regard to automated encryption key management. However, standards-compliant IPsec implementations must support both preshared keys and the automated key management mechanism called the Internet Key Exchange (IKE) protocol (see RFC 2401). IKE is a specific design instance of a larger design framework called the Internet Security Association and Key Management Protocol (ISAKMP; see RFC 2408). ISAKMP is an authentication and key exchange framework that is independent of any specific keying technology. IKE relies on another protocol, called OAKLEY, for secure keying within the ISAKMP model.

The OAKLEY Protocol

OAKLEY is a protocol that uses a Diffie-Hellman (DH) key exchange to establish a shared key securely between two peers (see RFC 2412). OAKLEY works within the ISAKMP framework to establish IPsec SAs. The OAKLEY key determination standard establishes an initial ISAKMP SA, but allows a more lightweight mechanism to establish subsequent SAs.

The Internet Key Exchange Protocol

IKE is an implementation subset of ISAKMP and OAKLEY. It is a secure key management protocol designed to establish IPsec SAs and to enable fast rekeying of existing SAs. IKE operates in two phases. Phase 1 sets up the authenticated and encrypted cha

  • el. Since all key exchanges result in SAs, a successful phase 1 exchange will create an SA for each end of the communications cha
  • el, as well as the key required for phase 2. Phase 2 establishes one or more application SAs. A phase 1 IKE exchange creates an SA for each communicating party that has the following:

  • Identity information for the remote peer
  • Proof of the validity of that identity
  • A securely obtained key appropriate for AH and ESP

All phase 1 exchanges establish key material using a DH operation. The remote peer has three ways to prove its identity: preshared keys, a DSA digital signature, or RSA encryption.

Authentication with Preshared Keys

Standards dictate that IKE implementations must support preshared keys, but are agnostic as to the actual sharing mechanism. Due to the order of events in a phase 1 exchange, preshared keys enable IPsec peers to identify each other by IP address only. (See Chapter 6 for a more detailed discussion of preshared keys.)

Authentication with DSA

IKE implementations are also required to support DSA for a phase 1 exchange. DSA has the advantage of being in the public domain. In spite of its burdensome patents, however, RSA encryption has significant advantages over DSA. It is generally more appropriate for large IKE implementations.

Authentication with RSA

The RSA mechanism has several advantages over digital signature authentication for a phase 1 IKE exchange. The peers in RSA encrypt the DH key, so a third party would have to crack two cryptographic systems to steal the key. The IPsec peers also encrypt their identity information, preventing eavesdropping on the authentication exchange. One drawback of RSA authentication is that to protect privacy, the peers do not exchange certificates. The initiating peer must already have a known-good copy of the responder's public key.


IPsec is a suite of protocols that interface with each other in well-known ways. It has a modular architecture, and the current standard protocols are relatively agnostic with regard to specific cryptographic technologies. Although all IPsec products must support preshared keys, most IPsec installations require a PKI for scalability and management sanity. PKIs raise a number of issues with implications for an organization that extend far beyond IPsec-related concerns.

In the next chapter, "What Won't Work with IPsec," we examine how IPsec integrates with other common network technologies and enhanced services.

Read More Show Less


The Networking Council Series was created in 1998 within Wiley's Computer Publishing group to fill an important gap in networking literature. Many current technical books are long on details but short on understanding. They do not give the reader a sense of where, in the universe of practical and theoretical knowledge, the technology might be useful for a particular organization. The Networking Council Series is concerned more with how to think clearly about networking issues than with promoting the virtues of a particular technology. It strives to relate new information to what readers already know and need, so they can develop customized strategies for vendor and product selection, outsourcing, and design.

In Implementing IPsec: Making Security Work on VPNs, Intranets, and Extranets, by Elizabeth Kaufman and Andrew Newman, you'll see the hallmarks of Networking Council books: examination of the advantages, disadvantages, strengths, and weaknesses of market-ready technology, useful ways to think about options pragmatically, and direct links to business practices and needs. The book also investigates pertinent background issues needed to understand who supports each technology and how it was developed-another goal of all Networking Council books.

The Networking Council Series is aimed at satisfying the need for perspective in an evolving data and telecommunications world filled with hyperbole, speculation, and unearned optimism. In Implementing

IPsec: Making Security Work on VPNs, Intranets, and Extranets, you'll get clear information from experienced practitioners.

We hope you enjoy this book. Let us know what you think. To contactus or get more information, visit the Networking Council Web site at www.wileycom/networkingcouncil.

-Scott Bradner
Senior Technical Consultant, Harvard University

-Vinton Cerf
Senior Vice President, MCIWorldCom

-Lyman Chapin
Chief Scientist, BBN/GTE

-Ed Kozel
Senior VP Corporate Development, Cisco Systems

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)