IPSec

• IPsec is a standard for the secure transmission of IP packets over insecure networks.

• There are two protocols:

  • Authentication Header (AH): Ensures the integrity/authenticity of the payload and (part of) the header data.
  • Encapsulating Security Payload (ESP): Ensures the confidentiality and/or the authenticity of the payload.

• There are two modes of operation:

  • Transport: AH or ESP directly applied to the original IP packet
  • Tunnel: Original IP packet is put into new IP packet which is then protected.

• Often used for:

  • Site-to-Site VPN connections, e.g. corporate networks
  • Remote Access VPN

• IKEv2 for key exchange and authentication

  • Security Associations contain information necessary to do IPsec communication
  • IKEv2 supports NAT-T

• IPsec is a collection of protocols that allow secure communication over IP networks:

  • RFC 4301 Security Architecture for the Internet Protocol
    • Defines basic architecture and requirements for IPsec gateways.
    • In particular: Security Associations Management
      • e.g. “MUST support ESP”
      • e.g. “MAY support AH”
  • RFC 4302 Authentication Header (AH)
    • Protocol to protect the integrity/authenticity of both payload and header data
  • RFC 4303 Encapsulating Security Payload (ESP)
    • Protocol to protect the confidentiality and integrity/authenticity of payload data
  • RFC 7296 Internet Key Exchange v2 (IKEv2)
    • Protocol for manual and automated key exchange
    • Relevant for creating Security Associations used in AH and ESP
  • RFC 4308 Crypto Suites for IPsec
  • RFC 4309 Using AES CCM with IPsec ESP
  • RFC 4106 Use of GCM in IPsec ESP
  • RFC 8247 Algorithm Implementation Requirements and Usage Guidance for IKEv2
  • RFC 8221 Cryptographic Algorithm Implementation Requirements and Usage Guidance for ESP and AH
  • …

• NIST Guide to IPsec VPNs: https://doi.org/10.6028/NIST.SP.800-77r1

Authentication Header (AH)

• Protects the integrity/authenticity of
  • the payload
  • and parts of the IP Header:
    • 
• Protocol Field in the IP header: 0x33
• Provides (optional) replay protection
• Does NOT provide confidentiality

Authentication Header:

• Next Header: ID of the protocol of the payload
  • e.g., TCP or UDP
• RESERVED: “zero”
• SPI: Identifies the Security Association (SA)
  • SA defines security attributes
    • Authentication algorithms
    • Keys
• Sequence Number: for replay protection
• ICV: Integrity Check Value
  • e.g. HMAC_SHA2_512_256

Replay Protection

• The sender increments the sequence number by one for every packet sent.
• The receiver stores the highest sequence number received so far.
  • Too old or already received packets are rejected
  • “Too old” is defined via the anti-replay window (default: 64)
    • ⇒ Keep the newest (and thus highest) 64 sequence numbers
• The sequence number
  • is tracked per security association (SA)
  • is a 32-bit value
    • max $2^{32}-1$ packets can be sent per SA
    • Periodically a new SA is built
• Extended Sequence Numbering
  • 64-bit values
  • Used for high-speed connections (>100 Gbps)

Encapsulating Security Payload (ESP)

• Provides
  • Confidentiality and authenticity of the payload
    • Authenticity (via ICV) is optional (but recommended!)
  • Optional replay protection
• The IP header is NOT protected
• Protocol Field in the IP header: 0x34

• ESP-Header:
  • 
  • Sequence Number is for replay protection
• ESP-Trailer + ESP-ICV:
  • 

Modes of Operation

Both AH and ESP have two modes of operation:

• Transport Mode: Protects IP packets directly
• Tunnel Mode: IP packets are packed into a new IP packet (as payload) which is then protected

Transport Mode

• The IP traffic is intended for the IPsec endpoints
• End-to-end security, but transparent for applications
• ESP: secure channel
• AH: authentic channel

Tunnel Mode

Site-to-Site VPN

• Tunnel between two IPsec gateways
• Transparent for endpoints. Independent of application
• Internal IP addresses remain confidential
• VPN tunnel between corporate networks

Client-to-Site VPN

• Tunnel between an IPsec client and an IPsec gateway
• Internal IP addresses remain confidential
• Remote access to corporate network

Security Associations

• For IPsec communication the peers need to share information on
  • Cipher Suite, Key Length, Keys, …
  • Protocol: AH or ESP
  • Mode (Transport or Tunnel)
  • Sequence number counter
  • Validity period of security associations
• This information is stored in a security association (SA):
  • Identified by a Security Parameters Index (SPI)
  • Separate SAs for each communication direction, i.e. one per sender
  • Separate SAs for AH and ESP

SAD and SPD (Nominal mOdel)

• Security Policy Database (SPD): decides how to handle an IP packet:
  • Decision: Discard, Bypass, Protect
  • based on selectors: IP addresses, Next Layer Protocol, …
• Security Association Database (SAD): holds all the security associations
  • Incoming packets: SPI and possibly IP address point to SAD entry
  • Outgoing packets: SPD entry points to SA

Handling of Outbound and Inbound Packets

