|
IPsec (an abbreviation of IP security) is a standard for securing Internet Protocol (IP) communications by encrypting and authenticating all IP packets.
IPsec is a protocol suite (i.e., a set of interdependent protocols) consisting of (1) protocols for securing packet flows and (2) key exchange protocols used for setting up those secure flows. Of the former, there are two: Encapsulating Security Payload (ESP) for encrypting packet flows, and the rarely used Authentication Header (AH) which provides authentication and message integrity guarantees for such flows, but does not offer confidentiality. Currently only one key exchange protocol is defined, the IKE protocol.
Current status as a standard
IPsec is an obligatory part of IPv6, the new IETF Internet standard for Internet Protocol (IP) packet traffic, and is optional for use with IPv4. As a result, IPsec is expected to become more widely deployed as IPv6 becomes more popular. IPsec protocols are defined by RFCs 2401_2409. As of 2004, work is progressing to release updated replacement documents.
Design intent IPsec was intended to provide either (1) portal-to-portal communications security in which security of packet traffic is provided to several machines (even to whole LANs) by a single node, or (2) end-to-end security of packet traffic in which the end-point computers do the security processing. It can be used to construct Virtual Private Networks (VPN) in either mode, and this is the dominant use. Note, however, that the security implications are quite different between the two operational modes.
End_to_end communication security on an Internet_wide scale has been slower to develop than many had expected. Part of the reason is that no universal, or universally trusted, public key infrastructure has emerged (DNSSEC was originally envisioned for this), part is that many users understand neither their needs nor the available options well enough to force inclusion in vendors' products (which would lead to widespread adoption), and part is probably due to degradation (or anticipated degradation) of Net responsivity due to bandwidth loss from such things as spam.
IPsec vs. other Internet security protocols IPsec protocols operate at layer 3 of the OSI model, which makes them suitable for protecting both TCP and UDP-based protocols when used alone. This means that, compared with transport layer and above protocols such as SSL, which cannot protect UDP level traffic, the IPsec protocols must cope with reliability and fragmentation issues, adding their complexity and processing overhead. SSL/TLS, in contrast, rely on a higher level layer TCP (OSI Layer 4) to manage reliability and fragmentation.
Technical Details Authentication Header Authentication Header (AH) is intended to guarantee the integrity and authenticity of the transferred packets. Further, it protects against replay attacks. AH tries to protect all fields of an IP datagram. Only fields changeable during transfer of an IP packet are excluded.
An AH packet diagram:
| 0 | 1 | 2 | 3 | | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | | Next Header | Payload Length | RESERVED | | Security Parameters Index (SPI) | | Sequence Number | | Authentication Data (variable) |
Field meanings:
- Next Header
- Identifies the protocol of the transferred data.
- Payload Length
- Size of AH package.
- RESERVED
- Reserved for future use (all zero until then).
- Security Parameters Index (SPI)
- Identifies the security parameters in combination with IP address.
- Sequence Number
- A monotonically increasing number, used to prevent replay attacks.
- Authentication Data
- Contains the data necessary to authenticate the package.
Encapsulated Security Payload (ESP) The Encapsulating Security Payload (ESP) protocol provides origin authenticity, integrity, and confidentiality of a packet. Unlike the AH header, the IP packet header is not accounted for.
An ESP packet diagram:
| 0 | 1 | 2 | 3 | | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | Security Parameters Index (SPI) | | Sequence Number | | Payload * (variable) | | | Padding (0-255 bytes) | | | | Pad Length | Next Header | | Authentication Data (variable) |
Field meanings:
- Security Parameters Index (SPI)
- Identifies the security parameters in combination with IP address
- Sequence Number
- A monotonically increasing number, used to prevent replay attacks.
- Payload Data
- The data to be transferred.
- Padding
- Used with some block ciphers to pad the data to the full length of a block.
- Pad length
- Size of padding in bits.
- Next Header
- Identifies the protocol of the transferred data.
- Authentication Data
- Contains the data used to authenticate the package.
Implementations The FreeS/WAN (http://www.freeswan.org) project has developed an open source implementation of IPsec for GNU/Linux. An IPsec implementation based on the KAME (http://www.kame.net) project is included in NetBSD and FreeBSD, as well as the 2.6 Linux kernel. Thus, the KAME code will be widely available as GNU/Linux distributions change over to 2.6; in part because of this, development of the Free S/WAN project was discontinued in March 2004. Openswan (http://www.openswan.org) and Strongswan (http://www.strongswan.org) are continuations of FreeS/WAN.
There are a number of implementations of IPsec and ISAKMP/IKE protocols. These include:
See also
Overview of IPsec Related RFCs - RFC 2401
- Security Architecture for the Internet Protocol
- RFC 2402
- Authentication Header
- RFC 2406
- Encapsulating Security Payload
- RFC 2407
- IPsec Domain of Interpretation for ISAKMP (IPsec DoI)
- RFC 2408
- Internet Security Association and Key Management Protocol (ISAKMP)
- RFC 2409
- Internet Key Exchange (IKE)
External links - The IPsec Working Group at IETF (http://www.ietf.org/html.charters/ipsec-charter.html).
- Free S/WAN project homepage (http://www.freeswan.org/).
- Openswan project homepage (http://www.openswan.org/).
- The VPN Consortium (http://www.vpnc.org/).
- A long thread on the ipsec@lists.tislabs.com (http://www.netsys.com/ipsec/2000/msg00777.html) about whether uppercasing the S or not. The RFCs are clear, IPsec it is.
|
Feeds |
Contact