LTE689 – LTE IPSec Support Main Menu

Table of Contents

Introduction
1 Motivation and Feature Overview

Technical Details
2 Functionality and Implementation, Message Flows

Configuration Management
3 Parameters

Deployment Aspects
4 Feature Activation and Configuration Examples

NEI Contact: Dominik Dulas, Roman Arcea

For internal use

9 © Nokia Siemens Networks 2012 MBB CS Network Engineering / Author / Date
 IPSec Basics 1/4 Table of Contents Main Menu
LTE689 – LTE IPSec Support

• IPSec is L3 layer security architecture, defined by IETF.

• Fundamental components of IPSec (RFC 4301):

– Security protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP),
– Security Associations,
– Key management, manual and automatic, Internet Key Exchange (IKE),
– Mathematical algorithms for authentication and encryption.

• Hence, the term “IPSec” does not refer to a single protocol, but a set of protocols  about ~20 IETF RFCs on
IPSec currently.

• Security protocol:
– Authentication Header (AH), not in RL10/RL20. AH has no encryption, only authentication.
– Encapsulating Security Payload (ESP), encrypts and authenticates.
– ESP adds a new header.
– ESP implemented in RL10/RL20.

For internal use

10 © Nokia Siemens Networks 2012
 IPSec Basics 2/4 Table of Contents Main Menu
LTE689 – LTE IPSec Support

• Two operation modes: Transport and Tunnel

– Transport mode:
 Transport mode encrypts the payload of the IP packet only. AH can be used.
 Transport mode not suitable for site-to-site VPN (note: eNB – security gateway tunnel is site-to-site VPN).
 Transport mode not recommended by 3GPP.
– Tunnel mode:
 The whole IP packet is encapsulated and encrypted.
 A new IP header is added.
 Used to create VPN.
 Implemented in RL10/RL20.

• Key management
– Internet Key Exchange (IKE) is a set of protocols used by IPSec to create a Secure Association (SA) between two ends.
– Two versions: IKEv1 and IKEv2.
– IKEv2 supports SCTP.
– IKEv2 recommended by 3GPP, but not supported by all IPSec implementations.
–  both IKEv1 and IKEv2 implemented in RL10/RL20.

For internal use

11 © Nokia Siemens Networks 2012
 IPSec Basics 3/4 Table of Contents Main Menu
Supported IPSec functionality in LTE RL10 & RL20 (1/2)

 LTE RL10 and RL20 implement a subset of the full IPSec protocol suite:
Data encryption and integrity protection, origin authentication and anti-
Services:
replay protection

ESP (RFC 4303)

Protocol:
Tunnel mode (RFC 4301)

AES-128-CBC (RFC 3602)

Encryption/Ciphering: : 3DES-192-CBC (RFC 2405)
NULL (RFC 2410)

Modes: CBC, random chosen IV CBC, random chosen IV

Integrity: HMAC-SHA-1-96 (RFC 2404)

Identification: IP addresses and Fully Qualified Domain Names (FQDN)

Authentication: Digital certificates in X.509v3 format

Key exchange: dual stack IKEv1 (RFC 2409) / IKEv2 (RFC 4306)

Diffie-Hellman key exchange: Group 2 (1024-bit MODP)

For internal use

12 © Nokia Siemens Networks 2012
 IPSec Basics 4/4 Table of Contents Main Menu
Supported IPSec functionality in LTE RL10 & RL20 (2/2)

 LTE RL10 and RL20 implement a subset of the full IPSec protocol suite:

IKE SA life time 24 hours (fixed)

5 Minutes/300 sec up 24 hours/86400 sec

IPSec child SA life time
common to all child SA

Negotiation starts with IKEv2

IKE version probing during autoconnection:
fall-back to IKEv1

IPSec set-up initiation By eNB during Network Integration (start-up)

Dead peer detection For IKE v1 and IKEv2 (inherent)

For internal use

13 © Nokia Siemens Networks 2012
 LTE689 – LTE IPSec Support Main Menu

Table of Contents

Introduction
1 Motivation and Feature Overview

Technical Details
2 Functionality and Implementation, Message Flows

Configuration Management
3 Parameters

Deployment Aspects
4 Feature Activation and Configuration Examples

NEI Contact: Dominik Dulas, Roman Arcea

For internal use

14 © Nokia Siemens Networks 2012 MBB CS Network Engineering / Author / Date
 IPSec components: ESP tunnel mode Table of Contents Main Menu
LTE689 – LTE IPSec Support

• tunnel mode encapsulates and protects the entire source IP packet,

• Payload + padding ciphered. Payload + padding + ESP header optionally authenticated.

ESP protocol id = 50dec

RL10/RL20 supports 3DES

and AES-128 block ciphers

Padding needed for

block ciphers (variable
length)

For internal use

15 © Nokia Siemens Networks 2012
 IPSec components: Security Policy and Security Association Table of Contents Main Menu
LTE689 – LTE IPSec Support

• A security policy defines:

– which traffic flow to protect, by defining a packet filter, also called ”traffic selector”,
– what are the allowed security algorithms to protect the traffic flow.

