Internet Protocol
Security (IPsec)
IPsec is a protocol suite for securing Internet Protocol
(IP) communications by authenticating and encrypting each IP packet of a
communication session. IPsec includes protocols for establishing mutual
authentication between agents at the beginning of the session and negotiation
of cryptographic keys to be used during the session. IPsec can be used in
protecting data flows between a pair of hosts (host-to-host), between a pair of
security gateways (network-to-network), or between a security gateway and a
host (network-to-host).
IPsec is an end-to-end security scheme operating in the
Internet Layer of the Internet Protocol Suite, while some other Internet
security systems in widespread use, such as Secure Sockets Layer (SSL),
Transport Layer Security (TLS) and Secure Shell (SSH), operate in the upper
layers of the TCP/IP model. Hence, IPsec protects any application traffic
across an IP network. Applications do not need to be specifically designed to
use IPsec. Without IPsec, the use of TLS/SSL had to be designed into an
application to protect the application protocols.
History
The IPsec working group in the IETF was started to create an
open freely available and vetted version of protocols that had been developed
under NSA contract in the Secure Data Network System (SDNS) project. The SDNS
project had defined a Security Protocol Layer 3 (SP3) that had been published
by NIST and was also the basis of the ISO Network Layer Security Protocol
(NLSP). Key management for SP3 was provided by the Key Management Protocol
(KMP) that provided a baseline of ideas for subsequent work in the IPsec
committee.
In December 1993, the Software IP Encryption protocol swIPe
(protocol) was developed at Columbia University and AT&T Bell Labs by John
Ioannidis and others.
In July 1994, Wei Xu at Trusted Information Systems
continued this research which was completed successfully on the BSDI platform
after a few months. Wei quickly extended his development on to Sun OS, HP UX,
and other UNIX systems. One of the challenges was slow performance of DES and
Triple DES. The software encryption was unable to support a T1 speed under the
Intel 80386 architecture. By exploring the Crypto cards from Germany, Wei Xu
further developed an automated device driver, known as plug-and-play today. By
achieving the throughput for more than a T1s, this work made the commercial
product practically feasible that was released as a part of the well-known
Gauntlet firewall. In December 1994, it was the first time in production for
securing some remote sites between east and west coastal states of the United
States.
The IETF IP Security Protocol was developed starting in 1992
at the Naval Research Laboratory as part of a DARPA-sponsored research project,
with openly published drafts by 1993. ESP was originally derived from the US
Department of Defense SP3D protocol, rather than being derived from the ISO
Network-Layer Security Protocol (NLSP). The SP3D protocol specification was
published by NIST, but designed by the Secure Data Network System project of
the US Department of Defense. AH is derived in part from previous IETF standards
work for authentication of the Simple Network Management Protocol (SNMP)
version 2.
IPsec is officially standardized by the Internet Engineering
Task Force (IETF) in a series of Request for Comments documents addressing
various components and extensions. It specifies the spelling of the protocol
name to be IPsec.
Security architecture
The IPsec suite is an open standard. IPsec uses the
following protocols to perform various functions:
Authentication
Headers (AH) provide connectionless integrity and data origin
authentication for IP datagrams and provides protection against replay attacks.
Encapsulating
Security Payloads (ESP) provide confidentiality, data-origin
authentication, connectionless integrity, an anti-replay service (a form of
partial sequence integrity), and limited traffic-flow confidentiality.
Security Associations
(SA) provide the bundle of algorithms and data that provide the parameters
necessary to AH and/or ESP operations. The Internet Security Association and
Key Management Protocol (ISAKMP) provides a framework for authentication and
key exchange, with actual authenticated keying material provided either by
manual configuration with pre-shared keys, Internet Key Exchange (IKE and
IKEv2), Kerberized Internet Negotiation of Keys (KINK), or IPSECKEY DNS
records.
Authentication Header
(AH)
It is a member of the IPsec protocol suite. AH guarantees
connectionless integrity and data origin authentication of IP packets. Further,
it can optionally protect against replay attacks by using the sliding window
technique and discarding old packets (see below).
In IPv4, the AH protects the IP payload and all header
fields of an IP datagram except for mutable fields (i.e. those that might be
altered in transit), and also IP options such as the IP Security Option
(RFC-1108). Mutable (and therefore unauthenticated) IPv4 header fields are
DSCP/ToS, ECN, Flags, Fragment Offset, TTL and Header Checksum.
In IPv6, the AH protects most of the IPv6 base header, AH
itself, non-mutable extension headers after the AH, and the IP payload.
Protection for the IPv6 header excludes the mutable fields: DSCP, ECN, Flow
Label, and Hop Limit.
AH operates directly on top of IP, using IP protocol number
51.
The following AH packet diagram shows how an AH packet is
constructed and interpreted:
Next Header (8 bits)
Type of the next header, indicating what upper-layer
protocol was protected. The value is taken from the list of IP protocol
numbers.
Payload Len (8 bits)
The length of this Authentication Header in 4-octet units,
minus 2. For example an AH value of 4 equals 3x(32-bit fixed-length AH fields)
+ 3x(32-bit ICV fields) - 2 and thus an AH value of 4 means 24 octets. Although
the size is measured in 4-octet units, the length of this header needs to be a
multiple of 8 octets if carried in an IPv6 packet. This restriction does not
apply to an Authentication Header carried in an IPv4 packet.
Reserved (16 bits)
Reserved for future use (all zeroes until then).
Security Parameters Index (32 bits)
Arbitrary value which is used (together with the destination
IP address) to identify the security association of the receiving party.
Sequence Number (32 bits)
A monotonic strictly increasing sequence number (incremented
by 1 for every packet sent) to prevent replay attacks. When replay detection is
enabled, sequence numbers are never reused, because a new security association
must be renegotiated before an attempt to increment the sequence number beyond
its maximum value.
Integrity Check Value (multiple of 32 bits)
Variable length check value. It may contain padding to align
the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.
Encapsulating
Security Payload
Encapsulating Security Payload (ESP) is a member of the
IPsec protocol suite. In IPsec it provides origin authenticity, integrity and
confidentiality protection of packets. ESP also supports encryption-only and
authentication-only configurations, but using encryption without authentication
is strongly discouraged because it is insecure. Unlike Authentication Header
(AH), ESP in transport mode does not provide integrity and authentication for
the entire IP packet. However, in Tunnel Mode, where the entire original IP
packet is encapsulated with a new packet header added, ESP protection is
afforded to the whole inner IP packet (including the inner header) while the
outer header (including any outer IPv4 options or IPv6 extension headers)
remains unprotected. ESP operates directly on top of IP, using IP protocol
number 50.
The following ESP packet diagram shows how an ESP packet is
constructed and interpreted:
Security Parameters Index
(32 bits)
Arbitrary value used (together with the destination IP
address) to identify the security association of the receiving party.
Sequence Number (32 bits)
A monotonically increasing sequence number (incremented by 1
for every packet sent) to protect against replay attacks. There is a separate
counter kept for every security association.
Payload data (variable)
The protected contents of the original IP packet, including
any data used to protect the contents (e.g. an Initialisation Vector for the
cryptographic algorithm). The type of content that was protected is indicated
by the Next Header field.
Padding (0-255 octets)
Padding for encryption, to extend the payload data to a size
that fits the encryption's cipher block size, and to align the next field.
Pad Length (8 bits)
Size of the padding (in octets).
Next Header (8 bits)
Type of the next header. The value is taken from the list of
IP protocol numbers.
Integrity Check Value (multiple of 32 bits)
Variable length check value. It may contain padding to align
the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.
Security association
The IP security architecture uses the concept of a security
association as the basis for building security functions into IP. A security
association is simply the bundle of algorithms and parameters (such as keys)
that is being used to encrypt and authenticate a particular flow in one
direction. Therefore, in normal bi-directional traffic, the flows are secured
by a pair of security associations.
Security associations are established using the Internet
Security Association and Key Management Protocol (ISAKMP). ISAKMP is
implemented by manual configuration with pre-shared secrets, Internet Key
Exchange (IKE and IKEv2), Kerberized Internet Negotiation of Keys (KINK), and
the use of IPSECKEY DNS records. RFC 5386 defines Better-Than-Nothing Security
(BTNS) as an unauthenticated mode of IPsec using an extended IKE protocol.
In order to decide what protection is to be provided for an
outgoing packet, IPsec uses the Security Parameter Index (SPI), an index to the
security association database (SADB), along with the destination address in a
packet header, which together uniquely identify a security association for that
packet. A similar procedure is performed for an incoming packet, where IPsec
gathers decryption and verification keys from the security association
database.
For multicast, a security association is provided for the
group, and is duplicated across all authorized receivers of the group. There
may be more than one security association for a group, using different SPIs,
thereby allowing multiple levels and sets of security within a group. Indeed,
each sender can have multiple security associations, allowing authentication,
since a receiver can only know that someone knowing the keys sent the data.
Note that the relevant standard does not describe how the association is chosen
and duplicated across the group; it is assumed that a responsible party will
have made the choice.
Modes of operation
·
Transport
mode
o
In transport mode, only the payload of the IP
packet is usually encrypted and/or authenticated. The routing is intact, since
the IP header is neither modified nor encrypted; however, when the
authentication header is used, the IP addresses cannot be translated, as this
will invalidate the hash value. The transport and application layers are always
secured by hash, so they cannot be modified in any way (for example by
translating the port numbers).
o
A means to encapsulate IPsec messages for NAT
traversal has been defined by RFC documents describing the NAT-T mechanism.
·
Tunnel
mode
o
In tunnel mode, the entire IP packet is
encrypted and/or authenticated. It is then encapsulated into a new IP packet
with a new IP header. Tunnel mode is used to create virtual private networks
for network-to-network communications (e.g. between routers to link sites),
host-to-network communications (e.g. remote user access) and host-to-host
communications (e.g. private chat).
o
Tunnel mode supports NAT traversal.
Cryptographic
algorithms
Cryptographic algorithms defined for use with IPsec include:
·
HMAC-SHA1 for integrity protection and
authenticity.
·
TripleDES-CBC for confidentiality
·
AES-CBC for confidentiality.
Software
implementations
IPsec support is usually implemented in the kernel with key
management and ISAKMP/IKE negotiation carried out from user-space. The openly
specified 'PF_KEY Key Management API, Version 2' is often used to enable the
application-space key management application to update the IPsec Security
Associations stored within the kernel-space IPsec implementation.
Existing IPsec implementations usually include ESP, AH, and
IKE version 2. Existing IPsec implementations on UNIX-like operating systems,
for example Sun Solaris or Linux, usually include PF_KEY version 2.
