IPsec

IPsec (abbreviation for Internet Protocol security) is a set of protocols whose function is to secure communications over the Internet Protocol (IP) by authenticating and/or encrypting each IP packet in a data stream. IPsec also includes protocols for establishing encryption keys.

Summary

IPsec protocols operate at the network layer, layer 3 of the OSI model. Other widely used Internet security protocols, such as SSL, TLS and SSH operate at the application layer (layer 7 of the OSI model). This makes IPsec more flexible, as it can be used to secure Layer 4 protocols, including TCP and UDP.

Security architecture

IPsec is implemented by a set of cryptographic protocols to:

1. ensure the flow of packages,
2. ensure mutual authentication,
3. establish cryptographic parameters.

The IP security architecture uses the concept of security association (SA) as a basis for building security functions in IP. A security association is simply the package of algorithms and parameters (such as keys) that are being used to encrypt and authenticate a particular flow in one direction. Therefore, in normal two-way traffic, flows are secured by a pair of security associations. The final decision on encryption and authentication algorithms (from a defined list) rests with the IPsec administrator.

To decide what protection to provide for an outgoing packet, IPsec uses the security parameter index (SPI), an index to the security association database (SADB), along with the destination address of the packet. the packet header, which together uniquely identify a security association for that packet. A similar procedure is performed for an incoming packet; In this case IPsec takes the verification and decryption keys from the security association database.

In the case of multicast, a security association is provided to the group, and is duplicated for all authorized receivers in the group. There can be more than one security association for a group, using different SPIs, and thus allowing multiple levels and sets of security within a group. In fact, each sender can have multiple security associations, allowing authentication, since a receiver can only know that someone who knows the keys has sent the data. It should be noted that the relevant standard does not describe how the association is chosen and duplicated across the group; It is assumed that a responsible interested party will have made the choice.

Current status of the standard

IPsec was a mandatory part of IPv6 based on the definition of RFC 4294, however, in 2011, this RFC was obsolete by RFC 6434 which indicates that IPsec is recommended and not mandatory for IPv6. For IPv4, its use is optional. Although the standard is designed to be indifferent to IP versions, the deployment and experience until 2007 concerns IPv4 implementations.

The IPsec protocols were originally defined in RFCs 1825 and 1829, published in 1995. In 1998 these documents were replaced by RFCs 2401 and 2412, which are not compatible with 1825 and 1829, although they are conceptually identical. In December 2005 the third generation of documents was produced, RFCs 4301 and 4309. They are largely a superset of 2401 and 2412, but provide a second Internet Key Exchange standard. This third generation of documents standardized the IPsec abbreviation as "IP" in capital letters and "sec" lowercase.

It is rare to see a product that offers support for RFC1825 and 1829. "ESP" generally refers to 2406, while ESPbis refers to 4303.

Design Purpose

IPsec was designed to provide transport mode (end-to-end) security of packet traffic, in which end-end computers perform security processing, or in tunnel(door-to-door) in which packet traffic security is provided to multiple machines (even the entire local area network) by a single node.

IPsec can be used to create VPNs in both modes, and this is its main use. It should be noted, however, that the security implications are quite different between the two modes of operation.

End-to-end communications security at Internet scale has developed more slowly than expected. Part of the reason for this is that no universally or universally trusted public key infrastructure has emerged (DNSSEC was originally intended for this); Another part is that many users do not understand their needs or the available options well enough to promote their inclusion in sellers' products.

As the Internet Protocol does not inherently provide any security capabilities, IPsec was introduced to provide security services such as:

1. Figure traffic (so that it cannot be read by anyone but the parties to which it is directed)
2. Validation of integrity (insure that traffic has not been modified throughout your journey)
3. Authentic the extremes (secure that traffic comes from a confidence end)
4. Anti-repetition (protecting against repetition of the safe session).

Modes

Thus, and depending on the level on which we act, we can establish two basic modes of IPsec operation: transport mode and tunnel mode.

Transport mode

In transport mode, only the payload (the data being transferred) of the IP packet is encrypted or authenticated. The routing remains intact, as the IP header is not modified or encrypted; However, when the authentication header (AH) is used, IP addresses cannot be translated, as that would invalidate the hash. The transport and application layers are always secured by a hash, so they cannot be modified in any way (for example by translating TCP and UDP port numbers). Transport mode is used for computer-to-computer communications.