Processing Model for Outbound Packets:

Processing Model for Inbound Packets:

Host SPD Example:

Source: “Network Security Essentials by William Stallings”

Internet Key Exchange V2 (IKEv2)

• Internet Key Exchange (RFC 7296)

• Protocol for mutual authentication (⇒ authenticates both peers) and building of security associations

  • Between an Initiator and a Responder
  • Goal: Initiator and Responder each have
    • a security association for IKE transport (IKE-SA)
    • security associations for ESP or AH traffic (CHILD-SA)

• Establishes an IKE-SA including key material which allows establishing SAs for AH or ESP.

• Communication consists of request-response message pairs.

  • The first two messages (IKE_SA_INIT)
    • negotiate the security parameters
    • do a DH key exchange
  • The second pair of messages (IKE_AUTH)
    • verifies the identities
    • establishes a first CHILD_SA

• The peers announce their IP addresses (via traffic selectors)

• Messages are transmitted over UDP (port 500)

Phases

Initial Exchanges

In the IKE_AUTH messages:

• The identity of peers is verified by means of
  • Signatures
    • Certificates are sent in the messages
  • Symmetric MAC if using a pre-shared-key
• The authenticity of the IKE_INIT messages is verified as well
• Instead of AUTH one can use Extensible Authentication (EAP)
  • Initiator omits the AUTH field to indicate this mode
  • Normally used to authenticate an initiator
  • Uses an additional exchange IKE_AUTH messages

Child SA Exchange

• Either:
  • New Child-SA
  • Rekeying of a Child-SA
  • Rekeying of the IKE-SA
• Based on existing key material, optionally rekeying using DH

INFORMATIONAL

• Control messages, e.g. error messages, event notification
• Deletion of SAs

Key Derivation

• IKEv2 uses a PRF (pseudorandom function) to derive key material
  • PRF depends on cipher suite
    • e.g. AES-CMAC
• Inputs to the PRF comes from
  • Existing key material
  • Nonce
  • DH key exchange (ephemeral key)

Key Material

Algorithms

• IPsec use various cryptographic algorithms (in IKEv2 negotiated (SAs)).
• RFC 8247 specifies “mandatory-to-implement” algorithms für IKEv2
• RFC 8221 specifies algorithms for AH and
• Various RFCs defines cipher suites with the goal of interoperability and a certain level of security
  • RFC 4308: Cryptographic Suites for IPsec (2005)
    • VPN-A - commonly used
    • VPN-B - expected
  • RFC 6379: (NSA) Suite B Cryptographic Suites for IPsec (2011)
• Technische Richtlinie TR-02102-3 (BSI)
• NIST SP

Logjam

https://weakdh.org

• Attack on DH key exchange (MitM)
  • Many systems use the same primes (aka integer groups) to do DH.
    • Attacker can do some pre-computation to speed up computation of discrete logarithms in a fixed group.
  • 2015 estimate: Precomputation cost for 1024bit DH group: ~100M $
• Problem for protocols such as IKE
  • Solution: Use larger integer groups or elliptic curves.

IPsec & NAT

• Scenario: Client-to-Site VPN
  • E.g. from home or from a hotel
  • Client has no public IP, is behind a NAT

NAT Variants

• One-to-one NAT. The NAT:
  • replaces source address with its public address
  • only works with one client
• Port Address Translation (PAT). The NAT:
  • replaces source address with its public address
  • Replaces (UDP/TCP) source port with unique free port
  • Relays incoming packets to the right client based on the port number.

NAT Problems with IPsec

• Problems with ESP
  • PAT: The payload (UDP/TCP) is encrypted and cannot be changed by the NAT
  • One-to-One NAT: TCP (and UDP in IPv6) has checksums that break when swapping out IP
• AH incompatible as IP addresses are authenticated
• Problems with IKE
  • Using IP addresses as an identifier (IKEv1) causes issues.
  • IKE responder needs to accept packets from a non 500 port.
• And more (RFC 3715)

Solution: NAT-T

• RFC 3948: UDP-Encapsulation of IPsec ESP Packets
  • 
  • UDP-Header between IP-Header and ESP-Header
  • Source und destination port: 4500
• IKEv2 (RFC 4306) can (implementation optional)
  • 
  • Detect NAT (NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP in INIT-msg)
  • Negotiate UDP-Encapsulation for IKE and ESP
  • Source und dst. port: 4500, reply to arbitrary port

Other VPN Protocols

• SSL VPN
  • Based on TLS
    • Port 443 ⇒ less blocked
  • Often implemented as application
    • e.g. OpenVPN
  • Mainly used for remote access
• WireGuard
  • New, written for the Linux kernel
  • Minimalist implementation
  • Less complexity & less flexibility
• Secure Socket Tunneling Protocol (SSTP)
  • Microsoft’s implementation of SSL VPN
• L2TP (Layer 2 Tunneling Protocol)
  • L2 via L3 networks
  • Offers no security on its own
    • ⇒ combine it with IPsec
• PPTP (Point to Point Transport Protocol)
  • Generic Routing Encapsulation
  • unsafe crypto algorithms

---

Relevant Note(s):