- Shopping Bag ( 0 items )
Ships from: Chatham, NJ
Usually ships in 1-2 business days
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 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: www.wiley.com/compbooks
Visit the Networking Council web site at: www.wiley.com/networkingcouncil
"...includes a brief tutorial on IPSec functionalities... plus IPSec services (VPNs, remote access), diagnostics & troubleshooting, related technologies (cryptography, firewalls & tunnelling methods), & recent IP advances."
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.
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.
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.
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.
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.
MAKING IT WORK.
What Won't Work with IPsec: Other Network Services and Technologies.
IPsec and PKI Rollout Considerations.
What to Ask Your Vendors.
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.Gateway
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:
To transmit an AH packet, the IPsec host or gateway must do the following:
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:
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:
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.
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:
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:
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:
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.
Figure 7. 6 Example of cross-certification.
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
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 asCN= 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.
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:
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
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
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
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.
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.
Senior Technical Consultant, Harvard University
Senior Vice President, MCIWorldCom
Chief Scientist, BBN/GTE
Senior VP Corporate Development, Cisco Systems