A way to encapsulate IPsec messages to traverse NAT has been defined by RFCs that describe the NAT traversal mechanism.

Tunnel mode

In tunnel mode, the entire IP packet (data plus message headers) is encrypted or authenticated. It must then be encapsulated in a new IP packet for routing to work. Tunnel mode is used for network-to-network communications (secure tunnels between routers, e.g. for VPNs) or computer-to-network or computer-to-computer communications over the Internet.

Protocols

IPsec consists of three protocols that have been developed to provide packet-level security for both IPv4 and IPv6:

• Authentication Header (AH) provides integrity, authentication and not repudiation if appropriate cryptographic algorithms are chosen.
• Encapsulating Security Payload (ESP) provides confidentiality and the highly recommended option of authentication and integrity protection.
• Internet key exchange (IKE) uses a secret exchange of Diffie-Hellman type keys to establish the shared secret of the session. Public Key Criptography systems or pre-shared key systems are often used.

Cryptographic algorithms defined for use with IPsec include HMAC-SHA-1 for integrity protection, and Triple DES-CBC and AES-CBC for confidentiality. More details in RFC 4305.

Authentication Header (AH)

AH is aimed at ensuring integrity, connectionless and source data authentication of IP datagrams. To do this, it calculates a Hash Message Authentication Code (HMAC) through some hash algorithm operating on a secret key, the content of the IP packet and the immutable parts of the datagram. This process restricts the possibility of using NAT, which can be implemented with NAT traversal. On the other hand, AH can optionally protect against replay attacks by using the sliding window technique and discarding old packets. AH protects the IP payload and all fields in the header of an IP datagram except the mutating fields, that is, those that can be altered in transit. In IPv4, mutated (and therefore unauthenticated) IP header fields include TOS, Flags, Fragment Offset, TTL, and header checksum. AH operates directly above IP, using IP protocol number 51. An AH header measures 32 bits, here is a diagram of how they are organized:

Meaning of the fields:

Next header

Identify the data protocol transferred.

Payload length

AH package size.

RESERVED

Reserved for future use (until then all zeros).

Security parameters index (SPI)

Indicates the security parameters that, in combination with the IP address, identify the security association implemented with this package.

Sequence number

An ever-growing number, used to prevent repeat attacks.

HMAC

It contains the integrity verification value (ICV) necessary to authenticate the package; it may contain filling.

Encapsulating Security Payload (ESP)

The ESP protocol provides origin authenticity, integrity, and confidentiality protection of a packet. ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is highly discouraged because it is insecure. . Unlike with AH, the IP packet header is not protected by ESP (although in ESP in tunnel mode, protection is provided to the entire internal IP packet, including the internal header; the external header remains unprotected). ESP operates directly over IP, using IP protocol number 50.

An ESP package diagram:

Meaning of the fields

Security parameters index (SPI)

Identify the security parameters in combination with the IP address.

Sequence number

An ever-growing number, used to prevent repeat attacks.

Payload data

Data to transfer.

Padding

Used by some cryptographic algorithms to complete the blocks.

Pad length

Size of the filling in bytes.

Next header

Identify the data protocol transferred.

Authentication data

It contains the data used to authenticate the package.

Implementations

IPsec support is typically implemented in the kernel with key management and ISAKMP/IKE negotiation performed in user space. Existing IPsec implementations typically include both capabilities. However, because there is a standard interface for key management, it is possible to control a core IPsec stack using key management tools from a different implementation.

For this reason, there is confusion about the origins of the IPsec implementation found in the Linux kernel. The FreeS/WAN project made the first complete, open source implementation of IPsec for Linux. It consists of a KLIPS core IPsec stack, along with a daemon (pluto) and many shell scripts. The FreeS/WAN project was dismantled in March 2004. Openswan and strongSwan are continuations of FreeS/WAN. The KAME project also implemented full IPsec support for NetBSD and FreeBSD. Its key management daemon is called racoon. OpenBSD made its own ISAKMP/IKE daemon, called simply isakmpd (and it has been ported to other systems, including Linux).

