RFC 4301

Security Architecture for the Internet Protocol
Standards Track Obsoletes: RFC 2401
December 2005
RFC Library > IPsec & IKE > RFC 4301
Abstract: This document describes the security architecture for the Internet Protocol. IPsec provides confidentiality, data origin authentication, connectionless integrity, access control, and limited traffic flow confidentiality at the IP layer. It is the foundation of 3GPP Network Domain Security (NDS/IP) per TS 33.210.
Canonical source: https://www.rfc-editor.org/rfc/rfc4301  |  IETF Datatracker

1. Introduction

▶

IPsec provides security services at the IP layer by enabling systems to select required security protocols, determine algorithms, and manage cryptographic keys. IPsec can protect one or more paths between hosts, gateways, or a combination.

In 3GPP, IPsec is the mandatory security mechanism for Network Domain Security (NDS/IP, TS 33.210). It protects all signaling and user-plane traffic between core network nodes on the Za (between SEGs) and Zb (within an operator domain) interfaces.

2. 3GPP NDS/IP Architecture

▶
3GPP Mandate: TS 33.210 §5.2 requires ESP (RFC 4303) in tunnel mode for Za interface between SEGs. AH (RFC 4302) is NOT used in 3GPP NDS/IP.
  ┌─────────────┐     Za interface     ┌─────────────┐
│   Operator   │    (inter-domain)    │   Operator   │
│   Domain A   │                      │   Domain B   │
│              │    ┌─────┐  ┌─────┐  │              │
│  ┌────┐ Zb   │    │SEG-A│──│SEG-B│  │   Zb ┌────┐  │
│  │ NE ├──────┼────┤     │  │     ├──┼──────┤ NE │  │
│  └────┘      │    │ESP  │  │ESP  │  │      └────┘  │
│              │    │Tunnel│  │Tunnel│  │              │
│  ┌────┐ Zb   │    └─────┘  └─────┘  │   Zb ┌────┐  │
│  │ NE ├──────┼───────────────────────┼──────┤ NE │  │
│  └────┘      │                      │      └────┘  │
└─────────────┘                      └─────────────┘
NE = Network Element
SEG = Security Gateway
Zb = intra-domain IPsec
Za = inter-domain IPsec

3. Security Policy Database (SPD)

▶

The SPD determines the security treatment for all IP traffic. For each packet, the SPD specifies one of three actions:

  • SPD entries are matched by selectors: source/destination IP, protocol, ports, direction
  • 3GPP NDS/IP typically uses IP address-based selectors for SEG-to-SEG tunnels
  • SPD MUST be configured before any Security Associations are established
Action Description 3GPP Usage
PROTECT Apply IPsec (ESP/AH) Za/Zb interfaces — all NDS signaling
BYPASS Allow without IPsec Management traffic on trusted interfaces
DISCARD Drop the packet Unauthorized traffic on protected interfaces

4. Security Association Database (SAD)

▶

A Security Association (SA) is a simplex connection that provides security services. Each SA is uniquely identified by:

  • SPI (Security Parameters Index): 32-bit value in ESP/AH header, selected by the receiving end
  • Destination IP: Tunnel endpoint or host address
  • Protocol: ESP (50) or AH (51)
  • SA parameters include: sequence number counter, anti-replay window, AES-GCM/CBC keys, lifetime, mode (tunnel/transport)

5. Processing Model

▶

IPsec processing occurs at two levels:

  • Outbound: SPD lookup → find matching SA → apply ESP encapsulation → transmit
  • Inbound: Demux by SPI → SA lookup → verify/decrypt → SPD check → deliver
  • SA bundling: Multiple SAs can be applied in sequence (e.g., transport ESP inside tunnel ESP)
  • Anti-replay: Sliding window (minimum 64 packets) to detect replayed packets

6. Security Considerations

▶
  • IPsec does not protect against traffic analysis — packet sizes and timing are visible
  • Tunnel mode hides inner IP addresses but outer addresses are visible
  • Key management via IKEv2 (RFC 7296) is strongly recommended over manual keying
  • SA lifetimes should be configured to force periodic rekeying (TS 33.210 recommends time-based)