• IPSec Security Association (IPSec SA)

– the security algorithms actually used to protect a given traffic flow,
– SA is negotiated by IKE at SA establishment, SA depends on peer SEG capability,
– SA security algorithms must be a subset of those allowed by the security policy.

NOTE: in addition to IPSec SA described above, there exist also another kind of SA, called IKE SA, that
is used in initial connection establishment between IPSec peers (see following slides).

For internal use

16 © Nokia Siemens Networks 2012
 IPSec components: Ciphering Algorithms Table of Contents Main Menu
LTE689 – LTE IPSec Support

• In general, there are two classes of ciphering algorithms:

– Asymmetric cipher, different key for encrypting and decrypting ( a pair of keys needed per transfer
direction),
– Symmetric cipher, the same key for encrypting and decrypting ( one key needed per transfer
direction).

• Symmetric vs asymmetric ciphers:

– Symmetric ciphers are computationally fast (”~10-100 faster than asymmetric”).
– Asymmetric cipher per transfer direction consists of secret key and public key. Public key can be
shown to everyone, eg posted to internet or e-mailed.
– Symmetric cipher has only one secret key. Nobody except sender and receiver should see this key.

• IPSec security protocols typically use symmetric ciphers for protecting user data (example: AES-CBC-
128).

For internal use

17 © Nokia Siemens Networks 2012
 IPSec components: IKE Table of Contents Main Menu
LTE689 – LTE IPSec Support

• Symmetric ciphers use a key to encrypting and decrypting. There should be a mechanism to
exchange that key between the ends.

• Internet Security Association and Key Managemement Protocol (ISAKMP) is one of those
protocols.

• Internet Key Exchange protocol in itself is (again!) a set of protocols instead of a single protocol
• With the help of ISAKMP, IPSec uses the best of both symmetricities:
– Using asymmetric ciphering for ISAKMP establishes secure connection between IPSec peers
– The security association of this connection is called IKE SA
– Secret keys for symmetric ciphering can be distributed over this secure connection
– Using symmetric keys for protecting user data flows  more efficient
• IKE has two versions: IKEv1 and IKEv2
– IKEv2 recommended by 3GPP

For internal use

18 © Nokia Siemens Networks 2012
 IKEv2 Signaling, IKE SA and IPSec SA setup Table of Contents Main Menu
LTE689 – LTE IPSec Support

SEG #1 SEG #2
”inititator” ”receiver”
IKE_SA_INIT request (plain text) • IKE SA SPI used by SEG#1
• Supported security algorithms for IKE
• Almost identical format to SA
IKE_SA_INIT request, except: • DH key exchange data
• includes also IKE SA SPI for SEG#2 • Nonce payload
• Certificate Request • Notification fields (optional)
IKE_SA_INIT response (plain text)

SEG #2 selects
security algorithms for
IKE SA

IKE_AUTH request (encrypted)

Creates CHILD SA:

Identical format to IKE_AUTH
request (except ”initiator” changed
to ”receiver”)
IKE_AUTH response (encrypted)
• Child SA initiator ID
• Child SA initiator certificate
• Child SA receiver ID
• Child SA initiator authentication
• Child SA initiator traffic selector
• Child SA receiver traffic selector

For internal use

19 © Nokia Siemens Networks 2012
 IPSec in E-UTRAN transport Table of Contents Main Menu
LTE689 – LTE IPSec Support

UE eUu eNB S1 MME eNB eNB

MME

NAS Signaling
(ciphered & integrity protected using NAS signaling security)

S1-AP signaling X2-AP signaling

C-plane RRC signaling
(ciphered and integrity protected)
S1-AP signaling
(ciphered and integrity protected (ciphered and integrity protected
with IPSec - optional) with IPSec - optional)

SAE-GW
S1 U
U-plane U-plane data
U-plane data U-plane data
(ciphered and integrity protected packets forwarded over X2
(ciphered) with IPSec-optional) ciphered and integrity
protected with IPSec - optional)

O&M EMS/
M-plane
NMS
M-plane data AKA/Subscriber Security
(ciphered and integrity protected
with IPSec & TLS - optional) Transport Security
NOTE: S-plane security not specified by 3GPP

For internal use

20 © Nokia Siemens Networks 2012 LTE Sys.PM – R.Kausl 2010
 LTE: 3GPP Recommendations (Transport Security) Table of Contents Main Menu
LTE689 – LTE IPSec Support

• TS 33.210 – Network Domain Security/IP Network Layer Security

– IPSec in tunnel mode between Security Gateways
– IPSec profile and configuration

• TS 33.401 – Security Architecture

– IPSec*) for
 S1-MME & X2 Control plane
 S1 & X2 User plane
 Management plane
– Tunnel mode
– IKEv2
– Authentication by Public Certificates

• TS 33.310 – Authentication Framework

– specifies rules for Cross Certification between operators

*) for un-trusted networks

For internal use
21 © Nokia Siemens Networks 2012 LTE Sys.PM – R.Kausl 2010