This chapter introduces IP Security (IPSec) and the base compo-nents that build the technology. The fundamental concepts of IPSec are detailed and their role in the protection of TCP/IP-based communications is established.
IP packets have no security associated with them. They are vulnerable to a plethora of attacks that include forging addresses, changing or replacing the contents, retransmittal of old packets, and they are completely modifiable in transit.
With IP, there is no guarantee that the packet is from the expected sender and the data contained is what was transmitted. Even if these two are not considered, there is no assurance that the contents have remained private and not been disseminated.
IPSec was created to thwart these vulnerabilities by a providing several layers of protection with authentication, encryption, message authentication, and the leveraging of existing security concepts applied in combination to the communication.
History
In October 1993, John Ioannidis of Columbia University and Matt Blaze of Bell Labora-tories presented a case for IP layer security, appropriately entitled, “The Architecture and Implementation of Network Layer Security in UNIX.” This paper represented a change in the application of security and communication, and was well ahead of its time. The paper discussed how to implement security features without altering the IP structure, and went on to discuss implementations of encapsulating IP datagrams in a new IP datagram. It also detailed the advantages of encapsulating protocols and authen-tication processes and the transparency that can be provided to upper layer activities.
Given the massive growth of the Internet, combined with the inherent security weaknesses of the TCP/IP protocol, the industry was in great need of a technology to provide security of data on the Internet. In 1994, the Internet Architecture Board (IAB) issued a report on “Security in the Internet Architecture” (Request for Comment [RFC]
1636). The report stated the general consensus that the Internet needed more and better security, and it identified key areas for security improvements. The IAB also mandated that the same security functions become an integral part of the next generation of the IP, IPv6.
Standards-based VPNs, as known today, started in 1995 with the AIAG (Automotive Industry Action Group), a nonprofit association of North American vehicle manufactur-ers and supplimanufactur-ers, and their creation of the ANX (Automotive Network eXchange) project. The project was spawned to fulfill a need for a TCP/IP network comprised of trading partners, certified service providers, and network exchange points. The require-ment demanded efficient and secure electronic communications among participants, with only a single connection over unsecured channels. As this technology grew, it quickly became recognized as a solution for any organization wishing to provide secure communications with partners, clients, or any remote network.
Structure
IPSec is defined by several RFCs that detail the many layers of the technology. Some RFCs detail specific portions of the protocol, while others address the solution as a whole. The interrelationship and organization of the documents are necessary for understanding the development process of the overall standard.
Exhibit 3-1 illustrates the seven groups of documents that allow the separate aspects of the IPSec protocol suite to be developed independently while providing a functioning relationship that can be easily managed.
1. The architecture is the main description document that covers the overall tech-nology concepts and security considerations. It is a starting point for an initial understanding of the IPSec protocol suite and the RFCs that define the standard.
2/3. The encapsulating security payload (ESP) and the authentication header (AH) protocol documents detail the packet formats and the default standards for packet structure.
4. The encryption algorithm documents detail the use of various encryption tech-niques utilized for the ESP.
5. The authentication algorithm documents describe the processes and technolo-gies used to provide an authentication mechanism for the AH and ESP protocols.
6. All of these documents specify attributes that require a value to be assigned and consolidated for proper interaction between the RFCs and other IETF-defined protocols. The domain of interpretation (DOI) specifies the numbers that iden-tify certain aspects within each RFC. The DOI document is part of the IANA-assigned numbers mechanism and is constant throughout the standard. It pro-vides the central repository for values, allowing other documents to relate to each other. The DOI contains parameters that are required for other portions of the protocol to ensure that the definitions are consistent.
7. The final group is key management, which details the standards defining key management protocols.
RFCs
Request for comments (RFCs) are documents that define an accepted technological form and suggest implementation details. RFCs must first be submitted as a draft to the Internet Engineering Task Force (IETF) for peer review. The IETF is segmented into groups that are responsible for certain projects. Although the final conversion of a draft to an RFC to become a standard is governed by the IETF, anyone can participate in the review process and provide points of view and comments.
Exhibit 3-1. IPSec document roadmap.
ESP Protocol
AH Protocol Architecture
Key Management Encryption
Algorithm
Authentication Algorithm
DOI
Following is a list of IPSec-related RFCs and their corresponding descriptions:
g IP Authentication Using Keyed MD5 (RFC 1828) g The ESP DES-CBC Transform (RFC 1829)
g HMAC: Keyed-Hashing for Message Authentication (RFC 2104) g HMAC-MD5 IP Authentication with Replay Prevention (RFC 2085) g Security Architecture for the Internet Protocol (RFC 2401)
g The NULL Encryption Algorithm and Its Use with IPsec (RFC 2410) g IP Security Document Roadmap (RFC 2411)
g IP Authentication Header (RFC 2402)
g The OAKLEY Key Determination Protocol (RFC 2412) g The ESP CBC-Mode Cipher Algorithms (RFC 2451) g The Use of HMAC-MD5-96 Within ESP and AH (RFC 2403) g The Use of HMAC-SHA-1-96 Within ESP and AH (RFC 2404) g The ESP DES-CBC Cipher Algorithm with Explicit IV (RFC 2405) g IP Encapsulating Security Payload (ESP) (RFC 2406)
g The Internet IP Security Domain of Interpretation for ISAKMP (RFC 2407) g Internet Security Association and Key Management Protocol (ISAKMP) (RFC 2408) g The Internet Key Exchange (IKE) (RFC 2409)