However, none of these core IPsec stacks were integrated into Linux. Alexey Kuznetsov and David S. Miller wrote a core IPsec implementation for Linux from scratch around late 2002. This stack was later released as part of Linux 2.6, and is called by many "native"or " #34;NETKEY".

Therefore, contrary to popular belief, the Linux IPsec stack did not originate from the KAME project. Because it supports the standard PF KEY protocol (RFC 2367) and the native XFRM interface for key management, the Linux IPsec stack can be used in conjunction with Openswan/strongSwan's pluto, isakmpd. > from the OpenBSD project, racoon from the KAME project or without any ISAKMP/IKE daemon (using manual keys).

New network processor architectures, including multicore processors with integrated encryption engines, have changed the way IPsec stacks are designed. A dedicated Fast Path is used to offload processing of IPsec tasks (SA, SP lookups, encryption, etc.). These Fast Path stacks must be co-integrated into dedicated cores with Linux or RTOS running on other cores. These OSs are the control plane that runs ISAKMP/IKE of the IPsec Fast Path stack.

There are quite a few implementations of the IPsec and ISAKMP/IKE protocols. Among other:

• 6WINDGate, Fast Path IPsec stack for multi-core network processor
• NRL [1] Archived on 8 August 2007 at Wayback Machine. IPsec, one of the original sources of IPsec code [2]
• OpenBSD, with its own code derived from NRL IPsec
• The KAME stack, which is included in Mac OS X, NetBSD and FreeBSD
• "IPsec" in Cisco IOS software [3]
• "IPsec" in Microsoft Windows, including Windows XP[4] [5], Windows 2000[6], and Windows 2003[7]
• SafeNet QuickSec Tools [8]
• IPsec in Solaris [9]
• IBM's AIX operating system
• IBM z/OS
• IPsec and IKE in HP-UX (HP-UX IPSec)
• "IPsec and IKE" in VxWorks [10] (breakable link available on the Internet Archive; see history, first version and last).

List of RFCs related to IPsec

• RFC 2327: PF_KEY Interface
• RFC 2367: PF_KEY Interface
• RFC 2401 (replaces RFC 1825 and was replaced by RFC 4301): Security Architecture for the Internet Protocol
• RFC 2402 (substituted by RFC 4302 and RFC 4305): Authentication Header
• RFC 2403: The Use of HMAC-MD5-96 within ESP and AH
• RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH
• RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV
• RFC 2406 (replaced by RFC 4303 and RFC 4305): Encapsulating Security Payload
• RFC 2407 (substituted by RFC 4306): IPsec Domain of Interpretation for ISAKMP (IPsec DoI)
• RFC 2408 (replaced by RFC 4306): Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 2409 (substituted by RFC 4306): Internet Key Exchange (IKE)
• RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec
• RFC 2411: IP Security Document Roadmap
• RFC 2412: (replaces RFC 1829) The OAKLEY Key Determination Protocol
• RFC 2451: The ESP CBC-Mode Cipher Algorithms
• RFC 2857: The Use of HMAC-RIPEMD-160-96 within ESP and AH
• RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
• RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
• RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements
• RFC 3947: Negotiation of NAT-Traversal in the IKE
• RFC 3948: UDP Encapsulation of IPsec ESP Packets
• RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
• RFC 4301 (replaces RFC 2401): Security Architecture for the Internet Protocol
• RFC 4302 (replaces RFC 2402): IP Authentication Header
• RFC 4303 (replaces RFC 2406): IP Encapsulating Security Payload (ESP)
• RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 4305 (substituted by RFC 4835): Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
• RFC 4306 (replaces RFC 2407, RFC 2408, and RFC 2409): Internet Key Exchange (IKEv2) Protocol
• RFC 4307: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
• RFC 4308: Cryptographic Suites for IPsec
• RFC 4309: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
• RFC 4478: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
• RFC 4543: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
• RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)
• RFC 4621: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
• RFC 4718: IKEv2 Clarifications and Implementation Guidelines
• RFC 4806: Online Certificate Status Protocol (OCSP) Extensions to IKEv2
• RFC 4809: Requirements for an IPsec Certificate Management Profile
• RFC 4835 (replaces RFC 4305): Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
• RFC 4945: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX